添付資料のコード変換規則のテーブルに一部間違いが見つかりましたので 訂正しました. 訂正したのは以下のテーブルです.
Microsoft Windows 3.51 式の変換
JIS X 0208 漢字
JIS X 0221 式の変換 (ASCII と併用する場合)
JIS X 0212 補助漢字
添付資料のコード変換規則のテーブルに一部間違いが見つかりましたので 訂正しました. 訂正したのは以下のテーブルです.
Microsoft Windows 3.51 式の変換
JIS X 0212 補助漢字
Unicode および ISO/IEC 10646-1 (以下, UCS と総称する) は1993年に規定さ れた新しいコードセットであり, いくつかの応用分野において徐々に使われだそ うとしている.
UCS には, 漢字が約2万文字, その他記号類も多数登録されているが, それで も日本や中国, 台湾, 韓国などで使われている (または使われていた) 漢字や記 号類のすべてをカバーしているわけではなく, ユーザ定義文字の利用は必要と考 えられる. また, これまで日本で使われてきたコードセットには, ベンダ定義文 字も多数含まれているが, すべてのベンダのベンダ定義文字が UCS に取り入れ られたわけではないため, UCS と既存のコードセットとのコード変換の際には問 題になるだろう.
ユーザ定義文字やベンダ定義文字については, UCS でも実装依存になっている ため, なにも取り決めがない場合, 相互運用上の問題になる. ここでは, それを 避けるための解決策を検討する.
ここでは, 次に示す各問題について考察する.
UCS では, 似たような形をした文字が定義されたコードポイントがいくつもあ り (たとえば, 「〜」に似た文字は, UCS では 0x301C, 0x223C, 0x223D, 0x223E, 0x223F の各コードポイントに定義されている), 既存のコードセットとの間の変換の際 にどのコードポイントに対応付けるかが問題となる.
UCS では Private Use Area (PUA) として6400文字のコードポイントがあり, ユーザ定義文字のために利用可能だが, 6400文字を超えたユーザ定義文字が必 要な場合どうすればよいかが問題である.
既存のコードセットとのコード変換を考えた場合, JIS X 0201, JIS X 0208 および JIS X 0212 の各規格で規定されている文字にはすべて対応するコードポ イントが UCS 内にあるはずだが, ベンダ定義文字についてはそのような保証は なく, UCS 側に対応する文字が存在しないことがある. この場合にどう対処する かが問題となる.
UNIX システムではロケールを切り換えることによって一つのシステム上で日 本語・中国語・韓国語など複数の言語を使用できる. ユーザ定義文字を使用する 場合, 日本語ロケールと中国語ロケールとでは違う種類の文字を定義したいこと が考えられるが, UCS を使用する場合これらを共存させるかどうかが問題となる.
この章では, 前の章で提起された各問題について, 解決策を検討する.
ここでは, eucJP-open と UCS との間のコード変換について考える. コード変 換において問題となるのは次の点である.
UCS には似たような形をした文字がいくつもあり, 既存のコードセットとの 対応付けが一対一にならず, 一対多になる場合がある. たとえば, JIS X 0208 の1区33点の「〜」（波ダッシュ）に似た UCS の文字は,
0x301C WAVE DASH 0x223C TILDE OPERATOR 0x223D REVERSED TILDE 0x223E INVERTED LAZY S 0x223F SIGN WAVE 0xFF5E FULLWIDTH TILDE
の各種がある. JIS X 0221 (ISO 10646 の JIS 版) 附属書3表3では, 名前の一致と形の類似から 0x301C を選んだが, Windows NT 3.51 で採用されているコード変換では 0xFF5E を選んでいる.
同様の問題は「〜」のほか, 「―」, 「‖」, 「−」で発生している.
解決としては,
の2つが考えられる. a. と b. とは両立できるが, UCS からの変換においても b. の方式を選択することも可能である.
UCS では, 一つの文字には一つのコードポイントを割り当てるのを原則として いるが, 他のコードセットからのコード変換を保証するため, 全角 (FULLWIDTH) および半角 (HALFWIDTH) という名前の付いた文字を制限使用領域 (R-Zone) に 定義している. 「Ａ」や「ア」のように日本語 EUC やシフト JIS に全角・半角 の両方が存在する文字の場合, 対応付けは自明であるが, 「£」や「¢」のよう に日本語 EUC やシフト JIS には全角の方しかないのに, UCS には FULLWIDTH のものとそうでないものとが存在する場合, どちらに対応付けるかが問題となる. JIS X 0208 の実装では「£」は「全角」で表示されることが多く, その点から は FULLWIDTH に対応付けることも考えられるが, 「本来コードセットの規格に は, 文字がどんな幅で表示されるかなどといったことまでは決めていない. HALFWIDTH や FULLWIDTH のような制限使用領域の文字は, どうしても必要な場 合以外は使うべきではない」という考えからは FULLWIDTH でない方に対応付け るべきである.
この問題によって JIS X 0208 と UCS との変換に問題が出るのは, 「£」や 「¢」, 「¬」がある.
これも, (1) と同様の解決が採用できる. つまり,
UCS には, JIS 等の既存の規格に存在した文字はすべて含まれているはずだが, ベンダ定義文字のように規格に存在しなかった文字は含まれているとは限らない. また, 規格でも空きのコードポイントには文字が規定されていないので, 対応する UCS のコードポイントはない.
このような, UCS に存在しないコードポイントを変換する場合にどうするかは 問題となる.
これには2通りの対策が考えられる.
b. の方式は, ベンダ間で共通の解決案を作るのは難しい. 従来製品との互換 が必要なベンダが個別に対応するのが現実的だろう.
共通の解決としては, a. の方式で対応表をつくるのがよいだろう.
日本ではいわゆる半角英数字のコードセットとして, ISO 646 IRV (ASCII) そ のものではなく, ISO 646 の日本版である JIS X 0201 ラテン文字が使われるこ とが多い. ASCII と JIS X 0201 ラテン文字との違いは, 次の2文字である.
コードポイント ISO 646 IRV JIS X 0201 Latin 0x5C ＼ ￥ 0x7E 〜 ￣
しかし, コードポイントがたまたま同じ所にあるため, 0x5C のコードポイント を見かけ上は円記号「￥」であるが意味上は逆斜線「＼」として扱うことが多か った. たとえば, C 言語プログラムで「￥ｎ」を「＼ｎ」のつもりで使ったり, MS-DOS や Microsoft Windows でパス名の区切り文字に「＼」ではなく「￥」を 使うのがそうである. 0x7E のコードポイントにも同様の問題があるが, この コードポイントは 0x5C ほど重要な用途には使われていなかったこと, および, JIS X 0201 規格上は「上線」であるにもかかわらず「チルダ」のように見える 実装もあることから, この問題はもっぱら「￥問題」(yen sign problem) と呼 ばれることが多い.
「＼」と「￥」との区別は, UCS のように「＼」と「￥」との両方のコードポ イントが存在するコードセットとの間のコード変換をする際には次のような問題 が発生する.
UCS ではさらに「全角の逆斜線」と「全角の円記号」という2つの文字が存在 するため, 前に説明した全角・半角問題とからんで変換ルールが多様化してしま う.
Windows 3.1/NT/95 では, この問題に対して
という解決を取っている.
これに対する解決案としては,
の2通りが考えられる. 0x7E を「チルダ」とするか「上線」とするかを 0x5C の 問題と別とすれば, a. では最大4通りのコード変換になってしまうが, 実際には すべてが必要になることはないだろう.
前節で述べたように, コード変換規則をただ一つに決めるのは問題が多い. そ こで, ここでは次の3通りのコード変換を規定し, 用途によって使い分けること にする.
このコード変換規則は, Windows の動作するコンピュータとの間のデータ交換 に使われることを想定している.
この場合, 「￥」や「＼」の変換は次の表のようになる.
| eucJP-open | UCS |
| \ (0x5C) | YEN SIGN (0x00A5) |
| ~ (0x7E) | OVERLINE (0x203E) |
| ＼ (0xA1C0) | REVERSE SOLIDUS (0x005C) |
| ￥ (0xA1EF) | FULLWIDTH YEN SIGN (0xFFE5) |
| ￣ (0xA1B1) | FULLWIDTH MACRON (0xFFE3) |
このコード変換規則は, 0x5C のコードポイントが「￥」であることを前提と したデータの変換に使われることを想定している.
この場合, 「￥」や「＼」の変換は次の表のようになる.
| eucJP-open | UCS |
| \ (0x5C) | REVERSE SOLIDUS (0x005C) |
| ~ (0x7E) | TILDE (0x007E) |
| ＼ (0xA1C0) | FULLWIDTH REVERSE SOLIDUS (0xFF3C) |
| ￥ (0xA1EF) | YEN SIGN (0x00A5) |
| ￣ (0xA1B1) | OVERLINE (0x203E) |
このコード変換規則は, 0x5C のコードポイントが「＼」であることを前提と したデータの変換に使われることを想定している.
具体的なコードポイントの対応については, 添付資料 を参照.
次に, 本 WG で規定した日本語 EUC(eucJP-open)と UCS との間のユーザ定義 文字領域のコード変換仕様を規定する.
ユーザ定義文字領域として利用可能な eucJP-open の 自由領域は, G1:JIS X 0208 の85区〜94区, G3:JIS X 0212 の78区〜82区, および85区〜94区 からなる. ただし, G3:JIS X 0212 の78区〜82区は, JIS X 0212 の「保留領域」 であり, 将来の JIS X 0212 の拡張に備え, この領域へのユーザ/ベンダ定義 文字の割り当てをできる限り行なわない事を, 本 WG では推奨している.
ここで規定するユーザ定義文字のコード変換仕様では, eucJP-open のユーザ 定義文字領域を, UCS の PUA に割り付ける事によって, eucJP-open←→UCS 間のコード変換を実現する.
eucJP-open と UCS との間のユーザ定義文字領域のコード変換は, 次のような 変換規則に従うものとする.
UCS eucJP-open 0xE000〜0xE3AB
0xE3AC〜0xE757G1 85区〜94区
G3 85区〜94区
IBM : IBM拡張文字 (eucJP-open G3 83区〜84区)
UCS のユーザ定義文字領域として BMP (Basic Multilingual Plane) の PUA を使用できるが, この領域は6400文字に制限されている. 6400個を超える ユーザ定義文字を使用する手段として, 次の方法を検討した.
UCS には未定義の保留領域がいくつかあり, これらにユーザ定義文字を 割り当てたとすれば, 6400文字を超えるユーザ定義文字を使用できることになる. しかし, 保留領域は将来の標準化や拡張に使用される可能性があり, 他の目的で 使用してはならないとされている. 現に, これまで UCS の 0xA000 〜 0xDFFF は 保留領域とされていたが, Unicode Version 2.0で 0xAC00 〜 0xD7A3がハングルの 領域と定義し直された.
このように, 保留領域は特別な用途や将来の拡張に使われる可能性が高いため 問題が多く, ユーザ定義文字として使用するべきではない. よって, この方法は 採用しないこととする.
UTF-16 は, BMP に加えて16面 (planes) 分の文字を扱えるように UCS-2 を 拡張したものである. 面 0x00 つまり BMP の領域の文字は, そのまま2バイトで 表現される. 面 0x01〜0x10 の文字は, high-half zone codes を 0xD800〜0xDBFF, low-half zone codes を 0xDC00〜0xDFFF とした4バイトで 表現される. そのうち, 面 0x0F と 0x10 を私用領域として使うことができる. つまり, UTF-16 を利用することにより, 2×65536=131072 個のユーザ定義文字を 使用することが可能となる. UTF-16 の仕様と標準化の動向については, 次の URL を参照.
http://www.dkuug.dk/JTC1/SC2/WG2/
UCS-2 では, 全ての文字を2バイト固定長で扱えるという利点があった. しかし, UTF-16 を使用すると, 面 0x00 つまり BMP の文字は 2バイトで, 面 0x01 〜 0x10 の文字は 4バイトで表現され, 1文字が2バイト固定長でな くなるため, 文字処理が複雑になる可能性がある.
UNIX では, UTF-8 や UCS-4 をファイルもしくは内部処理のコードとして 使用する可能性が高く, UCS-2 は他の処理系との互換性を取る際に使われる のが一般的である. したがって, UCS-2 の拡張としての UTF-16 を使用する よりもむしろ, UNIX の方式に合った次節の方法を採るべきである.
ISO/IEC 10646-1 の仕様および UTF-16 の拡張仕様では, 次の群(group) および面(plane)を私用領域とすることが定められている. これらの領域を利用すれ ば, 膨大な数のユーザ定義文字を扱うことができる.
UNIX では, 処理コードつまり固定長のワイド文字のサイズとして, 32ビットを 使用できるシステムが一般的である. そこで, UNIX で UCS を扱う際のワイド 文字列の形式を UCS-4 とし, 上記の Private Use Plane (PUP) をユーザ定義 文字領域として利用することを推奨する. その際, コードの小さい領域つまり 群 0x00 の面 0x0F と 0x10 から使用することを推奨する.
UNIX で UCS を扱う場合, ファイルコードつまりマルチバイト文字の形式として UTF-8 を使用することを推奨する. また, 処理コードつまりワイド文字の形式とし て UCS-4 を使用することを推奨する. PUP をユーザ定義文字として利用するにあ たり, UCS-4 を UTF-8 に変換したコードをマルチバイト形式として使用すること になる.
ベンダが独自に割り当てたベンダ定義文字を, UCS のいずれかのポイントに マッピングするには, 次の方法が考えられる.
この割り当て方法は, 上記の理由から不適切と思われる.
この方法では, 131072個のベンダ定義文字を使用することが可能になるが, 3.3.1 の 2. と同様に, 各ベンダの割り当てを順番・領域等について協議しなくては ならず, 実現が困難である.
BMP の空き領域には代表的に以下のものがある.
この割り当ては, 以上の理由から不適切と思われる.
結論として, 以上のようにベンダ定義文字のマッピングに関しては, そのマッピング先 を決定することが困難なため規定しないこととする.
日本, 韓国, 中国, 台湾の各国では, UCS を除き, それぞれ独自のコード セットが使われており, ユーザ定義文字領域もそれぞれ独自に定義されている. 各国の既存のコードセットと, UCS のマルチリンガル環境との間で, ユーザ定義 文字データの相互運用性を保つためには, UCS のユーザ定義文字領域を各国ごと に分割して個別に定義し共存をはかることが考えられる.
まず考えられる方法は, PUA を各国ごとに分割することである. しかし, PUA は 6400 文字に限られるし, 他国の標準との関連や, 他のプラットフォ ームとの互換性の点から, 以下の問題点がある.
文字数の制限 (1) については, 3.2.3 の方法を使用することで解決できる 可能性がある. しかし, この方法でも依然として他の問題が残る. また, 他 の問題については, 他国や他の多くのベンダと協議をする必要があるため, 実現はかなり困難であると思われる.
したがって, 本 WG では日本における推奨のみを定めることとし, 各国 のユーザ定義文字の共存は考えないものとする.
Windows NT 漢字処理技術協議会は, Windows NT 上の Unicode での 漢字処理の拡張仕様として, Windows NT 拡張漢字処理仕様書 (XKP) の 第 2.0 版を公開した. この仕様書では以下の拡張が規定されている.
これらの拡張を利用するために, ユーザ定義文字を管理するユーザ定義文字 サーバが開発され, ユーザ定義文字サーバにアクセスするための API が規定された.
本 WG でこの XKP 2.0 の仕様を検討した結果, 以下の問題点があげられた.
以上の問題点から, 本 WG ではこの仕様について考慮しないこととする.
eucJP-open と UCS との間のユーザ定義文字領域のコード変換規則として, 次の3案が示された.
UCS eucJP-open 0xE000〜0xE3AB
0xE3AC〜0xE757
0xE758〜0xE92DG1 85区〜94区
G3 85区〜94区
G3 78区〜82区
IBM : IBM拡張文字 (eucJP-open G3 83区〜84区)
UCS eucJP-open 0xE000〜0xE3AB
0xE3AC〜0xE757
0xE83C〜0xF8FFG1 85区〜94区
G3 85区〜94区
G3 78区〜82区
IBM : IBM拡張文字 (eucJP-open G3 83区〜84区)
UCS eucJP-open 0xE000〜0xE3AB
0xE3AC〜0xE757G1 85区〜94区
G3 85区〜94区
IBM : IBM拡張文字 (eucJP-open G3 83区〜84区)
(1)案の割り当て理由は, 次の通り.
マイクロソフト標準キャラクタセット仕様書で定義されている SJIS←→ Unicode の外字マッピングテーブルでは, SJIS のコードポイント 0xF040 〜 0xF9FC (95区 〜 114区) を Unicode の PUA 0xE000 〜 0xE757 に割り付けて いる. このマッピングで Unicode←→SJIS←→eucJP-open の相互変換において, ユーザ定義文字領域(UDC(A)およびUDC(B))の変換に, 一貫性を持たせることが できる.
(1)案では, eucJP-open の G3 78区 〜 82区の空き領域をユーザ定義文字とみなし, また, マッピングを簡単にするため, eucJP-open の G3 78区〜82区は, PUA の 0xE758〜0xE92D に, コードの小さいものから順に, 隙間なく詰めて割り当 てることとする.
(2)案の割り当て理由は, 次の通り.
UDC(A) および UDC(B) の変換は (1)案と同じである.
現在, マイクロソフト標準キャラクタセット仕様書では, Unicode←→SJIS 間 のユーザ外字のマッピングテーブルでは, SJIS の 0xF040〜0xF9FC の間の 1880 文字に対してのみ, 変換が定義されており, PUA の 0xE758 以降につい ては, どのような用途で使用するか, 決められていない.
(2)案では, eucJP-open の G3 78区 〜 82区の空き領域をベンダ定義文字とみなし, 今後, マイクロソフトにより, 0xE758 以降の 4520 文字分の空き領域の使用 に関して, 規約が拡張された場合を考慮し, eucJP-open の G3 78区 〜 82区 を, PUA の終端から逆順にマッピングする.
(3)案の割り当て理由は, 次の通り.
UDC(A) および UDC(B) の変換は (1)案と同じである.
eucJP-open の G3:JIS X 0212 78区〜82区(共通自由領域)は, 次に挙げる 理由から, 本仕様では変換規則を定めない.
同領域のコード変換については, 今後, マイクロソフト, JIS などで, UCS←→JIS X 0212 の変換規則が拡張(規定)された場合, その規則に従う.
これらの案を検討し, 各社の意見を集めたところ, 多数派となった (3)案を 採用することとした.
この文書では, 次の用語を使用する.
ISO/IEC 10646-1:1993 (ISO 10646 と略記する場合が多い) および The Unicode Standard で規定されたコードセットを総称して UCS と呼ぶ. ISO 10646 には各種の実装水準 (implementation level) が規定されているし, 16ビットコードセットである UCS-2 と32ビットコードセットである UCS-4 との 2種類のコードセットが規定されている. また, ISO 10646 と Unicode には, コード表としては同じものを採用しているが, 規定内容には細かい違いがある. UCS という名前はこれらを総称した名前であり, そのような違いを無視してよい 場合に使用する. Unicode や UCS-4 などに個別の特徴について論じる場合は, そのように明示する.
なお, JIS X 0221 は ISO 10646 の翻訳規格であり, 附属書1〜3を追加規定 した以外は技術的に同一である. 追加された附属書は次の通り.
ISO/IEC 10646-1 では基本的には32ビットのコードセットを規定しており, そ れを上位ビットから8ビットごとにそれぞれ群・面・区・点と呼んでいる.
群 (Group) 面 (Plane) 区 (Row) 点 (Cell)
ただし, 実際には16ビットのコード表である面の単位で扱われることが多く, 区や点のレベルが意味をもつことは少ない.
群 0x00 の面 0x00 を Basic Multilingual Plane (基本多言語面) と呼ぶ. 1996年現在, ISO/IEC 10646-1 において文字が定義されているのはこの BMP だ けである.
UCS-2 または UCS-4 が直接使用できない環境において, UCS の文字セットを 処理・伝達したい場合に使用する変換形式.
UTF には, 8ビットの ASCII 互換の環境で使用するための UTF-8, 各バイトの 8ビット目が透過であることを保証できないインターネットの電子メールで使用 するための UTF-7, UCS-2 の16ビットコードの環境で 65586 個を超える文字を 使用するための UTF-16 などがある.
UTF-8 は ASCII と上位互換を保ちながら UCS の文字を利用できるようにした 変換形式である. UTF-8 では, 0x0000〜0x007F の範囲が1バイト, 0x0080〜 0x03FF の範囲が2バイト, 0x0400〜0xFFFF の範囲が3バイト……となっており, UCS-2 の範囲ならば最大3バイト, UCS-4 の範囲ならば最大6バイトまでで表現 できる可変長コードである. 各文字は, 最初の1バイトを見ればその文字が何バイト の文字かわかるようになっている.
UTF-16 は, UCS-2 を使いつつ群 0x00 の面 0x01〜0x10 の範囲の文字も使える ようにした変換形式である. UCS-2 では普通は1文字が16ビットであるが, UTF-16 では特定の範囲のコードポイントを BMP 以外$NLL$r;H$&$?$a$KM=Ls$7, 16ビットのコードポイント2つで面 0x01〜0x10 の範囲の文字1個を表現している.
UCS では, ユーザ定義文字やベンダ定義文字のような用途に使ってもよい領 域として PUA (私用領域) を規定している. これは BMP の 0xE000〜0xF8FF の 6400文字の領域である.
UCS では, 面全体が私用に使ってよい私用面 (Private Use Plane) が規定さ れている. 群 0x00 の面 0x0F, 0x10 および 0xE0 〜 0xFF, ならびに群 0x60 〜 0x7F のすべての面が私用面である.
標準で規定されたコードセットの中の空きコードポイントに, ユーザが独自に 追加定義した非標準の文字. コードセットによって利用できる空きコードポイン トの数が違うため, ユーザ定義文字の数やコードポイントの範囲はコードセット に依存する.
標準で規定されたコードセットの中の空きコードポイントに, ベンダが独自に 追加定義した非標準の文字. コードセットによって利用できる空きコードポイン トの数が違うため, ベンダ定義文字の数やコードポイントの範囲はコードセット に依存する.
ある文字セットの個々の文字に対して, ユニークなコードの値（コードポイン ト）を割り当てたもの. なお, エンコーディング方式もコードセットの一種とし て扱う. また, コード変換は code set conversion と訳す.
あるコードセットで定義される文字の集合. 文字セットについて議論する場合, それぞれの文字にどのようなコードの値（コードポイント）が割り当てられるか については無視することが多い.
複数のコードセットを組み合わせて一つのコードセットを構成する場合の, コー ドポイントを割り当てる規則のこと. 日本語 EUC 及び シフト JIS は, どちら も JIS X 0201 ラテン文字, JIS X 0201 片仮名及び JIS X 0208 漢字という３ つのコードセットを組み合わせて使用する際のエンコーディング方式だと言える. (ただし, 日本語 EUC の場合, 4 つ目のコードセットも利用可能)
あるコードセットの中で個々の文字に対して割り当てられたコードの値のこと を, その文字のコードポイントと呼ぶ. たとえば, 「あ」のコードポイントは, シフト JIS では 0x82A0, 日本語EUCでは 0xA4A2 である.
以上