EUC-JP は、UNIX 系オペレーティングシステムで日本語テキストを扱うために設計された文字エンコーディングです。IANA の文字集合登録簿では Extended_UNIX_Code_Packed_Format_for_Japanese という正式名で登録されており、HTTP ヘッダーや meta charset に書く推奨表記が EUC-JP です。1980 年代後半から 1990 年代にかけて、日本の UNIX コミュニティで標準的に採用されました。正式には JIS X 0208 で定義された漢字集合を 2 バイトで符号化し、ASCII 互換の 1 バイト領域と組み合わせることで、英語と日本語の混在テキストを効率的に処理できる仕組みを提供しています。

EUC-JP のエンコーディング構造は、バイト値の範囲によって文字種を判別できる点が特徴です。ASCII 文字は 0x00-0x7F の 1 バイト、JIS X 0208 の漢字・ひらがな・カタカナは 0xA1-0xFE の 2 バイトで表現されます。さらに、JIS X 0201 の半角カタカナは 0x8E を先頭バイトとする 2 バイト、JIS X 0212 の補助漢字は 0x8F を先頭バイトとする 3 バイトで符号化されます。この明確なバイト値の区分により、Shift_JIS で問題となる「5C 問題」が発生しません。Shift_JIS には「ソ」(83 5C) や「表」(95 5C) のように 2 バイト目がバックスラッシュ (0x5C) と同じ値になる文字があり、バイト単位で走査するプログラムが 2 バイト目をエスケープ文字と誤認します。EUC-JP では 2 バイト目以降に 0x80 未満のバイトが現れないため、この誤認自体が起こりません。

Linux や FreeBSD などの UNIX 系 OS では、2000 年代前半まで EUC-JP がデフォルトのロケールとして広く使われていました。特にサーバー用途では、C 言語の文字列処理関数との相性がよく、grep や sed などのテキスト処理ツールが安定して動作する点が重宝されました。日本の大学や研究機関のサーバー、ISP のメールサーバーなど、多くのインフラが EUC-JP を前提に構築されていた時代があります。

Shift_JIS との比較では、EUC-JP はプログラムからの扱いやすさで優位に立ちます。Shift_JIS は MS-DOS や Windows で標準的に使われましたが、2 バイト目に ASCII と重複するバイト値が含まれるため、パス区切り文字やエスケープ文字との衝突が頻繁に発生しました。一方、EUC-JP は 2 バイト目が常に 0xA1 以上であるため、こうした衝突が起きません。ただし EUC-JP は Windows の標準的なコードページではないため、Windows 中心の環境では Shift_JIS (CP932) との変換を挟む必要がありました。

2026 年時点では UTF-8 への移行がほぼ完了しており、新規のシステムやアプリケーションで EUC-JP を採用する理由はありません。しかし、レガシーシステムの保守、古いログファイルの解析、メーリングリストのアーカイブ閲覧など、実務で EUC-JP に遭遇する場面は依然として存在します。iconv コマンドや Python の codecs モジュールを使えば EUC-JP と UTF-8 の相互変換が可能ですが、UTF-8 から EUC-JP へ戻す方向は文字が落ちる前提で扱う必要があります。丸数字の「①」や全角チルダ (U+FF5E) は EUC-JP の基本的な変換表に存在せず、変換時にエラーか置換文字になります。また JIS X 0212 の補助漢字は、Web ブラウザが従う仕様では読み込み (デコード) だけが対象で書き出し (エンコード) の対象外とされているため、読めた文字を同じエンコーディングで書き戻せない非対称性があります。

文字数カウントの観点では、EUC-JP でエンコードされたテキストのバイト数と文字数の関係を理解することが重要です。ASCII 文字は 1 バイト = 1 文字、JIS X 0208 の漢字・ひらがな・全角カタカナは 2 バイト = 1 文字です。注意が必要なのは半角カタカナと補助漢字で、半角カタカナは Shift_JIS では 1 文字 1 バイトなのに EUC-JP では 0x8E が付いて 2 バイトになり、JIS X 0212 の補助漢字は 1 文字で 3 バイトを占めます。バイト数を 2 で割って文字数を推定する近道は、この 2 種類が混じった時点で崩れます。日本語 100 文字のテキストは EUC-JP で 200 バイト、UTF-8 で 300 バイトになるため、日本語主体のテキストでは EUC-JP のほうがファイルサイズが小さくなります。レガシーデータの文字数を正確に把握するには、バイト数から逆算せず、いったん UTF-8 などへデコードしてから数えるのが確実です。