日本語EUCとSJIS間のコード変換
UNIXマシンとPCとの相互運(yùn)用性を考慮すると，UNIXマシン上の標(biāo)準(zhǔn)的な文字コードである日本語EUCとPC上の標(biāo)準(zhǔn)的な文字コードであるSJISとの統(tǒng)一されたコード変換は必要である．
いわゆるSJISというコード系にもいくつかのバリエーションが存在する．ここでは，PC上で現(xiàn)在，広く普及している文字コードということで，Microsoft Windows 3.1で定義されている「マイクロソフト標(biāo)準(zhǔn)キャラクタセット」を選択した．
また，日本語EUCは各社で詳細(xì)について様々な実裝がされているようだが，ここでは，標(biāo)準(zhǔn)的なUI-OSF共通日本語EUCをベースとした．
日本語EUCとSJISとの間のコード変換において次のことに留意する必要がある．
- 日本語EUCにはJIS X0212があるがSJISにはない．
- ユーザ定義文字の文字?jǐn)?shù)が異なる．
- SJISにはNEC特殊文字, IBM拡張文字, NEC選定IBM拡張文字があるが，日本語 EUCにはない．
- 単純にコード変換を行なうとSJISの95區(qū)～120區(qū)という領(lǐng)域を日本語EUCにおいてマップする領(lǐng)域がない．
日本語EUCとSJISとの間のコード変換において本W(wǎng)Gは次のことを要求仕様とした．
- SJISで使われている文字が落ちない．
- SJISベースのシステムと日本語EUCベースのシステムとが混在し，データ交換を行いながら協(xié)調(diào)動作する場合は，たとえ日本語EUCベースのシステムでは JIS X 0212の文字が利用可能であっても，SJISベースのシステムではそれらのデータがすべて受け取れるわけではないので，結(jié)果としてJIS X 0212の文字がすべて使われることはない．
要求仕様に基づきコード変換案が作成されたがこれを大別すると，次の2つになった．
- 日本語EUCにおけるJIS X0208およびJIS X0212の空き領(lǐng)域にSJISの95區(qū)～ 120區(qū)を割り當(dāng)てる．
- 日本語EUCのG3領(lǐng)域(コードセット3)にJIS X0212が存在しないものとして， SJISの95區(qū)～120區(qū)を割り當(dāng)てる．
ここで，JIS X0212を日本語EUCでどうするかが論點(diǎn)となったが，各社の意見を集めたところ，JIS X0212を必要とする意見が大勢を占め，JIS X0212を不要とする意見はわずかであった．
これにより，(a)のJISの空き領(lǐng)域にSJISの95區(qū)～120區(qū)を割り當(dāng)てることを方針として，コード変換案を作成することとした．
この方法では，SJISのNEC選定IBM拡張文字の領(lǐng)域がつぶれてしまうが，次の理由で問題無い．
- NEC選定IBM拡張文字と同じ文字が，IBM拡張文字にある．
- Windows3.1 上でcut&pasteすると，NEC選定IBM拡張文字がIBM拡張文字に変換されてしまう．
- マイクロソフトのマニュアルでも，NEC選定IBM拡張文字は使わないように指導(dǎo)している．
コード変換の処理においては，SJISから日本語EUCへの変換の際には，変換元文字としてNEC選定IBM拡張文字を使用せずに，あらかじめSJISの処理系內(nèi)で， NEC選定IBM拡張文字をIBM拡張文字に変換しておくこととする．SJISから日本語EUCの変換の際に変換元文字として，NEC選定IBM拡張文字が現(xiàn)れた場合，変換不能文字として置換文字に置換されるものとする．
具體的な割り當(dāng)て案としては，次のようになった．
| SJIS |
EUC |
| (a) 95區(qū) - 104區(qū) |
(A) G1 85區(qū) - 94區(qū) |
| (b) 105區(qū) - 114區(qū) |
(B) G3 85區(qū) - 94區(qū) |
| (c) 115區(qū) - 120區(qū) |
(C) G3 79區(qū) - 84區(qū) |
ここで日本語EUCのG3側(cè)，JIS X0212の空き領(lǐng)域への割り當(dāng)てで，次の點(diǎn)が議論となった．
- JIS X 0212 の後ろの空き領(lǐng)域は17區(qū)あるが，SJIS のうち G3 に対応付ける必要があるのは16區(qū)であり，空きをどこに置くか
- ユーザ定義文字と IBM 拡張文字をそれぞれ日本語EUC側(cè)の(B)(C)どちらの領(lǐng)域に置くか
具體的に次の3案が示された．
(1)案の割り當(dāng)て理由は，次の通り．
- コード順をひっくり返すより，SJIS 105區(qū)～120區(qū)を X 0212 の79區(qū)以降に対応付けた方が単純でよい．
- JIS では，將來の文字の追加は JIS X 0221 (ISO/IEC 10646-1 の JIS 版) に対して行う方針であり，X 0212 に対する文字の追加は考えなくてよいのでは．
(2)案の割り當(dāng)て理由は，次の通り．
- 他の，文字?jǐn)?shù)の多いコードとの変換を考えると，78區(qū)から IBM 拡張文字を割り當(dāng)てて，後ろを空けておいた方がいいのでは．
(3)案の割り當(dāng)て理由は，次の通り．
- 78區(qū)～84區(qū)は JIS でいう「保留領(lǐng)域」であり，將來の拡張で使用される可能性があるので，ユーザ定義がつぶされるのを避けるため「自由領(lǐng)域」に置いた．78區(qū)を空けたのは，1區(qū)ぶんだけでも IBM 選定文字の範(fàn)囲がつぶされるのを遅らせるため．
各社の意見を集めたところ，多數(shù)派となった(3) 案とすること決定した．
なお，この変換案に対して，UI-OSF 共通日本語 EUC の規(guī)定に反するのではないかという疑問が出されたが，UI-OSF共通日本語 EUCの規(guī)定內(nèi)容は，
- JIS 未定義領(lǐng)域の中で，次の領(lǐng)域を「共通自由領(lǐng)域」として定める．
- JIS X 0208 の未定義領(lǐng)域のうち，85區(qū)から94區(qū)までの領(lǐng)域
- JIS X 0212 の未定義領(lǐng)域のうち，78區(qū)から94區(qū)までの領(lǐng)域
- 共通自由領(lǐng)域には，ユーザ／ベンダ定義文字を割り當(dāng)てることができる．
だけであり，どの領(lǐng)域をユーザ定義なりベンダ定義なりに割り當(dāng)て「なければならない」といったことは何も規(guī)定していない．よって，「共通自由領(lǐng)域」のある範(fàn)囲をベンダ定義に使用しても，それは「規(guī)約に反する」わけではない．また，解説の
なお，これらの領(lǐng)域の使用にあたっては，以下の方針を推奨する．
- ユーザ／ベンダ定義文字は，JIS X 0208 および JIS X 0212 ともに， 94區(qū)から85區(qū)の順に使用する．
- JIS X 0212 の「保留領(lǐng)域」（78區(qū)から84區(qū)まで）の使用は，他の「自 由領(lǐng)域」を使いきった上で，さらにユーザ／ベンダ定義文字を利用した い場合に限る．
は，「推奨」であり，強(qiáng)制力はない．
以上のことから，この割り當(dāng)て案はUI-OSF共通日本語 EUCの規(guī)約に対して問題とはならないと判斷した．
これはUI-OSF共通日本語EUCが詳細(xì)化される結(jié)果となるが，ここで決定した日本語 EUC は「Windows とインタオペラビリティをとるためのコード系」という位置付けとする．
その後，IBM より，JIS X 0212 と IBM 拡張文字との間の変換表を提供するとの申し出があった．これにより，以前の案にあった「IBM 拡張文字の一部が JIS X 0212 と重複するため，コードを二重にもつ文字ができてしまう」という問題が解決できるので，再度検討を行い，次に示す4案のうち，どれに決めるかを議論した．
- (1) 案:
- SJIS の115區(qū)～120區(qū)を G3 の79區(qū)～84區(qū)に変換する．IBM 拡張文字に は JIS X 0212 に対応するものもあるが，マッピングは行わない．
- (2) 案:
- SJIS の115區(qū)～120區(qū)のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は (1) と同様の変換を行う．
- (3) 案:
- SJIS の115區(qū)～120區(qū)のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は84區(qū)94點(diǎn)から數(shù)字の小さい 方に詰める．
- (4) 案:
- SJIS の115區(qū)～120區(qū)のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は非漢字は83區(qū)1點(diǎn)から，漢 字は84區(qū)1點(diǎn)からの領(lǐng)域に置く．
(1) 案はコード変換がもっとも単純であるが，いくつかの文字については JIS X 0212 の領(lǐng)域と IBM 拡張文字の領(lǐng)域とに重複してコードをもつことになる．
(2) 案は，変換のバリエーションに強(qiáng)い (特に，(1) と同じ変換を行っても， JIS X 0212 に対応しない文字については変換先が同じになる) という特徴がある．
(3) 案は規(guī)格が改訂されて文字が追加されても IBM 拡張文字に重なってしまう確率がいちばん低い．また，82區(qū)までの空き領(lǐng)域をユーザ定義文字のために利用することも可能である
(もっとも，SJIS には変換できないが)．
(4) 案は AIX で実裝されているものと同じで，非漢字と漢字とでコード範(fàn)囲が明確に分かれていることが特徴である．歴史的事情により，84區(qū)の漢字部分は一部のコードが飛び飛びになっている．(84區(qū)1點(diǎn)～88點(diǎn)だが，13, 22, 33, 35, 42, 50, 61, 80 點(diǎn)が空きになっている)
(1) 案はコードと文字の一対一対応が崩れることが問題で支持がなかった． (2) 案は(3), (4) 案に比べれば (変換の実裝方法にも依るが) 変換表が小さくなるという點(diǎn)が指摘されたが，388文字分の変換表が106文字分減るだけなので大して違わないという意見もあった．(4) 案は変換規(guī)則の規(guī)定理由が不明確な點(diǎn)が標(biāo)準(zhǔn)としてふさわしくないという指摘があった．変則的な変換は IBM 拡張文字の將來の追加に備えたものではないかという推測もあったが，現(xiàn)在そのような予定はない．
上記のような議論の後，投票を行い，(3) 案が賛成多數(shù)で選択された．
未定義文字の扱い(置換文字)について
コード変換では，変換元のコードとしては有効だが変換先コードには対応する文字がない場合，特別な文字で置き換えることが多い．
この特別な文字(置換文字)をひとつに決めるべきかについてメンバ各社の意見を集めたところ，積極派(決めるべき)，消極派(決めない，または，何か一つに決めるのではなく，デフォルト又は推奨を決める程度でよい)，中立(どちらでもよい)の三つの意見にわかれた．全體としては規(guī)定しないほうがよいのでは(規(guī)定ではなく，推奨にとどめるなど)，という意見が多い結(jié)果となり，特に置換文字を規(guī)定しないこととした．
「決められない」理由には，ユーザによって置換文字をどれにしたいという要望が異なるということがある．また，特に置換文字を決めないことにより発生する問題は少ないであろうという意見が多くあった．
この議論の中で，置換文字に使用する文字としては，次のようなものが候補(bǔ)にあがった．()內(nèi)はSJISコード．
空白 (0x8140)
□ (0x81A0)
■ (0x81A1)
〓 (0x81AC)
(0xFCFC)
ここで空白よりも目に見える文字の方がよいという意見が多く現(xiàn)れた．これは，文字が置き換えられたことが視覚的に判斷できることが必要であると考えるためである．
SJISコードで 0xFCFC が提案された理由は，既に定義されている文字（たとえば■）に変換してしまうと，出力データに■が見つかった場合，意図的に入っていた■なのか，変換できなくて化けてしまった■なのかが區(qū)別できないため，表示結(jié)果は出力依存であるが，あえて特殊なコードを割り當(dāng)てるほうがよいというものであった．一方で，ユーザの目に見えるのは「どんな字に化けたか」なので，それが出力裝置依存になるのは問題だという意見もあった．
さらに，1バイト／2バイト文字(半角／全角文字)で置換文字を変えるかと點(diǎn)についても意見の交換がなされた．1バイト(半角)文字の置換には1バイト(半角) 文字を，2バイト(全角)文字の置換には2バイト(全角)文字を使う方がよいという意見が出され，次のようなものが置換文字の候補(bǔ)としてあがった．
? (0x3F)
_ (0x5F)
全體として置換文字を規(guī)定しないという結(jié)論に達(dá)したため，この件についてもあえて何かを規(guī)定しないこととした．
コード系名の詳細(xì)化
ここでコード系名の詳細(xì)化を行った理由は次のようなものである．
UI-OSF 共通日本語 EUC は大まかな枠組みを決めたものであり，この枠にそって作られた日本語 EUC の実裝は複數(shù)存在しうる．また，すでに自社でそのような日本語 EUC を?qū)g裝してそれに eucJP という名前を付けてしまったベンダもある．SJIS との特定のコード変換を前提にした日本語 EUC にeucJP という名前を付けてしまうと，（間接的にユーザ?ベンダ定義文字の位置?個數(shù)などを詳しく規(guī)定してしまうことになって，結(jié)果的に）そのような実裝との間で矛盾が生じるため，別な名前を付けるべきである．
ここで規(guī)定する日本語EUCおよび各社の文字コードを識別できるようにするための名前付けルールとして，次のようなものが候補(bǔ)としてあがった．
- ベンダ名 "-" コード系名 (例: XXX-eucJP)
- コード系名 "-" ベンダ名 (例: eucJP-XXX)
- コード系名 "@" "vendor=" ベンダ名 (例: eucJP@vendor=XXX)
各社の意見を集めた結(jié)果，(2)案 の コード系名 "-" ベンダ名 が圧倒的に支持されたため，(2) 案を採用することとした．
(2)案を支持する理由としては，ベンダ名を付けるのなら，前に付けるより後ろに付けた方がオプショナルという意味合いが強(qiáng)くなるので，よいのではないかということである．
(3)案は XPG4 System Interface Definitions の Chapter 6 Environment Variablesの 6.2 Internationalisation Variables (P. 89, Version 2 では P. 93) に，
If the locale value has the form: language[_territory][.codeset]
it refers to an implementation-provided locale, where settings of language, territory and codeset are implementation-dependent. LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC and LC_TIME are defined to accept an additional field ``@modifier'', which allows the user to select a specific instance of localisation data within a single category (for example, for selecting the dictionary as opposed to the character ordering of data). The syntax for these environment variables is thus defined as: [language[_territory][.codeset][@modifier]]
とあり，@modifier が LANG に設(shè)定できないため，問題がありそうとの意見があった．
なお，今回の規(guī)則は日本國內(nèi)での名前の統(tǒng)一を前提にしているため，國際的な仕様ではない．