jinfeng_wang

G-G-S,D-D-U!

BlogJava 首页 新随笔 联系 聚合 管理
  400 Posts :: 0 Stories :: 296 Comments :: 0 Trackbacks

[1] はじめに

 OSF 日本ベンダ協議会 (OSF/JVC) CDE/Motif 技術検討 WG では,ユーザ定義文字サポートを主な検討テーマとして,検討を続けてきた.その結果として,日本語 EUC とシフト JIS との間のコード変換及び命名規則を規定した.また,文字コードのサポートの実態調査を行った.

  • 現在のコード系のサポート状況
     UNIX や PC では,日本語文字コードは日本語 EUC やシフト JIS が使われることが多いが,同じ日本語 EUC といってもベンダ毎に微妙な違いがあり,マルチベンダ環境のデータ交換の問題となっていた.しかし,これまで文字コードについては,ベンダ毎に違いがあることは認識されていたものの,具体的に何がどう違うのかについては明らかではなかった.また,各ベンダが実装しているコード変換についても,特にユーザ定義文字として利用されているコード範囲の変換ルールがベンダ毎に違っていることが多かった.そのため,相互運用・相互接続の際に問題になった.

  • 実態調査
     具体的な検討を始める前に,まずベンダ各社の現状の文字コード及びコード変換の実装を調べた.これによって,現状の各種の実装の違いを認識し,有効な解決策を考えるための基礎資料とした.本 WG では,この調査結果を元に,OSF CDE/Motif PST プロジェクトと連携してコード変換ツールを作成することを検討している.なお,この調査結果はシステムベンダ,ISV,システムインテグレータ等にとっても非常に有用な資料であるので,ここで公開することにした.

     また,この調査結果をもとに CDE/Motif PST と連携してコード変換ツールを提供する予定である.

  • 日本語 EUC とシフト JIS 間のコード変換
     Microsoft Windows 3.1 において標準的なシフト JIS コードを規定しているが,これに対して, UNIX の標準的な日本語文字コードである UI-OSF 共通日本語 EUC との間でのコード変換は規定されていなかった.そこで,このシフト JIS と UI-OSF 共通日本語 EUC との間で標準的なコード変換を規定し,Windows とのデータ交換に際して混乱が起こらないようにした.

 なお,コード変換仕様においては UI-OSF 日本語環境実装規約を参照しているが,本仕様はこの規約の規定に従いつつ日本語 EUC とシフト JIS との変換仕様を定めたものであり,規約の規定内容を変更するものではない.

 今後は,Unicode との関係についても検討していく予定である.

