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

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-1983 の日本語モードに切り替え、ESC ( B (0x1B 0x28 0x42) で ASCII モードに復帰します。旧版の JIS X 0208-1978 を指す ESC $ @ (0x1B 0x24 0x40) と、JIS X 0201 のラテン文字集合を指す ESC ( J (0x1B 0x28 0x4A) も併せて定義されています。日本語の各文字は 2 バイトで表現され、ASCII 文字は通常どおり 1 バイトです。このモード切り替えの仕組みにより、同一のバイトストリーム内で日本語と英語を混在させることが可能になります。

実装で見落としやすい規定が 2 つあります。1 つは「日本語を含む行は、行末 (改行) の前に必ず ASCII か JIS X 0201 のラテン文字集合へ戻さなければならない」というもので、もう 1 つは「本文全体が ASCII で終わっていなければならない」というものです。切り替えを戻し忘れたテキストは、行単位で処理する中継システムや、途中で分割・結合されたメール本文で日本語モードの状態が失われ、そこから先が読めなくなります。自前でエンコーダーを書くのではなく、言語標準のライブラリ (Python の iso2022_jp、Java の ISO-2022-JP など) に任せるのが安全です。

もう 1 つの実務上の落とし穴は、扱える文字が JIS X 0208 の範囲に限られる点です。半角カタカナ (JIS X 0201 の片仮名) は ISO-2022-JP では使えず、丸数字の①や㈱、いわゆる「はしごだか」の髙のような CP932 独自拡張の文字も範囲外です。送信側がこれらを断りなく詰め込むと、受信側では未定義の文字として落ちるか文字化けします。JIS X 0212 を足した ISO-2022-JP-1 (RFC 2237)、さらに中国語・韓国語などを足した ISO-2022-JP-2 (RFC 1554) といった拡張版もありますが、対応状況はまちまちで、現在この制約を回避する現実的な手段は UTF-8 へ移ることです。

現在のメールシステムは 8 ビット対応が標準となり、MIME の Content-Transfer-Encoding で Base64 や Quoted-Printable を使えるため、UTF-8 での送受信が一般的です。しかし、日本の企業や官公庁では古いメールシステムとの互換性を維持するために 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 バイトです。オーバーヘッドは文字数ではなくモード切り替えの回数で決まるため、日本語と英数字が細かく交互に並ぶ文面ほど不利になります。たとえば「今日 10 時に A 社へ」は切り替えが 6 回発生して 37 バイトになり、UTF-8 の 25 バイト、Shift_JIS の 19 バイトを大きく上回ります。エンコーディングによってバイト数が異なる点は、メールのサイズ制限や、バイト数で上限が決まるシステムへ流し込む際に重要な知識です。