ISO-8859-3（Latin-3）とは何か：南欧向け8ビットエンコーディングの特徴とUnicode/UTF-8移行ガイド
エバープレイ編集部ISO-8859-3（Latin-3）とは — 概要
ISO-8859-3（通称 Latin-3、別名 South European）は、ISO/IEC 8859 シリーズの一部で、8ビットの単一バイト符号化方式です。ISO/IEC 8859 シリーズは、ASCII（7ビット）を拡張して各地域の言語で必要となるラテン文字拡張を提供することを目的としており、ISO-8859-3 は南ヨーロッパ系言語や特定の補助文字を必要とする言語向けに設計されました。
技術的特徴
- 単一バイトエンコーディング：1バイト＝1文字で、0x00–0x7F は標準の ASCII をそのまま使用し、0xA0–0xFF に印字可能な追加文字を定義します。
- 文字集合の範囲：ASCII 以外の 96 文字（0xA0–0xFF）に地域固有文字を収める設計です。
- MIME / IANA 名：IANA 登録名は "ISO-8859-3"（しばしば "latin3" のエイリアスでも知られる）で、メールや HTTP ヘッダで charset として使用できます。
- Unicode との関係：ISO-8859-3 の各コードポイントには対応する Unicode コードポイントがあり、標準のマッピング表が公開されています。つまり、ISO-8859-3 ⇄ Unicode（UTF-8/UTF-16）への相互変換が可能です。
カバーする言語と収録文字
ISO-8859-3 は特に以下の言語での利用が意図されていました：
- マルタ語（Maltese）：ġ（G ドット付き）やż（Z ドット付き）、ħ（H ストローク）など、マルタ語特有の文字が含まれます。
- エスペラント（Esperanto）：ĉ, ĝ, ĥ, ĵ, ŝ, ŭ のような、帽子（サーカムフレックス）やウムラウトに対応する文字が含まれ、エスペラントの表記を単一バイトで扱えるようになっています。
- その他の南欧言語や補助記号：特定地域で必要となるいくつかの拡張文字が含まれていますが、西欧全体を包括するものではありません。
重要なのは、ISO-8859-3 は「すべての南欧言語を完全にカバーする」わけではなく、特定のニーズ（マルタ語・エスペラント等）に最適化された集合である点です。
歴史と経緯
ISO-8859 シリーズは 1980年代後半から策定され、多くの国際化作業で採用されました。ISO-8859-3 はその中で南ヨーロッパ向けのオプションとして定義され、当時は文字セットを増やすための実用的な選択肢となりました。
しかしながら、その後の世界的な文字コードの統一（Unicode の普及、特に UTF-8 の台頭）により、ISO-8859-3 のような地域別単一バイトエンコーディングの重要度は低下しました。さらに、トルコ語など特定言語向けには ISO-8859-9（Latin-5）など、より適した別の部分集合が登場したため、ISO-8859-3 の利用は限定的にとどまりました。
現場での互換性と注意点
- 互換性：ISO-8859-3 は ASCII と互換性があるため、英数字や基本記号は問題なく扱えます。しかし、0x80–0x9F の制御領域は拡張文字が割り当てられていないことが多く、プラットフォーム差に注意が必要です。
- MIME や HTTP: 古いメールや HTTP ヘッダで "Content-Type: text/plain; charset=ISO-8859-3" のように指定される場合があります。現代では UTF-8 に置き換えるのが推奨されますが、既存のアーカイブやレガシーデータを扱う際にはこの指定を正しく解釈する必要があります。
- モジバケ（文字化け）：サーバーやクライアントが誤って別のエンコーディング（例：ISO-8859-1）で解釈すると、マルチバイト文字やダイアクリティカルのある文字が誤表示されます。特にエスペラントやマルタ語の文字は誤解釈されやすいです。
- Unicode 変換：ISO-8859-3 から Unicode に変換するマッピング表は公開されており、正しいマッピングを使えばデータ損失なく移行できます。ただし、同一の見かけでも異なるコードポイント（合字や前置補助符号など）には注意が必要です。
利用状況と後継（UTF-8 への移行）
2000年代以降、Web とアプリケーションは Unicode（特に UTF-8）へ急速に移行しました。UTF-8 は世界中の言語を単一の可変長エンコーディングで表現できるため、地域別の単一バイトエンコーディングの必要性を大きく低下させました。
その結果、ISO-8859-3 は新規プロジェクトで採用されることは稀になり、レガシーデータの変換や保存されたドキュメントの解釈といった限定用途で主に参照されます。とはいえ、特定の組版や古いシステムとの互換性維持のために知識として押さえておく価値はあります。
実務での取り扱いガイドライン
- 新規開発では原則 UTF-8 を採用する。既存データが ISO-8859-3 の場合は、正しいマッピング表を用いて UTF-8 に変換してから処理すること。
- HTTP やメールで charset が ISO-8859-3 指定の場合は、その指定を尊重してバイト列を Unicode にデコードする。デコード後は内部表現を UTF-8（あるいは UTF-16）に統一する。ブラウザ表示用に出力する場合は Content-Type を UTF-8 に変換して配信するのが望ましい。
- 文字化けのトラブルシューティングでは、まず Content-Type / meta charset の宣言と実際のバイト配列の照合を行う。誤ったエンコーディング推測により特定のダイアクリティカルマークが変わってしまうケースが多い。
- データのアーカイブや移行プロジェクトでは、変換前後での文字列の等価性を検証（チェックスムやサンプル比較）し、特に言語固有文字が失われていないかを確認する。
まとめ
ISO-8859-3（Latin-3）は、マルタ語やエスペラントなど特定言語向けに設計された 8 ビットのラテン文字拡張セットです。歴史的には地域ごとの文字コード需要を満たす役割がありましたが、Unicode（特に UTF-8）の普及により新規採用は減少しました。とはいえ、レガシーデータや古い通信フォーマットを扱う現場では依然として関連知識が重要です。実務上は、既存の ISO-8859-3 データを正しく Unicode に変換してから統一的に扱うのが安全で、将来的な互換性を確保するための最善策です。