[2] 現在のコード系のサポート状況

 現在,各社のシステムでサポートされている文字コードは各種あり,それぞれ微妙に違っているため,データ交換などの相互運用の際に問題になることがある.文字コードに関する問題は多様な要素が入り交じっているため複雑になりやすいが,整理すると次の通りになる.

  • エンコーディング方式の違い
     文字コード自体は JIS 規格 (X 0201, X 0202, X 0208, X 0212 等) で規定されているが,実際に使用される場合は JIS のコード値をそのまま使うのではなく,日本語 EUC やシフト JIS のようなエンコーディングに変換されて使用されることが多い.

     これらのエンコーディング方式では,2バイト文字のコード範囲はどの処理系でもほぼ同じだが,使用できる文字数を増やすためにベンダによって独自拡張されることがある.拡張された部分を使用していると,拡張を持たない処理系との間でのデータ交換に支障が生じる場合がある.

     エンコーディングが違う場合,コード変換をすればデータを交換できる.コード変換にはシステムやアプリケーションで提供されるコード変換関数や変換表に基づいて行うことが多いが,このコード変換規則が処理系によって異なる場合があるため,コード変換をどこで行うかによって変換結果が変わってくることがある.また,システムが提供するコード変換と,アプリケーションの提供するコード変換との間で変換規則が違うことがある.

  • ユーザ定義文字の違い
     規格には定義されていないが必要な文字は,ユーザ定義として文字パターンを作成し,空いているコードに割り当てるのが普通である.このユーザ定義文字として使用できるコード範囲や文字数が処理系によって異なっていると,データ交換の際にコード変換が必要になる.

  • ベンダ定義文字の違い
     規格にはないがベンダが独自に追加した文字をここではベンダ定義文字と呼ぶ.ベンダ定義文字には,丸付き数字や括弧つき漢字など一種の記号として使用されるものの他,規格にはないが利用されることが多い漢字を追加した場合もある.このようなベンダ定義文字は,ベンダによってサポートされている文字の種類・数が違うし,同じ文字がサポートされていても,コードポイントが違うこともあるので,これらの文字の交換には制限が付くことが多い.

  • 命名規則の違い
     どの文字コードを使用するか指定する際に,文字コード名を示す文字列を使う場合がある.たとえば,XPG4 で規定された iconv コマンドでは,変換元及び変換先の文字コードの名前を,たとえば,

    iconv -f "変換元文字コード名" -t "変換先文字コード名"

    のように指定する.これらの名前は実装によって違うため,同じ実体に違う名前が付けられたり,違う実体に同じ名前が付けられたりすることがある.

       上記のような問題を解決するため,まず [3] に示す調査を行い,実体を調べた.また,命名規則については,[5] に示す一定のルールを定め,これの採用を呼び掛ける予定である。

      [3] 実態調査

       コード変換ツールの検討を行なうにあたっては,既存のシステムでどのようなコード系やコード変換規則が使用されているかを調査し,それらに対応できるように考えた.
      1. 調査項目
         各社の実装している日本語 EUC 及びシフト JIS 系の文字コードについて,次の項目を調査した。

        1. 有効なコードの範囲
        2. ベンダ定義文字・ユーザ定義文字の範囲と個数
        3. コード変換規則

      2. 調査対象
         システムベンダ及び ISV を対象とした.
      3. 調査結果
         添付資料を参照のこと.

      [4] 日本語EUCとシフトJIS間のコード変換とコード系名

      [4.1] 日本語EUCとシフトJIS間のコード変換

       日本語EUCとシフトJIS (以下 SJIS と略) 間相互のコード変換は,次のような変換規則に従うものとする.

       ここで,SJISとはMicrosoft が Windows 3.1 で規定した「マイクロソフト標準キャラクタセット」のこととする.

       また,日本語EUCとはUI-OSF共通日本語EUCにSJISとのコード変換を考慮して,共通自由領域にユーザ外字,IBM拡張文字を次のように割り当てたものとする.

        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区
       なお,ユーザ外字は区番号及び点番号共に番号の小さい方から順にコードを割り当てる. IBM 拡張文字は,JIS X 0208, JIS X 0212 に対応する文字がある場合はその文字にマッピングし,それ以外の文字は 84 区 94 点からコードの値の小さい方に順にマッピングする.この変換を行った場合,G3の83区1点~83区82点に文字は割り当てられないが,この領域は予約とする.IBM 拡張文字の変換については,添付資料(2)を参照.

      SJIS-日本語EUC

             *NEC/IBM : NEC選定IBM拡張文字
             UDC  : ユーザ外字 (SJIS 95区~114区の1880文字)
             IBM  : IBM拡張文字 (SJIS 115区~119区の388文字)
      
      注記:
      1. ASCIIとJIS X0201ローマ文字の字形上の差は無視する.
      2. JIS X 0212は,日本語EUCからSJISへの変換において SJIS に対応するコードがない文字はある特定の文字 (以下,「置換文字」と呼ぶ) に変換する.
      3. NEC選定IBM拡張文字は,SJISから日本語EUCへの変換においては,SJISでいったん IBM拡張文字に変換してから日本語EUCに変換する.日本語EUCからSJISへの変換においてIBM 拡張文字から NEC選定IBM拡張文字への変換は行なわない.
      4. 変換元のコードとしては有効だが変換先には対応するコードがない場合,「置換文字」に置き換える.
      5. 「置換文字」として使用する文字コードは実装依存とする.

      [4.2] コード系名の詳細化

       コード系の詳細を区別する場合,次の命名規則を用いる.この名前は,ロケール名の codeset フィールドや iconv コマンドの引き数などに利用できる.
      コード系名 - ベンダ名

      例:
               eucJP-ABC:     ABC 社の日本語 EUC
               SJIS-DEF :     DEF 社のシフト JIS
      
      コード系名
      符合化文字集合の記号名を指定する.
      符合化文字集合名については,「UI-OSF日本語環境実装規約 Version 1.1」の
      4.1 符合化文字集合名を参照のこと.
      ベンダ名
      コード系の詳細な差異を区別するために使用する名称を指定する.

       [4.1] の日本語EUCおよびシフトJISの名称は次の通りとする.

              日本語EUC:      eucJP-open
              シフトJIS:      SJIS-open
      

       その他の名称は OSF/JVC にて登録するものとする.

      [5]検討経緯

      1. 日本語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つになった.

        1. 日本語EUCにおけるJIS X0208およびJIS X0212の空き領域にSJISの95区~ 120区を割り当てる.
        2. 日本語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の規定内容は,

        1. JIS 未定義領域の中で,次の領域を「共通自由領域」として定める.
          • JIS X 0208 の未定義領域のうち,85区から94区までの領域
          • JIS X 0212 の未定義領域のうち,78区から94区までの領域
        2. 共通自由領域には,ユーザ/ベンダ定義文字を割り当てることができる.

        だけであり,どの領域をユーザ定義なりベンダ定義なりに割り当て「なければならない」といったことは何も規定していない.よって,「共通自由領域」のある範囲をベンダ定義に使用しても,それは「規約に反する」わけではない.また,解説の


        なお,これらの領域の使用にあたっては,以下の方針を推奨する.

        • ユーザ/ベンダ定義文字は,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) 案が賛成多数で選択された.

      2. 未定義文字の扱い(置換文字)について

         コード変換では,変換元のコードとしては有効だが変換先コードには対応する文字がない場合,特別な文字で置き換えることが多い.

         この特別な文字(置換文字)をひとつに決めるべきかについてメンバ各社の意見を集めたところ,積極派(決めるべき),消極派(決めない,または,何か一つに決めるのではなく,デフォルト又は推奨を決める程度でよい),中立(どちらでもよい)の三つの意見にわかれた.全体としては規定しないほうがよいのでは(規定ではなく,推奨にとどめるなど),という意見が多い結果となり,特に置換文字を規定しないこととした.

         「決められない」理由には,ユーザによって置換文字をどれにしたいという要望が異なるということがある.また,特に置換文字を決めないことにより発生する問題は少ないであろうという意見が多くあった.

         この議論の中で,置換文字に使用する文字としては,次のようなものが候補にあがった.()内はSJISコード.

                空白 (0x8140)
                □   (0x81A0)
                ■   (0x81A1)
                〓   (0x81AC)
                     (0xFCFC)
        
         ここで空白よりも目に見える文字の方がよいという意見が多く現れた.これは,文字が置き換えられたことが視覚的に判断できることが必要であると考えるためである.

         SJISコードで 0xFCFC が提案された理由は,既に定義されている文字(たとえば■)に変換してしまうと,出力データに■が見つかった場合,意図的に入っていた■なのか,変換できなくて化けてしまった■なのかが区別できないため,表示結果は出力依存であるが,あえて特殊なコードを割り当てるほうがよいというものであった.一方で,ユーザの目に見えるのは「どんな字に化けたか」なので,それが出力装置依存になるのは問題だという意見もあった.

         さらに,1バイト/2バイト文字(半角/全角文字)で置換文字を変えるかと点についても意見の交換がなされた.1バイト(半角)文字の置換には1バイト(半角) 文字を,2バイト(全角)文字の置換には2バイト(全角)文字を使う方がよいという意見が出され,次のようなものが置換文字の候補としてあがった.

                ?  (0x3F)
        	_  (0x5F)
        
         全体として置換文字を規定しないという結論に達したため,この件についてもあえて何かを規定しないこととした.

      3. コード系名の詳細化

         ここでコード系名の詳細化を行った理由は次のようなものである.

         UI-OSF 共通日本語 EUC は大まかな枠組みを決めたものであり,この枠にそって作られた日本語 EUC の実装は複数存在しうる.また,すでに自社でそのような日本語 EUC を実装してそれに eucJP という名前を付けてしまったベンダもある.SJIS との特定のコード変換を前提にした日本語 EUC にeucJP という名前を付けてしまうと,(間接的にユーザ・ベンダ定義文字の位置・個数などを詳しく規定してしまうことになって,結果的に)そのような実装との間で矛盾が生じるため,別な名前を付けるべきである.

         ここで規定する日本語EUCおよび各社の文字コードを識別できるようにするための名前付けルールとして,次のようなものが候補としてあがった.

        1. ベンダ名 "-" コード系名 (例: XXX-eucJP)
        2. コード系名 "-" ベンダ名 (例: eucJP-XXX)
        3. コード系名 "@" "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 に設定できないため,問題がありそうとの意見があった.

         なお,今回の規則は日本国内での名前の統一を前提にしているため,国際的な仕様ではない.

                                                                   以上
      

              	OSF/JVC CDE/Motif 技術検討 WG 委員名簿
              	(1995年11月16日現在)
               
              主査:	成田 雅彦	富士通株式会社
              
              委員:   厚芝 俊樹	日本ディジタルイクイップメント株式会社
                     稲垣 充正      株式会社 日立製作所
                     岡本 将吾      日本ユニシス株式会社
                     奥津 正義      日本サン・ソフト
                     小崎 將弘      ノベル株式会社
                     片貝 正紀      日本サン・ソフト
                     川合 良行      日本ユニシス株式会社
                     塩田 知則      日本サン・ソフト
                     鈴木 一雄      株式会社 日立製作所
                     鈴木 真人      日本アイ・ビー・エム株式会社
                     清野 正幸      日本サン・ソフト
                     竹内 正樹      ソニー株式会社
                     玉野 隆一      日本電気株式会社
                     冨谷 真一      ソニー株式会社
                     長瀬 嘉秀      オープン・ソフトウェア・ファウンデーション
                     中原 康        株式会社 東芝
                     難波 健一      日本ユニシス株式会社
                     沼田 利典      富士通株式会社
                     林  秀幸      日本ヒューレット・パッカード株式会社
                     日高 大輔      沖電気工業株式会社
                     平倉 一郎      日本電気株式会社
                     福井 恵右      富士通株式会社
                     藤原 隆        富士通株式会社
                     三浦 英敦      株式会社 日立製作所
                     山本 明        日本ディジタルイクイップメント株式会社
              
                      (氏名の五十音順)
      
      

      添付資料

      各社の文字コード調査結果

      IBM 拡張文字一覧(テキスト形式)

      IBM 拡張文字一覧(422K)

    posted on 2006-01-19 09:02 jinfeng_wang 阅读(4681) 评论(1)  编辑  收藏 所属分类: ZZ

    评论

    # re: 日本語 EUC ・シフト JIS 間コード変換仕様とコード系実態調査 2006-01-27 11:53 -=Kino=-
    へへ
    いい~~~
    来週、朝礼の文章がありますよう。  回复  更多评论
      


    只有注册用户登录后才能发表评论。


    网站导航: