ISO-8859-3（Latin-3）とは？仕様・文字割り当てと実務での検出・変換・UTF-8移行の完全ガイド
エバープレイ編集部ISO-8859-3とは：概要
ISO/IEC 8859-3（通称Latin-3、South European）は、1980年代に策定されたISO/IEC 8859シリーズの一つで、ラテン文字圏のうち西欧以外の一部言語を扱うための単一バイト文字エンコーディングです。基本的なASCII（0x00–0x7F）はそのまま保持し、上位バイト（0xA0–0xFF）に各国語で必要な拡張文字を割り当てることで、Maltese（マルタ語）やEsperanto（エスペラント語）など南欧系・共通補助文字をサポートすることを目的に作られました。
歴史と位置づけ
ISO/IEC 8859 シリーズは、8ビット（1バイト）でASCIIを拡張する形で各地域・言語の必要文字を扱うために分割して作られました。ISO-8859-1（Latin-1）が西欧言語向けとして広く採用されたのに対し、ISO-8859-3（Latin-3）は主に南欧系や一部の補助的言語を想定して作られました。策定当初は特定言語群のテキスト処理や電子メール、古いホスト間通信などで有用でしたが、やがてUnicode/UTF-8の普及により実務での重要度は低下しました。
対象言語と設計趣旨
- 主にマルタ語（Maltese）やエスペラント語（Esperanto）など、ラテン基盤だがLatin-1に含まれない文字を必要とする言語に対応するために設計されました。
- トルコ語なども当初 considerations に入っていましたが、トルコ語専用の置換を行ったISO-8859-9（Latin-5）が別に策定され、実際のトルコ語用途はそちらが採用されました。
- ASCII互換であるため既存のASCIIベースのソフトウェアとの互換性が維持されますが、拡張領域は8ビット単位で固定された文字セットです。
文字割り当ての特徴
ISO-8859-3は0x00–0x7FがASCII、0xA0–0xFFが拡張文字領域です（0x80–0x9Fは制御や別用途で用いられることが多く実装依存）。拡張領域には、マルタ語のĦ/ħ（Hに横棒）、Ġ/ġ（Gに点）や、エスペラントのĈ/ĉ、Ĝ/ĝ、Ĥ/ĥ、Ĵ/ĵ、Ŝ/ŝ、Ŭ/ŭなど、複数言語で必要となるラテン拡張字が含まれています。
多くの拡張文字はISO-8859-1（Latin-1）には含まれておらず、同じバイト値でもLatin-1とLatin-3で異なる文字を意味する場合があるため、誤ったエンコーディング解釈（mojibake）が発生しやすい点に注意が必要です。
実装上の識別子と互換性
- IANAの文字セット名称は "ISO-8859-3"（MIMEではこの名前で指定）です。
- Microsoft / Windows のコードページでは "Windows-28593" というラベルが使われることがあります（互換実装）。
- IBMではCCSID 913などで扱われることがあり、各社ごとにコードページ番号が割り当てられている場合があります。
利用上の注意点と問題点
- 単一バイトであるため、ラテン以外の文字（ギリシャ文字やキリル文字、漢字など）は扱えません。グローバルな用途ではUnicode（UTF-8）への移行が推奨されます。
- 同じバイト値が別エンコーディングで別文字を表すため、エンコーディング判別に失敗すると文字化けが起きます。特にメールや古い文書アーカイブでは要注意です。
- HTMLやXMLで使用する場合、現代のブラウザやツールはUTF-8を標準前提としているため、明示的に charset を指定しないと誤解釈される可能性があります。
- 多くのHTMLエンティティには対応していない文字があり、表示互換性のために数値文字参照（&#xXXXX;）やUnicodeに変換して扱うことが一般的です。
実務での扱い（検出・変換・移行）
レガシーデータや古いメールからISO-8859-3の文字列を扱う際は、まずエンコーディング検出を行います。自動判定ライブラリ（例えば chardet、uchardet、ICU の判別機能、Mozilla の Universal Charset Detector など）を用いると良いですが、完全ではないため言語情報や文書のメタ情報と併用します。
代表的な変換ツール・関数
- iconv（多くのUNIX系環境で利用可能）: iconv -f ISO-8859-3 -t UTF-8 infile > outfile
- PHP: mb_convert_encoding($str, 'UTF-8', 'ISO-8859-3')
- Python: bytes_obj.decode('iso8859_3')（または 'latin_3' というエイリアス）でデコード、str.encode('iso8859_3') でエンコード
移行方針としては、保存・配信・表示の各レイヤーで UTF-8 を標準とし、入出力時に確実にエンコーディングを変換することを推奨します。データベースやWebサーバ、メールサーバの設定もUTF-8に統一するのが現代的なベストプラクティスです。
実運用でよくあるトラブルと対策
- 文字化け（mojibake）: 送信元がISO-8859-3であるのに受信側がLatin-1やUTF-8で解釈すると発生。対策は正しい charset ヘッダ／meta の付与と、受信側での明示的な変換。
- 欠落するHTMLエンティティ: HTMLで表示させるときは数値参照（&#xHHHH;）を使うか、UTF-8に変換してから表示する。
- 検索・ソートの不一致: 検索エンジンやDBの照合順序(collation)が想定する文字セットと異なると、検索結果に差異が出る。移行時に正規化（NFC/NFKC）を行い、適切な照合順序を設定する。
現在の位置づけ：なぜ覚えておくべきか
現代ではUTF-8が圧倒的に主流ですが、ISO-8859-3は古い文書、メールアーカイブ、レガシーなシステムに残っていることがあります。システム統合やデータマイグレーション、アーカイブのリストア作業を行うエンジニアや運用担当者にとって、どのような文字がどのバイト値に対応しているか、どのように安全にUTF-8へ変換するかは重要な実務知識です。
まとめ（実務ポイント）
- ISO-8859-3はLatin-3としてマルタ語・エスペラント語等を扱うための単一バイト文字集合。
- 同じバイト値が他のエンコーディングで別文字になるため、正確なエンコーディング指定が重要。
- レガシーデータ対応のため変換ツール（iconv、mb_*、Python codecs 等）を用いてUTF-8へ移行するのが現代的対処。
- ブラウザやWebアプリでは可能な限りUTF-8を使い、古いデータだけを入出力時に変換する方針が安全かつ保守的。
