EUC-JP (Extended Unix Code for Japanese) は、UNIX 系オペレーティングシステムで日本語テキストを扱うために設計された文字エンコーディングです。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 問題」(バックスラッシュと漢字の 2 バイト目が衝突する問題) が発生しません。Linux 日本語環境の書籍で EUC-JP の技術的な詳細を学べます。

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 環境ではほとんどサポートされず、Web ブラウザでの表示にも制約がありました。

現在は UTF-8 への移行がほぼ完了しており、新規のシステムやアプリケーションで EUC-JP を採用する理由はありません。しかし、レガシーシステムの保守、古いログファイルの解析、メーリングリストのアーカイブ閲覧など、実務で EUC-JP に遭遇する場面は依然として存在します。iconv コマンドや Python の codecs モジュールを使えば、EUC-JP と UTF-8 の相互変換が可能です。文字コード変換の書籍では各エンコーディング間の変換方法が解説されています。

文字数カウントの観点では、EUC-JP でエンコードされたテキストのバイト数と文字数の関係を理解することが重要です。ASCII 文字は 1 バイト = 1 文字ですが、日本語文字は 2 バイト = 1 文字となります。UTF-8 では日本語が 3 バイトを消費するのに対し、EUC-JP では 2 バイトで済むため、日本語主体のテキストでは EUC-JP のほうがファイルサイズが小さくなります。レガシーデータの文字数を正確に把握するには、エンコーディングの特性を踏まえたカウント処理が欠かせません。