この章では、国際化対応と分散ネットワークに関連するタスクについて説明します。
この節では、8 ビットのユーザ名と 8 ビット・データが、ftp、メール、デスクトップ・クライアント間のクライアント間通信などの通信ユーティリティによりネットワーク上で通信できる方法を説明します。
データを通信するにあたって、まず考慮すべき点が 3 つあります。
送信側のコード・セットと受信側のコード・セット
通信プロトコルが 8 ビット・データを許可するか、または 7 ビット・コード・データに限られているか
たとえば、日本のインターネットは JIS (日本工業規格) コード・データを 7 ビット・プロトコルで通信します。
プロトコル規則ごとにある変換エンコーディングの型
実際に必要となる変換は、使用される個々のプロトコルに依存します。
リモート・ホストがローカル・ホストと同じコード・セットを使用する場合は、次の事項が真になります。
プロトコルが 8 ビット・データを使用できる場合、変換は不要
プロトコルが 7 ビット・データしか使用できない場合、8 ビット・コード・ポイントを 7 ビット ASCII 値にマップする必要がある
これは、iconv() フレームワークと、次の 7 ビット・エンコード方法の 1 つを使って達成できます。
8 ビット・データを、POSIX.2 仕様の uuencode および uudecode アルゴリズムに指定されているとおりにマップする。
任意で、8 ビット・データをプロトコルで定義されているように 7 ビット変換エンコーディングにマップする。たとえば、Xlib の 7 ビット ISO2022 や MIME (Multipurpose Intrenet Message Extensions: 多目的インターネット・メッセージ拡張機能) の base64 があります。
リモート・ホストのコード・セットがローカル・ホストのコード・セットと異なるときは、次の 2 つの場合が当てはまります。必要な変換は、使用される特定のプロトコルに依存します。
プロトコルが 8 ビット・データを使用できる場合、プロトコルはどちら側が iconv() 変換を行うかを指定し、また回線上でのエンコーディングを指定する必要があります。プロトコルによっては、可能なコード・セットのすべてをエンコードでき、文字レパートリーを識別する機能のある 8 ビット変換エンコーディングを推奨します。
プロトコルが 7 ビット・データしか使用できない場合は、7 ビット変換エンコーディングと文字レパートリーの識別が必要です。
ネットワーク環境では、通信し合っているシステムのコード・セットと通信のプロトコルによって、ユーザの指定したデータが意味ある方法でリモート・システムに送信されるように、データの変換方法が決定されます。(ユーザ名でなく) ユーザ・データを送信側のコード・セットから受信側のコード・セットに変換したり、プロトコルに準拠するよう 8 ビット・データを 7 ビット形式に変換する必要があります。このことを達成するには一様なインタフェースが必要です。
次の例では、iconv_open()、iconv()、iconv_close() の使い方を説明し、iconv() インタフェースの使用方法を示しています。この変換を実行するには、 iconv_open() の次に必ず iconv() を続けてください。7 ビット変換および 8 ビット変換という用語は、それぞれ 7 ビット・データと 8 ビット・データの変換エンコーディングの意味で使用します。
プロトコルが 8 ビット・データを使用できる場合は、同じコード・セットが使用されているので 8 ビット・データを使用します。変換は必要ありません。
プロトコルが 7 ビット・データしか使用できない場合は、iconv() を使用します。
locale_codeset は、そのロケールのアプリケーションによって使用されているコード・セットです。nl_langinfo()(CODESET) 関数を使用して現在のロケールに関連付けられたコード・セットを獲得できますが、それは変換名が nl_langinfo()(CODESET) 関数からの戻り値と一致するかどうかは実装に依存します。
表 3-1 に、さまざまな条件のもとで変換を実行する際の iconv() の使用方法を示します。プロトコルによっては他の変換が必要な場合もあります。
表 3-1 変換を実行するための iconv の使用方法
|
同じコード・セットを使用するシステムとの通信 (例: XYZ) |
異なるコード・セットを使用するシステムとの通信、または受信側のコード・セットが不明 |
||
使用する変換 |
7 ビット・プロトコル |
8 ビット・プロトコル |
7 ビット・プロトコル |
8 ビット・プロトコル |
コード XYZ |
無効 |
最適 |
無効 |
リモート・コード・セットが不明の場合無効 |
7 ビット変換 ISO2022 |
OK |
OK |
最適 |
OK |
8ビット変換 ISO2022, ISO10646 |
無効 1 |
OK |
無効 |
最適 |
7 ビットタグなし引用符付き印刷可能な uucode |
OK |
OK |
コード・セットの識別が必要 |
コード・セットの識別が必要 |
8 ビットタグなし base64 |
無効 |
OK |
コード・セットの識別が必要 |
コード・セットの識別が必要 |
無効とは、選択したコード・セットとプロトコル型には変換エンコーディングは使用すべきでないという意味です。
コード・セットは、状態を持つ (ステートフルな) エンコーディングと状態を持たない (ステートレスな) エンコーディングの 2 つのカテゴリに分類できます。
状態を持つエンコーディングは、特定のコード値に関連付けられた文字セットを変換するのに、シフトイン / シフトアウトなどの制御コードのシーケンスを使用します。
たとえば、コンパウンド・テキストでは、文字データの流れの中で日本語 16 ビット・データの開始を示すのにコントロール・シーケンス「ESC$(B」を使用できます。また、「ESC(B」は、そのダブルバイト文字データの終了と 8 ビット ASCII データの開始を示すのに使用できます。状態を持つエンコーディングでは、ビット値 0x43 はシフト状態が不明の場合解釈できません。EBCDIC アジア・コード・セットは、シフトイン制御とシフトアウト制御を、それぞれダブルバイトとシングルバイト・エンコーディング間の入れ換えに使用します。
別のコード・セットへの状態を持つエンコーディング変換を行うために記述されるコンバータは、特別な処理が必要なためにやや複雑になります。
状態を持たないコード・セットは、次の 2 つのうちの 1 つに分類できます。
シングルバイト・コード・セット (ISO8859 ファミリなど)
マルチバイト・コード・セット (日本語用 PC コード、通称 Shift-JIS (SJIS) など)
マルチバイト・コード・セットという用語は、1 つの文字をエンコードするのに 1 つ以上のバイトを必要とするコード・セットにも使います。マルチバイト・コード・セットは状態を持たないと見なされます。
コード・セットが同じ文字セットを表すときに限り、変換してください。
あるプログラムがリモート・ホストにある別のプログラムにデータを通信するとき、元のマシンのコード・セットから受信側のコード・セットへデータを変換する必要が生じることがあります。たとえば、PC コードを使用している PC システムが、ISO/EUC (国際標準化機構 / 拡張 UNIX コード) のエンコーディングを使用しているワークステーションと通信する必要があるときなどです。また、プログラムがあるコード・セットのデータを獲得したが、そのデータを別のコード・セットで表示しなければならない場合も同様です。そのような変換をサポートするために、XPG4 iconv() 関数定義に基づく標準プログラム・インタフェースが用意されています。
コード・セット変換を行うすべてのコンポーネントは、変換のインタフェースとして iconv() 関数を使用してください。システムは、変換のデフォルト・セットをカスタマイズする機構の他に、広範囲の変換を提供することを期待されます。
1 つのコード・セットから別のコード・セットへ変換する共通の方法は、テーブルを使う方法です。場合によりテーブルが大きすぎることもあります。この時は、アルゴリズムによる方法が望ましい方法です。多様な要求事項を満たすために、XPG4 にコード・セット変換のフレームワークが定義されています。そのフレームワークでは、あるコード・セットから別のコード・セットに変換するにはコンバータを開き、変換を実行し、コンバータを閉じます。iconv() 関数には iconv_open()、iconv()、iconv_close() があります。
コード・セット・コンバータは、関数 iconv_open()、iconv()、iconv_close() のフレームワークの下にあります。これらの関数により、数種類の異なる型のコンバータを提供し、使用することができます。アプリケーションは、あるコード・セットの文字を別のコード・セットの文字に変換するのにこれらの関数を呼び出します。iconv() フレームワークにより、コンバータが一様に提供できるようになります。このようなコンバータのアクセスおよび使用は、X/Open XPG4 で標準化されています。
X ICCCM マルチバイト関数 |
ICCCM ワイド文字関数 |
XmbTextPropertyToTextList() |
XwcTextPropertyToTextList() |
XmbTextListToTextProperty() |
XwcTextListToTextProperty() |
libXm() ライブラリは、XmStringConvertToCT() 関数と XmStringConvertFromCT() 関数を提供します。しかし、特定の XmString タグにはハードコードされた前提条件があるため、それらの関数は推奨できません。たとえば、タグが bold() の場合、XmStringConvertToCT() は処理系に依存します。さまざまなプラットフォームで、この関数の動作を世界のすべての地域では保証できません。
詳細は、「ローカライズされたテキストのクライアント間通信規約」を参照してください。
タイトルを設定する一般的な方法は、リソースを使用することです。しかしアプリケーションが直接ウィンドウのタイトルを設定する場合は、ローカライズされたタイトルをウィンドウ・マネージャに送信しなければなりません。次のガイドラインの他に、XICCEncodingStyle() に定義された XCompundTextStyle() エンコーディングを使用してください。
コンパウンド・テキストは、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 (簡易メール転送プロトコル) です。SMTP は 7 ビット転送チャネルだけをサポートします。
この他に、電子メールの手順については次のような点があげられます。
送信側プログラムは、(ユーザが別の手順を指定しなければ) デフォルトで、本文の部分を送信側の転送チャネルの標準形式に変換し、使用される文字エンコーディングで本体の部分にラベル付けします。
受信側プログラムは文字エンコーディングをサポートできるかどうか知るために本文の部分を見ます。サポートできる場合はローカル文字セットに変換します。
さらに、メッセージには MIME 形式が使用されるため、8 ビットから 7 ビットへの変換は、組み込み MIME 転送エンコーディングを使用して実行されます (base64 または引用符付き表示可能形式)。RFC (Request for Comments) 1521 MIME 標準仕様を参照してください。
コード・セットを理解するには、まず文字セットを理解することが必要です。文字セットは、文字を表すのに使用するエンコーディング値は考慮せずに、1 つ以上の言語の特定のニーズに基づいてあらかじめ定義された文字の集まりです。どのコード・セットを使用するかの選択は、ユーザのデータ処理要件に依存します。特定の文字セットは、異なるエンコーディング・スキーマを使用してエンコードされます。たとえば、ASCII 文字セットは英語の中で見つけられる文字のセットを定義します。JIS (日本工業規格) の文字セットは、日本語で使用される文字のセットを定義します。英語および日本語の文字セットは、両方とも異なるコード・セットを使用してエンコードされます。
ISO2022 標準は、コード化文字セットを、文字セットと、各文字とそのビット・パターンの一対一の関係を定義する細かい規則の集まりとして定義します。コード・セットは、システムが文字を識別するのに使用するビット・パターンを定義します。
コード・ページはコード・セットに似ていますが、コード・ページの仕様は 16 列 * 16 行のマトリクスに基づくという制限があります。各列と行の交わりが、コード化文字を定義します。
共通オープン・ソフトウェア環境のコード・セット・サポートは、ISO (国際標準化機構) と、ユーザのデータ処理ニーズを満たす業界標準のコード・セットを提供する業界標準コード・セットに基づいています。
システム上の各ロケールは、どのコード・セットを使用するか、またそのコード・セット内の文字がどのように処理されるかを定義します。システムには複数のロケールをインストールできるので、複数のコード・セットがシステム上の異なるユーザによって使用されます。システムが複数の異なるコード・セットを使用する複数のロケールで構成される一方、すべてのシステム・ユーティリティはシステムが単一のコード・セットの下で動作していると想定します。
ほとんどのコマンドは、ロケールが使用している下位のコード・セットについては何も知りません。コード・セットの知識は、コード・セットに依存しないライブラリ・サブルーチン (国際化対応ライブラリ) によって隠されています。コード・セットに依存しないライブラリ・サブルーチンは、コード・セット依存サブルーチンに情報を渡します。
多くのプログラムが ASCII に依存しているため、すべてのコード・セットには 7 ビット ASCII コード・セットが適正なサブセットとして含まれています。7 ビット ASCII コード・セットはサポートされているすべてのコード・セットに共通なので、7 ビット ASCII コード・セットの文字はポータブル文字セットと呼ばれることがあります。
7 ビット ASCII コード・セットは ISO646 定義に基づいており、制御文字、句読文字、数字 (0-9)、大文字と小文字の英字のアルファベットが含まれます。
各コード・セットは 2 つの主な領域に分かれます。
グラフィック・レフト (GL) 0-7 列
グラフィック・ライト (GR) 8-F 列
各コード・セットの最初の 2 列は、制御文字用に ISO 標準が確保しています。C0 と C1 は、それぞれグラフィック・レフトとグラフィック・ライトの領域用の制御文字を表すのに使用されます。
PC コード・セットは、グラフィック文字をエンコードするのに C1 コントロール領域を使用します。
残りの 6 列はグラフィック文字をエンコードするのに使用されます (図 3-1 参照)。グラフィック文字は印刷可能な文字と見なされます。制御文字は、デバイスとアプリケーションによって特別な機能を表すために使用されます。
ISO 定義に基づき、制御文字は動作を開始、変更、停止します。制御文字はグラフィック文字ではありませんが、場合によってはグラフィック表現を持つことができます。ISO646-IRV 文字セットの制御文字は、サポートされているすべてのコード・セット内にあります。C0 制御文字のエンコードされた値は、あらゆるコード・セットを通じて一貫しています。
各コード・セットは、各文字に固有のコード値が与えられるように、1 つ以上の文字セットに分かれると考えられます。ISO 標準は 6 つの列を文字のエンコーディングのために確保しており、グラフィック文字を制御文字の列でエンコードできません。
1 バイトの 8 ビットすべてを使用するコード・セットは、ヨーロッパ、中東その他のアルファベット言語をサポートします。そのようなコード・セットはシングルバイト・コード・セットと呼ばれます。シングルバイト・コード・セットは、文字のエンコーディングを制御文字を除いて 191 文字までに制限しています。
マルチバイト・コード・セットは、特定の文字をエンコードするのに必要なバイト数に関わらず、すべての可能なコード・セットを指します。オペレーティング・システムは 1 文字をエンコードするのに何ビットでもサポートできるので、マルチバイト・コード・セットには、8 ビット、16 ビット、32 ビット、あるいはそれ以上のビットでエンコードされた文字を含めることが可能です。シングルバイト・コード・セットもマルチバイト・コード・セットと考えられます。
EUC コード・セットは、一部の文字セットの中で文字を識別するのに制御文字を使用します。エンコーディング規則は ISO2022 の 7 ビット・データと 8 ビット・データのエンコーディングの定義に基づいています。EUC コード・セットは一部の文字セットを区切るのに制御文字を使用します。
EUC という用語はそのような一般的なエンコーディング規則を指します。EUC に基づくコード・セットは EUC エンコーディング規則に準拠しますが、特定の場合に関連付けられた特定の文字セットも識別します。たとえば、日本語用 eucJP は EUC エンコーディング規則による JIS 文字のエンコーディングを指します。
最初のセット (CS0) には常に ISO646 文字セットが含まれます。他のすべてのセットは、最上位ビット (MSB) を 1 に設定しなければならず、文字をエンコードするのに何バイトでも使用できます。さらに、1 つのセットの中のすべての文字は次のようでなければなりません。
すべての文字をエンコードするのに同じバイト数を使用する
列表示幅 (固定幅の端末での列数) が同じである
3 番目のセット (CS2) の各文字の前には、常に制御文字 SS2 (シングルシフト 2、0x8e) が付きます。EUC に準拠するコード・セットは、3 番目のセットを識別する目的以外では制御文字 SS2 を使用しません。
4 番目のセット (CS3) の各文字の前には、常に制御文字 SS3 (シングルシフト 3、0x8f) が付きます。EUC に準拠するコード・セットは、4 番目のセットを識別する目的以外では制御文字 SS3 を使用しません。
次のコード・セットは、ISO (国際標準化機構) により設定された定義に基づいています。
ISO646-IRV
ISO8859-1
ISO8859-x
eucJP
eucTW
eucKR
ISO646-IRV コード・セットは、7 ビット・エンコーディングに基づく情報処理に使用されるコード・セットを定義します。このコード・セットに関連付けられた文字セットは ASCII 文字から得られます。
ISO8859-1 エンコーディングは、その他の ISO、ANSI (米国規格協会)、ECMA (欧州コンピュータ製造者協会) のコード拡張技術に基づき、それらと互換性のあるシングルバイトのエンコーディングです。ISO8859 エンコーディングは、各メンバが独自の文字セットを持つコード・セットのファミリを定義します。7 ビット ASCII コード・セットは、ISO8859 ファミリの各コード・セットの適切なサブセットです。
ISO8859-1 コード・セットは ISO Latin-1 コード・セットと呼ばれ、2 つの文字セットから成ります。
ISO646-IRV グラフィック・レフト、7 ビット ASCII 文字セット
ISO8859-1 グラフィック・ライト (ラテン) 文字セット
これらを組み合わせた文字セットには、デンマーク語、オランダ語、英語、フィンランド語、フランス語、ドイツ語、アイスランド語、イタリア語、ノルウェー語、ポルトガル語、スペイン語、スウェーデン語などの西欧諸語に必要な文字が含まれます。
ASCII コード・セットが英語のアルファベット順に順序を定義する一方、GR (グラフィック・ライト) 文字は特定のどの言語によっても順序付けされません。言語固有の順序はロケールによって定義されます。
この節ではその他の重要な ISO8859 コード・セットをリストします。各コード・セットには ASCII 文字とそのコード・セット独自の文字があります。
ラテン・アルファベット、No.2、東欧
アルバニア語
チェコスロヴァキア語
英語
ドイツ語
ハンガリー語
ポーランド語
ルーマニア語
セルビア-クロアチア語
スロヴァキア語
スロヴェニア語
ラテン / キリル・アルファベット
ブルガリア語
白ロシア (ベロルシア) 語
英語
マケドニア語
ロシア語
ウクライナ語
ラテン / アラビア語アルファベット
英語
アラビア語
ラテン / ギリシャ語アルファベット
英語
ギリシャ語
ラテン / ヘブライ語アルファベット
英語
ヘブライ語
ラテン / トルコ語アルファベット
デンマーク語
オランダ語
英語
フィンランド語
フランス語
ドイツ語
アイルランド語
イタリア語
ノルウェー語
ポルトガル語
スペイン語
スウェーデン語
トルコ語
日本語用 EUC はシングルバイト文字とマルチバイト文字 (2 バイトと 3 バイト) から成ります。エンコーディングは ISO2022 に準拠し、JIS および EUC の定義に基づきます。
表 3-2 eucJP のエンコーディング
CS |
エンコーディング |
|
文字セット |
---|---|---|---|
cs0 |
0xxxxxxx |
|
ASCII |
cs1 |
1xxxxxxx |
1xxxxxxx |
JIS X0208-1990 |
cs2 |
0x8E |
1xxxxxxx |
JIS X0201-1976 |
cs3 |
0x8F |
1xxxxxxx 1xxxxxxx |
JIS X0212-1990 |
情報交換用の日本語のグラフィック文字セットのコード (1990 年版) です。この中には特殊文字が 147、数字が 10、ひらがな文字が 83、カタカナ文字が 86、ラテン文字が 52、ギリシャ文字が 48、キリル文字が 66、線描画要素が 32、漢字が 6355 含まれます。
カタカナを 63 文字含む、情報変換用コードです。
情報変換用の日本語のグラフィック文字セットの補助コード (1990 年版) です。この中には、追加の特殊文字が 21、追加のギリシャ文字が 21、追加のキリル文字が 26、追加のラテン文字が 27、発音区別符号の付いたラテン文字が 171、追加の漢字が 5801 含まれます。
繁体字用 EUC はシングルバイト文字とマルチバイト文字 (2 バイトと 4 バイト) を含む文字から成るエンコーディングです。EUC エンコーディングは、ISO2022 に準拠しており、中華人民共和国によって定義された CNS (Chinese National Standard) および EUC 定義に基づきます。表 3-3 を参照してください。
表 3-3 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 は、中国標準変換コード用に 16 の面を定義します。各面は、8836 文字 (94 * 94) までサポートできます。現在は、面 1〜7 のみ文字が割り当てられています。表 3-4 は、CNS 11643-1992 標準の 16 の各面を示しています。
表 3-4 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 |
RIS 2、ベンダ定義 |
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 |
EDP: 予算、会計、統計の中央理事会
RIS: 居住地情報システム
MOE: 文部省
韓国語用 EUC は、シングルバイト文字とマルチバイト文字から成るエンコーディングです (表 3-5 参照)。エンコーディングは ISO2022 に準拠し、KSC (韓国語標準コード) セットと EUC 定義に基づきます。
表 3-5 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 含まれます。
1 つのハングル文字は子音と母音から成ります。ハングルのほとんどの単語はハンジャの単語でも表現できます。ハンジャは繁体字のセットであり、現在韓国語圏の人々に使用されています。各ハンジャには意味があるので、ほとんどの場合ハングルよりも明確です。