| 1996年1月21日 |
| OSF 日本ベンダ協議会 (OSF/JVC) |
| CDE/Motif 技術検討 WG |
また，この調査結果をもとに CDE/Motif PST と連携してコード変換ツールを 提供する予定である．
今後は，Unicode との関係についても検討していく予定である．
これらのエンコーディング方式では，2バイト文字のコード範囲はどの処理系 でもほぼ同じだが，使用できる文字数を増やすためにベンダによって独自拡張さ れることがある．拡張された部分を使用していると，拡張を持たない処理系との 間でのデータ交換に支障が生じる場合がある．
エンコーディングが違う場合，コード変換をすればデータを交換できる．コー ド変換にはシステムやアプリケーションで提供されるコード変換関数や変換表に 基づいて行うことが多いが，このコード変換規則が処理系によって異なる場合が あるため，コード変換をどこで行うかによって変換結果が変わってくることがあ る．また，システムが提供するコード変換と，アプリケーションの提供するコー ド変換との間で変換規則が違うことがある．
iconv -f "変換元文字コード名" -t "変換先文字コード名"
のように指定する．これらの名前は実装によって違うため，同じ実体に違う名前 が付けられたり，違う実体に同じ名前が付けられたりすることがある．
上記のような問題を解決するため，まず [3] に示す調査を行い，実体を調べた． また，命名規則については，[5] に示す一定のルールを定め，これの採用を呼び 掛ける予定である。
各社の実装している日本語 EUC 及びシフト JIS 系の文字コードについて，次 の項目を調査した。
- 有効なコードの範囲
- ベンダ定義文字・ユーザ定義文字の範囲と個数
- コード変換規則
システムベンダ及び ISV を対象とした．
添付資料を参照のこと．
ここで，SJISとはMicrosoft が Windows 3.1 で規定した「マイクロソフト標準 キャラクタセット」のこととする．
また，日本語EUCとはUI-OSF共通日本語EUCにSJISとのコード変換を考慮して， 共通自由領域にユーザ外字，IBM拡張文字を次のように割り当てたものとする．
なお，ユーザ外字は区番号及び点番号共に番号の小さい方から順にコードを割 り当てる． IBM 拡張文字は，JIS X 0208, JIS X 0212 に対応する文字がある場合はその文字に マッピング し，それ以外の文字は 84 区 94 点からコードの値の小さい方に順にマッピングする． この変換を行った場合，G3の83区1点〜83区82点に文字は割り当てられないが，この 領域は 予約とする．IBM 拡張文字の変換については，添付資料(2)を参照．
SJIS 日本語 EUC ユーザ外字 95区-104区(10区)
105区-114区(10区)G1 85区-94区
G3 85区-94区IBM 拡張文字 115区-120区(6区) G1 JIS X0208
G3 JIS X0212
G3 83区-84区
*NEC/IBM : NEC選定IBM拡張文字
UDC : ユーザ外字 (SJIS 95区〜114区の1880文字)
IBM : IBM拡張文字 (SJIS 115区〜119区の388文字)
注記:
コード系名 - ベンダ名
例： eucJP-ABC: ABC 社の日本語 EUC SJIS-DEF : DEF 社のシフト JIS
[4.1] の日本語EUCおよびシフトJISの名称は次の通りとする．
日本語EUC: eucJP-open
シフトJIS: SJIS-open
その他の名称は OSF/JVC にて登録するものとする．
UNIXマシンとPCとの相互運用性を考慮すると，UNIXマシン上の標準的な文字コー ドである日本語EUCとPC上の標準的な文字コードであるSJISとの統一されたコー ド変換は必要である．
いわゆるSJISというコード系にもいくつかのバリエーションが存在する．ここ では，PC上で現在，広く普及している文字コードということで，Microsoft Windows 3.1で定義されている「マイクロソフト標準キャラクタセット」を選 択した．
また，日本語EUCは各社で詳細について様々な実装がされているようだが，こ こでは，標準的なUI-OSF共通日本語EUCをベースとした．
日本語EUCとSJISとの間のコード変換において次のことに留意する必要があ る．
日本語EUCとSJISとの間のコード変換において本WGは次のことを要求仕様とした．
要求仕様に基づきコード変換案が作成されたがこれを大別すると，次の2つに なった．
ここで，JIS X0212を日本語EUCでどうするかが論点となったが，各社の意見を 集めたところ，JIS X0212を必要とする意見が大勢を占め，JIS X0212を不要と する意見はわずかであった．
これにより，(a)のJISの空き領域にSJISの95区〜120区を割り当てることを方 針として， コード変換案を作成することとした．
この方法では，SJISの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の空き領域への割り当てで，次の点が議 論となった．
具体的に次の3案が示された．
(1)案の割り当て理由は，次の通り．
(2)案の割り当て理由は，次の通り．
(3)案の割り当て理由は，次の通り．
各社の意見を集めたところ，多数派となった(3) 案とすること決定した．
なお，この変換案に対して，UI-OSF 共通日本語 EUC の規定に反するのでは ないかという 疑問が出されたが，UI-OSF共通日本語 EUCの規定内容は，
だけであり，どの領域をユーザ定義なりベンダ定義なりに割り当て「なければ ならない」といったことは何も規定していない．よって，「共通自由領域」 のある範囲をベンダ定義に使用しても，それは「規約に反する」わけではない． また，解説の
なお，これらの領域の使用にあたっては，以下の方針を推奨する．
- ユーザ／ベンダ定義文字は，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案のうち，どれに決めるかを議論した．
(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および各社の文字コードを識別できるようにするた めの名前付けルールとして，次のようなものが候補としてあがった．
各社の意見を集めた結果，(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]]
なお，今回の規則は日本国内での名前の統一を前提にしているため，国際的な 仕様ではない．
以上
OSF/JVC CDE/Motif 技術検討 WG 委員名簿
(1995年11月16日現在)
主査: 成田 雅彦 富士通株式会社
委員: 厚芝 俊樹 日本ディジタルイクイップメント株式会社
稲垣 充正 株式会社 日立製作所
岡本 将吾 日本ユニシス株式会社
奥津 正義 日本サン・ソフト
小崎 將弘 ノベル株式会社
片貝 正紀 日本サン・ソフト
川合 良行 日本ユニシス株式会社
塩田 知則 日本サン・ソフト
鈴木 一雄 株式会社 日立製作所
鈴木 真人 日本アイ・ビー・エム株式会社
清野 正幸 日本サン・ソフト
竹内 正樹 ソニー株式会社
玉野 隆一 日本電気株式会社
冨谷 真一 ソニー株式会社
長瀬 嘉秀 オープン・ソフトウェア・ファウンデーション
中原 康 株式会社 東芝
難波 健一 日本ユニシス株式会社
沼田 利典 富士通株式会社
林 秀幸 日本ヒューレット・パッカード株式会社
日高 大輔 沖電気工業株式会社
平倉 一郎 日本電気株式会社
福井 恵右 富士通株式会社
藤原 隆 富士通株式会社
三浦 英敦 株式会社 日立製作所
山本 明 日本ディジタルイクイップメント株式会社
(氏名の五十音順)