Loading article…
拡張Unixコード（EUC ）は、主に日本語、韓国語、簡体字中国語（文字）に使用されるマルチバイト文字エンコーディングシステムです。
最も一般的に使用される EUC コードは可変長エンコーディングであり、 ISO/IEC 646に準拠した符号化文字セット ( ASCIIなど) に属する文字は 1 バイト、94×94 符号化文字セット ( GB 2312など) に属する文字は2 バイトで表現されます。GB 2312のEUC-CN形式とEUC-KRは、このような 2 バイト EUC コードの例です。EUC -JPでは、先頭シフト コードを含めて最大 3 バイトで表現される文字が含まれますが、 EUC-TWでは 1 文字が最大 4 バイトになる場合があります。
現代のアプリケーションでは、EUCコードのすべてのグリフをサポートし、さらに多くのグリフにも対応するUTF-8が使用される傾向が強くなっています。UTF-8は一般的に移植性が高く、ベンダーによる違いやエラーも少ないためです。しかしながら、EUCは依然として非常に人気があり、特に韓国向けのEUC-KRは広く利用されています。
EUC の構造はISO/IEC 2022規格に基づいており、94 個の 7 ビット バイト0x 21–7E、または 8 番目のビットが使用可能な場合は 0xA1–FE のシーケンスで表現できるグラフィカル文字セットのシステムを規定しています。これにより、94 個のグラフィカル文字、または 8836 (94 2 ) 文字、または 830584 (94 3 ) 文字のセットが可能になります。当初は 0x20 と 0x7F は常にスペースと削除文字であり、0xA0 と 0xFF は使用されませんでしたが、ISO/IEC 2022の後の版では、特定の状況下でセット内でバイト 0xA0 と 0xFF (または 0x20 と 0x7F) を使用することが許可され、96 文字セットを含めることが可能になりました。0x00–1F と 0x80–9F の範囲は、C0 および C1 制御コードに使用されます。
EUC はISO/IEC 2022の 8 ビット プロファイルのファミリーであり、 ISO-2022-JPなどの 7 ビット プロファイルとは異なります。そのため、ISO 2022に準拠した文字セットのみが EUC 形式を持つことができます。最大 4 つのコード化文字セット (G0、G1、G2、G3、またはコード セット 0、1、2、3 と呼ばれます) を EUC スキームで表現できます。G0 セットは、ASCII、ISO 646:KR ( KS X 1003 )、またはISO 646:JP ( JIS X 0201の下半分) などのISO/IEC 646に準拠したコード化文字セットに設定され、GL (つまり、最上位ビットがクリアされた 0x21–0x7E) を介して呼び出されます。[ 1 ] ASCII が使用される場合、このコードは拡張 ASCIIエンコーディングになります。 ASCIIからの最も一般的な逸脱は、EUC-JPでは0x5C（ ASCIIではバックスラッシュ）が円記号を表すためによく使用され（下記参照）、 EUC-KRではウォン記号を表すためによく使用されることです。
他のコードセットは GR を介して呼び出されます (つまり、最上位ビットがセットされます)。したがって、文字の EUC 形式を取得するには、各コーディング バイトの最上位ビットがセットされます (各 7 ビット コーディング バイトに 128 を加えるか、kutenコードの各数値に 160 を加えることと同等)。これにより、ソフトウェアは文字列内の特定のバイトがISO 646コードに属するか拡張コードに属するかを簡単に区別できます。コードセット 2 および 3 の文字には、それぞれ制御コードSS2 (0x8E) およびSS3 (0x8F)が接頭辞として付けられ、GR を介して呼び出されます。最初のシフト コードを除いて、コードセット 1 から 3 の文字に現れる 0xA0～0xFF の範囲外のバイトは、有効な EUC コードではありません。[ 1 ]
EUCコード自体はISO 2022のアナウンスと指定のシーケンスを使用していません。[ 1 ]ただし、コード仕様は、次の意味に分解される4つのISO 2022アナウンスシーケンスのシーケンスと同等です。 [ 1 ]
上記で説明したISO-2022 ベースの可変長エンコーディングは、 EUC パックド フォーマットと呼ばれることもあり、これは通常 EUC とラベル付けされるエンコーディング フォーマットです。ただし、EUC データの内部処理では、EUC 完全 2 バイト フォーマットと呼ばれる固定長変換フォーマットを使用する場合があります。これは以下を表します。[ 2 ]
コードセットが 1 バイトしか使用しない場合は、先頭の 0x00 と 0x80 バイトが使用されます。また、4 バイトの固定長フォーマットもあります。[ 2 ]これらの固定長エンコード形式は内部処理に適しており、通常は交換では使用されません。
EUC-JPは、IANAに「EUC-JP」または「csEUCPkdFmtJapanese」という圧縮形式と、「csEUCFixWidJapanese」という固定幅形式の両方で登録されています。[ 3 ] HTML5で使用されるWHATWGエンコーディング標準には、圧縮形式のみが含まれています。[ 4 ]
EUC-CN [ 6 ]は、簡体字中国語のGB 2312規格の通常のエンコード形式です。日本語のJIS X 0208やISO-2022-JPとは異なり、GB 2312は通常 7 ビットのISO 2022コード バージョンでは使用されませんが、HZと呼ばれるバリアント形式(ASCII シーケンスでGB 2312テキストを区切る) がUSENETで時々使用されていました。
ASCII文字は通常のエンコード方式で表現されます。GB 2312の文字は2バイトで表現され、どちらも0xA1～0xFEの範囲の値をとります。
EUC-CNに関連するエンコーディングとして、北京のFounder Technology社が開発したWITS組版システム（現在は同社の新しいFITS組版システムに置き換えられている）で使用されていた「748」コードがあります。748コードにはGB 2312のすべてが含まれていますが、ISO 2022に準拠していないため、真のEUCコードではありません。（8ビットの先頭バイトを使用しますが、最上位ビットがセットされた2番目のバイトと、最上位ビットがクリアされた2番目のバイトを区別するため、構造的にはBig5やその他のISO 2022に準拠していないDBCSエンコーディングシステムにより近いものとなっています。）748コードのGB2312以外の部分には、新聞の組版で使用される繁体字、香港字、その他のグリフが含まれています。
IBMコード ページ 1381 ( CCSID 1381 ) は、シングル バイトコード ページ 1115 ( CCSID 1115 として CPGID 1115 ) とダブル バイト コード ページ 1380 ( CCSID 1380 として CPGID 1380 ) から構成され、[ 7 ] GB 2312 を EUC-CN と同じ方法でエンコードしますが、先頭バイト範囲を 0x8C まで拡張し、0x8CE0 から 0x8CFE に 31 個の IBM 選択文字を追加し、先頭バイト 0x8D から 0xA0 に 1880 個のユーザー定義文字を追加することで EUC 構造から逸脱しています。[ 8 ]
IBM コード ページ 1383 (CCSID 1383) は、シングル バイトコード ページ 367とダブル バイト コード ページ 1382 (CCSID 1382 としての CPGID 1382) から構成されます。[ 9 ]これは、EUC 構造に準拠し、代わりに 0xFEE0 から 0xFEFE に 31 個の IBM 選択文字を追加し、GB 2312 で使用されていない位置に散在する 1360 個のユーザー定義文字のみを含める点で異なります。[ 10 ]代替の CCSID 5479 [ 11 ]は、純粋な EUC-CN コード ページ用です。これは、ダブル バイト セットとして CCSID 9574 を使用し、CPGID 1382 を使用しますが、IBM 選択文字とユーザー定義文字は除外します。[ 12 ]
GBKはGB 2312の拡張版です。これは、主にUnicode 1.1から取得した、より多くのCJK文字（繁体字中国語や日本語のみで使用される文字を含む）を表現できるEUC-CNエンコーディングの拡張形式を定義しています。ただし、より大きなエンコーディング空間が必要となるため、ASCIIバイトが末尾バイトとして現れる場合があり（また、C1バイトは、単一シフトに限らず、先頭バイトまたは末尾バイトとして現れる場合がある）、真のEUCコードではありません。
GBKの派生版は、Windowsコードページ936（簡体字中国語用のMicrosoft Windowsコードページ）とIBMのコードページ1386によって実装されている。
Unicode ベースのGB 18030文字エンコーディングは、 Unicode全体をエンコードできる GBK の拡張を定義します。ただし、GB 18030としてエンコードされた Unicode は可変長エンコーディングであり、より大きなエンコード空間が必要となるため、1 文字あたり最大 4 バイトを使用する場合があります。GBK の拡張であるため、EUC-CN の上位セットですが、それ自体は真の EUC コードではありません。Unicode エンコーディングであるため、そのレパートリーはUTF-8などの他のUnicode 変換フォーマットと同一です。
EUC メカニズムから逸脱する他の EUC-CN バリアントには、クラシック Mac OS中国語簡体字 (コード ページ 10008 または として知られていますx-mac-chinesesimp) があります。[ 13 ]これは、ウムラウト付きの U (ü)、2 つの特殊フォント メトリック文字、改行なしスペース、著作権記号(©)、商標記号 (™)、省略記号(...) にそれぞれバイト 0x80、0x81、0x82、0xA0、0xFD、0xFE、および 0xFF を使用します。[ 6 ]これは、単一バイト文字と 2 バイト文字の最初のバイトとみなされるものが、EUC (そのうち 0xFD と 0xFE がリード バイトとして定義されています) と GBK (そのうち 0x81、0x82、0xFD、および 0xFE がリード バイトとして定義されています) の両方と異なります。
この0xA0、0xFD、0xFE、0xFFの使用は、AppleのShift_JISバリアントと一致します。
先頭バイト範囲のこれらの変更に加えて、Mac OS 中国語簡体字の 2 バイト部分のもう 1 つの特徴は、基本 GB 2312-80 セットの 6 行目と 8 行目に2 つの拡張機能が含まれていることです。 [ 6 ]これらは「GB 2312 の標準拡張機能」と見なされており 、どちらも Apple 独自のものではありません。8 行目の拡張機能はGB 6345.1から取得され、[ 6 ]両方の拡張機能はGB/T 12345 (GB 2312 の繁体字中国語版 ) に含まれており、[ 14 ]両方の拡張機能はGB 18030 (GB 2312 の後継 ) に含まれています。[ 15 ]
EUC-JPは、 JIS X 0208、JIS X 0212、JIS X 0201の3 つの日本語文字セット標準の要素を表すために使用される可変長エンコーディングです。このエンコーディングの他の名前には、Unixized JIS (またはUJIS ) およびAT&T JISがあります。[ 2 ] 2026 年 2 月現在、すべての Web ページのうち EUC-JP を使用しているのは 0.1% 未満です。[ 16 ]日本語で書かれた Web サイトの 2.1% がこの (日本語用) 2 番目に人気のあるエンコーディングを使用しています。[ 17 ] ( Shift JISよりも多いですが、どちらもUTF-8より使用頻度ははるかに低いです)。IBMではコード ページ 954 と呼ばれています。 [ 18 ] [ 19 ] Microsoft では、このエンコーディングに 2 つのコード ページ番号 (51932 と 20932) があります。
このエンコード方式では、同じ文字セット規格に基づいているISO-2022-JPで使用されるエスケープ文字を必要とせず、また（ Shift JISとは異なり）ASCIIバイトが末尾バイトとして現れることもなく、7ビットASCIIと8ビット日本語を簡単に混在させることができます。
関連する部分互換性のあるエンコーディングであるEUC-JISx0213またはEUC-JIS-2004は、JIS X 0201およびJIS X 0213をエンコードします[ 20 ]（Shift_JISベースの対応物であるShift_JISx0213と同様）。
EUC-CNやEUC-KRと比較すると、EUC-JPは日本国内のPCやMacintoshシステムではそれほど広く普及しませんでした。これらのシステムではShift JISまたはその拡張機能（Microsoft WindowsではWindowsコードページ932、従来のMac OSではMacJapanese）が使用されていましたが、HP-UXを除くUnix系OSやUnixライクなOSでは広く使用されていました。そのため、日本のウェブサイトでEUC-JPを使用するかShift_JISを使用するかは、多くの場合、著者が使用するOSによって異なります。
文字は以下のようにエンコードされます。
EUC-JPへのベンダー拡張機能（例えば、Open Software Foundation、IBM、NECなど）は、無効なEUCシーケンスを使用する（EUC-CNやEUC-KRの一般的な拡張機能のように）のではなく、個々のコードセット内に割り当てられることが多かった[ 25 ] [ 26 ] 。
しかし、一部のベンダー固有のエンコーディングは、GR上でJIS X 0208をエンコードしているため、EUC-JPと部分的に互換性がありますが、EUCのパック構造には従っていません。多くの場合、これらはEUC-JPのシングルシフトを使用していないため、Super DEC Kanjiを除いて、EUC-JPの直接的な拡張ではありません。
デジタル機器株式会社は、 EUCパック形式に部分的に準拠しつつ、完全な2バイト形式にもいくらか類似したEUC-JPの2つのバリアントを定義しています。「DEC Kanji」エンコーディングの全体的な形式は、ほとんど固定長（完全な2バイト）EUCに対応していますが、コードセット0は（パック形式と同様に）ヌルバイトで左詰めする必要はありません。[ 28 ] JIS X 0208は、通常どおりコードセット1に使用され、コードセット2（半角カタカナ）は存在しません。コードセット 3 は、2 バイト固定幅フォーマット (つまり、シフト バイトがなく、最初の最上位ビットのみがセットされている) のようにエンコードされますが、JIS X 0212 用に指定されるのではなく、2 バイトのユーザー定義文字に使用されます。[ 28 ]基本的な「DEC 漢字」エンコーディングでは、コードセット 3 の最初の 31 行のみがユーザー定義文字に使用され、32 行目から 94 行目までは、コードセット 1 の未使用行と同様に予約されています。[ 29 ]
「Super DEC Kanji」エンコーディングは、「DEC Kanji」エンコーディングとパック形式EUCの両方からのコードを受け入れ、合計5つのコードセットに対応しています。[ 28 ]また、ユーザー定義コードセット全体と、JIS X 0208およびJIS X 0212コードセットの末尾の未使用行（それぞれ85～94行目と78～94行目）をユーザー定義文字に使用できます。[ 29 ]
ヒューレット・パッカードは「HP-16」と呼ばれるエンコーディングを定義しています。これは、Shift JISのバリアントである「HP-15」エンコーディングに付随するものです。HP-16 はEUC-JP と同じバイトを使用してJIS X 0208をエンコードしますが、単一のシフトコードを使用せず (したがってコード セット 2 と 3 を省略)、パック フォーマット EUC 構造に従わない 3 つのユーザー定義領域を追加します。[ 28 ]
Data Generalが使用する IKIS (Interactive Kanji Information System) エンコーディングは、シングルシフトのない EUC-JP に似ており、コードセット 0 と 1 のみを使用します。半角カタカナは、代わりに JIS X 0208 の 8 行目 (1983 年に標準に追加されたボックス描画文字と衝突) に含まれています。JIS X 0208 の 9 行目から 12 行目は、ユーザー定義文字に使用されます。[ 28 ] [ 29 ]
KEIS (Kanji-processing Extended Information System) は、日立が使用しているEBCDICエンコーディングです。 [ 29 ]シフトシーケンスを使用して 2 バイト文字 (DBCS-Host エンコーディング) が含まれているため、ステートフルエンコーディングとなっています。具体的には、シーケンスが1 バイト モードに切り替わり、シーケンスが2 バイト モードに切り替わります。[ b ]ただし、JIS X 0208 文字は、EUC-JP でエンコードするのと同じバイト シーケンスを使用してエンコードされます。この結果、表意文字スペース(DBCS-Host コード構造による 0x4040 と EUC-JP の 0xA1A1) の重複したエンコーディングが発生します。これは、日本語用の IBM の DBCS-Host エンコーディングとは異なり、そのレイアウトは JIS X 0208 より前のバージョンに基づいています。先頭バイトの範囲は0x59まで拡張され、そのうち先頭バイト0x81～A0はユーザー定義文字用に指定され[ 28 ]、残りは漢字と非漢字の両方を含む企業定義文字に使用されます[ 29 ] 。0x0A 0x410x0A 0x42
JEF (Japanese-processing Extended Feature) [ 29 ]は、富士通FACOM メインフレームで使用される EBCDIC エンコーディングであり、富士通 PC で使用される FMR (Shift JIS のバリアント ) とは対照的です。 KEIS と同様に、JEF はステートフル エンコーディングであり、シフト シーケンスを使用して 2 バイト DBCS-Host モードに切り替わります ( は0x291 バイト モードに切り替わり、 は0x282 バイト モードに切り替わります)。[ 30 ]また、KEIS と同様に、JIS X 0208コードは EUC-JP と同じように表現されます。[ 28 ]先頭バイト範囲は 0x41 まで拡張され、0x80–0xA0 はユーザー定義用に指定されています。先頭バイト 0x41–0x7F は、クテンの目的で行番号 101 から 163 に割り当てられますが、行 162 (先頭バイト 0x7E) は使用されません。[ 28 ] [ 29 ] 101行目から148行目は拡張漢字に使用され、149行目から163行目は拡張非漢字に使用されます。[ 29 ]
EUC-KRは、 KS X 1001 (旧 KS C 5601) [ 31 ] [ 32 ]とISO 646 :KR ( KS X 1003、旧KS C 5636 ) またはASCII (バリアントによる) の 2 つのコード化文字セットを使用して韓国語のテキストを表現する可変長エンコーディングです。KS X 2901 (旧KS C 5861 ) はエンコーディングを規定しており、RFC 1557はこれを EUC-KR と名付けました。
KS X 1001 (G1、コードセット 1) から抽出された文字は GR (0xA1–0xFE) の 2 バイトとしてエンコードされ、KS X 1003または ASCII (G0、コードセット 0) の文字は GL (0x21–0x7E) の 1 バイトを占めます。
大韓民国では、通常、Wansung（韓国語: 완성、RR : Wanseong、直訳すると「あらかじめ合成された」 [ 33 ]）と呼ばれています。IBM は、2 バイトのコンポーネントをコード ページ 971 [ 34 ]と呼び、ASCII を使用した EUC-KR をコード ページ 970 [ 35 ] [ 36 ] [ 37 ]と呼んでいます。Microsoftでは、コード ページ 20949（「韓国語 Wansung」）[ 38 ] [ 39 ]およびコード ページ 51949（「EUC Korean」）として実装されています[ 38 ] 。
2026年3月現在 世界中のウェブページのうち、EUC-KR を使用していると宣言しているページは 0.06% 未満ですが[ 40 ] 、韓国のウェブページの 3.8% は EUC-KR を使用しています[ 41 ] 。拡張機能を含めると、EUC-KR は韓国の 3 つの主要プラットフォーム ( macOS 、その他の Unix 系 OS、Windows) で最も広く使用されているレガシー文字エンコーディングですが、特に Linux と macOS で UTF-8 の人気が高まるにつれて、使用は徐々にUTF-8に移行しています。
他のほとんどのエンコーディングと同様に、UTF-8は現在、新しい用途において推奨されており、プラットフォーム間やベンダー間の一貫性の問題を解決している。
EUC-KR の一般的な拡張機能は、統合ハングルコード( 통합형 한글 코드 ; Tonghabhyeong Hangeul Kodeu , [ 42 ]または통합 완성형 ; Tonghab Wansunghyung ) で、これは Microsoft Windows のデフォルトの韓国語コードページです。Microsoft ではコードページ番号 949 が割り当てられ、IBM では1261 [ 43 ]または 1363 [ 44 ]が割り当てられています。IBMのコードページ 949 は、EUC-KR の別の無関係な拡張機能です。
Unified Hangul Codeは、EUC構造に準拠しないコードを使用して追加の音節ブロックを組み込むことでEUC-KRを拡張し、JohabとUnicodeで利用可能な複合音節ブロックの網羅を完成させます。HTML5で使用されるW3C / WHATWGエンコーディング標準は、EUC -KRの定義にUnified Hangul Codeの拡張機能を組み込んでいます。[ 45 ]
EUC-KR をサブセットとして組み込んだ他のエンコーディングには、Mac OS 韓国語スクリプト (コード ページ 10003 または として知られるx-mac-korean) [ 13 ]があり、これはクラシック Mac OSの韓国語ローカライズである HangulTalk (MacOS-KH) で使用されていました。これは、当時韓国で Apple Macintosh コンピュータの正規代理店であったElex Computer ( 일렉스 )によって開発されました。 [ 46 ] [ 29 ]
HangulTalk は、EUC-KR GR プレーン内の未使用領域 (トレイル バイト 0xA1 – 0xFE) と、その外側の非 EUC コード (トレイル バイト 0x41 – 0xA0) の両方で、先頭バイトが 0xA1 から 0xAD の間にある拡張文字を追加します。これらの文字の中には、フォント スタイルに依存しない様式化された装飾文字もあります。[ 29 ]これらの文字の多くは正確な Unicode マッピングを持たないため、Apple ソフトウェアはこれらのケースを、結合シーケンス、往復目的の修飾子として付加されたプライベート ユース文字を使用した近似マッピング、またはプライベート ユース 文字に様々にマッピングします。[ 47 ]
Apple は、EUC-KR プレーン外の特定のシングル バイト コードを使用して追加の文字も使用しています。必須スペースには 0x80 、ウォン記号(₩) には 0x81、エン ダッシュ( – ) には 0x82、著作権記号( © ) には 0x83、ワイドアンダースコア( ＿ ) には 0x84、省略記号(...)には 0xFF です。 [ 47 ]これらの追加のシングル バイト コードは、いずれもプレーン EUC-KR の先頭バイト範囲には含まれていません (上記で参照したEUC-CN に対する Apple の拡張とは異なります) が、一部は Unified Hangul Code の先頭バイト範囲内にあります (具体的には 0x81、0x82、0x83、0x84)。
KS X 1001と同様に、北朝鮮のKPS 9566規格は通常EUC形式で使用され、これらの文脈ではEUC-KPと呼ばれることもあります。[ 48 ]この規格のより新しい版では、統一ハングルコードと同様の方法で、非EUC 2バイトコードを使用する文字でEUC表現が拡張されています。[ 49 ]
ISO/IEC 8859シリーズなどの特定のシングルバイト エンコーディングは技術的には EUC 構造に準拠していますが、EUC とラベル付けされることはほとんどありません。ただし、SolarisではTIS-620のラベルとしてeucTH使用されています。[ 50 ]
EUC-TWは、ASCIIとCNS 11643の16プレーン（各プレーンは94×94）をサポートする可変長エンコーディングです。台湾で使用されている繁体字中国語のエンコーディングとしては、あまり使われていません。Big5の派生版はEUC -TWよりもはるかに一般的ですが、Big5はCNS 11643漢字の最初の2プレーンしかエンコードできず、UTF-8は普及が進んでいます。
CNS 11643のプレーン1は、コードセット1とコードセット2の一部として2回エンコードされていることに注意してください。
10 6510 660xA0 0x42ULMBCS_GRP_KO"windows-949"OptGroupByteToCPName