ISO-8859-3とは何か？南ヨーロッパ向けラテン文字コードの概要とUnicode移行の実務ガイド
エバープレイ編集部ISO-8859-3とは：概要
ISO-8859-3（別名 Latin‑3、南ヨーロッパ用ラテン文字集合）は、ISO/IEC 8859 標準シリーズの一つで、8ビット（1バイト）でラテン系文字を表現するために設計された文字エンコーディングです。正式名称は ISO/IEC 8859‑3:1988（1988年制定）で、特にマルタ語やエスペラントなど、ラテン系アルファベットに特有の記号・拡張文字を扱えるように作られました。歴史的には、Unicode が普及する前に地域言語を扱うために複数の「Latin‑n」エンコーディングが作られた流れの一部です。
歴史的背景と目的
1980年代から1990年代にかけて、コンピュータ同士でテキストをやり取りする場面が増えるにつれ、英語以外の多くの言語で用いられる文字を1バイト（256文字）枠内でどのように収めるかが問題になりました。ISO/IEC 8859 シリーズはこの問題に対応するために分野・地域別に複数の部分（-1, -2, -3 …）として策定されました。
ISO-8859-3（Latin‑3）は「南ヨーロッパ向け（South European）」として位置づけられ、マルタ語やエスペラントなどの言語で必要とされる拡張ラテン文字を提供する目的で定められました。設計当時は欧州内の各言語をそれぞれの8ビットエンコーディングでカバーすることが実用的だと考えられていました。
文字集合の特徴
- ASCII 互換：0x00–0x7F は ASCII と同一のコードを維持します。つまり英数字・基本記号は従来通り。
- 拡張領域：0xA0–0xFF の範囲に、スペースや句読点、通貨記号、そして各言語固有の拡張ラテン文字が割り当てられます。0xA0 はノーブレークスペース（NBSP）で、これは ISO‑8859 系で共通です。
- C1 制御領域：0x80–0x9F は ISO‑8859 シリーズ自体ではグラフィック文字として定義されておらず、通常は C1 制御文字（ISO/IEC 6429）として扱われます。実装や環境によっては別用途に使われる場合があります。
- ユーロ記号なし：ISO-8859-3 は 1988 年の制定であり、ユーロ導入前のためユーロ記号（€）は含みません。ユーロ記号が必要な場合は別の更新や拡張、あるいは Unicode を用いる必要があります。
対応言語と実際の利用状況
ISO-8859-3 がカバーする主要言語は次のとおりです（代表例）：
- マルタ語（Maltese）：ċ, ġ, ħ, ż などマルタ語固有の文字
- エスペラント（Esperanto）：ĉ, ĝ, ĥ, ĵ, ŝ, ŭ など擬音符や特殊発音記号つきの文字
「南ヨーロッパ向け」とされるため、他の一部の南欧言語でも一部の文字がサポートされますが、地域によっては別の ISO‑8859 系や国別拡張が適している場合があります。たとえばトルコ語は後に ISO-8859-9（Latin‑5）で専用のサポートが提供されました。
現在では、Unicode（特に UTF‑8）の普及に伴い ISO-8859-3 の使用は大幅に減少しています。ただし、過去にこのエンコーディングで保存された文書やメール、データベース、組込み機器のログなどの互換性維持のために、レガシー環境で扱う必要がある場面が残っています。
技術的な取り扱い（Web、メール、プログラムでの指定方法）
- HTTP/HTML：古いウェブページでは <meta charset="ISO-8859-3"> や HTTP ヘッダの Content-Type: text/html; charset=ISO-8859-3 指定が行われていました。現代では UTF‑8 を推奨しますが、レガシー資産をそのまま公開する際は正しい charset 指定が必要です。
- MIME/メール：メールのヘッダで charset=ISO-8859-3 を指定して本文を送ることができます。受信側で正しいデコーディングが行われなければ文字化けの原因になります。
- プログラミング：多くの言語/環境で ISO‑8859‑3 のエンコーディング名として "ISO-8859-3"、"latin3"、"iso8859_3"（Python など）等のエイリアスが使えます。Unix の iconv、Python の codecs、その他ライブラリでの変換サポートを確認してください。
- Windows コードページ：Microsoft のコードページでは CP28593 が ISO‑8859‑3 相当として扱われることが知られています（環境依存の扱いを確認してください）。
互換性と注意点（文字化け、欠落文字、ユーロ問題）
ISO-8859-3 を使う際の代表的な問題点は次のとおりです。
- 文字化け（mojibake）：送信側と受信側で異なるエンコーディングが指定されていると、特に拡張文字が誤表示されます。たとえば Latin‑1（ISO‑8859‑1）や Latin‑2（ISO‑8859‑2）と混同すると別のグラフィック文字が表示されることがあります。
- ユーロ記号の欠如：ユーロ記号が含まれていないため、マネー関連の表示で不足が生じる場合は代替策（文字列 "(EUR)" など）や、Unicode での保存に切り替える必要があります。
- 限定的な文字集合：Unicode と比べると表現できる文字が非常に少ないため、多言語対応のドキュメントや国際化アプリケーションには不向きです。
実務上の扱い方と移行戦略
現代のシステム設計では、可能な限り Unicode（UTF‑8）へ移行することが最も現実的な対応です。移行時のポイントは以下の通りです。
- 既存データの特定：DB、ファイル、メール、ログなどで ISO‑8859‑3 のデータがどこにあるかを洗い出します。
- 検証とサンプリング：変換前にサンプルデータで文字化けや不正バイトを検証し、変換ルール（たとえば iconv や Python の codecs）を決めます。
- 自動変換とバックアップ：一括変換を行う前に必ずバックアップを取り、段階的に変換して動作を確認します。変換ツールとして iconv、recode、各言語の標準ライブラリを使う例が一般的です。
- メタデータの更新：ウェブサイトやメールシステム、API の charset 宣言を UTF‑8 に変更します。クライアント側も UTF‑8 を受け付けられるように準備します。
- フォールバック：変換できないバイト列の扱い方（無視、置換、エラー）を方針決定しておきます。
まとめ：いつ ISO-8859-3 を使うべきか
原則として新規開発や新しいドキュメント、ウェブサイトでは UTF‑8（Unicode）を選ぶべきです。ただし、過去に ISO‑8859‑3 で保存・配信されている資産を扱う場合は、正しいエンコーディング指定で表示・変換する必要があります。特にマルタ語やエスペラントの古い文書を扱う場面では ISO‑8859‑3 で保存されているケースがあり、その場合は適切にデコード（そして可能なら UTF‑8 に移行）することを検討してください。
