文字コード総合スレ part13

**デフォルトの名無しさん** · 2020/07/03(金) 20:53:47.08

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
　（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
　（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
文字コード総合スレ Part12 https://mevius.5ch.net/test/read.cgi/tech/1544931495/

**デフォルトの名無しさん** · 2023/03/02(木) 13:08:38.21

いや、そこまでしてBOMを避ける理由がわからん
BOMでなければなんでもいいのかよw

**デフォルトの名無しさん** · 2023/03/02(木) 13:36:36.77

>>968
好きな理由1つ選んで
・UTF-8の最大の特徴はASCIIと上位互換、BOMをつけたら台無しになる
・今はUTF-8 はBOM無しが主流
・将来の外部コードはUTF-8のBOM無しになることがほぼ確定している
・移行期だけのために余計なものをつけたくない
・BOMつきだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるので削除したい
・SJISとか時代遅れのものはもう使用してない
・BOMの曖昧さはセキュリティホールになる可能性がある
・ZWNBS との曖昧さがいやらしい
・規格で非推奨のものは避けたい
・ファイルの接続とか分割やファイル名操作などに曖昧さがあるのはいや
・不要なものを付ける理由が思いつかない
・とにかく嫌い
他にも理由はあるだろうけど、人それぞれ

**デフォルトの名無しさん** · 2023/03/02(木) 13:36:59.98

BOMを付けておくと都合がいいケースがたまたまあっただけ

**デフォルトの名無しさん** · 2023/03/02(木) 15:35:38.23

・移行期だからこそBOMで他のエンコーディングと区別できるようにしておきたい場合がある
・BOMなしだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい
・SJISはJIS X 0208で標準化されている現役の規格
・今のUnicodeの規格ではZWNBSP(U+FEFF)ではなくWORD JOINER(U+2060)の使用が強く推奨されているのでBOMとの曖昧性は起きない
・規格で許可されてるものを無理に避ける必要はない
・許可されているものを避ける理由が思いつかない

**デフォルトの名無しさん** · 2023/03/02(木) 15:58:33.33

すべてはカネ次第。カネを出す人が決めればいいだけ。つまり経営マターってこと。

**デフォルトの名無しさん** · 2023/03/02(木) 16:21:08.46

> ・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい

BOM付けてリスク変わる？

**デフォルトの名無しさん** · 2023/03/02(木) 17:03:17.28

そりゃ変わるだろ、BOMが付いてれば判定ミスがなくなる

**デフォルトの名無しさん** · 2023/03/02(木) 17:19:23.19

BOM見てUTF-8だってのは自動判定の一要素でしかないしBOMなし対応いらなくなるわけじゃないから変わらないと思うんだけどな
ユーザー視点の話なら一つ前のと同じこと言ってるわけだし

**デフォルトの名無しさん** · 2023/03/02(木) 17:51:26.36

>>975
ゴールポストを動かすように自動判定の定義を動かすのはみっともないからやめとけ

**デフォルトの名無しさん** · 2023/03/02(木) 18:28:28.35

>>975
BOMは99.999%正しく判定できる自動判定だよ
実質完全に判定できるといっても過言じゃない。

**デフォルトの名無しさん** · 2023/03/02(木) 18:43:46.01

>>977
自動判定のセキュリティ・リスクはそういうところじゃないよ。認識率100％でも起こる、むしろそっちが攻撃に使い易い。セキュリティまわりは勉強したことない素人が思いつくほど単純じゃない。

**デフォルトの名無しさん** · 2023/03/02(木) 19:12:41.37

>>978
BOMによる自動判定だけなら先頭の数バイトの固定パターンを見るだけの単純なものだから
バグの入り込む余地はかなり小さくなるだろ

**デフォルトの名無しさん** · 2023/03/02(木) 19:16:14.91

>>978
つまり世の中のテキストエディタからEUC-JP対応を削除しろって話をしてるの？

**デフォルトの名無しさん** · 2023/03/02(木) 19:30:13.68

仕様で文字コードが固定されていようがBOMで判断しようが
不正データを読んで変なことにならないようにすることと全く関係ないだろ
もしかして「文字コードの自動判定」という機能単体の話でBOMチェックだけならば堅牢だって趣旨だったのか

**デフォルトの名無しさん** · 2023/03/02(木) 20:53:06.62

「文字コードの自動判定にはセキュリティリスクがある」
↓
BOMによる判定も自動判定だ
↓
だからBOMにセキュリティリスクがある

