「文字エンコーディングはUTF8で本当に十分なのか？」記事へのコメント

ShiftJISなら非対応システムでも

[O1iver (31019)]

÷2で文字数がわかるので便利です！

個人的にはMatzきらいだけどMatzの意見に賛同。

#あほぷろぐらまなのでID

Re:ShiftJISなら非対応システムでも

[fukapon (4131)]

ちょ、それじゃバグだらけだって。
半角は1byteだから÷1ですよ!

まぁ、ネタにマジレスだとは思うけど。
そーゆー基本を忘れて書かれているプログラムを、実際に見ちゃってるとねぇ。

Re:ShiftJISなら非対応システムでも

[taka2 (14791)]

UTF-16なら、バイト数÷2でちゃんと文字数が出てきます。シンプルですよ～

…というのが、Unicode が出てきたときにメリットとして挙げられていたと思うのですが
合成文字なんてものがあったり、しまいには16ビットで足りなくなってサロゲートペアなんてものを導入したり、かなりイビツなものになっちゃってますよね。
どうせなら、最初から32ビット文字コードにしておけば、もっと使いやすかっただろうに。
内部表現は1文字が4バイトになってメモリ効率が悪くなっても、使い勝手がよくなるメリットが大きそうだし。
交換時にはUTF-8みたいなことするなら、元のコードに無駄が多くても問題ないし。

Re:ShiftJISなら非対応システムでも

[funya (14942)]

Unicode でない方のISO-2022 の延長でも32bitだったし、Emacs の日本語拡張でも24bitを使ってました。
Unicode も容認されたのは32bit code が入ってから。TRONでも文字鏡でも、たった20万字程度なら、
UCS-4 に入れちゃえば良い。CJKVで、それをやっても余裕ではいります。

Encode に関しては、UTF-8 は合理的で便利だと思う。文字数のカウントとかは、どうせ難しいのだから、
可変長コードだからどうってことはないです。

言語タグとかは文字数のカウントを難しくするために存在するようなものなのだし。内部処理でも
表示処理でも言語依存な処理は必須。なのにUnicode自体から言語依存部分を落としても意味がない。
もちろん、Alphabet unification するなら話は別だったんですけどね。とかすると、実は、ISO-2022 的な
表現になっていたってわけだな。実際にプログラムする方から見れば、悪夢度はどっちでも同じ。
Shift JISよりははるかにましなので、UTF-8 でいいよ。