日本語EUCとSJIS間のコード変換
UNIXマシンとPCとの相互運用性を考慮すると，UNIXマシン上の標準的な文字コードである日本語EUCとPC上の標準的な文字コードであるSJISとの統一されたコード変換は必要である．
いわゆるSJISというコード系にもいくつかのバリエーションが存在する．ここでは，PC上で現在，広く普及している文字コードということで，Microsoft Windows 3.1で定義されている「マイクロソフト標準キャラクタセット」を選択した．
また，日本語EUCは各社で詳細について様々な実装がされているようだが，ここでは，標準的なUI-OSF共通日本語EUCをベースとした．
日本語EUCとSJISとの間のコード変換において次のことに留意する必要がある．
- 日本語EUCにはJIS X0212があるがSJISにはない．
- ユーザ定義文字の文字数が異なる．
- SJISにはNEC特殊文字, IBM拡張文字, NEC選定IBM拡張文字があるが，日本語 EUCにはない．
- 単純にコード変換を行なうとSJISの95区～120区という領域を日本語EUCにおいてマップする領域がない．
日本語EUCとSJISとの間のコード変換において本WGは次のことを要求仕様とした．
- SJISで使われている文字が落ちない．
- SJISベースのシステムと日本語EUCベースのシステムとが混在し，データ交換を行いながら協調動作する場合は，たとえ日本語EUCベースのシステムでは JIS X 0212の文字が利用可能であっても，SJISベースのシステムではそれらのデータがすべて受け取れるわけではないので，結果としてJIS X 0212の文字がすべて使われることはない．
要求仕様に基づきコード変換案が作成されたがこれを大別すると，次の2つになった．
- 日本語EUCにおけるJIS X0208およびJIS X0212の空き領域にSJISの95区～ 120区を割り当てる．
- 日本語EUCのG3領域(コードセット3)にJIS X0212が存在しないものとして， SJISの95区～120区を割り当てる．
ここで，JIS X0212を日本語EUCでどうするかが論点となったが，各社の意見を集めたところ，JIS X0212を必要とする意見が大勢を占め，JIS X0212を不要とする意見はわずかであった．
これにより，(a)のJISの空き領域にSJISの95区～120区を割り当てることを方針として，コード変換案を作成することとした．
この方法では，SJISのNEC選定IBM拡張文字の領域がつぶれてしまうが，次の理由で問題無い．
- NEC選定IBM拡張文字と同じ文字が，IBM拡張文字にある．
- Windows3.1 上でcut&pasteすると，NEC選定IBM拡張文字がIBM拡張文字に変換されてしまう．
- マイクロソフトのマニュアルでも，NEC選定IBM拡張文字は使わないように指導している．
コード変換の処理においては，SJISから日本語EUCへの変換の際には，変換元文字としてNEC選定IBM拡張文字を使用せずに，あらかじめSJISの処理系内で， NEC選定IBM拡張文字をIBM拡張文字に変換しておくこととする．SJISから日本語EUCの変換の際に変換元文字として，NEC選定IBM拡張文字が現れた場合，変換不能文字として置換文字に置換されるものとする．
具体的な割り当て案としては，次のようになった．
| SJIS |
EUC |
| (a) 95区 - 104区 |
(A) G1 85区 - 94区 |
| (b) 105区 - 114区 |
(B) G3 85区 - 94区 |
| (c) 115区 - 120区 |
(C) G3 79区 - 84区 |
ここで日本語EUCのG3側，JIS X0212の空き領域への割り当てで，次の点が議論となった．
- JIS X 0212 の後ろの空き領域は17区あるが，SJIS のうち G3 に対応付ける必要があるのは16区であり，空きをどこに置くか
- ユーザ定義文字と IBM 拡張文字をそれぞれ日本語EUC側の(B)(C)どちらの領域に置くか
具体的に次の3案が示された．
(1)案の割り当て理由は，次の通り．
- コード順をひっくり返すより，SJIS 105区～120区を X 0212 の79区以降に対応付けた方が単純でよい．
- JIS では，将来の文字の追加は JIS X 0221 (ISO/IEC 10646-1 の JIS 版) に対して行う方針であり，X 0212 に対する文字の追加は考えなくてよいのでは．
(2)案の割り当て理由は，次の通り．
- 他の，文字数の多いコードとの変換を考えると，78区から IBM 拡張文字を割り当てて，後ろを空けておいた方がいいのでは．
(3)案の割り当て理由は，次の通り．
- 78区～84区は JIS でいう「保留領域」であり，将来の拡張で使用される可能性があるので，ユーザ定義がつぶされるのを避けるため「自由領域」に置いた．78区を空けたのは，1区ぶんだけでも IBM 選定文字の範囲がつぶされるのを遅らせるため．
各社の意見を集めたところ，多数派となった(3) 案とすること決定した．
なお，この変換案に対して，UI-OSF 共通日本語 EUC の規定に反するのではないかという疑問が出されたが，UI-OSF共通日本語 EUCの規定内容は，
- JIS 未定義領域の中で，次の領域を「共通自由領域」として定める．
- JIS X 0208 の未定義領域のうち，85区から94区までの領域
- JIS X 0212 の未定義領域のうち，78区から94区までの領域
- 共通自由領域には，ユーザ／ベンダ定義文字を割り当てることができる．
だけであり，どの領域をユーザ定義なりベンダ定義なりに割り当て「なければならない」といったことは何も規定していない．よって，「共通自由領域」のある範囲をベンダ定義に使用しても，それは「規約に反する」わけではない．また，解説の
なお，これらの領域の使用にあたっては，以下の方針を推奨する．
- ユーザ／ベンダ定義文字は，JIS X 0208 および JIS X 0212 ともに， 94区から85区の順に使用する．
- JIS X 0212 の「保留領域」（78区から84区まで）の使用は，他の「自 由領域」を使いきった上で，さらにユーザ／ベンダ定義文字を利用した い場合に限る．
は，「推奨」であり，強制力はない．
以上のことから，この割り当て案はUI-OSF共通日本語 EUCの規約に対して問題とはならないと判断した．
これはUI-OSF共通日本語EUCが詳細化される結果となるが，ここで決定した日本語 EUC は「Windows とインタオペラビリティをとるためのコード系」という位置付けとする．
その後，IBM より，JIS X 0212 と IBM 拡張文字との間の変換表を提供するとの申し出があった．これにより，以前の案にあった「IBM 拡張文字の一部が JIS X 0212 と重複するため，コードを二重にもつ文字ができてしまう」という問題が解決できるので，再度検討を行い，次に示す4案のうち，どれに決めるかを議論した．
- (1) 案:
- SJIS の115区～120区を G3 の79区～84区に変換する．IBM 拡張文字に は JIS X 0212 に対応するものもあるが，マッピングは行わない．
- (2) 案:
- SJIS の115区～120区のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は (1) と同様の変換を行う．
- (3) 案:
- SJIS の115区～120区のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は84区94点から数字の小さい 方に詰める．
- (4) 案:
- SJIS の115区～120区のうち，JIS X 0212 に対応する文字がある場合は その文字にマッピングし，それ以外の文字は非漢字は83区1点から，漢 字は84区1点からの領域に置く．
(1) 案はコード変換がもっとも単純であるが，いくつかの文字については JIS X 0212 の領域と IBM 拡張文字の領域とに重複してコードをもつことになる．
(2) 案は，変換のバリエーションに強い (特に，(1) と同じ変換を行っても， JIS X 0212 に対応しない文字については変換先が同じになる) という特徴がある．
(3) 案は規格が改訂されて文字が追加されても IBM 拡張文字に重なってしまう確率がいちばん低い．また，82区までの空き領域をユーザ定義文字のために利用することも可能である
(もっとも，SJIS には変換できないが)．
(4) 案は AIX で実装されているものと同じで，非漢字と漢字とでコード範囲が明確に分かれていることが特徴である．歴史的事情により，84区の漢字部分は一部のコードが飛び飛びになっている．(84区1点～88点だが，13, 22, 33, 35, 42, 50, 61, 80 点が空きになっている)
(1) 案はコードと文字の一対一対応が崩れることが問題で支持がなかった． (2) 案は(3), (4) 案に比べれば (変換の実装方法にも依るが) 変換表が小さくなるという点が指摘されたが，388文字分の変換表が106文字分減るだけなので大して違わないという意見もあった．(4) 案は変換規則の規定理由が不明確な点が標準としてふさわしくないという指摘があった．変則的な変換は IBM 拡張文字の将来の追加に備えたものではないかという推測もあったが，現在そのような予定はない．
上記のような議論の後，投票を行い，(3) 案が賛成多数で選択された．
未定義文字の扱い(置換文字)について
コード変換では，変換元のコードとしては有効だが変換先コードには対応する文字がない場合，特別な文字で置き換えることが多い．
この特別な文字(置換文字)をひとつに決めるべきかについてメンバ各社の意見を集めたところ，積極派(決めるべき)，消極派(決めない，または，何か一つに決めるのではなく，デフォルト又は推奨を決める程度でよい)，中立(どちらでもよい)の三つの意見にわかれた．全体としては規定しないほうがよいのでは(規定ではなく，推奨にとどめるなど)，という意見が多い結果となり，特に置換文字を規定しないこととした．
「決められない」理由には，ユーザによって置換文字をどれにしたいという要望が異なるということがある．また，特に置換文字を決めないことにより発生する問題は少ないであろうという意見が多くあった．
この議論の中で，置換文字に使用する文字としては，次のようなものが候補にあがった．()内はSJISコード．
空白 (0x8140)
□ (0x81A0)
■ (0x81A1)
〓 (0x81AC)
(0xFCFC)
ここで空白よりも目に見える文字の方がよいという意見が多く現れた．これは，文字が置き換えられたことが視覚的に判断できることが必要であると考えるためである．
SJISコードで 0xFCFC が提案された理由は，既に定義されている文字（たとえば■）に変換してしまうと，出力データに■が見つかった場合，意図的に入っていた■なのか，変換できなくて化けてしまった■なのかが区別できないため，表示結果は出力依存であるが，あえて特殊なコードを割り当てるほうがよいというものであった．一方で，ユーザの目に見えるのは「どんな字に化けたか」なので，それが出力装置依存になるのは問題だという意見もあった．
さらに，1バイト／2バイト文字(半角／全角文字)で置換文字を変えるかと点についても意見の交換がなされた．1バイト(半角)文字の置換には1バイト(半角) 文字を，2バイト(全角)文字の置換には2バイト(全角)文字を使う方がよいという意見が出され，次のようなものが置換文字の候補としてあがった．
? (0x3F)
_ (0x5F)
全体として置換文字を規定しないという結論に達したため，この件についてもあえて何かを規定しないこととした．
コード系名の詳細化
ここでコード系名の詳細化を行った理由は次のようなものである．
UI-OSF 共通日本語 EUC は大まかな枠組みを決めたものであり，この枠にそって作られた日本語 EUC の実装は複数存在しうる．また，すでに自社でそのような日本語 EUC を実装してそれに eucJP という名前を付けてしまったベンダもある．SJIS との特定のコード変換を前提にした日本語 EUC にeucJP という名前を付けてしまうと，（間接的にユーザ・ベンダ定義文字の位置・個数などを詳しく規定してしまうことになって，結果的に）そのような実装との間で矛盾が生じるため，別な名前を付けるべきである．
ここで規定する日本語EUCおよび各社の文字コードを識別できるようにするための名前付けルールとして，次のようなものが候補としてあがった．
- ベンダ名 "-" コード系名 (例: XXX-eucJP)
- コード系名 "-" ベンダ名 (例: eucJP-XXX)
- コード系名 "@" "vendor=" ベンダ名 (例: eucJP@vendor=XXX)
各社の意見を集めた結果，(2)案 の コード系名 "-" ベンダ名 が圧倒的に支持されたため，(2) 案を採用することとした．
(2)案を支持する理由としては，ベンダ名を付けるのなら，前に付けるより後ろに付けた方がオプショナルという意味合いが強くなるので，よいのではないかということである．
(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 に設定できないため，問題がありそうとの意見があった．
なお，今回の規則は日本国内での名前の統一を前提にしているため，国際的な仕様ではない．