パスワードを忘れた? アカウント作成
723290 journal

kubotaの日記: Unicode と JIS マッピング (2) 15

日記 by kubota

IRG Report にある Beyond the request of JIS COMPATIBILITY IDEOGRAPHS revised (WG2_N2223R) (pdf ファイル) によると、Unicode とその他のエンコーディングとのマッピングは、その他のエンコーディングの側で持つべきだ、というのが日本の主張らしいです。

2000-06-01 のことなので、この主張はとっくに議論され結論が出ているはずだと思うのですが、どうなのでしょう。どこかに情報が転がってなかったら、IRG に問い合わせないといけないかな。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • JIS X 0208 と Unicode (ISO/IEC 10646) との対応は,JIS 規格で規定されています.

    • 漢字部分については,ISO/IEC 10646-1:1993 の規定の際に, 規格の本文に書かれています. これは,統合漢字 (UNIFIED IDEOGRAPH) については既存の規格にある文字だけを含めることにし,出典を明示したのだから当然.
    • 非漢字部分については,ISO/IEC 10646-1:1993 の翻訳規格として JIS X 0221:1994 が出たときに,「附属書 (参考)」(規格の一部ではない,単なる「ご参考」) として公開され,JIS X 0208:1997 で規格に規定として取り込まれました.

    ただし,JIS X 0208 では,そのものずばりの「変換表」という形では書かれていないので,「読み方」を知らないと,そういう情報が記載されていることすらわからないでしょう.

    ISO/IEC 10646-1 以降,符号化文字集合の規格では,含まれるすべての文字について「名前」を与えることにしています. そして,異なる符号化文字集合規格の間でデータを変換する際には,「同じ名前をもつ文字は同じ文字と見なす」という方針で変換表を作ります.たとえば,JIS X 0201 ラテン文字集合では,0x41 のコードポイントの文字には LATIN CAPITAL LETTER A という名前が割り当てられ, これは ISO/IEC 10646 (Unicode) の 0x0041 の文字と同じ名前だから,これらの2つを同じ文字と見なす,といった具合です.

    そういう視点で見ていけば,JIS X 0208 では記号も含めてすべての文字について「名前」が割り当てられていることがわかるはずです. 漢字については「附属書3 (規定)」で,その他については「附属書4 (規定)」で,名前が決まっています.たとえば,「和字間隔」(いわゆる「全角空白」) は IDEOGRAPHIC SPACE ですし,「読点」は IDEOGRAPHIC COMMA です.名前さえわかれば,あとは ISO/IEC 10646 なり The Unicode Standard なりで同じ名前の文字を探せばいいわけです. そうすれば,IDEOGRAPHIC SPACE が U+3000 に,IDEOGRAPHIC COMMA が U+3001 に,それぞれあることはすぐわかります.

    ややこしいのは,JIS X 0208 の場合,この規格単独で使用する場合と,他の規格との組み合わせで使用する場合とが考えられ, 他の規格と組み合わせで使用する場合,こんどは「同じ文字に複数のコードポイントを割り当ててはいけない」という方針があることです.そこで考えられるたのが「代替名称」で, JIS X 0208 のある種の文字は,ISO 646 国際基準版 (IRV) [というのは ASCII のことです] や JIS X 0201 ラテン文字と 組み合わせる場合には代替名称を使用することになります. 代替名称は「附属書5 (規定)」にあります.

    これはどういうことかといえば,JIS X 0201 ラテン文字にも JIS X 0208 にも「大文字の A (LATIN CAPITAL LETTER A)」という文字があり,両方を組み合わせて使用する場合,同じ文字に対するコードポイントが2つあることになるので, 「JIS X 0208 の方の文字は原則として使うな」というのが JIS としての推奨です.しかし,どうしても JIS X 0208 の方の文字も使いたいということであれば,「JIS X 0208 の大文字 A には FULLWIDTH LATIN CAPITAL LETTER A という別の名前を割り当てる」ことにして,「同じ文字」に複数のコードポイントが割り当てられることがないようにする,というわけです.

    というわけで,変換表はしっかり規格として規定されています.問題は,規定がないことではなくて,使われていないことなんですが.

    • 詳しい説明、ありがとうございます。

      ということは、たとえば EUC-JP なら ISO 646 IRV と JIS X 0208 と JIS X 0201 カナと JIS X 0212 を組み合わせるので、JIS X 0208 部分については「代替名称」を使うということですね。事実上、JIS X 0208 を単独で使うことはまずありえないので、代替名称のほうが重要になってくるのでしょう。

      というか、そうと分かれば、さっそく JIS X 0208:1997 の規格票を入手して、JIS X 0208 ←→ JIS X 0221 の正式な変換表を GNU libc や XFree86 や Bruno Haible さんの libiconv などなどに採用してもらうよう働きかけるのがいいっぽいですね。あと、Java とか Tcl/Tk とか mlterm とか、変換表を内蔵しているソフトウェアっていっぱいあるし。

      JIS の正式な規格なのだとしたら、Unicode Consortium に「『変換表については JIS X 0208:1997 を参照せよ』と言ってください」と頼むのもいいだろうし、Unicode Consortium の各メンバ企業にも同調してもらわないと。たぶん無理だろうけど。

      ついでに、その変換表を規準にして、Unicode Standard Annex #11 East Asian Width の問題をきちんと議論しなおすことも可能になります。

      できれば、JIS 自ら、変換表なり名称なり代替名称なりをウェブ上で公表してほしいなあ、と思います。たとえばぼくが規格票を買って調べてウェブ上で公表したところで、ぼくのミスで間違いが入るかもしれないし。JIS の規格票にも間違いがあるとかいう話だし。

      質問なんですが、ISO 646 IRV と組み合わせる場合の「代替名称」と、JIS X 0201 ローマ字と組み合わせる場合の「代替名称」は、同じなのでしょうか。問題は円記号・バックスラッシュ・チルダ・オーバーラインをどう扱うか、ですが。

      あと、問題としては、JIS X 0212 と JIS X 0213 です。JIS X 0212 については、同様な「名称」があるのか、将来作られる見込みがあるのか。JIS X 0213 については、JIS X 0208 とコードポイントが重なる部分の互換性が保てているのか、ということが気になります。

      親コメント
      • 規格票の「代替名称」によるマッピングは使い物にならないから使われていない、という認識です。規格作る方は勝手ですが、たとえば EUC-JP で GL への文字集合の設定が GR に影響されたんでは作る方はやっておれん、というのが正直なところ。ISO-2022 的な考え方としても変ですし。世の中の物はたぶん全部代替名称側に飛ぶか、全部 Unification してしまうかどっちかなんじゃないかなぁ。
        親コメント
      • 質問なんですが、ISO 646 IRV と組み合わせる場合の「代替名称」と、JIS X 0201 ローマ字と組み合わせる場合の「代替名称」は、同じなのでしょうか。問題は円記号・バックスラッシュ・チルダ・オーバーラインをどう扱うか、ですが。

        どちらも「附属書5 表2」を参照しています.そして,この表は JIS X 0201 の方と組み合わせた場合を前提としているようなので, ISO 646 IRV と組み合わせると,

        • REVERSE SOLIDUS が2つある (ISO 646 IRV の 0x5C と JIS X 0208 の 1-32)
        • FULLWIDTH YEN SIGN はあるのに YEN SIGN がない
        • FULLWIDTH OVERLINE はあるのに OVERLINE がない
        • TILDE はある (逆に,JIS X 0201 と組み合わせた場合,TILDE がない)

        ということになります.困ったな.

        あと、問題としては、JIS X 0212 と JIS X 0213 です。JIS X 0212 については、同様な「名称」があるのか、将来作られる見込みがあるのか。JIS X 0213 については、JIS X 0208 とコードポイントが重なる部分の互換性が保てているのか、ということが気になります。

        JIS X 0212 については,JIS X 0221:1994 の附属書に,JIS X 0208 と合わせて変換表が書かれていたと思います.今手元にないので確認できませんが.

        JIS X 0213 は持っていないので確認できませんが, ISO/IEC 10646 との間の整合性はチェックして, ない文字は追加要求を出したはずです.

        親コメント
        • ぼくの意見としては、「内容については細かいことを言わないから、とにかくひとつに統一してくれ」というものです。実用上の要請のためなら、規格として少々汚くなっても仕方がない、と思っています。

          というわけで、

          • REVERSE SOLIDUS が2つある (ISO 646 IRV の 0x5C と JIS X 0208 の 1-32)
          は困りますが、
          • FULLWIDTH YEN SIGN はあるのに YEN SIGN がない
          • FULLWIDTH OVERLINE はあるのに OVERLINE がない
          は困りません。むしろ、EUC-JP (の一部としての JIS X 0208) ←→ Shift_JIS (の一部としての JIS X 0208) の変換が正しく行われるためには (つまり、ISO 646 IRV と組み合わせる用の代替名称と、JIS X 0201 ローマ字と組み合わせる用の代替名称とを一致させるには)、こうならなければならないと思います。EUC-JP における JIS X 0208 の 1-79 (「¥」) と、Shift_JIS における JIS X 0208 の 1-79 は、どう考えても同じ文字ですから。

          たしかに、FULLWITDTH/HALFWIDTH FORM は通常の文字が埋まって初めて使う、という原則には反しますが、それは実用上はなんら不利益をもたらしませんので、反してもかまわないと思います。

          親コメント
          • > ぼくの意見としては、「内容については細かいことを言わないから、とにか
            > くひとつに統一してくれ」というものです。

            なんとなく誤解があるような気がするんですが、JIS とのマッピングを
            規定しても、問題の解決にはならないと思います。
            なぜなら、Windows や MacOS で使われている符号化文字集合は、JIS 的な
            Shift_JIS コードとは似ているけれども異なる符号化文字集合だからです。

            ですから、例えば Microsoft が Windows で JIS とは異なるマッピングを使
            うのは、ある意味当然のことだし、このマッピングに、今後互換性のない変更
            を加えるのも、難しい
            • なぜなら、Windows や MacOS で使われている符号化文字集合は、JIS 的な Shift_JIS コードとは似ているけれども異なる符号化文字集合だからです。

              論理的には、そのとおり、で終わってしまいます (ただし、Shift_JIS はエンコーディングであって符号化文字集合ではありません)。そして、その方法こそが、論理的な整合性を保ち、矛盾を避ける唯一の方法でもあります。が、ぼくが「正統な変換表」にこだわるのはいくつか理由があって、

              • オープンソースな世界で使われる EUC-JP なり Shift_JIS のマッピングテーブルをどうするか。みんなが好き勝手に実装して非互換がさらに広がるのはまずい。
              • 「似ているけれども異なる符号化文字集合」という解決策がはたして本当にいいのか。Unicode との変換さえ考えなければ、CP932 (Windows で用いられる日本語エンコーディング) は、Shift_JIS に Microsoft 独自の拡張文字 (いわゆる機種依存文字) を加えたもの、だったはずです。そして、JIS X 0208 の部分については、データを共有できたはずです。それが、Unicode との変換表が異なってしまったために、それを後から正当化するために「これはもともと別のエンコーディングなんだから別の変換表になってもかまわないんだ」と言っているように思うのです。
              • 異なるシステムの間の通信を正しく行うには、共通の変換表が必要になります。それは、ユーザ数が最も多いであろう CP932 や、Apple の変換テーブルではなく、正統な JIS の変換表である必要があります。(もちろん、Unicode Consortium が正統な変換表を用意してくれれば、それでもいいです。資料へのアクセスのしやすさ、という意味では、むしろそっちのほうがいい)。

              MS なり Apple なりが、今後かれらが用いている変換表に変更を加える、ということは、たぶんありえないでしょう。それは残念なことではありますが、かといって、いまさら変更を加えると大変な混乱が起きるというのも理解できます。

              たぶん、MS なり Apple なりの企業は、JIS の「正式な変換表」の存在を Unicode Consortium が認知するだけでも、たいへん嫌がるのではないか、と思います。というのは、「正式な変換表」がもし存在すれば、MS や Apple の変換表は「正式ではない」つまり「正式」から見れば「間違った」ものとみなすことができるからです。これについては、実際、去年の 5 月ごろに樋浦さんとメールを交わしたことがあって、Unicode Consortium 公認 Unicode ←→ JIS 変換表というのは参加企業間の激しい対立のために到底できそうにない、ということでした。

              ちなみに、その樋浦さんとの議論の中で、前回書いた [srad.jp] Technical Report の話が出てきたのですが、いまメールを読み返してみると、樋浦さんは XFree86 I18N (これってぼくも一翼を担ってるやつじゃないか) との戦いなどなどでとても時間がとれない状況で、Technical Report を出すには volunteer の協力が不可欠だとのことだそうです。

              親コメント
              • 工学的には、逆に "cp932" でなぜいけないのか、です。デファクトスタンダードなのは認めるべきなんじゃないかな。単なる面子だけの問題に実装に関与する人間は口出しちゃいけないんじゃないかな。そういう生産性皆無の問題は事務屋に任せときゃいい。我々の工数は貴重なんです :-)

                結局こういう統一化ってのは変更コスト最小の方向に引きづられますし、何か手を打つなら事前、です。事後である今更努力して cp932 と微妙に違うコードセット(とあえて言おう)を仮に標準と出来たとしても空しいだけ。

                親コメント
              • > それを後から正当化するために「これはもともと別のエンコーディングなんだ
                > から別の変換表になってもかまわないんだ」と言っているように思うのです。

                既存コードの側から見たら、これは全くその通りですし、実際僕も、個人的には
                この「後から正当化」の方が本質だと思ってます。

                例えば沼田さんの書いた方針によるJIS的に正式な変換表と、Microsoft の変
                換表の違いも、実は、Shift_JIS と Windows-31J の違いというよりは、「¢」
                や「£」のような文字について、既存のアプリケーションとの互換性を重視して、
                「FULL WIDTH ~」を使うか (これが Microsoft 流)、それ
              • CP932 でもいいんですよ。もしそれで統一できるなら。いや、これは反語表現ではなくて、ほんとうにそう思っています。ただ、まるっきり CP932 はどうしても許容できなくて、それは、U+005C に円記号のグリフを割り当てることです。これだけは、国際社会にはどうしても受け入れられないと思います。

                ただ、Microsoft の立場としては、その解しかなかったことは理解できます。

                親コメント
              • もういっこのほうにも書きましたが、JIS が CP932 (の JIS X 0208 部分) とまるっきり同じ内容の変換表を定めたとしても、それはそれで OK です。ぼくは一方で文字幅の問題についても Unicode Consortium をつついたりしてるので、CP932 が標準になってくれれば文字幅問題も一挙に解決してめでたしめでたし、という思いもあります。(ついでに、Shift_JIS の 0x21 - 0x7e の部分はじつは US ASCII だったんだよ、ってな捏造が成立してしまえば、円記号の問題まで解決してしまう、というのは、冗談です)。

                どちらにせよ、今のままだとさらなる変種がとめどもなく増えていくことを押しとどめるものは何もありません。せめて、現状よりも悪くならないためにも、なにか標準が必要なのです。なにか標準が決まったところで、MS や Apple や Sun や IBM がそれを守るとは考えていません。それでも、もし「標準」があれば、「標準との違い」だけを考えればいいので、現在の混沌とした状況よりはずいぶんとすっきりするはずです。

                親コメント
              • > もういっこのほうにも書きましたが、JIS が CP932 (の JIS X 0208 部分) と
                > まるっきり同じ内容の変換表を定めたとしても、それはそれで OK です。

                それは無理があるんじゃないでしょうか。
                たとえば意味処理の用途に使うのであれば、「¢」や「£」については
                FULL WIDTH... じゃない方にマップする方が正しいので。

                > ぼくは一方で文字幅の問題についても Unicode Consortium をつついたりして
                > るので、CP932 が標準になってくれれば文字幅問題も一挙に解決してめでたし
                > めでたし、という思いもあります。

                たとえば、内部処理を Unicode で統一し
              • 「意味処理に使うのなら FULLWIDTH じゃないほうにマッピング するのが正しい」というのは、たとえば FULLWIDTH POUND SIGN は ポンド記号としての意味を持っていない、ということでしょうか? いまやぼくにとって、「正しさ」は、現実の便利さや、 現実に存在しうる問題を回避できる能力を伴わなければ、 何の意味もありません。

                変換表の統一は、かりに「確たる理由がなければこれを使え」 というようなものであったとしても、Unicode Consortium にリリースさせるのは政治的に絶対に不可能である、ということは まえからわかっています。それに、ほんとうにそんなことをしたら 大変な混乱が予想されるのもわかっています。それで、次善の策が 必要ですが、どうすればこの問題が解決するのか、はっきりいって ぼくにはわかりません。解決策なんかないのでしょう。

                せめて、現在流通している複数の変換表を認知させ、 それ以上混乱が広まらないようにすることが、必要でしょう。 それから、Unicode Consortium に、「今日の混乱を作りだしたのは おまえら (メンバー企業含む) なんだから、おまえらがなんとかしろ。 おまえら専門家なんだろう」と、問題に向き合うことを促す つもりもあります。たぶん、Unicode Consortium では、このような 外圧がなければ、このような、解決策が見当たらず、政治的にも 極めて難しい問題は、見て見ぬふりをするのではないかと思うのです。

                親コメント
        • すみません.もうお気付きかと思いますが, JIS X 0221:1994 は JIS X 0221:1995 の間違いです.

          親コメント
        • どちらも「附属書5 表2」を参照しています.そして,この表は JIS X 0201 の方と組み合わせた場合を前提としているようなので,

          これはJIS X 0213で改善されています。

          具体的には、FULLWIDTHな代替名称の表に、円記号とバック スラッシュとオーバーラインとチルダの代替名称が全部一緒に 入っています。そして、ISO 646 IRVとJIS X 0201のどちらと 組み合わせるときも同じ表を参照します(この点はX0208と同じ)。

          この場合一見、EUCに要らないFULLWIDTH YEN SIGNがあったりする ように見えますが、代替名称の許容は重複している文字につい

typodupeerror

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

読み込み中...