# 分散国際化についてのガイドライン国際化と分散ネットワーク

この章では、国際化と分散ネットワークに関連する作業について説明します。

## 変換の概念

この節では、8ビットの
ユーザ名および8ビット・データを、ftp、mail、デスクトップ・クライアントのクライアント間通信などの通信ユーティリティによって、ネットワーク上で
通信する方法について説明します。

データを通信するに際して、まず３つの
考慮すべき点があります。`
`

- 送信側のコード・セットと受信側のコード・セット

- 通信プロトコルが8ビット・データを許可するか、それとも、7ビット・コード・データに限定されているか。（たとえば、日本のJUNETはJIS（日本工業規格）コードのデータを7ビット・プロトコルで通信します。）

- プロトコル規則ごとの使用可能な変換エンコードの型。実際に必要な変換は使用される特定のプロトコルに依存します。

リモート
ホストがローカル・ホストと同じコード・セットを使用している場合は、次の事項が真となります。

- プロトコルが8ビット・データを許可する場合、変換は必要ありません。

- プロトコルが7ビット・データしか許可しない場合、8ビット・コード・ポイントを7ビットASCII値にマップする必要があります。これは、`iconv`フレームワークと次の7ビット・エンコード方法のうちのひとつを使用して達成することができます。

  - 8ビット・データを、POSIX.2仕様のuuencodeおよびuudecodeアルゴリズムに指定されている通りにマップする。

  - 任意で、8ビット・データがプロトコルに定義されている7ビット変換エンコードにマップされる。たとえば、Xlibの7ビットISO2022やMIME - 多目的メール（Multipurpose Internet Message Extensions）のbase64があります。

リモート
ホストのコード・セットがローカル・ホストのコード・セットと異なる場合は、次の２つ事項が適用されます。必要な変換は使用される特定のプロトコルに依存します。

- プロトコルが8ビット・データを許可する場合、プロトコルは、どちら側が`iconv`変換を行なうかを指定し、回線上でのエンコードを指定する必要があります。プロトコルによっては、可能なすべてのコード・セットをエンコードし、文字レパートリーを識別することができる8ビット変換エンコードをおすすめします。

- プロトコルが7ビット・データしか許可しない場合、文字レパートリーを識別する7ビット変換エンコードが必要です。

### iconv
インタフェース

ネットワーク環境では、通信中のシステムのコード・セットと通信プロトコルによって、ユーザが指定したデータが意味のある方法でリモート・システムに送信されるように、データの変換方法が決定されます。ユーザのデータ（ユーザ名ではありません）を送信側のコード・セットから受信側のコード・セットに変換したり、プロトコルに準拠するよう8ビット・データを7ビット形式に変換したりする必要があります。これを達成するには一様なインタフェースが必要です。

次の例は、`iconv_open()`、`iconv()` および`iconv_close()`の使い方を説明し、`iconv`インタフェースの使用方法を示しています。変換を行なうためには、`iconv_open()`の後に`iconv()`を続ける必要があります。 7ビット変換および8ビット変換という用語はそれぞれ、7ビット・データの変換エンコードと8ビット・データの変換エンコードを指すために使用されます。

#### 送信側と受信側が同じコード・セットを使用している場合

- プロトコルが8ビット・データを許可している場合は、同じコード・セットが使用されているので8ビット・データを使用します。変換は必要ありません。

- プロトコルが7ビット・データしか許可しない場合は、`iconv`を使用します。

  - 送信側

        cd = iconv_open(locale_codeset, uuencoded);

  - 受信側

        cd = iconv_open(“uucode”, locale_codeset);

##### 送信側と受信側が異なるコード・セットを使用している場合

- プロトコルが8ビット・データを許可する場合

  - 送信側

        cd = iconv_open(locale_codeset,8-bitinterchange);

  - 受信側

        cd = iconv_open(8-bitinterchange, locale_codeset);

- プロトコルが7ビット・データしか許可しない場合は、次のようにします。

  - 送信側

        cd = iconv_open(locale_codeset, 7-bitinterchange);

  - 受信側

        cd = iconv_open(7-bitinterchange, locale_codeset);

