文字コード総合スレ Part12
レス数が900を超えています。1000を超えると表示できなくなるよ。
>>837
うわなつかしい、俺のアドレスもあったw 議論の理由も似てるかも
free()が必要かどうかは環境による。基本は必要最低限で使え。
BOMが必要かどうかは環境による。基本は必要最低限で使え。
というのが正しい答えだが、特定の環境のみ前提に主張するやつや、
念のためにいれておこうと考える不届き者のせいで話が混乱する。 >>837
俺はこれ知らんかったけど、太田・久野・河野…とそうそうたるメンバーですなあ懐かしい >>839
それに「そもそも BOM という名前が」云々の原理主義者もお忘れなく、あー私のことか‥‥ つまりBOMの話題はプログラマ界隈にとって爆弾のようなものだ、とこういうことか >>844
ミニマム・シンプルというのがプログラムの基本というのが理解できないやつがいる。
「不必要なものは入れるな」というのは最低限の知識. パーセントエンコーディングした文字列を正確にURL引数に渡すには
文字エンコーディングをサーバーに教えるためのパラメーターが別途必要になる。
だが、しかしサーバー側アプリにはBOMの情報をまるっと捨て去って平然と不具合を起こす権利がある。
文字エンコーディングをサーバーに教えるためのパラメーターと同じ役割を果たすのがBOM。
テキストエディタやコンパイラやブラウザはBOMをガン無視する権利がある。 すっげー、面白い解釈してるな。どの規格読んだの？
URI は全体で一つの文字列なので、BOM つけるのなら最初の https: とかの前につけないと意味ないんだが？
そんな規格違反の URI に対応する必要があるという主張? それとも文字列の途中に BOM を入れて解釈しろという主張？ それは不要なもの入れる入れないではなくて、拡張性のある実装と拡張性の乏しい実装の違い。
unicode の文字の中には余計なものもあることは認めるが、それは関係ない。 >>850
つまりUTF-32が正解ってことでしょ？ その辺は既に結論が出てる。
UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。必要なら32bitまで拡張可能。外部コードに最適
UTF-32: 固定長。必要なら32bit分の文字まで拡張可能。内部コードに最適。
UTF-16: メリットがない。拡張性ない。オワコン。将来は特定のOSやプログラム言語やアプリで過去の遺物として残る UTF-32が固定長なのはすべての文字が32bit長に収まる時期限定の話でしかない
いずれUTF-64を固定長として定義してUTF-32を可変長にせざるを得ない
そしていつの日かUTF-64も可変長になる日が来る
以後ループ >>852
あのさ、UTF-32のBOMを無視するなよ > UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。
って言ってるのに、これが
欧米ではない文章だとUTF-16に劣るという
意味になるってわかってないのかな？ UTF-16だと2バイトですむのに、UTF-8だと3バイト必要だからな
データ量が33%増加する 日本語の漢字かな中心の文章や、中国語の文章などでは UTF-16 の方が短かくなるけど
欧米のやつらは日本語での長さなんて気にもかけないので。もはや UTF-16 はオワコンで意見が固まってる。
欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
日本のすみっこで、いくら叫んでも世界の流れは変えられないのだ。
少し腹立つけど仕方ない。 WindowsやJavaの内部エンコードに使われている限り生き続けるだけだろ。日本がどうとか関係ない。
>欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
そのマルチバイトエンコーディングからUTF-16に乗り換えたWindowsやJavaの中の人は欧米なんだが。
もしかしたらUTF-8を推したいのかもしれないけど論理が支離滅裂。 U+xxxxxxxxで表現されるバイト列をRAWデータで扱うための概念としてUTF-16,UTF-32は必要とされ続ける 合成文字があるのにいつまで固定長なんて幻想にしがみついてんだよ これからはUTF-16の時代だって思うやつがいるんなら英語の掲示板に行ってぜひ布教してくれ。
もう世の中の流れは変わってることがわかる。昔に戻せるならやってみてくれ。
無理だと思うが、個人的には嬉しいので。 git diff コマンドがUTF-16テキストファイルをバイナリ扱いして困る これからはUTF-16の時代だなんて思う奴はまずいないだろうが、
これからもUTF-16の時代が続くと思う奴はいるだろう。 欧米の奴らも絵文字は使いたがる、これはある意味いいことかも。 >>861
これからもなにもずっと前からUnicodeの時代で
UTF-16もUTF-8もその表現の一つでしかないんだが
WindowsのAPIは柔軟だから両方に対応してるね U+xxxxxxxxで表現されるバイト列をRAWデータで扱うためとしても
UTF-16は桁が足りないんだからUTF-16を使っている箇所はUTF-32に移行すべき ASCII文字も1文字=7bitを前提にした文字の並びになっているから
1文字=8bitを前提に文字の並びを変えて
ISO646による言語別の文字の変更（バックスラッシュが円マークになる）も
廃止すればシンプルになっていいね。
ISO8859でもASCII文字の部分は何も変えなかったのは
ASCIIとISO646が普及してしまって変えられなかったから？ 過去のファイルは編集されずにずっと残るんだから古いファイルを
開くために仕様や規格を廃止することは不可能だよ
これからの話しか見えてないのは視野が狭すぎる 過去の文字コードってASCIIでしょ。だったらUTF-8でそのまま読めるじゃん。というのがアメリカンの発想。
ローカルなSJISなどというものは念頭にない。ASCIIに比べれば大した量ではないので変換でも何でもしろくらいに思ってる。
オープンソース系のアプリとか気の早いやつは、もうUTF-8以外のサポート切り捨てようとか本気で言い出してる。
まだ時期尚早と説得してるが、どうなることやら。 もうAltコード覚えてしまってるから勘弁して
まあ今もアプリ側でマップしてるだろうけど、文字セットの実装が失われると参照が難しくなり方言化が進む
なにより二重ループで一覧表生成出来なくなるだろうしやだー コードポイント=エンコードにできるはずの128-255を捨てるutf-8一人勝ちは避けたい
欧州文字セットでも記号類とか重宝する
8-bitクリーンかを気にする機会減ってきたし、新規参入の機会では
ダイアクリティカルマークは別バイトにすれば記号いっぱい詰め込めるだろ >>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの >>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの Windows用実行バイナリの場合、システムの文字コードに依存したC言語ライブラリを使ってコンパイルされた実行バイナリが大部分だから、移行は簡単じゃないよ。
新しいライブラリにリンクするよう作り直したバイナリを再配布する必要がある。動作検証がたいへん お堅くwin32API叩いて書かれたバイナリの互換性は驚異的だよな
MSが気まぐれに出しては忘れるフレームワーク叩いてたら知らんが
バイナリ配布文化を育ててしまった原因でもあるが、ここまで大事にしてきたのにエンコード対応なんかで折れてもらっては残念
win10(64bit)でoffice97が元気に動くのは誇っていい >>876
ロケール指定する処理が省かれたC言語アプリ全般 大部分と言う割に、事例を一個も思いつかないなら矛盾してる Cで書かれたレガシープログラムほぼ全部なので挙げるまでもないんだけど、有名どころだとPerlだね
システムコード以外の文字を含むファイル名をperlに引数で渡せない Cで書かれたmain()関数にはシステムコードページで引数が渡されるのだけど、その時点で文字化けしてるので復元不能。 >>880
お前、もう少し黙っとけ。無知過ぎる。
アホを晒し続けてるの実は同一人物だろ。 >>867
勿論普及してたからはあるだろうけど、そもそも変えるとかまた作り直すとかいう発想が無かったんじゃないかな。
ASCII制定→ISO 646制定→各国で変えられるのは10文字とか足りる訳無いだろ！→
ASCIIを拡張して8ビットフルに使おう→ISO 8859制定
とかそんな流れでしょ、増やして積んでけばいいと。当時のことは資料でしか知らないけどたぶん。 メールで添付ファイルを送ろうとしたらbase64でエンコードされたせいで容量オーバーした
ネットワークのトラフィックを減らすためにもメールでバイナリデータをエンコード無しで送れるのが標準化すればいいのに いち早く国際化はずのjavaもシステムのコードページでしか引数を受け取れない制約がある ほんまに？
Unicode対応していながら_wmain()とかGetCommandLineW()使ってないとは信じがたいが Windows 専用ソフトでなくて、複数のOSに対応したソフトは当然そうなる。
特に Unix 系からの移植ならロケールをコードページに対応させるのは当たり前。
Windows独自の特殊APIで実装とか頭の悪いローカル変更は極力しない。 というか単にC言語がASCII互換の文字コードしか
対応できないんだよな
そこは言語側の問題だと思う 例えばJavaとかはUnicode前提で設計されてるから
当然Javaで作った複数のOS対応のソフトは
WindowsでもUnicodeが使える
これは殆どの言語に当てはまると思う
C#、JavaScript、Ruby、Python、などなど そういやC言語はマルチバイト対応の機能は標準化されてないんだっけ？
流石にC++は標準化されてるよな？ <locale>ヘッダがマルチバイト対応を実現してくれる
問題は誰もlocaleの機能を使ってないことだ おや？<locale>ヘッダとはなんのためにあるのでしょう？
使わなくても多言語対応できるのだったのでは？（苦笑） CがASCII互換じゃないと駄目ってどこの異世界。そんなもんコンパイラの実装次第。
規格では他の文字コードも考慮されてる。
実際 EBCDIC ですら動くやつあるのに。 >>896
CはASCII互換である必要はないが、
C言語文字列互換、つまり「文字列終端が\0」互換でなければならない
EBCDICはC言語文字列互換だが、UTF-16とUTF-32は互換性がない >>898
意味わからない。wchar はC言語とは認めない主義の人かな？ 別にnull終端文字列を使うのがスタンダードかつ標準ライブラリもそう期待しているというだけであって、好きに実装したらいいよ
ぶっちゃけ舐めないと文字列長決められないので性能がスケーラブルでないし、null文字衝突の問題もあるし筋が良くない
マトモなCで書かれたテキスト関連アプリ、特にエディタでヌル終端文字列使ってるのなんて皆無だろ
普通はrope、もう少しカジュアルならパスカルストリング そもそも今時ゴミstdlib引いてC書く時点でアッて感じだし(組み込み等以外) >>899
え？C言語の仕様にwchar_tを使うmainが無いんだからら
C言語の問題でしょうが >>902
Linux/Unix のプログラムはほとんど stdlib 使ってるけど、何か問題でも？
exit() とかの基本関数は stdlib にあるんだよ。 C言語を捨てろと言ってるんだろ
他の言語に移ったところで文字コードから逃れることはできないがな >>907
他の言語はWindowsのUnicodeにちゃんと対応してる >>893
C++はヤバすぎる
utf-8用の1B型を最近標準化したけど、まともに実装されてないし設計もユルユル
WGの中の人がサードのライブラリ引いてね発言するくらいヤバい 結局の所Unicode対応ができてないのはC/C++の言語自体と
無能なC/C++プログラマが根本的な原因なんだよな
無能なくせにクソ言語を使うなと OSなどの実行環境まで含めて全部をセルフ記述できる言語だけがC言語をけなして良い。
C言語の代わりになる高級アセンブラとか存在しないのが実情。 Windowsを全部セフル記述できる人だけが、Windowsをけなしていい 訂正
Windowsを全部セルフ記述できる人だけが、Windowsをけなしていい >>912
C言語（とその派生）が無くなると世の中のほぼ全ての言語が一緒に死ぬからなあ。
ハンドアセンブルのマシン語は残るとして他に生き残りそうなやつって何があるだろうか？
汎用機のCOBOLとかなら大丈夫か？
C言語で使えない文字コードとかあったらゴミだな。 Lisp MachineではFortranもCもlispで書かれていたのじゃよ、もうlisp専用ハードが無いけど…
今のハードがほぼC用に設計されているというだけ
それでもソフト資産が莫大だからCエミュレータは不滅だろうが lispマシンは滅びたのじゃよ。
javaマシンは産まれもしなかった。
別に今のCPUがCに合わせて設計されてるわけではない。
Cのオプティマイザーが頑張って今のCPUにあわせてるだけ。
lisp で lisp コンパイラと CPU オプティマイザ書けば理論的には同じことができるはずだけど誰もしようとしないだけ。
これ以上はスレチだな。 lispマシンのタグ付き思想はBOMに近いから関係ない事もないと思う
違うのは自動でオブジェクト=型+ワードから値だけ取り出す機構が(普及して)無いところだな
動的言語がこのまま持て囃され続ければ、ハードウェアGCの可能なlispマシン風ハードが出るかもしれん、何十年後になるか知らんが アドレス付け単位としてのバイトが8bitでは効率良く型(あるいはエンコ)情報付けるのは厳しいな
文字単位で付けると少なくとも16bitになってしまう
やっぱり36bit時代の話だね やっぱりヤンキーはASCIIのことしか考えてないのか
Copying non-ASCII characters from Windows to WSLg broken
https://github.com/microsoft/wslg/issues/20 CP932やUTF-8で保存されたテキストファイルをバイナリエディタで見る時、
0x0Dと0x0Aは常にCR・LFに対応するという理解であっていますか
例えば"東"は以下のように保存されますが、0x0Dや0x0Aが含まれる字が存在しない事を確かめたいです。
UTF-8: e6 9d b1
CP932: 93 8c
尚、ファイルは破損しておらず、デコードできない文字は含まれていません >>925
WikipediaのCP932とUTF-8の記事見てみ >>926
ありがとうございます
難しくてわかりませんでした プログラミングのお題スレ Part18
https://mevius.5ch.net/test/read.cgi/tech/1594702426/453
UTF-8 では、先頭ニブル(4ビット)が0なのは、1バイト文字だけだから、
0x0D・0x0A は、1バイト文字だけしかない MSのCP932や、UTF8はASCIIの上位互換。
つまり 0x0A とかは同じ解釈でいける。
UTF16とかUTF32とかは上位互換じゃないので駄目。 >>927
どのあたりが難しかった？ 煽りじゃなくて ありがとうございます
>>928
UTF-8では、0x0Dと0x0Aは常にCR・LFと対応するのですね、助かりました
CP932も同様でしょうか
>>929
アスキー文字(0x00-0x7F)のみが書かれる時、CP932もUTF-8も同じバイト列であることは知っていましたが
0x0Dや0x0Aを含む文字が存在しない事を知らなかったので質問しました
例えば「帰」はCP932だと8b 41で、0x41が含まれていますが「A」を表してはいないわけで
同様の例が0x0D 0x0Aに当てはまるのか知りたかったのです 長すぎたので分割しました
>>930
うわ、どっちも文字がいっぱい……
UTF-8のページ
「エンコード体系」の表が関係しそうだなあ、でもよくわからんなあ。何故2進で書いたし……
今
あ、16進表記の列もあったのか。どれどれ…、あ、0x80以上なのか。じゃあ0D 0Aを含む文字はないんだなあ
CP932のページ
「構造」の表が関係しそうだなあ、でもこれはutf-8のサブセットのことを言っているのかな、それは知っているけどなあ
うーん、でも他に関連しそうな記載は見つけられないなあ
今
あ、CP932って必ず2バイトに収まるのか？そしたら第2バイトの0x00-0x3Fが未使用だから、0x0Dと0x0Aは常にCR・LFと対応すると言って良さそうだなあ CP932に依存するコードを車輪の再発明するのはやめたほうがいい
UTF16を介して処理するのが堅実だよ CP932だと絵文字が入ったファイル名とか扱えないからね
WindowsがUnicodeなんだからそれに従ったほうが良い >>932
わかりませんでしたって書いてたけどだいたい読めてるじゃん
「自信ないけどこう読み解きました」
「それでおｋ」
で済む(・∀・) >>933
今更UTF16はないよ。中途半端なゴミ。
UTF32にするべき。じゃなければUTF8で処理する方かまし。 レス数が900を超えています。1000を超えると表示できなくなるよ。
