CP1255（Windows-1255）とは？ヘブライ語エンコーディングの技術解説と移行方法
エバープレイ編集部概要：CP1255（Windows-1255）とは何か
CP1255（一般には「windows-1255」や「cp1255」と呼ばれる）は、Microsoft が定義した単一バイトの文字エンコーディングで、主にヘブライ語（Hebrew）を扱うためのコードページです。ASCII（0x00–0x7F）を下位互換として持ち、上位バイト領域にヘブライ文字や関連記号を割り当てることで、Windows 環境でヘブライ語を表示・保存できるように設計されています。歴史的には ISO-8859-8 などの既存のヘブライ文字集合と機能的に近い部分がありますが、Windows 固有の文字配置や拡張を持ちます。
技術的特性と仕様のポイント
- 単一バイト（1バイト＝1文字）エンコーディングで、最大 256 の値を表現する。
- 0x00–0x7F はほぼ ASCII と同一で、英数字や基本記号を共通して扱える。
- ヘブライ文字（アルファベット）は上位バイト領域に割り当てられており、Unicode では U+05D0 から U+05EA（ヘブライ文字）にマッピングされる。当該マッピングの詳細は公式マッピング表を参照すると確実である（後述の参考文献を参照）。
- 右から左（RTL：right-to-left）のスクリプトであるヘブライ語は、文字エンコーディングだけでなく表示（レンダリング）側の双方向（bidi）処理が重要になる。文字の順序や段落の方向、HTML や CSS の dir 属性などが適切に設定されていないと表示が乱れる。
CP1255 と ISO-8859-8／Unicode の違い
ISO-8859-8 は IANA に登録されたヘブライ語用の単一バイトエンコーディングで、CP1255 と文字セットそのものは近いですが、いくつかの点で差異があります。たとえば、制御領域や一部記号の割り当て、拡張文字（Windows 固有の記号や追加文字）の扱いが異なります。こうした差異のため、バイト列を単純に別のエンコーディングとして解釈すると文字化け（mojibake）が発生します。
今日では、文字集合の標準は Unicode（UTF-8 を含む）に移行しています。Unicode はヘブライ文字とニクード（母音記号／結合文字）や句読点、制御文字まですべて統一的に定義しているため、新しいシステムで国際化対応をする際は UTF-8 を選択することが推奨されます。
双方向テキスト（BiDi）と表示の注意点
ヘブライ語を扱う際には、文字エンコーディングだけでなく「双方向処理」が肝要です。HTML では段落や要素に対して dir="rtl" を指定することで、ブラウザの bidi アルゴリズムに適切に処理させられます。さらに、特殊なケースでは Unicode の制御文字（RLM、LRM、RLE、LRE、PDF など）を使って表示順序を調整する必要があります。
特に注意すべきは次の点です：
- 英数字や括弧、記号が混在する場合、期待した方向に表示されないことがある。
- CSS で direction プロパティ（direction: rtl;）を使うことで見た目の調整が可能だが、意味的に正しい順序を保つこととは別問題である。
現場でよく起きる問題と対処法（WordPress 含むWeb）
cp1255 のテキストを Web サーバやブラウザ、データベースが別の文字コード（たとえば UTF-8）として扱うと文字化けが発生します。WordPress におけるよくあるシナリオは次の通りです：
- 外部の古いシステムから cp1255 でエクスポートしたテキストを UTF-8 の WordPress にインポートすると文字化けする。
- データベースの文字セットや照合順序（collation）が UTF-8 になっているが、データ本体は cp1255 で格納されているなど不整合がある。
基本的な対処の流れ：
- まず元データのエンコーディングを確定する（ファイルヘッダ、メールヘッダ、元システムの仕様、バイナリのバイト値のパターンなどで判別）。
- サーバーや WordPress に取り込む前に、確実に UTF-8 に変換する。iconv や recode、Python、Perl、あるいは専用の文字コード変換ライブラリを使う。
- データベースに入れる際は、テーブル／カラムの文字セットを UTF-8 にしておき（例：utf8mb4）、接続時にも適切な charset を設定する。
変換ツールと具体的なコマンド例
実際の変換に使える一般的なツールと例を示します（操作前にバックアップを必ず取得してください）。
- iconv（POSIX 標準の文字コード変換）
iconv -f CP1255 -t UTF-8 input_cp1255.txt -o output_utf8.txt - Python（組み込みのコーデック）
バイト列をデコードして UTF-8 で書き出す例：
with open('input_cp1255.txt','rb') as f: data = f.read()
text = data.decode('cp1255')
with open('output_utf8.txt','w', encoding='utf-8') as o: o.write(text) - iconv で DB ダンプを変換する場合：mysqldump でダンプしたファイルを iconv で変換して再インポートする方法が一般的。
注意点：ニクード（vowel marks）と正規化
ヘブライ語には母音や発音補助のための結合文字（ニクード、cantillation marks など）があり、Unicode では結合文字として扱われます。cp1255 を経由した変換では、結合文字の順序や存在有無が問題になることがあります。変換後に Unicode の正規化（NFC / NFD）を行い、アプリケーション側で一貫した正規形で扱うことが望ましいです。
Mojibake（文字化け）の診断方法
文字化けが起きたときの切り分け手順：
- 問題のテキストをバイナリ表示して、特定のバイト列が何を示しているかを確認する（hexdump や xxd を利用）。
- そのバイト列を想定される各エンコーディング（cp1255、iso-8859-8、windows-1252、utf-8）でデコードしてみて、意味のある出力になるか試す。
- ブラウザや HTTP ヘッダ、HTML の meta charset、サーバーの default-charset 設定、DB 接続の charset オプションなど、どこでエンコーディング情報が失われているかを調べる。
実際の運用・移行でのベストプラクティス
- 新規プロジェクトは UTF-8（推奨は UTF-8 / UTF-8 with BOM は原則不要）で統一する。
- レガシーデータの移行は、変換元の文字コードを正確に特定した上で、テストを重ね、元データのバックアップを保存しておく。
- WordPress では DB の文字セットを utf8mb4 にし、wp-config.php で DB_CHARSET を適切に設定する。古い wp-config のままインポートすると文字化けする可能性がある。
- RTL 言語向けの表示改善として、HTML 要素やテンプレートで dir="rtl" を正しく設定し、CSS で必要なスタイル調整を行う。
- 自動判別（charset sniffing）に頼らず、明示的に charset を指定して配信する（HTTP ヘッダ、meta タグ）こと。
まとめ
CP1255（windows-1255）はヘブライ語の扱いのために歴史的に使われてきた単一バイトのコードページです。現在では国際化対応の標準として Unicode（UTF-8）に移行することが推奨されますが、既存のレガシー資産を安全に移行するためには、元のエンコーディングを正確に把握し、適切な変換ツールと手順（バックアップ、正規化、双方向テキストの取り扱い）を踏むことが不可欠です。
参考文献
- WHATWG Encoding — windows-1255（IANA/WHATWG による仕様とマッピング）
- Unicode Consortium — CP1255 マッピングファイル（公式マッピング）
- IANA — Character Sets（登録されている文字セット一覧）
- Microsoft Docs（Windows のコードページやローカリゼーションに関する公式情報）
- Wikipedia — Windows-1255（補足的な解説）
投稿者プロフィール