`locale_codeset`はアプリケーションがローカルに使用しているコード・セットを参照します。`nl_langinfo(CODESET)`関数を使用して現在のロケールに関連付けられたコード・セットを取得することができますが、変換名が `nl_langinfo(CODESET)`関数からの戻り値と一致するかどうかはインプリメンテーションに依存します。

表3-1に、さまざまな条件で変換を実行するための`iconv`の使用方法を示します。プロトコルによっては他の変換が必要な場合もあります。

変換を実行するためのiconvの使用方法

| `同じコード・セットを使用するシステムとの通信（例: XYZ）` | `異なったコード・セットを使用するシステムとの通信、または、受信側のコード・セットが不明`
`使用する変換` | `7ビット・プロトコル` | `8ビット・プロトコル` | `7ビット・プロトコル` | `8ビット・プロトコル`
コード XYZ | 無効 | 最適 | 無効 | リモート・コード・セットが不明の場合は無効
7ビット変換 ISO2022 | OK | OK | 最適 | OK
8ビット変換 ISO2022 ISO 10646 | Invalid 1 | OK | 無効 | 最適
7ビット タグなし 引用符付き 印刷可能なuucode | OK | OK | コード・セットの識別が必要 | コード・セットの識別が必要
8ビット タグなし base64 | 無効 | OK | コード・セットの識別が必要 | コード・セットの識別が必要
1無効とは、選択したコード・セットとプロトコルの型には変換エンコードは使用すべきではないという意味です。

### 状態をもつ変換と状態をもたない変換

コード
セットは、状態をもつエンコードと状態をもたないエンコードの２つのカテゴリに分類することができます。

####
状態をもつエンコードの変換

状態をもつエンコードは、シフトイン／シフトアウトなどの制御コードのシーケンスを使用して特定のコード値に関連付けられたキャラクタ・セットを変換します。

