アカウント名:
パスワード:
UTF-16なら、バイト数÷2でちゃんと文字数が出てきます。シンプルですよ～
どうせなら、最初から32ビット文字コードにしておけば、もっと使いやすかっただろうに。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
ShiftJISなら非対応システムでも (スコア:2, おもしろおかしい)
個人的にはMatzきらいだけどMatzの意見に賛同。
#あほぷろぐらまなのでID
Re:ShiftJISなら非対応システムでも (スコア:5, おもしろおかしい)
私のナニに賛同してくれたのかさっぱりわからないけれど、
あなたが私をきらいだということはしっかり伝わりました(泣
まつもと ゆきひろ /;|)
Re:ShiftJISなら非対応システムでも (スコア:1)
これでは早晩、「おじいさんの対応」とか「ひいおばあさんの対応」なんて言葉も必要になりかねないじゃないか。
Re:ShiftJISなら非対応システムでも (スコア:1)
ACで「私も」と言ってもな。
Re:ShiftJISなら非対応システムでも (スコア:0)
傍から見て、すげーくだらない話なんだけど。
いったいこれのどこが大人なんだ。
Oliver氏はどこで関係してくるんだ。
Re:ShiftJISなら非対応システムでも (スコア:0)
まつもと氏のたった１行の感想に読む気も起こらないような長文で
反論するのが大人の対応ねぇ。俺はちょっと大人気ないと思ったよ。
Re:ShiftJISなら非対応システムでも (スコア:3, すばらしい洞察)
半角は1byteだから÷1ですよ!
まぁ、ネタにマジレスだとは思うけど。
そーゆー基本を忘れて書かれているプログラムを、実際に見ちゃってるとねぇ。
Re:ShiftJISなら非対応システムでも (スコア:1)
…というのが、Unicode が出てきたときにメリットとして挙げられていたと思うのですが
合成文字なんてものがあったり、しまいには16ビットで足りなくなってサロゲートペアなんてものを導入したり、かなりイビツなものになっちゃってますよね。
どうせなら、最初から32ビット文字コードにしておけば、もっと使いやすかっただろうに。
内部表現は1文字が4バイトになってメモリ効率が悪くなっても、使い勝手がよくなるメリットが大きそうだし。
交換時にはUTF-8みたいなことするなら、元のコードに無駄が多くても問題ないし。
Re:ShiftJISなら非対応システムでも (スコア:2, すばらしい洞察)
問題は内部表現のつもりだったものは必ずと言っていいほど外に出てくるということですが。16bit固定長の時代のUnicodeは内部コードとして使うことを想定してたのでBOMがなかったり(その計算機で自然なバイトオーダーに決まってるから)変換表の違いに無頓着だったり(外に出て行かなければ問題は表面化しないから)してて、そのツケを今になって払わされてるわけです。
Re:ShiftJISなら非対応システムでも (スコア:1)
Unicode も容認されたのは32bit code が入ってから。TRONでも文字鏡でも、たった20万字程度なら、
UCS-4 に入れちゃえば良い。CJKVで、それをやっても余裕ではいります。
Encode に関しては、UTF-8 は合理的で便利だと思う。文字数のカウントとかは、どうせ難しいのだから、
可変長コードだからどうってことはないです。
言語タグとかは文字数のカウントを難しくするために存在するようなものなのだし。内部処理でも
表示処理でも言語依存な処理は必須。なのにUnicode自体から言語依存部分を落としても意味がない。
もちろん、Alphabet unification するなら話は別だったんですけどね。とかすると、実は、ISO-2022 的な
表現になっていたってわけだな。実際にプログラムする方から見れば、悪夢度はどっちでも同じ。
Shift JISよりははるかにましなので、UTF-8 でいいよ。
Re:ShiftJISなら非対応システムでも (スコア:0)
Re:ShiftJISなら非対応システムでも (スコア:1)
しかも UTF-16 は 32ビットになることもあるので2で割っても正しい文字数になりませんね。
やはり、時代は UTF-32 だと感じます。
なんでもっとはやらないんでしょうか。
Re:ShiftJISなら非対応システムでも (スコア:0)
Re:ShiftJISなら非対応システムでも (スコア:0)
2バイト半角? プロポーショナルフォント?