ISO-8859-3（Latin-3）とは？ 南欧向け8ビットエンコーディングの歴史と現代のUTF-8移行ガイド
エバープレイ編集部ISO-8859-3（Latin‑3）とは — 概要
ISO-8859-3（別名 Latin‑3、South European）は、ISO/IEC 8859 シリーズの一部として定められた 8 ビット単一バイト文字エンコーディングの一つで、主にマルタ語やエスペラントなどラテン系で Latin‑1（ISO‑8859‑1）や Latin‑2（ISO‑8859‑2）で十分に扱えない文字を必要とする言語に対応するために作られました。正式名称は ISO/IEC 8859‑3:1988 で、1988 年に標準化されています。
設計目的と対象言語
ISO-8859 シリーズは地域ごと、あるいは言語グループごとにラテン文字の拡張を行うために分割されており、ISO‑8859‑3 は「South European（南欧）」向けと位置づけられていました。特に次のような言語で使われる追加文字を含むことが主目的です。
- マルタ語（Maltese）— マルタ語特有の子音記号や点付き文字を含む。
- エスペラント（Esperanto）— ĉ, ĝ, ĥ, ĵ, ŝ, ŭ といったアクセント付き文字を扱う。
- その他、南欧の少数言語や補助的な用途
ただし、トルコ語の本格的サポートは Latin‑5（ISO‑8859‑9）で行われており、トルコ語は ISO‑8859‑3 の主要な対象ではありません。
技術的特徴
ISO‑8859‑3 は 8 ビット（1 バイト）で 256 コードポイント（0x00–0xFF）を扱い、0x00–0x7F は ASCII と一致させ、0xA0–0xFF の領域に追加の印字可能文字（ラテン拡張）を割り当てています。制御文字領域（0x00–0x1F, 0x7F, 0x80–0x9F）は従来の C0/C1 に準じます。
実装上は「単一バイトで扱える」ことによりメモリや処理が軽く、1980〜90 年代の組込み機器や電子メール、古いUNIX系ロケールなどで使いやすいという利点がありました。
名前と登録情報（MIME/IANA 等）
- MIME/HTTP 等で使う標準的な文字セット名は "ISO-8859-3"（大文字小文字は区別されない）です。
- ISO 規格名は ISO/IEC 8859‑3:1988。
- Unicode 側には ISO‑8859‑3 から Unicode へのマッピング表が用意されており、変換ルールは確立されています（後述の参考リンク参照）。
代表的な文字と Latin‑1 との違い
ISO‑8859‑1（Latin‑1）は西欧主要言語の多くを扱いますが、マルタ語やエスペラントの一部文字は含まれていません。ISO‑8859‑3 ではそうした文字（たとえばエスペラントの ĉ, ĝ, ĥ, ĵ, ŝ, ŭ やマルタ語の特殊文字）が 0xA0 以降の位置に割り当てられています。具体的なコード位置は実際のマッピング表（公式の MAPPINGS ファイル等）を参照してください。
注意点として、各 ISO‑8859 の派生は 8 ビット空間を共有するため、ある文字が Latin‑1 の特定コードにある場合、Latin‑3 では別の字が割り当てられていることがあり、それによりバイナリでの互換性はありません。つまり文字列のバイト列だけを見てエンコーディングを誤ると誤表示が生じます。
利用例と歴史的経緯
ISO‑8859‑3 は 1990 年代にかけて、マルチバイト Unicode が普及する以前の電子メール、WWW（初期の HTML 文書）、組込み機器、古いワープロ・DTP 環境などで採用されることがありました。特にマルタ語やエスペラントの文書を扱う場合、Unicode が普及するまでは有用な選択肢でした。
しかし 2000 年代以降、UTF‑8 を含む Unicode の普及が進み、1 つの符号系でほぼすべての言語を表現できるようになったため、ISO‑8859‑3 のような地域別の 8 ビットエンコーディングは徐々に使われなくなりました。現在ではレガシーなデータや古いシステムとの互換性のために残っているケースが主です。
実務上の取り扱い（Web/WordPress 等）
WordPress やモダンな Web 環境で新規にコンテンツを作成する場合、推奨は UTF‑8（UTF‑8‑with‑BOM は一般に非推奨）です。理由は次の通りです。
- Unicode はあらゆる言語の文字を一貫して扱えるため、プラグインやテーマ、外部データとのやり取りで文字化けが起きにくい。
- 多言語サイトや将来の拡張を考えると 1 つの統一エンコーディングが便利。
ただし、既存のレガシーデータベースやファイルが ISO‑8859‑3 で保存されている場合は、正確に UTF‑8 に変換する必要があります。PHP では iconv や mb_convert_encoding、Linux では iconv コマンドや uconv（ICU）などで変換できます。例：
- PHP: mb_convert_encoding($text, 'UTF-8', 'ISO-8859-3')
- iconv コマンド: iconv -f ISO-8859-3 -t UTF-8 infile > outfile
WordPress に取り込む際は、データベースの文字セット（通常は utf8mb4）に合わせて文字列を UTF‑8 に変換し、投稿本文やタイトルが正しく表示されることを確認してください。変換の際はダブルエンコーディング（二重変換）や誤ったエンコーディング指定による文字化けに注意します。
よくあるトラブルと対処法
- 文字化け（ mojibake ）：元データのエンコーディングが不明な場合は、バイト列を調査して可能性のあるエンコーディングを当てはめ、試験変換する。エスペラントやマルタ語の特有文字が正しく出るかを確認する。
- 混在データ：同じプロジェクト内で複数のエンコーディングが混在していると厄介。可能なら一括で UTF‑8 に統一する。
- HTTP ヘッダ／HTML meta：レスポンスヘッダや HTML の meta charset が実際のバイト列と一致しているか必ず確認する（例: Content-Type: text/html; charset=ISO-8859-3）。ブラウザ側で自動検出に頼るのは避ける。
現状と推奨
ISO‑8859‑3 は歴史的、互換性の観点で重要な役割を果たしてきましたが、現在の Web やアプリ開発においては UTF‑8 の採用が事実上の標準です。レガシーデータを扱う場合は、変換前に文字セットを特定し、適切なマッピング表とツールで UTF‑8 に移行することをおすすめします。移行後は、HTML や HTTP ヘッダ、データベース接続で一貫して UTF‑8 を使用することにより将来の問題を防げます。
まとめ
ISO‑8859‑3（Latin‑3）は、マルタ語やエスペラントなど特定言語を対象にした 8 ビットラテン拡張コードページで、1988 年に標準化されました。Unicode の普及により使用頻度は下がりましたが、レガシーシステムや古い文書の互換性確保のために知識として押さえておく価値があります。実務では可能な限り UTF‑8 に統一し、既存の ISO‑8859‑3 データは信頼できる変換ツールで正しく UTF‑8 に移行してください。
参考文献
- ISO/IEC 8859‑3 — Wikipedia
- Unicode Consortium — ISO‑8859‑3 to Unicode mapping (8859-3.TXT)
- IANA — Character Sets (登録情報一覧。該当エントリから ISO‑8859‑3 を参照)
- MDN Web Docs — Content‑Type（charset の扱い）
投稿者プロフィール
