ISO-8859-3（Latin-3）徹底解説：仕様・収録文字・対象言語・Unicode移行と実務のポイント
エバープレイ編集部はじめに — ISO-8859-3（Latin-3）とは
ISO-8859-3（通称 Latin-3）は、ISO/IEC 8859 系列の1つで、8ビットの単一バイト文字コードセットです。1980年代に策定され、主に南欧系の言語で必要とされるラテン文字の拡張を目的に作られました。現在ではUnicode（特にUTF-8）の普及により利用は稀ですが、歴史的なファイルや一部レガシーなシステムでは依然として遭遇することがあります。本コラムでは、仕様の技術的側面、収録文字と対象言語、利用上の注意点、実務での変換・移行方法まで、実務者・開発者向けに深掘りして解説します。
仕様の概要
- 正式名称：ISO/IEC 8859-3
- 別名：Latin-3
- 公開年：規格は1988年（ISO/IEC 8859 シリーズの一部として）
- 文字幅：単一バイト（8ビット）で、0x00–0x7F は ASCII と互換、0xA0–0xFF に拡張文字を配置
- IANA 登録名：ISO-8859-3
設計思想は「既存の ASCII を壊さず、ラテン文字の補助（アクセント付き文字など）を 0xA0–0xFF の範囲に追加する」ことです。従って、基本ASCIIとの互換性が保たれます。
収録文字と対象言語
ISO-8859-3 は特に以下の言語のために必要な文字を補うことを目的に作られました。
- マルタ語（Maltese） — マルタ語固有の文字（例：Ġ, ġ, Ċ, ċ, Ħ, ħ, Ż, ż）を含みます。
- エスペラント（Esperanto） — ĉ, ĝ, ĥ, ĵ, ŝ, ŭ など、エスペラントの補助文字に対応しています。
- その他の南欧系言語や一部の地域変種で必要とされる追加文字
注意点として、トルコ語（Turkish）向けの完全なサポートは ISO-8859-3 の主目的ではありません。トルコ語の特殊文字（İ, ı, Ş, ş など）を標準的に扱うためには後に策定された ISO-8859-9（Latin-5）が用いられます。
ISO-8859-1（Latin-1）との違いと特徴
ISO-8859-3 は ISO-8859-1 と多くのコードポイントを共有しますが、0xA0–0xFF のうちいくつかのコードを入れ替えて特定言語の文字を収録しています。つまり、同じバイト値が別の文字を意味する場合があるため、誤った文字セットでデータを解釈すると「文字化け」が起きやすい点に注意が必要です。
具体的な文字例（代表的な追加文字）
ISO-8859-3 によりカバーされる代表的な追加文字（Unicode のコードポイント表記を併記）を挙げます。
- マルタ語：Ġ (U+0120)、ġ (U+0121)、Ċ (U+010A)、ċ (U+010B)、Ħ (U+0126)、ħ (U+0127)、Ż (U+017B)、ż (U+017C)
- エスペラント：Ĉ (U+0108)、ĉ (U+0109)、Ĝ (U+011C)、ĝ (U+011D)、Ĥ (U+0124)、ĥ (U+0125)、Ĵ (U+0134)、ĵ (U+0135)、Ŝ (U+015C)、ŝ (U+015D)、Ŭ (U+016C)、ŭ (U+016D)
上記のような字母は、Unicode では一意のコードポイントを持ちますが、ISO-8859-3 では単一バイトで表現されます。逆に、ISO-8859-1 に含まれる一部の記号や文字は ISO-8859-3 で別の文字へ置き換えられている場合があります（互換性に注意）。
歴史的背景と利用状況
1980年代から90年代にかけて、インターネットや電子文書の国際化が進む中で、各地域の言語を扱うために ISO-8859 系列の複数のサブセットが作られました。ISO-8859-3 はその一つで、当初はマルタ語やエスペラントなど、Latin-1 等でカバーされない言語のための選択肢として提案されました。
しかし実際には、ISO-8859-3 は他のサブセット（Latin-1, Latin-2, Latin-5 など）に比べ採用が限定的でした。理由としては対象言語の使用人口が小さいことや、1990年代後半以降の Unicode（UTF-8）の普及により単一バイトの地域別エンコーディング自体の重要度が下がったことが挙げられます。
実務上の注意点（Web・メール・ファイル等）
- 文字化けリスク：ファイルやHTTPレスポンス、メールヘッダで宣言された文字セットと実際のバイト列が合致していないと、誤解釈（mojibake）が生じます。ISO-8859-3 を扱う場合は正しい Content-Type ヘッダ（例：Content-Type: text/html; charset=ISO-8859-3）や HTML meta タグを確実に設定してください。
- 混在問題：同一システム内で複数の ISO-8859 系を混在させると、同じバイトが別文字を表すためバグの元になります。可能なら統一（特に UTF-8 へ統一）することを強く推奨します。
- フォント互換性：ISO-8859-3 に含まれる一部の拡張文字は、古いフォントや限定的なフォントセットで欠けていることがあります。表示確認は必須です。
移行と変換（ISO-8859-3 → Unicode/UTF-8）
現代の標準は Unicode（UTF-8）です。既存の ISO-8859-3 データを扱う際は、以下手順・ツールが一般的です。
- 自動変換ツール：iconv（Linux/Unix）、uconv、libiconv、Python の codecs や .encode/.decode、PHP の mb_convert_encoding などが利用可能です（例：iconv -f ISO-8859-3 -t UTF-8 infile > outfile）。
- 検証：変換後はバイナリ比較だけでなく、表示検証と文字範囲チェック（期待するマルタ語／エスペラント文字が正しく変換されているか）を行ってください。
- データベース：レガシー DB カラムが ISO-8859-3 として保存されている場合、DB の文字セットを UTF-8 に変更する際はエクスポート→変換→インポートの順で行います。MySQL 等は文字セット指定に注意（mysqldump の --default-character-set など）。
よくあるトラブルと対策
- 誤った文字セット指定による文字化け：HTTP ヘッダとファイル実体が一致しているか確認。ブラウザは時に推測するため、明示的なヘッダ指定が重要です。
- 部分的な互換性による見落とし：ISO-8859-3 と ISO-8859-1 の間で共通の文字は正しく見えるため、見た目だけで安全と判断しないこと（内部には別文字が含まれる可能性あり）。
- 検索・ソートの違い：レガシー環境ではロケール依存の挙動が異なるため、検索やソートを行うアプリケーションは移行時に検証が必要です。
実務向けチェックリスト
- 既存データのエンコーディングを正確に特定（バイト列と期待する文字列を突き合わせる）
- 変換前にバックアップを取得
- 変換用ツール（iconv 等）でサンプル変換→目視確認→自動テストで完全性確認
- Web サーバーとアプリケーションの Content-Type ヘッダを整合させる
- 可能なら UTF-8 へ移行（その際、文字コード正規化（NFC/NFD）やロケールを考慮）
まとめ（いつ ISO-8859-3 を使うべきか）
現在の推奨は、原則として Unicode（UTF-8）を採用することです。ISO-8859-3 は歴史的な理由で存在し、マルタ語やエスペラントなど特定用途ではかつて有用でしたが、国際化対応や将来性を考えると新規システムで採用する理由はほとんどありません。ただし、レガシーシステムや古い文書の扱い、外部相手との互換性維持のために ISO-8859-3 の理解と、正確な変換手順を知っておくことは実務上有用です。
