アカウント名:
パスワード:
「秀丸ですらutf8だよ」とまだSJIS至上主義の人を改心させて欲しい文字コードが混在する時代を早く脱せたらいいな
本当ですねでもwindows本体はutf16標準とかになりそうで嫌ですね
Windows内部(主にメモリ)での内部表現はutf16相当だけど、テキストファイルのエンコードはかなり前からuft8が標準だよ。httpなど外部とのやり取りは基本的にutf8としているわけで、システム内部のエンコーディングを気にする理由がいまいちわかりません。
パフォーマンスとしてはちょっと問題。dotnetは昔から内部がUTF-16だけど、最近変換コストが無視できなくなって来ている。だからできるだけUTF-8を使うようにしたいのだが…破壊的変更はしたくないしで困ってる。
文字列操作関係の仕様変更や実装やり直しの多さを考えると破壊的変更と呼ぶのも生ぬるいレベルになりそうだから、内部実装のuft8化はやめといた方がいいと思う。String.Lengthの意味が全く変わることだけ考えてもひどいことになる。
UTF-16も固定長じゃないので、別に意味が変わるとは思わないけど。まさか Length プロパティが文字数だとかしてないよね？ まさか、ね？
んなことはわかってて言ってるの。Lengthはutf8のバイト数を返すようになったらまともに動かなくなるプログラムがどれだけあるか、それがまともに動くように修正するのがどれほどの負担になるか想像してからコメントしろ。
具体的に言ってみろよ元々可変長だった文字列表現が別の可変長になったところで大して困ることはないと思うが？え、まさか UTF-16 だから要素サイズを 2 とかハードコーディングしちゃってるとかないよねw
.NETなどの文字列処理を理解してないことがよくわかるコメントだな。.NETはUTF-16なのでchar型は16ビットで、バイト配列に変換でもしなければ一文字を2とカウントすることはほぼない。
具体例としては入力フォームなどでテキストボックスなどの最大文字数を指定している場合、たとえば4と指定していれば英数字でも漢字でもサロゲートペアなどでなければ4文字入力できる。それをUTF-8で扱うとどうなる？漢字は2文字までしか入力できなくなって動作に支障をきたす？UTF-8だと3バイトになる漢字も多いから12とする？それだとアルファベットは12文字まで入力可能になってそちらが問題となる可能性も十分ある。
それって要するに「自分は可変長のエンコーディングをまともに取り扱うことができない無能です」っていってるだけだよね？
書き忘れてたけど、それって Length プロパティと何の関係があるの？あとサロゲートペアにしか言及してないけど合字は？ 結合文字はどうするの？自分の方が無知なんじゃね？
文字単位のインデックスアクセスではパフォーマンスに大きな差が出るから、主要な実装のほとんどが内部的にはUTF-16で扱ってるという事実をまるごと無能呼ばわりできるあなたはとても有能なんですね。
何文字目かを正しく取得するのにはUTF-8だろうがUTF-16だろうが、先頭からたどっていくしか方法はない。文字配列のn番目を取得するのにも、UTF-8だろうがUTF-16だろうが関係ない。何文字目かを正しくとらなくてもいいんならUTF-8だって、nバイト目を含む文字を取得するのは極めて高速にできる。さらに処理系を作るのに文字列の内部実装がUTF-8かUTF-16かなんてのはたいした違いがない。Java や Windows が UTF-16 を採用していたり、JavaScript の内部実装で UTF-16 が多かったりするのは単に16ビットあればすべての文字を表せるという幻想に漬かっていた頃にルーツがあるからに過ぎないよ。
現実にはそれだと時間がかかるから、文字数は2バイトを1文字分ということにしてサロゲートペアなどは複数文字扱いしてるんだよ。文字列処理では「何文字目にアクセス」が極めて多くていちいち先頭からスキャンするのは効率が悪すぎるから、16ビットで表せない文字による文字数カウントの矛盾は妥協して速度を優先している。あくまで内部実装だけの話なのだから、パフォーマンスへの影響が無視できるほど小さいならUTF-8へ移行することもできなくはないだろうよ。
Lengthは一例として取り上げただけなのでそこにこだわる必要性はまったくないよ。それにサロゲートペア以外の存在に言及したところでなにか違いがある？話が長くなるだけで何も変わらないからいちいち言及しないよ。そんなに無理して突っ込むところを探さなくてもいいんだよ。
Length の本質的意味は変わってないのに、一例としてあげるのはおかしいだろ
だからそれが許される実例を挙げてみろっての。「2バイトで表現できない文字が現れたときには正常で動作しないのが仕様」という場合を除いて。そして現実に UTF-8 では大きな問題になるような場合を。
パフォーマンスの問題は無視できないほど大きいと言ってるだろうが。だからGoogleは速度を重視した独自javascriptエンジンのV6を作り、Microsoftは.NET Coreを作るタイミングで速度重視の実装を作り直したりしている。今どきはweb関係は動的な文字列処理がかなり増えたので、JITのような最適化は難しいこういう低レベルな処理はランタイムレベルで遅いと全体の足を引っ張る。
だからどんな処理で問題になるのか実例を示せといってる。たびたびインデックスアクセスとかいってるが、そのインデックスはどこから来るんだよ。天からランダムに降り注いでくるのか？ 違うだろ。通常それらは検索などを行った結果で、検索などのアルゴリズムにおいて、UTF-16とUTF-8で、本質的に違いがない。つまりUTF-8にしたといって速度が猛烈に変化するわけじゃない。
substringやreplaceなど文字数単位のインデックスを引数として渡すメソッドはありふれていて、それらに渡す数字は検索結果などで取得したインデックスとは限らないことは珍しくない。ほとんどの場合インデックスとして渡される値は検索結果で得られた値をそのまま使っていると決めつけるのが間違い。実装する側としては「インデックスパラメータの値は任意の整数値」と考えざるを得ないんだよ。
具体性が一切無いwwwつまり自分がそう思うからそうなんだ位の根拠しかないんですね
これが具体的な話に見えないなら理解力が足りないだけだね。
wwwwwwwwwwwwwwwwwwwwどんなときに、どういう目的で、どのような方法でインデックスを計算するのかの情報が皆無なのに、どうやっておまえの主張の正当性を検証するの？ 馬鹿なの？
UTF-8は、よく使うのだけでも、1-4バイトの可変長。例外対応するなら1-6バイトの可変長まで想定する必要がある。1-6バイトの可変長になるU+10FFFFより先のコード拡張なんてやめてくれというのが切実な願いだろう。
UTF-16は、使用頻度が高いのが2バイトで、サロゲートペアがあると4バイトになる。処理は、UTF-16の方が楽だわな。
使用頻度と処理の簡単さには何の関係もないと思いますが。OSとしては、使用頻度が低いから対応しなくてもいいとはならないから、UTF-16だろうがUTF-8だろうが、実装しないといけない処理に大差はないでしょう。
あと、サロゲートペアにしか言及していませんが、合字とか結合文字列とかあるのでUTF-16の1文字は最大4バイトというのも間違い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
windowsの脱SJISが進んで欲しい (スコア:0)
「秀丸ですらutf8だよ」とまだSJIS至上主義の人を改心させて欲しい
文字コードが混在する時代を早く脱せたらいいな
Re: (スコア:0)
本当ですね
でもwindows本体はutf16標準とかになりそうで嫌ですね
Re: (スコア:0)
Windows内部(主にメモリ)での内部表現はutf16相当だけど、テキストファイルのエンコードはかなり前からuft8が標準だよ。
httpなど外部とのやり取りは基本的にutf8としているわけで、システム内部のエンコーディングを気にする理由がいまいちわかりません。
Re:windowsの脱SJISが進んで欲しい (スコア:0)
パフォーマンスとしてはちょっと問題。
dotnetは昔から内部がUTF-16だけど、最近変換コストが無視できなくなって来ている。
だからできるだけUTF-8を使うようにしたいのだが…破壊的変更はしたくないしで困ってる。
Re:windowsの脱SJISが進んで欲しい (スコア:1)
文字列操作関係の仕様変更や実装やり直しの多さを考えると破壊的変更と呼ぶのも生ぬるいレベルになりそうだから、内部実装のuft8化はやめといた方がいいと思う。
String.Lengthの意味が全く変わることだけ考えてもひどいことになる。
Re: (スコア:0)
UTF-16も固定長じゃないので、別に意味が変わるとは思わないけど。
まさか Length プロパティが文字数だとかしてないよね？ まさか、ね？
Re: (スコア:0)
んなことはわかってて言ってるの。
Lengthはutf8のバイト数を返すようになったらまともに動かなくなるプログラムがどれだけあるか、それがまともに動くように修正するのがどれほどの負担になるか想像してからコメントしろ。
Re: (スコア:0)
具体的に言ってみろよ
元々可変長だった文字列表現が別の可変長になったところで大して困ることはないと思うが？
え、まさか UTF-16 だから要素サイズを 2 とかハードコーディングしちゃってるとかないよねw
Re: (スコア:0)
.NETなどの文字列処理を理解してないことがよくわかるコメントだな。
.NETはUTF-16なのでchar型は16ビットで、バイト配列に変換でもしなければ一文字を2とカウントすることはほぼない。
具体例としては入力フォームなどでテキストボックスなどの最大文字数を指定している場合、たとえば4と指定していれば英数字でも漢字でもサロゲートペアなどでなければ4文字入力できる。
それをUTF-8で扱うとどうなる？漢字は2文字までしか入力できなくなって動作に支障をきたす？UTF-8だと3バイトになる漢字も多いから12とする？それだとアルファベットは12文字まで入力可能になってそちらが問題となる可能性も十分ある。
Re: (スコア:0)
それって要するに「自分は可変長のエンコーディングをまともに取り扱うことができない無能です」っていってるだけだよね？
Re: (スコア:0)
書き忘れてたけど、それって Length プロパティと何の関係があるの？
あとサロゲートペアにしか言及してないけど合字は？ 結合文字はどうするの？
自分の方が無知なんじゃね？
Re: (スコア:0)
文字単位のインデックスアクセスではパフォーマンスに大きな差が出るから、主要な実装のほとんどが内部的にはUTF-16で扱ってるという事実をまるごと無能呼ばわりできるあなたはとても有能なんですね。
Re: (スコア:0)
何文字目かを正しく取得するのにはUTF-8だろうがUTF-16だろうが、先頭からたどっていくしか方法はない。
文字配列のn番目を取得するのにも、UTF-8だろうがUTF-16だろうが関係ない。
何文字目かを正しくとらなくてもいいんならUTF-8だって、nバイト目を含む文字を取得するのは極めて高速にできる。
さらに処理系を作るのに文字列の内部実装がUTF-8かUTF-16かなんてのはたいした違いがない。
Java や Windows が UTF-16 を採用していたり、JavaScript の内部実装で UTF-16 が多かったりするのは
単に16ビットあればすべての文字を表せるという幻想に漬かっていた頃にルーツがあるからに過ぎないよ。
Re: (スコア:0)
現実にはそれだと時間がかかるから、文字数は2バイトを1文字分ということにしてサロゲートペアなどは複数文字扱いしてるんだよ。
文字列処理では「何文字目にアクセス」が極めて多くていちいち先頭からスキャンするのは効率が悪すぎるから、16ビットで表せない文字による文字数カウントの矛盾は妥協して速度を優先している。
あくまで内部実装だけの話なのだから、パフォーマンスへの影響が無視できるほど小さいならUTF-8へ移行することもできなくはないだろうよ。
Re: (スコア:0)
Lengthは一例として取り上げただけなのでそこにこだわる必要性はまったくないよ。
それにサロゲートペア以外の存在に言及したところでなにか違いがある？話が長くなるだけで何も変わらないからいちいち言及しないよ。
そんなに無理して突っ込むところを探さなくてもいいんだよ。
Re: (スコア:0)
Length の本質的意味は変わってないのに、一例としてあげるのはおかしいだろ
Re: (スコア:0)
だからそれが許される実例を挙げてみろっての。
「2バイトで表現できない文字が現れたときには正常で動作しないのが仕様」という場合を除いて。
そして現実に UTF-8 では大きな問題になるような場合を。
Re: (スコア:0)
パフォーマンスの問題は無視できないほど大きいと言ってるだろうが。
だからGoogleは速度を重視した独自javascriptエンジンのV6を作り、Microsoftは.NET Coreを作るタイミングで速度重視の実装を作り直したりしている。
今どきはweb関係は動的な文字列処理がかなり増えたので、JITのような最適化は難しいこういう低レベルな処理はランタイムレベルで遅いと全体の足を引っ張る。
Re: (スコア:0)
だからどんな処理で問題になるのか実例を示せといってる。
たびたびインデックスアクセスとかいってるが、そのインデックスはどこから来るんだよ。
天からランダムに降り注いでくるのか？ 違うだろ。
通常それらは検索などを行った結果で、検索などのアルゴリズムにおいて、UTF-16とUTF-8で、
本質的に違いがない。つまりUTF-8にしたといって速度が猛烈に変化するわけじゃない。
Re: (スコア:0)
substringやreplaceなど文字数単位のインデックスを引数として渡すメソッドはありふれていて、それらに渡す数字は検索結果などで取得したインデックスとは限らないことは珍しくない。
ほとんどの場合インデックスとして渡される値は検索結果で得られた値をそのまま使っていると決めつけるのが間違い。
実装する側としては「インデックスパラメータの値は任意の整数値」と考えざるを得ないんだよ。
Re: (スコア:0)
具体性が一切無いwww
つまり自分がそう思うからそうなんだ位の根拠しかないんですね
Re: (スコア:0)
これが具体的な話に見えないなら理解力が足りないだけだね。
Re: (スコア:0)
wwwwwwwwwwwwwwwwwwww
どんなときに、どういう目的で、どのような方法でインデックスを計算するのかの情報が
皆無なのに、どうやっておまえの主張の正当性を検証するの？ 馬鹿なの？
Re: (スコア:0)
UTF-8は、よく使うのだけでも、1-4バイトの可変長。例外対応するなら1-6バイトの可変長まで想定する必要がある。
1-6バイトの可変長になるU+10FFFFより先のコード拡張なんてやめてくれというのが切実な願いだろう。
UTF-16は、使用頻度が高いのが2バイトで、サロゲートペアがあると4バイトになる。
処理は、UTF-16の方が楽だわな。
Re: (スコア:0)
使用頻度と処理の簡単さには何の関係もないと思いますが。
OSとしては、使用頻度が低いから対応しなくてもいいとはならないから、
UTF-16だろうがUTF-8だろうが、実装しないといけない処理に大差はないでしょう。
あと、サロゲートペアにしか言及していませんが、合字とか結合文字列とかあるので
UTF-16の1文字は最大4バイトというのも間違い。