なにこの三段論法w

**デフォルトの名無しさん** · 2023/03/02(木) 21:03:19.85

そんなこと言ってんのお前だけやで

**デフォルトの名無しさん** · 2023/03/02(木) 21:44:42.19

BOMがあればデータチェックをスキップしていいと考えるやつがいることを想定するなら確かに心理的セキュリティリスクが存在することにはなる
でもそんな話はしていないんだよなあ
俺の起点は>>971に対するものでこれは>>969を受けてのものだから最初からBOMによる自動判定の話だし

**蟻人間** ◆T6xkBnTXz7B0 · 2023/03/02(木) 21:56:36.58

https://github.com/reactos/reactos/blob/6d57c6c91cdf2854b73b9696cd45f41322449368/base/applications/notepad/text.c#L40
ちなみにReactOSのメモ帳の文字セット判定はこうなっている。

**デフォルトの名無しさん** · 2023/03/03(金) 00:03:50.07

>>984
すげー単純な例だとバイナリファイルの先頭に UTF-8 BOM つけてテキストに偽装、ファイアウォールやウィルスチェックをすり抜ける。うかつなソフトが自動判別してBOMを外して次段に渡してマルウェア発動。
アホみたいだがこんなんで実際に被害が出てるんだぜ。実際はこんな単純じゃなくてもっと複雑で発見され難い攻撃ができる。

**デフォルトの名無しさん** · 2023/03/03(金) 01:54:41.66

>>971
ZWNBS についてだが uniccode standard には
「BOMが不要な場合には先頭の U+FEFF は後方互換性のために ZWNBS と解釈される」という規定がある。
これと「UTF-8 に BOM は不要」という規定を合わせると...入力処理系の実装はどうなる？曖昧さがあるだろ。

**デフォルトの名無しさん** · 2023/03/03(金) 02:53:30.47

>>986
BOMをなくすとバイナリとして扱うのか？
それともテキストして扱うのか？

**デフォルトの名無しさん** · 2023/03/03(金) 02:55:06.26

>>987
まずお前の言う「入力処理系」が何なのか説明しろ
「あれが困る」みたいな曖昧な言い方をするな

**デフォルトの名無しさん** · 2023/03/03(金) 05:11:52.34

バイナリとして扱ったとしてもデータとして使うのか?
それとも実行可能ファイルとして使うのか?
後者はもう BOMの使い方を大きく離脱しているな

**デフォルトの名無しさん** · 2023/03/03(金) 09:15:08.54

I hate Windows.

**デフォルトの名無しさん** · 2023/03/03(金) 09:18:38.82

https://answers.microsoft.com/en-us/windows/forum/all/i-hate-windows-11-so-incredibly-much-i-wish-i/877bb2ef-1784-4c8d-a341-53733ef4c1ea

**デフォルトの名無しさん** · 2023/03/03(金) 09:24:55.04

>>980
ついでにSJIS対応もISO2022JP対応も削除で

**デフォルトの名無しさん** · 2023/03/03(金) 09:26:04.28

>>982 が稀に観る白雉

**デフォルトの名無しさん** · 2023/03/03(金) 11:30:01.20

誰だシェルスクリプトをBOM付きで編集したのは!

**デフォルトの名無しさん** · 2023/03/03(金) 11:33:14.61

お前だろ

ってかBOMは許可されてるのに
そういう例外を持ってきてわーわー騒ごうとするのは頭が悪い

**デフォルトの名無しさん** · 2023/03/03(金) 12:02:55.61

シェルスクリプトが万が一BOM付きshebangを解釈するようになったとしても
catはどう処理されるんだろ
面倒だから止めてるんだろうな

**デフォルトの名無しさん** · 2023/03/03(金) 12:46:30.84

昔のmsysのcat.exeは0x0Aを勝手に0x0D0x0Aに変換して出力する仕様だったので、人知れず泣いた人多かったんじゃないかと思う

>>997
BOMをスキップするオプションとか追加すれば対処できるんじゃまいか

**デフォルトの名無しさん** · 2023/03/03(金) 12:50:33.85

binaryオプション付けなければwin上で0d0aにされても文句言えない罠
しかしデフォでbom無であるべきで
デフォがbom付になるのは許すまじ

**デフォルトの名無しさん** · 2023/03/03(金) 12:50:48.52

EOF

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 972日 15時間 57分 1秒