パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

UNICODEをどう組み込む」記事へのコメント

  • まず、Unicode (UTF-8) のほうがいい理由。

    • フル規格の ISO-2022 の実装は大変すぎてとてもできない。
    • ISO-2022 は、そこそこのサブセットでさえ、実装するのは面倒。
    • stateless である。つまり、「状態」を持たない。エスケープシーケンスもない。というわけで、サロゲートペアで批判されている UTF-16 でさえ、ISO-2022 よりもはるかにシンプル。ISO-2022-JP よりもシンプルと言える。
    • 必要に迫られていて、かなりの能力と時間がある人でないと実装ができないので、対応ソフトウェアがいつまでたっても増えない。
    • CJK の漢字はたしかに CJK で区別できるといろいろと利点があるが、 ISO-8859-* に載っている文字 (たとえば、ISO-8859-1 [の右半分] にも ISO-8859-2 [の右半分] にも同じ文字 [たとえば 0xc4 はウムラウトのついた A] が入っている [というか、大部分が共通な文字]) は区別しないほうがいい。

    次に、どちらでもいい、もしくは、どちらともいいがたい点。

    • 結合文字や bidi (bi-direction、アラビア文字やヘブライ文字のように右から左へと文字が進むのを許す実装) は、Unicode でも ISO-2022 でも手間は同じ。
    • 漢字のうち、CJK で字形が同じものについては、賛成、反対どちらも意見がある。賛成の意見で有名なのは「grep 毛沢東」だろう。(反対は「grep 手紙」かな?)

    最後に、Unicode に移行したほうが悪くなる点。

    • CJK 統合漢字のうち、字形が異なるもの。「骨」とかが有名だが、「直」に至っては中国の字形はたいていの日本人には判読不能と思われる。ただしこれも、U+E0000 からのタグや、もうひとつレベルを上げてマークアップで区別することが可能だが、実装が大変。
    • JIS X 0208 と Unicode との相互変換テーブルが、さまざまな実装があって統一されていない。漢字部分については Unicode Consortium がきちんと変換テーブルを用意しているので問題がないが、記号部分については各社ばらばら (英語ですみませんが、ぼくの書いた文書の Conversion tables differ between venders を参照してください)。 Unicode Consortium は、参考扱いの変換テーブルを用意していたが、 最近それも obsolete (廃止) 扱いにしてしまった (http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/)。 完全に移行しきってしまえば問題とはならないはずだけども。 ちなみに、GNU libc は、上記の OBSOLETE なテーブルのうちの JIS0208.TXT をもとに、上記拙文の EUC-JP round-trip compatibility に記載されている問題を回避する目的で、JIS X 0208 の 0x2140 (「\」) を U+005C から U+FF3C に変更したものを使っています。 XFree86 は、JIS0208.TXT そのままでしたが、GNU libc 式に追随するパッチが受け入れ待ちとなっています。
    • 文字幅問題。これは、ターミナルエミュレータなど、固定幅フォントを使う場面において、どの文字が倍角扱いになるかが、EUC-JP などで広く使われていたデファクトスタンダード (JIS X 0208 や JIS X 0212 に含まれている文字はすべて全角、ASCII や JIS X 0201 に含まれている文字はすべて半角) とは異なる。詳しくは、上記拙文の Width problems を参照 (英語)。 ただしこれも、完全に移行してしまえば問題でなくなる。
    • EUC-JP や Shift_JIS で、2バイト文字 = 全角、という世界では、マルチバイト文字に対応していないソフトウェアもごまかして使うことができる場合があったが、UTF-8 だとそうはいかなくなる。

    完全にユーザである (開発は一切おこなわない) のなら、対応ソフトウェアの状況で、移行するほうがいいかどうかを決めればいいと思います。

    • > 完全に移行しきってしまえば問題とはならないはずだけども。

      私はこれ、かなり疑問に思ってます。100% pure Unicodeな環境下で、IMEから「~」を入力した場合、それはWAVE DASHなんでしょうか? それともFULLWIDTH TILDEなんでしょうか? 「―」、「∥」、「-」についても同様の問題がありますよね。

      # で、URLやNewsgroup名に「~」あったとしたら……(‥;
      親コメント
      • 私はこれ、かなり疑問に思ってます。100% pure Unicodeな環境下で、IMEから「~」を入力した場合、それはWAVE DASHなんでしょうか? それともFULLWIDTH TILDEなんでしょうか? 「―」、「∥」、「-」についても同様の問題がありますよね。

        JIS X 0208 の範囲だけでもそれだけ問題になる文字があるわけですが,Unicode に移行すると対象になる文字はさらに増えます.

        たとえば「Å」は,JIS X 0208 の範囲なら U+212B ANGSTROM SIGN でしょうけれど,その限定をなくせば,

        • U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE かもしれないし
        • U+0041 LATIN CAPITAL LETTER A の後ろに U+030A COMBINING RING ABOVE が続いたもの (意味的に上と同じですが) かもしれないし
        • U+0391 GREEK CAPITAL LETTER ALPHA の後ろに U+030A COMBINING RING ABOVE が続いたものかもしれないし
        • U+0410 CYRILLIC CAPITAL LETTER A の後ろに U+030A COMBINING RING ABOVE が続いたものかもしれない

        わけですから.他にも,Σやμは2つずつあるし(ギリシャ文字アルファベットとしてのものと,記号としてのものと),「中点のような文字」や「横棒のような文字」や「空白のような文字」に至っては,数えるのが嫌になるほどあります.

        親コメント
      • これは、日本語人だけではなく全世界の人が被る問題なので、わかっててそうしているはずだと思います。にしても、どういうつもりなんでしょうね。たぶん、移行期の混乱の時代が終われば、どの字が実際よく使われ、どの字は事実上使われない、ということもなんとなく暗黙の了解みたいなのができてくると思うのですが、甘い期待なのかもしれません。

        Unicode Consortium とか、Unicode のやることはみんな正しいと思ってるっぽい Markus Kuhn とかに聞いたらどんな答えが返ってくるのか、興味はありますが。

        親コメント
        • もうなんか書いても特定の人しかみてないよーな気もしますが(^^;、

          > 甘い期待なのかもしれません。

          甘い期待では(汗) 私が挙げた例だと、Windows環境とUNIX環境という二大メジャー(?)環境での相違だったりするわけで。

          仮にMozillaのように([moz-users:03965]参照※)CP932ベースに統一するにしても、今度は「FULLWIDTH××って既存文字コードとの互換性のためにあるんじゃなかったけ。ということは将来的には『~』は「~」に変換されるのか?」とゆー疑問があったりします。(既に何らかの指針があるよーな気もしますが)

          ※これはこれでプラットフォームネイティブな要素(GUIのメニュー等)との整合性の問題が出ているようです。

          > Unicode Consortium とか、Unicode のやることはみんな正しいと思ってるっぽい Markus Kuhn とかに聞いたらどんな答えが返ってくるのか、興味はありますが。

          まさに「問い詰めたい。小一時間問い詰めたい」とゆーやつですねぇ。
          親コメント
          • もうなんか書いても特定の人しかみてないよーな気もしますが(^^;、

            あはははは.

            仮にMozillaのように([moz-users:03965] 参照※)CP932ベースに統一するにしても、今度は「FULLWIDTH××って既存文字コードとの互換性のためにあるんじゃなかったけ。ということは将来的には『~』は「~」に変換されるのか?」とゆー疑問があったりします。(既に何らかの指針があるよーな気もしますが)

            Unicode には Normalization forms という仕様があります.「同じ文字」(何をもって「同じ」とするかが,立場によって異なるのですが) に対して複数の表現形式があるので,データ処理に困る,ということから,「一つの形式に統一するための正規化規則を決めよう」という目的で考えられたものですが, これがまた4通りもあったりするのですね.

            FULLWIDTH/HALFWIDTH 等の「互換文字」については, これも「互換文字は,対応する普通の文字に変換する」という方針のものと,そうでないものとがあります. (その他に,合成文字の扱いについて2種類あったりして,ややこしくなりますが.)

            で,どういう場合にどの方針を取るとかいった 決まりがないので,結局は正規化をする人の考え次第 ということになります. まあ,混乱はこれからも続くということですね.

            親コメント
    • Unicode のメリットというより、他のコード体系の
      デメリットといったほうがよい気はしますが、
      新規に開発されているフォント群は Unicode
      エンコーディングのものばかりだったりとか、
      もはや商業的なリソースの割き方は Unicode 側に
      完全に倒れているので、そちら以外はつらいって
      のもありそうですね。

      あとはどのタイミングで見切るか、なのかも。

物事のやり方は一つではない -- Perlな人

処理中...