文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
そのutf-8の問題は utf-16でもutf-32でも同じなのでは seekがめんどくさいのがUTF-8の問題だと思うんだけど違うの？ UTF-16はUTF-8とUTF-32のデメリットを兼ね備えていて、
メリットが無いような気がする。 このスレに来るような人が、どうしてutf8とutf16/32が同じと思うのか不思議。
自力で文字判定処理をやったことがないスクリプト言語プログラミング一辺倒の人？ >>591
文字コードに習熟したプログラマしかここに来ちゃいけないのかい？
俺みたいにユニコードとUTFの違いすらよくわからない者が情報を求めて
ここに通うこともあるんだぜ pythonなんて内部の文字コードutf16だよ。
使う側が意識せずに済んでるってのがむしろ凄いわけで。
utf16要らないとか言ってる人は、事業仕分けでドヤ顔する民主党議員だわ。 仕分けしたからモリカケだけで済んでるんじゃないの？ 本当だよ
無駄な予算にかけようとするこういうバカは消えてほしい UTF-16はいきなり廃止するのは無理でも
新規設計非推奨くらいにはしてほしいよ WinAPIでUTF-16使ってるから廃止は無理でしょ UTF-16は世界中の文字を固定長で表せるようにすることが目標だったから
16bitではそれができないと分かった以上32bitに変えるべき linux64bit版gccは、wchar_tやstd::wstringが既定でutf32だし、徐々に変わっていくでしょう。 win32->win64のタイミングで変えとけばよかったのに >>600
ほんそれ
ついでにシステムロケールもUTF8はよ 必要な時にUTF32を使えればいいだけなのでそんなに深刻がらなくても大丈夫でしょ。 基本は8で臨時は32で答えが出ているよなあ
日本独自のJIS関係とかもう要らないし そういえば新元号合字ってJIS X 0213とかCP932とかの系統にも入るのかな？
元号合字使ってるとこはUnicodeじゃない古いとこが多そうだからここに入れないと意味半減な気がするけど 印刷に使うワープロソフトはすべてunicode対応しているから大丈夫。 日本語とか東アジア言語はバイト数の面では
UTF8よりUTF16の方が有利になるのだが。 お経とかならそうかも
でも普通の日本語の文書はUTF-8で１バイトになる字がわりと使われてるよね
改行もバカにならない エディタとかUTF-32に対応してないのが多いよな。
まあ、無駄が多いからな。最上位の1バイトは必ず0x00になるから。 余ってる場所を余計なことに使う奴が絶対出てきて、
それを根絶するのに凄い辛い思いをするからヤメレ。 もうこれ人類的に根絶できないんだろうね
一生これなんだろうね そういえば、utf9というのもあったな。３６ビットコンピュータに最適だとか。 UTF-24を策定するべきだな。
全ての文字を24ビット(3バイト)で表す。
UTF-32の0x00で固定な最上位バイトを省くというので。
BMP外の文字だらけの文章には有利になるだろう。 >>623
だな、固定長はUTF-24、可変長はUTF-8でいいだろう UTF16はいらないとかUTF24がよいとか、変な書き込みする人、同一人物？
CPUのレジスタは32bitまたは64bitなので、1バイトをコピーするのも4バイトをコピーするのも時間コストは同じだよ。 1バイトと4バイトとかミクロの性能比較なんか殆ど意味無い >>626
大ありですよ。
>>627
固定長の方が条件分岐が減るので処理速度が高く、プログラミングもしやすい。 >>626
ファイルサイズがでかくなればそれだけ処理をする回数が増えるからダイレクトに効いてくる。 CPUひとつあたりの処理速度は10年前とあまり変わってないけど、搭載できるメモリの量は劇的に増えた。
内部実装がUTF32になって文字列リソースが2〜4倍になったとしても利用できるメモリはそれ以上に激増しているのでまったく問題なし。
むしろUTF16やUTF32のほうが頭打ちのCPUにも優しい、ということがわかるはず。 16は全然優しくない
24もアライメントを考えると優しくない >>633
合成やセレクタを撤廃できるのなら128でいいよ UTF24とかメモリアクセス効率悪すぎるだろ。アライン考えろ。
情報交換用文字コードはエンディアンに依存しないUTF8。
内部用の文字コードはアクセス効率が良いUTF32。
貧乏人専用のUTF16。
それぞれ存在理由があるんだよ。 Windowsの場合、プログラムを何も改修することなくUTF16でサロゲートペアの絵文字を使えているでしょ。
もちろん、文字フォントを描画するAPI、つまりマイクロソフトの中の人が頑張っているからだが。 まぁ、Windowsプログラムで、動的に絵文字の肌色・髪色・性別などを変えようと思ったら、
UTF16のサロゲート処理を自分で行う必要があるけどね。 >>637
24が駄目なら8はもっと駄目なんでないの？ だからUTF8は内部利用じゃなくて情報交換用なんだろ。 SJISと取り決めてあるテキストデータにUTF8をぶっこんできた取引先があって
翌朝からの日本社会に大混乱を引き起こしかねない危機に晒された経験がある
UTF8滅ぶべしと俺は本気で思っている エンコーディングは関係ないだろ。
決めごとを守れないその取引先と異常データを突っ込まれただけで混乱しちゃうプログラムの問題。 何年か前に、地域の緊急速報のテストメールか何かに
エンコーディングを混在させて文字化けを地域住民に送って混乱させたのあったな
メールテンプレートのエンコーディングと、流し込む本文で混在させちゃったみたいな ないしほてし活復を語本日く書に左らか右どけい良もでき書横 中東の言語は確か右からだったよな
やろうと思えば簡単そう sjisの〜とcp932の〜の違いって何？
〜を入力して検索すると、sjisのほうはヒットしないんよね >>650
「入力して検索する」
どうやって入力して何を検索するのか他人に分かるように書いたらどうか
入力側がUNICODEで変換不能とかじゃない 絵文字がんがん増えてるけど、ぱっと見で見分けが付かない微妙なの多いよなぁ そのうち洗練されて象形文字になって、やがて漢字に…あれ? この際1byteを32bitか64bitにしたらどうよ
1byteが8bitになったのはアルファベットや数字が固定長で表せて
2^nbitで処理しやすかったからなんだろうけど
1byteが32bitか64bitになればエンディアンの問題もなくなって分かりやすくなる そうなんか？
16新数で2桁でちょうどいいからだと思ってた あと 8bit を 1byte というけど
4bit のことをなんていうの？ >>657
8bitや16bitのCPUはどうすんの？ >>657
32bitでも、64bitでも、好きな長さを「word」と呼べばいい。
これで、エンディアンの問題もなくなって分かりやすくなるんだよな。 無理。各コンピュータ内部なら好きなビッド数にすれば良いけど、インターネットのほぼ全ての規格はオクテットが基準になってる。
インターネット全部作り直すくらいやらないと今更変更できない。 >>584
昔の ISO/IEC 10646 がそんな感じじゃなかったっけ？
UCS-4 が Four-Octet Canonical Form (4オクテット正規形) と呼ばれてて
UTF-8 や UTF-16 はあくまで Transformation Format だと。 UTF-32に統一できないなら、UTF-8を残そうがUTF-16を残そうが
どちらも大して変わんないんだよね。
UTF-8 も UTF-16 も既存OSの互換性を保つためにあるのだから
UTF-8はANSI互換性というメリットがあるというけれど
なんてことはない、Unix/Linuxの改修が大変だったから、
文字コードのエンコーディング方式自体を作ったってだけの話
互換性のために作ったものだよ
16bitにすべての文字を収めるのは不可能だが、仮に収まったとしたら
UTF-16はサロゲートペアなどなく1文字16bitというシンプルなものになっていた。
もし最初から32bit必要だと認識していれば、UTF-32という1文字32bitに
統一された素晴らしい文字コードになっていただろう
そしてWindowsはそれを標準文字コードとして採用しただろう。
（WindowsがUTF-16なのは、その頃はUnicode = UTF-16の前身のUCS-2 だったから）
結局固定長でないなら、どちらも面倒なことに大差ないし
互換性を保つために面倒な方式を残すのであれば、
それがUTF-8でもUTF-16でも同じこと 8も16も大して変わらないと言えばそうだけど、種類が少ないに越したことはないし
どっちかひとつ残すならやっぱり8なので、16には退場願いたいね >>669
Windowsという重要な役目があるので無理だってわかってるだろ？ >>667
妄想は要らん
asciiとの互換性とosの改修は関係ない
16bitに収まったとしたらとか ifを言い出したらきりがない >>670
昔からMSは独自文字コードが大好きだからUNICODEからUTF-16が無くなっても問題ない >>671
> asciiとの互換性とosの改修は関係ない
大あり。C言語はASCII互換前提となっている。
具体的に言うと、文字列の終端文字が\0なので
UTF-16やUTF-32といった、1文字の中に\0が
含まれてる場合に対応できない
UTF-8でなければprintfなどの基本的でよく使われる関数
全てをUnicode対応に改修しなければならなかった。
もしくは捨て去さるかだ >>672
昔からUnicode対応なんですがーｗ UTF-16やUTF-32も1文字の中に\0が含まれているわけじゃないがな。 http://ash.jp/code/unitbl1.htm
41 41 41 41 0041 A
42 42 42 42 0042 B
43 43 43 43 0043 C
44 44 44 44 0044 D
45 45 45 45 0045 E
右から二番目がUTF16の文字コード
見ての通り基本のアルファベットの中に0x00が含まれてる
つまり ABCは、00 41 00 42 00 43 もしくは 41 00 42 00 43 00 という並びとなり
これをprintf等にわたすとASCII文字として1文字8bitと解釈し、
00を\0とみなすので途中で切れるか全く表示されなくなる 説明足らずな>>675が揚げ足取りだと思われると可愛そうなので（笑）
補足してあげると、UTF-16やUTF-32の1文字はそれぞれ16bit or 32bit で
16bitで\0、32bitで\0 は含まれてないと言いたいのだ
だが今は、printfなど1文字8bitと解釈する関数の話をしているので
8bitずつ見ていくと文字の途中に\0が含まれるのだ まあWindowsみたいにcharはロケール依存のままでwchar_tだけUnicodeという構成もあるので
UnixのUnicode対応にUTF-8が必須だったかというとわからんけどなー >>680
え？ Unixもwchar_tはUnicodeだけど？ 正確には、既存のコードの多くは wchar_t が使われて無くて、
その対応が大変だっていう話
WindowsはOSすべてを自分たちで作ってるからどうにかなったが、
オープンソースで他人が作ったものの寄せ集めだと対応が大変だろうね gcc は、 wchar_t を16bitと32bitでコンパイル時に選択できるようになっているので、のちのちWindows以上に厄介なことになるでしょう。 >>681
Linuxではそうだけど、Unix一般の話でいうとwchar_tはcharの多バイト文字をひとつの値で表せられるならなんでもいいし
実際BSDはcharがSJISならwchar_tはJISコード OSの中とかプログラム言語とかどうでもいい。
インターネットとかの通信プロトコルでオクテット(8bit)単位で交信、終端は0x0A 0x0Dとかの特定のオクテットコード列を使用とかになってるのが多数ある。
内部では好きなビット数で処理すれば良いけど、通信には8bit単位の処理系も必須。
ユニコード使うかどうか以前の問題。 wcharは、内部の符号化に依存しちゃいけないし、幅が 16bitか32bitかに依存するのもよくない
使うのがなかなか難しいね
但し、char と混在させるのは単なる誤り。printf に使うと途中で切れるとかいうのは使う側のミス ■ このスレッドは過去ログ倉庫に格納されています
