ISO-2022-JP は、電子メールで日本語テキストを送受信するために設計された文字エンコーディングです。エスケープシーケンスを使って ASCII と JIS X 0208 の文字集合を動的に切り替える仕組みを持ち、RFC 1468 で標準化されています。日本のインターネット黎明期において、メールで日本語を扱うための事実上の標準として広く普及しました。

1990 年代のインターネットでは、メールの転送経路に 7 ビットの ASCII しか通せないサーバーが多数存在していました。Shift_JIS や EUC-JP は 8 ビットエンコーディングであるため、こうした経路を通過する際にデータが破損するリスクがありました。ISO-2022-JP は全バイトが 7 ビットの範囲 (0x00-0x7F) に収まる「7 ビットクリーン」なエンコーディングとして、この問題を解決しました。インターネットの歴史に関する書籍でメール文字コードの変遷を学べます。

具体的な仕組みとして、ISO-2022-JP はエスケープシーケンス ESC $ B (0x1B 0x24 0x42) で JIS X 0208 の日本語モードに切り替え、ESC ( B (0x1B 0x28 0x42) で ASCII モードに復帰します。日本語の各文字は 2 バイトで表現され、ASCII 文字は通常どおり 1 バイトです。このモード切り替えの仕組みにより、同一のバイトストリーム内で日本語と英語を混在させることが可能になります。

現在のメールシステムは 8 ビット対応が標準となり、MIME の Content-Transfer-Encoding で Base64 や Quoted-Printable を使えるため、UTF-8 での送受信が一般的です。しかし、日本の企業や官公庁では古いメールシステムとの互換性を維持するために ISO-2022-JP が依然として使われるケースがあります。特に携帯電話のキャリアメールでは長らく ISO-2022-JP が標準でした。

よくある問題として「文字化け」があります。ISO-2022-JP のメールを UTF-8 として解釈したり、エスケープシーケンスが途中で欠落したりすると、意味不明な文字列が表示されます。メールヘッダの Content-Type: text/plain; charset=ISO-2022-JP が正しく設定されていないことが原因であるケースが多く見られます。メール技術の基礎書でプロトコルの詳細が解説されています。

Shift_JIS や EUC-JP との比較では、ISO-2022-JP はエスケープシーケンスによるオーバーヘッドがある反面、7 ビットクリーンという利点がありました。Shift_JIS は Windows 環境で、EUC-JP は UNIX 環境で主に使われ、ISO-2022-JP はメール専用という棲み分けが存在していました。現在はいずれも UTF-8 への移行が進んでいます。

文字数カウントの観点では、ISO-2022-JP はエスケープシーケンスの分だけバイト数が増加します。たとえば「こんにちは」(5 文字) は、JIS X 0208 モードへの切り替えと ASCII への復帰を含めると 16 バイトになります。同じ文字列が UTF-8 では 15 バイト、Shift_JIS では 10 バイトです。エンコーディングによってバイト数が異なる点は、メールのサイズ制限を考慮する際に重要な知識です。