ISO-8859-3とは？南欧用ラテン文字セットの概要とUTF-8移行の実務ポイント
エバープレイ編集部ISO-8859-3 とは — 概要
ISO-8859-3（別名 Latin-3、通称「南欧（South European）用ラテン文字セット」）は、ISO/IEC 8859 シリーズの一部である 8 ビットの単一バイト文字エンコーディングです。基本的な ASCII（0x00–0x7F）領域はそのままに、0xA0–0xFF の上位 128 バイトに南欧言語や一部の少数言語で必要とされる文字を割り当てることで、英語以外の諸言語を表現できるよう設計されました。歴史的には 1980～90 年代に広く用いられた標準の一つで、特にマルタ語（Maltese）やエスペラント（Esperanto）などへの対応を主目的として作られました。
歴史と位置づけ
ISO-8859 系列は、ASCII（7 ビット）を拡張して 8 ビットで地域ごとのラテン文字バリエーションを扱うために作られました。ISO-8859-3（Latin-3）は、1988 年に標準化された部の一つで、南欧や特殊言語で必要な合字・変音記号をサポートする目的で定義されました。
しかし、同時期に複数の「Latin-n」バリエーション（Latin-1 〜 Latin-5 など）が存在し、言語ごとに最適なサポートが異なったため、トルコ語のように Latin-3 では不十分であり後に Latin-5（ISO-8859-9）が用いられるようになった例もあります。最終的に Unicode（特に UTF-8）の台頭により、ISO-8859 系の利用は減少し、現在では互換性維持や古いデータの処理が主な用途になっています。
技術的な特徴
- 単一バイト/8 ビット：1 バイトで 256 通り（0x00–0xFF）を表現。ASCII 範囲（0x00–0x7F）は従来通り。
- グラフィック文字領域：0xA0–0xFF がグラフィック文字に割り当てられ、各国語固有の字形が配置される。
- 制御文字領域：0x00–0x1F および 0x7F は制御コードで予約（C0/C1 は別扱い）。
- IANA 登録名：通常の MIME/HTTP 等での表記は "ISO-8859-3"（エイリアスに "latin3" など）。
サポート対象の言語と代表的な文字
ISO-8859-3 は特に以下の言語に使えるよう設計されました（代表的なもの）：
- マルタ語（Maltese） — Ġ ġ、Ħ ħ、Ż ż などマルタ固有の文字を含む。
- エスペラント（Esperanto） — Ĉ ĉ、Ĝ ĝ、Ĥ ĥ、Ĵ ĵ、Ŝ ŝ、Ŭ ŭ（エスペラントの合字が含まれる）。
- その他、南欧圏の一部言語やラテン文字を使う状況での補助的な文字を含む。
注意点として、ISO-8859-3 は初期にはトルコ語も考慮された経緯がありますが、トルコ語固有の文字配置は Latin-5（ISO-8859-9）でより適切にサポートされるため、多くの実装ではトルコ語には Latin-5 を用いることが一般的です。
実際のマッピングと互換性
ISO-8859-3 の文字マップは 0x00–0x7F が ASCII と一致する一方、0xA0–0xFF の多くが ISO-8859-1（Latin-1）とは異なる配置になっています。したがって、ISO-8859-3 エンコーディングで書かれたテキストを誤って ISO-8859-1／Windows-1252 として解釈すると、マルタ語やエスペラントの合字が文字化け（mojibake）します。
Unicode（UTF-8/UTF-16）へ変換する際には、ISO-8859-3 の各バイト値ごとに対応する Unicode コードポイントへのマッピングが定められており、iconv や各種言語（Python、Ruby、Java など）の標準ライブラリでサポートされています。例：Linux 等での変換コマンドは
- iconv -f ISO-8859-3 -t UTF-8 in.txt -o out.txt
のように用います。プログラミング言語では Python のエンコーディング名 'iso8859_3'（または 'latin_3'）が利用可能です。
運用上の注意点と課題
- 互換性の問題：同じバイト列を異なる ISO-8859 系で解釈すると異なる文字になるため、古いファイルやメールのエンコーディングを正しく推測・指定することが重要です。
- 限定された使用範囲：対象言語が限定的であり、世界的には ISO-8859-1 や ISO-8859-2、そして後の Unicode に比べて普及度は低めでした。
- 現在の推奨：新規コンテンツやウェブサイトでは、互換性・多言語対応の観点から UTF-8（Unicode）を使用することが強く推奨されます。WordPress を含む多くの CMS は既に UTF-8 がデフォルトです。
- レガシーデータの扱い：過去の資料やメールアーカイブに ISO-8859-3 が混在している場合、変換ミスによる文字欠落や誤表示を防ぐため、正しいエンコーディングを確認してから UTF-8 へ移行することが重要です。
実務での使い方（サンプルとヒント）
・HTML ヘッダで明示する場合（古い方式）: <meta charset="ISO-8859-3"> と指定できます。ただし、現在のブラウザや CMS では UTF-8 を標準とするため、特別な理由がない限りこの指定は避けるべきです。
・コマンドラインでの変換（例）: iconv を使って ISO-8859-3 → UTF-8 へ一括変換。
・プログラムからの扱い: 多くの言語で 'iso8859_3' というエンコーディング名で読み書き可能。Python 例: open('f.txt', encoding='iso8859_3').read()
なぜ現在はあまり使われないのか
最大の理由は Unicode の普及です。Unicode は全世界の文字を統一的に扱えるため、複数の地域別 8 ビットコードページ（Latin-1 〜 Latin-9 など）を個別に使い分ける必要がなくなりました。特にインターネットやモバイルアプリケーションのグローバル化が進む中で、UTF-8 による単一のエンコーディング方針が運用・互換性・国際化の観点で圧倒的に有利です。
移行・解析の実務的ポイント
- 古いデータを UTF-8 に変換する際は、まずバイト列の元のエンコーディング（本当に ISO-8859-3 か）を確かめる。誤認識すると変換後に不可逆的な損失が生じることがある。
- メールアーカイブやデータベースの復旧では、Content-Type ヘッダや保存時のメタ情報を手がかりにエンコーディングを特定する。
- ブラウザやツールによる自動検出に頼らず、明示的に指定して検証を行うこと（特にマルタ語やエスペラントを含むテキスト）。
まとめ
ISO-8859-3（Latin-3）は、マルタ語やエスペラントなど特定言語を意識して定義された 8 ビットのラテン文字符号化方式です。歴史的に一定の役割を果たしましたが、現在は Unicode（UTF-8）への移行が標準となっており、新規利用はほとんど推奨されません。とはいえ、古い資料やシステムの互換性対応、データ復旧の現場では依然として遭遇する可能性があるため、マッピングや変換手順、文字化けのパターンを理解しておくことは有益です。
