アカウント名:
パスワード:
LLの場合、バイト列と文字列がごっちゃになりがちで、実際Perlの:utf8はかなりバッドノウハウの温床になっていて使いにくいので、基本バイト列として扱って文字列として扱う時は関数使うか別途クラスを立ち上げろ、というのは相応に理にかなった対応だとは思います。UTF-16はサロゲートペア問題があるためUNICODEの内部表現としては今となっては必ずしもベストではなく、結局文字列表現として何文字か数えるのに専用関数で数えて下さいみたいなことになるなら、バイト列にUTF-8で突っ込んで専用関数で取り扱えばいいじゃん、というのは原始的ですが間違いは少ないと言えます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
当面、ライブラリレベルでやれってことね (スコア:1)
そう言う問題は出なかった。なので、後方互換性に失敗したってこと
なんでしょう。
現状でも、mb_convert_encoding しまくれば良いとも言えるので、
ちょっとみっともないぐらい。PHPプログラマはそういう細かいことは
気にしないってことだな。
メールの扱いとかでも、すぐにencodeは混在しちゃうから、必ず
使うことになるし。
Re:当面、ライブラリレベルでやれってことね (スコア:2, 参考になる)
LLの場合、バイト列と文字列がごっちゃになりがちで、実際Perlの:utf8はかなりバッドノウハウの温床になっていて使いにくいので、基本バイト列として扱って文字列として扱う時は関数使うか別途クラスを立ち上げろ、というのは相応に理にかなった対応だとは思います。
UTF-16はサロゲートペア問題があるためUNICODEの内部表現としては今となっては必ずしもベストではなく、結局文字列表現として何文字か数えるのに専用関数で数えて下さいみたいなことになるなら、バイト列にUTF-8で突っ込んで専用関数で取り扱えばいいじゃん、というのは原始的ですが間違いは少ないと言えます。