ISO-8859-3（Latin-3）とは何か：マルタ語・エスペラントの拡張文字とUnicode移行の全体像
エバープレイ編集部ISO-8859-3 とは
ISO-8859-3（しばしば「Latin-3」「South European」とも呼ばれる）は、ISO/IEC 8859 系列に属する 8 ビットの単一バイト文字エンコーディングの一つで、ASCII（7 ビット）を拡張して西欧以外の一部の言語で必要となるラテン文字の追加文字を収容する目的で設計されました。0x00–0x7F は従来の ASCII と互換、0xA0–0xFF の上位半分にその言語特有の文字を割り当てるという、ISO-8859 系の基本設計を踏襲しています。
開発背景と位置づけ
1970–1990 年代にかけて、ネットワークや電子メール、オペレーティングシステムで用いるために「1 バイトで表現できるラテン系文字集合」の整備が進められました。ISO-8859 シリーズはそのために分割された規格群で、地域や言語に応じて複数のパート（Latin-1、Latin-2、Latin-3 …）を定義しました。
ISO-8859-3 は、その中で主にマルタ語（Maltese）やエスペラント（Esperanto）など南欧や人工言語の特定文字を収容するために用意されたパートで、ISO-8859-1（Latin-1）がカバーしない拡張文字を提供します。ただし、トルコ語のための文字は ISO-8859-9（Latin-5）が用意されたため、トルコ語を主目的としていません。
カバーする言語と代表的な文字
- 主対象言語：マルタ語、エスペラント（および一部の他言語や学術用途）
- 代表的な追加文字の例：
- マルタ語で重要な文字：Ġ / ġ（G のドット打ち）、Ħ / ħ（H の横線）、Ż / ż（Z の点）など
- エスペラントで使われるアクセント文字：Ĉ / ĉ、Ĝ / ĝ、Ĥ / ĥ、Ĵ / ĵ、Ŝ / ŝ、Ŭ / ŭ など
注意：上記は代表例で、ISO-8859-3 の上位 128 文字領域（0x80–0xFF のうち 0xA0–0xFF）がどの文字を割り当てているかは規格で厳密に決められています（ASCII に対して互換性を保つため 0x00–0x7F はそのまま）。
技術的特徴
- 単一バイトエンコーディング：1 バイト＝1 文字（制御コード領域を除く）、扱いが単純でメモリ効率が良い反面、多言語混在には弱い。
- ASCII 互換：低位 7 ビットは ASCII と同じため、従来の英語テキストとの互換性を確保。
- 上位領域の固定割当て：0xA0～0xFF に言語特有文字を配置。各 ISO-8859 系はこの上位領域で差異を持つ。
- Unicode との関係：ISO-8859-3 の各バイトは Unicode の特定コードポイントに一意にマップ可能で、Unicode へ変換する際のマッピング表が公開されています（例：Unicode Consortium が公開する 8859-3 のマッピングファイルなど）。
利用実例と歴史的な採用状況
ISO-8859-3 は特定言語コミュニティ（マルタ語やエスペラントの文書）で採用されたことがありますが、ISO-8859-1（Western European）や ISO-8859-2（Central European）、ISO-8859-9（Turkish）などと比べると普及は限定的でした。世界的には、次第に国際化と多言語対応の必要性が高まり、Unicode（特に UTF-8）の採用が急速に進んだため、ISO-8859-3 を新規に使うケースは稀になっています。
なぜ廃れた（あるいは局所的になった）のか
- 言語カバレッジの限界：単一バイトでは多くの言語を同時に扱えず、文書に複数言語が混在すると問題が生じる。
- Unicode（UTF-8）の登場：Unicode は全世界の文字を包括的に扱えるため、単一用途の 8 ビットエンコーディングよりも利便性が高い。
- インターネット標準の変化：Web やメールの世界で UTF-8 が事実上の標準となり、レガシーな 8859 系の需要が激減した。
実務上の取り扱い・注意点
既存の古いシステムやアーカイブで ISO-8859-3 を使ったデータが残っていることがあります。そうしたデータを扱う際のポイントは次のとおりです。
- 変換時に正しいマッピングを使う：ISO-8859-3 → Unicode（UTF-8）変換はマッピング表に従えば基本的に一対一で可能ですが、誤ったエンコーディングを指定すると文字化けします。
- HTTP / HTML のヘッダ指定：古い HTML やメールで charset=ISO-8859-3 を明示している場合、現代のブラウザは多くがレガシーエンコーディングにも対応していますが、可能なら UTF-8 に変換して公開するのが安全です。
- 混在文書の扱い：複数エンコーディングの混在文書や不明なバイト列を扱うときは、まずバイト列の推定（バイナリ調査）を行い、正しい前提でデコードすること。
- 検索・正規化：Unicode に変換した後、正規化（NFC/NFD）や大文字小文字変換の処理を行うと、検索や比較が安定します。
変換・互換性の具体例（概念）
例えば「ĝ」というエスペラントの文字は ISO-8859-3 の上位領域に割り当てられており、Unicode の U+011D（LATIN SMALL LETTER G WITH CIRCUMFLEX）に対応します。実際の変換はマッピングテーブルに従って 1:1 で行われますが、同じラテン系でも ISO-8859-1 や ISO-8859-2 を誤って使うと該当文字は存在せず別の記号に解釈されてしまうため文字化けが起こります。
現代のベストプラクティス
- 新規コンテンツは UTF-8（Unicode）で作成・配信する。これが最も互換性と将来性が高い。
- 古い ISO-8859-3 文書を扱う場合は、まず元のエンコーディングが本当に ISO-8859-3 であることを確認し（メタデータ、ヘッダ、ファイルの由来など）、Unicode に変換して保存・配信する。
- 変換ツールは信頼できるライブラリ（iconv、Python の codecs、ICU など）を使う。これらは ISO-8859-3 → Unicode のマッピングをサポートしている。
まとめ
ISO-8859-3（Latin-3）は、マルタ語やエスペラントなど特定の言語に必要な拡張文字を収容するために整備された 8 ビット文字セットです。かつては地域的・用途的に利用されましたが、現在は Unicode（UTF-8）への移行に伴い使用は限定的になっています。過去に作成されたデータを正しく扱うための知識としては重要ですが、今後の新規開発や公開コンテンツは UTF-8 を採用するのが推奨されます。
