ISO-8859-3（Latin-3）完全ガイド：概要・文字割り当てとUTF-8移行の実務ポイント
エバープレイ編集部ISO-8859-3 とは — 概要と歴史
ISO-8859-3（別名 Latin-3）は、ISO/IEC 8859 シリーズの一部をなす 8 ビット単一バイト文字エンコーディングの一つです。主にラテン文字圏の少数言語（特にマルタ語やエスペラントなど）をサポートする目的で設計され、ASCII（0x00–0x7F）の上位領域（0xA0–0xFF）に追加文字を割り当てることで、1 バイトで各種欧州語の文字を表現できるようにしたものです。ISO-8859-3 は 1980 年代後半に標準化され、当時の各国語対応の需要を満たすために使われました。
設計目的と対象言語
ISO-8859-3 の設計は「西欧でも中央・東欧でもないが、別途対応が必要な南欧系・周辺言語」を念頭に置いたもので、特に以下の用途が想定されました。
- マルタ語（Maltese）：固有字母（Ħ ħ、Ċ ċ、Ġ ġ、Ż ż など）を含む。
- エスペラント（Esperanto）：Ĉ ĉ、Ĝ ĝ、Ĥ ĥ、Ĵ ĵ、Ŝ ŝ、Ŭ ŭ といった特有のアクセント付き文字を含む。
- その他、比較的小規模な言語やラテン系文字の追加用途。
一方で、トルコ語のニーズにも一部応えようとした時期がありましたが、トルコ語独自の点（点付き大文字 İ と小文字 ı など）を正確に扱うため、後にトルコ語専用の ISO-8859-9（Latin-5）が策定され、実運用ではトルコ語はそちらに移行しました。
文字割り当ての構造
ISO-8859 系は共通の構造を持ちます。0x00–0x7F は ASCII と同一、0x80–0x9F は C1 制御文字（利用しないことが多い）、0xA0–0xFF がグラフィック文字（印字可能文字）領域です。ISO-8859-3 もこの設計に従い、0xA0 から 0xFF にマルタ語やエスペラントで必要なラテン文字拡張を配置しています。
それぞれのコード位置は Unicode の特定コードポイントにマッピングされており、Unicode/UTF-8 への変換は一対一対応で行えます（未定義のコードが含まれない限り）。実際のマッピング表は Unicode コンソーシアムや IANA のデータベースで公開されています。
主な特徴・含まれる代表的な文字
- マルタ語の固有字：Ħ (U+0126) / ħ (U+0127)、Ċ/ċ (U+010A/U+010B)、Ġ/ġ (U+0120/U+0121)、Ż/ż (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) など。
- その他の補助的ラテン文字や記号が含まれるが、西欧一般で使われる多くの文字は ISO-8859-1（Latin-1）などと共通。
利用状況と現状（実務的観点）
現在のウェブやアプリケーションでは、Unicode（特に UTF-8）の普及により ISO-8859-3 のような単一バイトエンコーディングは次第に廃れてきています。新規システムやコンテンツは基本的に UTF-8 を使うべきです。
ただし、レガシーシステム、古いメールアーカイブ、あるいは特定の組み込み機器や文書管理システムなどでは今でも ISO-8859-3 が使われているケースがあります。既存データを扱う際は、エンコーディングの誤認識や文字化けに注意が必要です。
よくあるトラブルと見分け方
- 文字化け（mojibake）：ISO-8859 系と Windows 系（たとえば Windows-1252）や UTF-8 を混同すると、特に 0x80–0x9F 領域や上位の特殊文字で文字化けが起きる。ISO-8859 系では 0x80–0x9F は制御コードであり、Windows-1252 では表示可能文字になっているため誤解が生じやすい。
- ブラウザやメールクライアントの自動判別ミス：Content-Type ヘッダや HTML の meta charset 宣言が正しくないと、表示側が UTF-8 として解釈してしまい、結果的にバイト列が異なるコードポイントに割り当てられ文字化けが発生する。
- トルコ語との混同：トルコ語は ISO-8859-3 で完全にサポートされない文字（İ/ı 等）があるため、トルコ語コンテンツには ISO-8859-9 や UTF-8 を用いる必要がある。
実務での扱い方（変換・設定例）
レガシーデータを処理・移行するとき、以下のような手順が一般的です。
- ファイルのエンコーディングを確認する：file コマンドや chardet、iconv のエラー、あるいはバイナリ検査で推定する。ただし自動判別は誤ることがあるため、特殊文字の出現頻度やソースを考慮する。
- UTF-8 へ変換する（推奨）：iconv や nkf、Python の codecs モジュールなどで変換する。例：iconv -f ISO-8859-3 -t UTF-8 in.txt > out.txt 。変換前にバックアップを必ず取る。
- ウェブで配信する場合：HTTP ヘッダ（Content-Type: text/html; charset=ISO-8859-3）または HTML の を使ってブラウザに解釈方法を通知する。ただし新規コンテンツは を推奨。
WordPress と ISO-8859-3
現行の WordPress は内部で UTF-8 を標準とするため、ISO-8859-3 のまま直接扱うことは想定されていません。外部から ISO-8859-3 の文書を取り込みたい場合は、事前に UTF-8 に変換してから投稿エディタに貼り付けるのが安全です。ブラウザが誤って元のバイト列を UTF-8 として解釈すると文字化けするため、変換後の内容で正しく表示されることを確認してください。
ISO-8859-3 と Unicode（UTF-8）との対応
ISO-8859-3 の各バイトは Unicode の固有コードポイントに対応しており、変換は基本的に可逆的です。Unicode マッピング表（ISO-8859-3 → Unicode）は公開されているため、プログラムでの変換は容易です。ただし、注意点としては以下があります。
- 未定義コード：ISO-8859 系では一部制御領域があり、意味を持たないバイト列が混ざっている可能性がある。変換時にこれらが除去・逸脱しないようにする。
- 合字・互換文字：Unicode には結合表現や互換文字（例えば U+00A0 のノーブレークスペースなど）があるため、見た目は同じでも内部的に異なるコードポイントになることがある。
いつまで ISO-8859-3 を使うべきか
基本方針としては「新規コンテンツは UTF-8（Unicode）を使用」することを強く推奨します。ISO-8859-3 を使い続ける理由はほとんどなく、互換性の観点からも UTF-8 に統一することが望ましいです。以下のようなケース以外では移行を検討してください：
- 既存の多数の文書やデータベースが ISO-8859-3 で保存されており、一括変換コストが高い場合（ただし一度に変換して以後 UTF-8 に統一することを推奨）。
- 組み込み機器や非常に古いソフトウェアでエンコーディングの変更が困難な場合。
まとめ（要点整理）
- ISO-8859-3（Latin-3）は、主にマルタ語・エスペラント等のために設計された 8 ビット文字セット。
- ASCII との互換性を保ちつつ、0xA0–0xFF に追加文字を配置する単一バイトエンコーディングである。
- 現代では Unicode（UTF-8）に置き換えられつつあり、新規開発では基本的に UTF-8 を使うべき。
- レガシー資産を扱う際は、エンコーディングの判定と安全な変換（例：iconv）を行うこと。WordPress 等の UTF-8 前提のプラットフォームに投入する場合は事前変換が必要。
参考文献
- ISO/IEC 8859-3 — Wikipedia
- ISO-8859-3 to Unicode Mapping — Unicode Consortium
- IANA Character Sets — 登録一覧（該当エントリで ISO-8859-3 を確認できます）
- RFC 1345 — Character Mnemonics and Character Sets（参照：文字セット名の取り扱い）
投稿者プロフィール
