アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
文字コード問題で思いつくもの (スコア:1, 興味深い)
同じ文字かどうか問題。(いわゆる)全角と半角のアルファベットAは同じとすべきか。漢字だと旧字の扱い。各国語のA(似た文字も含めて)は同じとすべきか。検索しやすさ(プログラム内での処理含む)にかかってきます。migemoみたいに類似文字をORする正規表現を作成させて、それでマッチさせるとか?
実装可能か、処理しやすいか。Unicodeがなんだかんだ言われても普及しているのは、実際に手を動かして動くものを増やしたからでは? ISO-2022との比較です。(比較できるものかな?)
-- A.C., nothing more, nothing less.
標準コード体系に使用目的への特化は要らない (スコア:3, すばらしい洞察)
Unicodeは情報交換や内部処理などの特定の目的に特化したものではありません。Asciiコードもそうですが、この手の標準コード体系は、どんな目的にもほどほどに使える中途半端な役割が求められます。そう考えると、今のUnicodeの中途半端さはまさに狙い通りだと思います。
UTF-8は1バイト文化を引きずっていますが、今のところはMatzさんが言うように短いに越したことがないという論理が勝っています。将来的にはどうか分かりませんが。
Unicode反対派は、このまま中途半端なものが定着するのを避けたいようですが、使用目的を考え出すとまず決まりません。使用目的を考えたところが間違いの元だと思います。
Re:標準コード体系に使用目的への特化は要らない (スコア:1, 参考になる)
情報交換の必要がなければ、標準コード体系なんて決める必要はないのですよ。
Unicode文字集合/符号化方法も、ASCIIコードも、情報交換のための約束事の一つです。
その約束事にもともとある程度以上の汎用性があったり、情報交換に使う機器の制約と
(外部との情報交換の必要のない)内部処理に使う機器の制約とが似通っている・もしくは
同一であるため、内部処理用途に使い回すことが容易だった、等の理由から、内部処理
用途にも使い回されている/きた、というだけのことに過ぎません。
Unicode符号化方法で表されたデータを通信用途に最適化する変換仕様が、UTF-8等です。
その仕様は、もともとASCIIコードベースで表現できていたデータは、Unicode符号化方法
で表現し直しても、通信時にはかつてのASCIIコードベースでの通信とほぼ同等の転送効率
を実現できることを主眼に作られています。そのとばっちりで、漢字などはUTF-8にすると
もともとのUnicodeよりも転送効率が落ちてしまうということになっているのは、ご承知かと
思います。
Unicode文字集合/符号化方法と、Unicode符号化方法によるデータの通信時転送仕様UTF-8は、
所属するレイヤが異なります。一緒くたに語ってしまうとわけがわからなくなりますよ。