たとえば、コンパウンド・テキストでは、文字のデータ・ストリームで日本語の16ビット・データの開始を示すのに制御シーケンス「ESC$(B」を使用することができます。また、このダブルバイト文字データの終了と8ビットASCIIデータの開始を示すのに、「ESC(B」を使用することができます。この状態をもつエンコードでは、ビット値0x43はシフト状態が不明の場合は解釈できません。EBCDICアジア・コード・セットは、シフトイン／シフトアウト制御を、それぞれ、ダブルバイトとシングルバイトのエンコードの間を切り換えるのに使用します。

別のコード・セットへの状態をもつエンコードの変換を実行するために記述されるコンバータは、特別な処理が必要なため少し複雑になる傾向があります。

####
状態をもたないエンコードの変換

状態をもたないコード・セットは次の２つの型に分類することができます。

- シングルバイト・コード・セット（ISO8859ファミリ等）

- マルチバイト・コード・セット（日本語用PCコードやShft-JIS(SJIS)など）

マルチバイト・コード・セットという用語は、1文字をエンコードするのにひとつ以上のバイトを必要とするコード・セットを指すのにも使用されます。マルチバイト・コード・セットは状態をもたないとみなされます。

コード・セットが同じキャラクタ・セットを表す場合のみ、変換は意味をもちます。

## シンプル・テキストの基本的な変換

プログラムがリモート・ホストにある別のプログラムにデータを通信する時には、元のマシンのコード・セットから受信側のコード・セットにデータを変換する必要性があります。 たとえば、PCコードを使用しているPCシステムが、ISO/EUC（国際標準化機構／拡張UNIXコード）エンコードを使用しているワークステーションと通信する必要がある場合などです。また、プログラムがデータを取得したコード・セットとは別のコード・セットでそのデータを表示しなければならない場合も同様です。これらの変換をサポートするために、標準プログラム・インタフェースがXPG4 `iconv()`関数定義に基づいて提供されています。

コード・セット変換を行なっているすべてのコンポーネントは、変換のインタフェースとして`iconv`を使用しなければなりません。システムは変換のデフォルト・セットをカスタマイズする機構だけでなく、広範囲の変換を提供することが期待されます。

### iconv変換関数

あるコード・セットから別のコード・セットへ変換するための
共通の方法は、テーブルを使用する方法です。テーブルが大きすぎる場合は、アルゴリズムによる方法が望ましいでしょう。さまざまな要求を満たすため、XPG4にコード・セット変換のフレームワークが定義されています。このフレームワークでは、ひとつのコード・セットから別のコード・セットに変換するために、コンバータを開き、変換を実行し、コンバータを閉じます。`iconv`関数には、`iconv_open()`、`iconv()`、`iconv_close()`があります。

コード・セット・コンバータは、`iconv_open()`、`iconv()`、`iconv_close()`の関数セットのフレームワークの下にあります。これらの関数によって、いくつかの型の異なったコンバータを提供し使用することができます。アプリケーションはこれらの関数を呼び出し、あるコード・セットの文字を別のコード・セットの文字に変換
します。`iconv`フレームワークにより、コンバータは一様の形式で提供されます。これらのコンバータのアクセスはX/Open XPG4下で標準化されています。

### Xクライアント間（ICCCM）変換
関数

Xlibは、
変換用に次の関数を提供します。

X ICCCMマルチバイト関数 | ICCCMワイド・キャラクタ関数
XmbTextPropertyToTextList() | XwcTextPropertyToTextList()
XmbTextListToTextProperty() | XwcTextListToTextProperty()

`Motif`ライブラリは、`XmCvtXmStringToCT()`関数と`XmCvtCtToXmString()`関数を提供しますが、特定のXmStringタグではハードコードされた前提条件があるためおすすめできません。たとえば、タグが `bold`の場合、`XmCvtXmStringToCT()`はインプリメンテーションに依存します。さまざまなプラットフォームに渡って、この関数の動作を世界中すべての地域で保証することはできません。

### ウィンドウ・タイトル

タイトルを設定する
一般的な方法はリソースを使うことです。しかし、ウィンドウのタイトルを直接設定するアプリケーションの場合、ローカライズされたタイトルをウィンドウ・マネージャに送信しなければなりません。次のガイドラインの他に`XICCEncodingStyle`に定義された`XCompoundTextStyle`エンコードを使用してください。

- コンパウンド
  テキストは、 `XmbTextListToTextProperty()`、もしくは、`XwcTextListToTextProperty()`のいずれかにより作成することができます。

- ローカライズされたテキストは`WMShell`ウィジェットの`XmNtitle`リソース、および、`XmNtitleEncoding`リソースを使用して表示することができます。ローカライズされたアイコン名は`TopLevelShell`ウィジェットの `XmNiconName`リソース、および、 `XmNiconNameEncoding`リソースを使用して表示することができます。

- ダイアログ・ボックスのローカライズされたタイトルは`XmBulletinBoard`ウィジェットの`XmNdialogTitle`リソースを使用して表示することができます。

- ウィンドウ・マネージャはローカライズされた文字列を表示するのに適切なフォント・リストをもっている必要があります。

次にローカライズされたタイトルとアイコン名を表示する例
を示します。この例では、コンパウンド・テキストはコンパウンド・ストリングから作成されます。

    include        <nl_types.h>
    Widget         toplevel;
    Arg            al[10];
    int            ac;
    XTextProperty  title;
    char           *localized_string;
    nl_catd        fd;

    XtSetLanguageProc( NULL, NULL, NULL );
    fd = catopen( “my_prog”, 0 );
    localized_string = catgets(fd, set_num, mes_num, “defaulttitle”);
    XmbTextListToTextProperty( XtDisplay(toplevel), &localized_string,
           1, XCompoundTextStyle, &title);
    ac = 0;
    XtSetArg(al[ac], XmNtitle, title.value); ac++;
    XtSetArg(al[ac], XmNtitleEncoding, title.encoding); ac++;
    XtSetValues(toplevel, al, ac);

ウィジェットではなく、ウィンドウを使用している場合は、 `XmbSetWMProperties()`関数が、ローカライズされた文字列を適切な`XICCEncodingStyle`に自動的に変換します。

## メールの基本的な変換

一般的に、電子メール（email）のストラテジーは、メッセージを受信側のロケールの与えられた情報に最適化するものではなく、電子メールを正規のラベル付け形式にするものです。これは、電子メールの世界では、受信者が異なったロケールにいる可能性を常に仮定しなければならないことを意味しています。デスクトップの世界では、デフォルトの電子メール転送はSMTP（Simple Mail Transfer Protocol）です。SMPTは7ビット転送チャネルしかサポートしません。

これをふまえた上で、デスクトップの電子メールのストラテジーには次のような点が挙げられます。

- 送信側は、デフォルトでは（ユーザが別の手順を指示しなければ）、本文の部分を送信側の転送チャネルの標準形式に変換し、本文の部分に使用される文字エンコードでラベル付けします。

- 受信側は、本文の部分を見て文字エンコードをサポートできるかどうかを調べます。サポートできる場合は、本文をローカルのキャラクタ・セットに変換します。

さらに、メッセージにMIME形式が使用されているため、8ビットから7ビットへの変換は組み込みのMIME転送エンコード（base64、または、引用符付き 印刷可能な形式）を使用して実行されます。RFC（Request for Comments）1521 MIME標準仕様を参照してください。

## エンコードとコード・セット

コード・セットを
理解するためには、まずキャラクタ・セットを理解することが必要です。キャラクタ・セットは、文字の表示に使用するエンコード値を考慮することなく、ひとつ以上の言語の特定の必要性に基づいてあらかじめ定義された文字の集合です。どのコード・セットを使用するかという選択は、ユーザのデータ処理要求条件に依存します。個々のキャラクタ・セットは異なったエンコード・スキーマを使用してエンコードされます。たとえば、ASCIIキャラクタ・セットは英語の文字のセットを定義します。JIS（日本工業規格）のキャラクタ・セットは日本語で使用される文字のセットを定義します。英語のキャラクタ・セットも日本語のキャラクタ・セットも、異なったコード・セットを使用してエンコードされます。

ISO2022規格は、コード化されたキャラクタ・セットを、キャラクタ・セット、および、各文字とそのビット・パターンの１対１の関係を定義する正確な規則の集まりとして定義します。コード・セットはシステムが文字を識別するために使用するビット・パターンを定義します。

コード・ページはコード・セットに似ていますが、コード・ページ仕様は16列×16行のマトリックスに基づくという制限があります。各列と行の交わりがコード化された文字を定義します。

###
コード・セットのストラテジー

共通オープン・ソフトウェア環境のコード・セット・サポートは、ISO（国際標準化機構）と、ユーザのデータ処理の必要性を満たす業界標準のコード・セットを提供する業界標準コード・セットに基づいています。

システムにおける各ロケールは、どのコード・セットを使用し、コード・セット内の文字がどのように処理されるかを定義します。システムに複数のロケールをインストールすることができるので、複数のコード・セットをシステム上の異なったユーザが使用することができます。異なったコード・セットを使用する複数のロケールでシステムが構成されることができる一方で、すべてのシステム・ユーティリティはシステムは単一コード・セットで動作していると仮定します。

ほとんどのコマンドはロケールが使用している下層のコード・セットについては何も認識しません。コード・セットの情報はコード・セットに依存しないライブラリ・サブルーチン（国際化対応ライブラリ）によって隠されており、コード・セットに依存しないライブラリ・サブルーチンは、コード・セットに依存するサブルーチンに情報を渡します。

多くのプログラムがASCIIに依存しているので、すべてのコード・セットは、7ビットASCIIコード・セットを適正なサブセットとして含んでいます。7ビットASCIIコード・セットはサポートされたすべてのコード・セットに共通しているため、その文字は可搬性のあるキャラクタ・セットとして参照されることもあります。

7ビットASCIIコード・セットはISO646定義に基づいており、制御文字、特殊文字、数字（0-9）、大文字と小文字の英語アルファベットを含んでいます。

###
コード・セット構造

各コード・セットは次の２つの主な領域に分けられます。

- GL 0-7列

- GR 8-F列

各コード・セットの最初の２列は、制御文字用にISO規格によって確保されています。C0とC1は、それぞれ、GLとGRの領域用の制御文字を表すのに使用されます。

PCコード・セットはC1制御領域を使用してグラフィック文字をエンコードします。

残りの６列はグラフィック文字をエンコードするのに使用されます。（IPG.distr.mkr.7を参照してください。） グラフィック文字は印刷可能な文字とみなされ、制御文字はデバイスとアプリケーションによってある特定の機能を指すために使用されます。

コード・セットの概要

#### 制御文字

ISO
定義に基づいて、制御文字は、制御操作を開始、変更、停止します。制御文字はグラフィック文字ではありませんが、場合によってはグラフィック表現をもつことができます。ISO646-IRVキャラクタ・セットの制御文字はサポートされたコード・セットすべてに存在し、C0制御文字のエンコードされた値はコード・セットを通して一貫しています。

#### グラフィック文字

各
コード・セットは、各文字が固有のコード化された値をもつように、ひとつ以上のキャラクタ・セットに分かれるとみなされます。 ISO規格はエンコード文字用に６列を確保し、グラフィック文字を制御文字でエンコードすることを許可しません。

#### シングルバイト・コード・セット

1バイト中の8ビットをすべて使用するコード・セット
は、ヨーロッパ、中東、その他のアルファベット言語をサポートすることができます。このようなコード・セットはシングルバイト・コード・セットと呼ばれます。これは、制御文字を含まず、エンコードを191文字までに制限します。

#### マルチバイト・コード・セット

マルチバイト・コード・セットという用語は、特定の文字をエンコードするのに必要なバイト数にかかわりなく、可能なすべてのコード・セットを指します。オペレーティング・システムは１文字をエンコードするのに何ビットでもサポートすることができるため、マルチバイト・コード・セットは、8、16、32、もしくはそれ以上のビットでエンコードされた文字を含むことができます。シングルバイト・コード・セットもマルチバイト・コード・セットとみなされます。

#### EUC（拡張UNIXコード）
コード・セット

EUCコード・セットは、一部のキャラクタ・セットの中では文字を識別するのに制御文字を使用します。エンコード規則は、ISO2022の7ビット・データおよび8ビット・データのエンコードに関する定義に基づいています。EUCコード・セットは一部のキャラクタ・セットを区切るのに制御文字を使用します。

EUCという用語は、そのような一般的なエンコード規則を表します。EUCに基づいたコード・セットはEUCエンコード規則に準拠しますが、特定の場合に関連付けられた特定のキャラクタ・セットも識別します。たとえば、日本語用eucJPはEUCエンコード規則に従ったJIS文字のエンコードを指します。

最初のセット（CS0）には常に、ISO646キャラクタ・セットが含まれます。その他のセットはすべて、最上位のビット（MSB）を1に設定しなければならず、文字をエンコードするのに何バイトでも使用することができます。さらに、１セット内のすべての文字は次の項目を満たしていなければなりません。

- すべての文字をエンコードするのに同じバイト数を使用する。

- 列表示幅（固定幅の端末での列数）が同じである。

３番目のセット（CS2）の各文字の前には、常に、制御文字SS2（シングルシフト2, 0x8e）が付きます。EUCに準拠するコード・セットは３番目のセットを識別する目的以外では制御文字SS2を使用しません。

４番目のセット（CS3）の各文字の前には、常に、制御文字SS3（シングルシフト3, 0x8f）が付きます。EUCに準拠するコード・セットは４番目のセットを識別する目的以外では制御文字SS3を使用しません。

### ISO EUCコード・セット

次の
コード・セット
はISO（国際標準化機構）により設定された定義に基づいています。

- ISO646-IRV

- ISO8859-1

- ISO8859-x

- eucJP

- eucTW

- eucKR

#### ISO646-IRV

ISO646-IRVコード・セット
は、7ビット・エンコードに基づく情報の処理に使用されるコード・セットを定義します。このコード・セットに関連付けられたキャラクタ・セットはASCII文字から得られます。

#### ISO8859-1

ISO8859-1
エンコードは、その他のISO、ANSI（米国規格協会）、ECMA（European Computer Manufacturer's Association）のコード拡張技術に基づいており、それらと互換性のあるシングルバイトのエンコードです。ISO8859エンコードは、各メンバが固有のキャラクタ・セットをもつコード・セットのファミリを定義します。7ビットASCIIコード・セットはISO8859ファミリの各コード・セットの適切なサブセットです。

ISO8859-1コード・セットは、ISO Latin-1コード・セットと呼ばれ、次の２つのキャラクタ・セットから成ります。

- ISO646-IRV GL、7ビットASCIIキャラクタ・セット

- ISO8859-1 GR（ラテン）キャラクタセット

これらの組合わされたキャラクタ・セットは、デンマーク語、オランダ語、英語、フィンランド語、フランス語、ドイツ語、アイスランド語、イタリア語、ノルウェー語、ポルトガル語、スペイン語、スウェーデン語などの西ヨーロッパの言語に必要な文字を含んでいます。

ASCIIコード・セットが英語のアルファベットの順番を定義するのに対し、GR文字は特定のどの言語によっても順序付けられません。言語特定の順序はロケールによって定義されます。

#### その他のISO8859
コード・セット

この節では、
その他の重要なISO8859コード・セットをリストします。各コード・セットは、ASCIIキャラクタ・セットとそのコード・セット固有の文字を含んでいます。

##### ISO8859-2

ラテン・アルファベット、No. 2、東ヨーロッパ

- アルバニア語

- チェコスロバキア語

- 英語

- ドイツ語

- ハンガリー語

- ポーランド語

- ルーマニア語

- セルビア-クロアチア語

- スロバキア語

- スロベニア語

##### ISO8859-5

ラテン／キリル・アルファベット

- ブルガリア語

- ベロルシア語

- 英語

- マケドニア語

- ロシア語

- ウクライナ語

##### ISO8859-6

ラテン／アラビア・アルファベット

- 英語

- アラビア語

##### ISO8859-7

ラテン／ギリシャ・アルファベット

- 英語

- ギリシャ語

##### ISO8859-8

ラテン／ヘブライ・アルファベット

- 英語

- ヘブライ語

##### ISO8859-9

ラテン／トルコ・アルファベット

- デンマーク語

- オランダ語

- 英語

- フィンランド語

- フランス語

- ドイツ語

- アイルランド語

- イタリア語

- ノルウェー語

- ポルトガル語

- スペイン語

- スウェーデン語

- トルコ語

#### eucJP

日本語用EUC
は、シングルバイト文字とマルチバイト文字（2バイトと3バイト）から成ります。エンコードは ISO2022に準拠し、JISおよびEUCの定義に基づいています。 IPG.distr.mkr.8を参照してください。

#### eucJPのエンコード

`CS` | `Encoding` |  | `Character Set`
cs0 | 0xxxxxxx |  | ASCII
cs1 | 1xxxxxxx | 1xxxxxxx | JIS X0208-1990
cs2 | 0x8E | 1xxxxxxx | JIS X0201-1976
cs3 | 0x8F | 1xxxxxxx 1xxxxxxx | JIS X0212-1990

##### JIS X0208-1990

情報変換用の日本語グラフィック文字セットのコード（1990年度版）です。この中には、147個の特殊文字、10個の数字、83個のひらがな文字、86個のカタカナ文字、52個のラテン文字、48個のギリシャ文字、66個のキリル文字、32個の線描画要素、6355個の漢字が含まれます。

##### JIS X0201

63個のカタナカを含む情報変換用のコードです。

##### JIS X0212-1990

情報変換用の日本語グラフィック文字セットの補助コード（1990年度版）です。これには、追加の特殊文字が21個、追加のギリシャ文字が21個、追加のキリル文字が26個、追加のラテン文字が27個、発音区別符号のついたラテン文字が171個、追加の漢字が5801個含まれます。

#### eucTW

繁体字用のEUC
は、シングルバイト文字とマルチバイト文字（2バイトと4バイト）を含む文字から構成されるエンコードです。EUCエンコードはISO2022に準拠し、中華民国とEUC定義によって定義される通り、CNS（Chinese National Standard）に基づいています。IPG.distr.mkr.10を参照してください。

#### eucTWのエンコード

`CS` | `エンコード` |  |  | `キャラクタ・セット`
cs0 | 0xxxxxxx |  |  | ASCII
cs1 | 1xxxxxxx | 1xxxxxxx |  | CNS 11643.1992 - plane 1
cs2 | 0x8EA2 | 1xxxxxxx | 1xxxxxxx | CNS 11643.1992 - plane 2
cs3 | 0x8EA3 | 1xxxxxxx | 1xxxxxxx | CNS 11643.1992 - plane 3
| 0x8EB0 | 1xxxxxxx | 1xxxxxxx | CNS 11643.1992 - Plane 16

CNS 11643-1992は、中国標準変換コード（Chinese Standard Interchange Code）用に16面を定義しており、各面は8836文字（94x94）までサポートすることができます。現在は、1面から7面だけが文字を割り当てられています。IPG.distr.mkr.11
は、CNS 11643-1992規格の16面を示しています。

#### CNS 11643-1992規格の16面

`面` | `定義` | `文字数` | `EUCエンコード`
1 | 最も多く使用される | 6085 | A1A1-FDCB
2 | 2番目に多く使用される | 7650 | 8EA2 A1A1 - 8EA2 F2C4
3 | Exec、Yuen EDP 1 センター | 6148 | 8EA3 A1A1 - 8EA3 E2C6
4 | RIS2、ベンダー定義 | 7298 | 8EA4 A1A1 - 8EA4 EEDC
5 | MOEにより使用されることはめったにない3 | 8603 | 8EA5 A1A1 - 8EA5 FCD1
6 | MOEによる変形キャラクタ・セット1 | 6388 | 8EA6 A1A1 - 8EA6 E4FA
7 | MOEによる変形キャラクタ・セット2 | 6539 | 8EA7 A1A1 - 8EA7 E6D5
8 | 未定義 | 0 | 8EA8 A1A1 - 8EA8 FEFE
9 | 未定義 | 0 | 8EA9 A1A1 - 8EA9 FEFE
10 | 未定義 | 0 | 8EAA A1A1 - 8EAA FEFE
11 | 未定義 | 0 | 8EAB A1A1 - 8EAB FEFE
12 | ユーザ定義文字（UDC） | 0 | 8EAC A1A1 - 8EAC FEFE
13 | UDC | 0 | 8EAD A1A1 - 9EAD FEFE
14 | UDC | 0 | 8EAE A1A1 - 8EAE FEFE
15 | UDC | 0 | 8EAF A1A1 - 8EAF FEFE
16 | UDC | 0 | 8EB0 A1A1 - 8EB0 FEFE
1 EDP: 予算、会計、統計の中央理事会（Center of Directorate, General of Budget, Accounting, and Stistics）
2 RIS: 居住地情報システム（Residence Information System）
3 MOE: 文部省（Ministry of Education）

#### eucKR

韓国語用EUC
は、
は、シングルバイト文字とマルチバイト文字から成るエンコードです（IPG.distr.mkr.12を参照）。エンコードはISO2022に準拠し、韓国語標準コード（Korean Standard Code）セットとEUC定義に基づきます。

#### eucKRのエンコード

`CS` | `エンコード` |  | `キャラクタ・セット`
cs0 | 0xxxxxxx |  | ASCII
cs1 | 1xxxxxxx | 1xxxxxxx | KS C 5601-1992
cs2 |  |  | 使用されていない
cs3 |  |  | 使用されていない

KSC 5601-1992（1992年度版 情報変換用韓国語キャラクタ・セットのコード）には、特殊文字が432個、アラビア数字およびローマ数字が30個、ハングル・アルファベット文字が94個、ローマ文字が52個、ギリシャ文字が48個、ラテン文字が27個、日本語の文字が169個、ロシア文字が66個、線描画要素が68個、あらかじめ作成されたハングル文字が2344個、ハンジャ文字が4888個含まれます。

ハングル文字は韓国語の単語の音を表します。ひとつのハングル文字は、１個から３個のハングル基本音声記号から構成されます（最初の子音（もしあれば）、母音、最後の子音（もしあれば））。多くの韓国語の単語は、繁体字（韓国ではハンジャと呼ばれています）でも記述することができます。伝統的には、韓国語のテキストは一般的にハングルとハンジャの混合（名詞、動詞、修飾語句という主となる単語にはハンジャ、不変化詞と文法的語尾変化にはハングルを使用）で記述されていました。最近は、人名ではまだハンジャが使用されていることもありますが、ほとんどの韓国語のテキストはすべてハングルで記述されています。