ISO-8859-3（Latin-3）徹底解説：歴史・特徴・実務対応とUTF-8移行のポイント
エバープレイ編集部ISO-8859-3とは — 概要と位置づけ
ISO-8859-3（別名 Latin-3、南欧用ラテン拡張）は、ISO/IEC 8859 系列の一つで、8ビットの単一バイト文字エンコーディングです。ISO/IEC 8859 の第3部として標準化され、基本ASCII（0x00–0x7F）をそのまま保持し、0xA0–0xFF の領域に南欧の特定言語や国際補助語（特にマルタ語やエスペラントなど）で必要となる追加ラテン文字を割り当てています。
歴史的背景と目的
1980年代から1990年代にかけて、各地域の言語要件を満たすために ISO-8859 系列（Latin-1〜Latin-10 等）が策定されました。ISO-8859-3 はその一環で、特にマルタ語（Maltese）やエスペラント（Esperanto）など、Latin-1（西欧）やLatin-2（中欧）では十分にカバーされない文字をサポートする目的で作られました。インターネットや電子メールで使うためのMIME文字セットとしても IANA に登録されています。
技術的特徴
- 単一バイト・固定長：1バイト（8ビット）で表現。ASCII互換（0x00–0x7F）を保持。
- 上位領域：0xA0–0xFF に各種拡張ラテン文字が割り当てられる。
- 目的言語：マルタ語やエスペラントなどの南欧・国際補助語を念頭に設計。
- 標準名（IANA）：“ISO-8859-3” 等のラベルで登録。
代表的な収録文字（抜粋）
ISO-8859-3 にはマルタ語やエスペラントで使う特殊文字が含まれます。例：
- マルタ語：Ħ（U+0126）、ħ（U+0127）、Ġ（U+012A）、ġ（U+012B）、Ċ（U+010A）、ċ（U+010B）、Ż（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）など
（注：ここは抜粋です。正確な1バイト→Unicode の対応表は Unicode コンソーシアムや IANA のマッピングファイルを参照してください。）
ISO-8859-3 と他の文字セットの違い
同じ ISO-8859 系列でも各部はサポート言語が異なり、上位バイト領域（0xA0–0xFF）の割り当てが変わります。例えば：
- ISO-8859-1（Latin-1）は西欧主要言語向けで、フランス語・ドイツ語等によく使われる。
- ISO-8859-2（Latin-2）は中欧言語（ポーランド語等）向け。
- ISO-8859-3 はマルタ語やエスペラント等に特化している点が異なります。
結果として、あるバイト列を誤った ISO-8859 系で解釈すると特定文字が別の文字に化けます（mojibake）。
実際の利用状況と現状（近年の動向）
歴史的にはローカルな処理や電子メールで用いられてきましたが、現在では Unicode（特に UTF-8）の普及により ISO-8859-3 の実運用は非常に稀になっています。UTF-8 はほぼすべての言語の文字を統一的に表現できるため、新規システムやウェブサイトでは UTF-8 を用いることが推奨されます。
WordPress や Web 開発での注意点
- WordPress を含む現代の Web 基盤は UTF-8（推奨は utf8mb4）での運用が主流です。既存データベースに ISO-8859-3 のデータが混在している場合、サイトの文字化けを避けるため正確な変換が必要です。
- 変換の基本コマンド例（サーバ上で）：iconv -f ISO-8859-3 -t UTF-8 infile > outfile
- PHP では mb_detect_encoding / mb_convert_encoding を使って検出・変換できますが、誤検出を防ぐため元のエンコーディングが分かっていることが望ましいです。
- WordPress の移行時はデータベースの文字セットと照合順序（collation）を utf8mb4 に変更し、テーブル内のテキストを正しく変換してから wp-config.php の DB_CHARSET を更新してください。
検出とトラブルシューティング
文字エンコーディングの判定は万能な方法がないため注意が必要です。ツールとしては file -i、enca、uchardet、chardet（Python ライブラリ）などがありますが、完全ではありません。以下は実務上の対処例です：
- まずメタ情報（ファイルのヘッダ、電子メールの Content-Type、HTTP ヘッダ）を確認する。
- 既知の候補（ISO-8859-3 と UTF-8 等）で変換して結果を人の目で確認する。
- 変換後は検索・置換・ソートなどアプリケーションの挙動を確認（例えば一部文字の正規化が必要な場合がある）。
移行時のよくある問題
- 二重エンコード：既に誤ったデコード→再エンコードが行われていると、単純な iconv 変換では元に戻らないケースがある。
- 混在データ：同じデータベース内に UTF-8 と ISO-8859-3 が混在していると、一括変換が困難になる。
- 正規化の違い：Unicode 変換後に文字の正規化（NFC／NFD）を揃える必要があることがある（特に結合文字を含む言語で問題になる）。
まとめ — 現場での結論と推奨
ISO-8859-3 は特定言語向けに設計された歴史的な1バイトエンコーディングで、マルタ語やエスペラント等の文字をサポートします。しかし、現代の Web・アプリケーションでは Unicode（UTF-8）への統一が最善策です。既存の ISO-8859-3 データがある場合は、慎重に検出・バックアップを行い、正確なマッピング（iconv や言語処理ライブラリ）を用いて UTF-8 に変換・正規化してから運用を移行してください。
