文字コード総合スレ 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/02/27(月) 19:12:40.37

>>884
> そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから
UTF-8は1992年9月にFSS-UTFとして提案されたのが初出
JavaとJavaScriptはどちらも1995年がファーストリリース

**デフォルトの名無しさん** · 2023/02/27(月) 20:54:01.76

>>889
>自前で用意する必要があると思うが
無理ゲーでしょ

**デフォルトの名無しさん** · 2023/02/27(月) 21:08:05.40

単純なUTF-32配列だとEMOJI MODIFIERなどに対処できない。すでにUTF-32でも可変長に対応必須が前提になってる。

**デフォルトの名無しさん** · 2023/02/27(月) 22:08:49.50

>>891
BOMでUTF-8とCP932を区別したい人が暴れてるだけでしょ
BOMにそんな機能ないのに

**デフォルトの名無しさん** · 2023/02/27(月) 22:45:37.52

>>892
その提案が採用された日付を見てみ

**デフォルトの名無しさん** · 2023/02/27(月) 22:46:26.63

>>895
Unicode signatureとしてそのような用途として使ってよいと書いてある

**デフォルトの名無しさん** · 2023/02/27(月) 22:52:06.63

>>890
だから理解してるって言ってるだろｗ
お前が今知ったばかりだからってｗｗｗ

**デフォルトの名無しさん** · 2023/02/27(月) 22:54:22.19

>>895
バイトオーダーの無いUTF-8のBOMにそれ以外に何の意味が

**デフォルトの名無しさん** · 2023/02/27(月) 22:57:56.43

utf8-bomで保存するソフトもutf8-bomを受け付けないソフトもそういう仕様だと謳えばどっちもありだろう。
自分の主義主張と合わないのは許せないという奴が困ったちゃんなだけで。

**デフォルトの名無しさん** · 2023/02/27(月) 22:59:30.26

>>897
規格はちゃんと読もう。
・UTF-8 のBOMは必要でもなければ推奨でもない。
・それにもかかわらず、UTF-16などからの変換やsignature として、BOMに遭遇するかもしれない
の2点だよ。CP932なんて眼中にないし、「使って良い(may use)」ではなく、「遭遇するかも(may encounter)」だよ

**デフォルトの名無しさん** · 2023/02/27(月) 23:03:56.05

>>896
UTF-8がUnicodeに入ったのはUTF-16と同じ1996年だけど
UTF-8がJavaやJavaScriptより前から存在していたことに
変わりはないぞ

**デフォルトの名無しさん** · 2023/02/27(月) 23:08:26.08

規格に入ったことを基準にするならShiftJISは1997年に
生まれたことになるんだけど、それでいいの?

**デフォルトの名無しさん** · 2023/02/27(月) 23:08:41.53

>>901
>・UTF-8 のBOMは必要でもなければ推奨でもない。
禁止されてなくて許可されてるのだから
UTF-8 のBOMは仕様として正しいということだね

やれやれｗ
UTF-16の前身のUCS-2のことも知らないようだ

> UTF-8がJavaやJavaScriptより前から存在していたことに
Unicode団体と関係ないところが考えて
まだ標準化されてないものに対応するわけ無いやろｗ

**デフォルトの名無しさん** · 2023/02/27(月) 23:09:42.74

>>901
英語苦手なやつのために解説しとくと may encounter の may は「許可」ではなく、「可能性」の may だからな。
これを根拠に使って良いとはならないからな。単に過去の経緯や不出来なシステムの可能性に注意喚起してる項目。

**デフォルトの名無しさん** · 2023/02/27(月) 23:10:15.34

>>903
ShiftJISならそうだろうな
それ以前は別の名前だったってだけだが

**デフォルトの名無しさん** · 2023/02/27(月) 23:11:07.15

>>905
使って良いになるだろｗ
可能性があるんだから

**デフォルトの名無しさん** · 2023/02/27(月) 23:12:14.77

https://youneedaken.hate
nablog.com/entry/2022/10/11/104904

MAY
MAY (してもよい) は、選択的な要件を表す場合に使います。
OPTIONAL (選択してもよい) も同じ使い方をします。

**デフォルトの名無しさん** · 2023/02/27(月) 23:17:27.33

>>907
お前は、赤信号横断するやつに遭遇する可能性があるって書いてあったら、赤信号で渡って良いって考える？

**デフォルトの名無しさん** · 2023/02/27(月) 23:23:20.91

マジで英語読めずに単語拾ってる状態やん

**デフォルトの名無しさん** · 2023/02/27(月) 23:35:24.56

>>909
赤信号は横断しちゃダメと決められているけどBOMは禁止されてる？

**デフォルトの名無しさん** · 2023/02/27(月) 23:52:22.36

先に英語の勉強した方がいいんじゃない？
いや日本語の読解力を鍛える方が先か

**デフォルトの名無しさん** · 2023/02/27(月) 23:54:30.47

>>904
> まだ標準化されてないものに対応するわけ無いやろｗ
ShiftJISは1980年代に各ベンダーが勝手に実装していて、
微妙に差異があったから1997年にJISで規格化した

UTF-8も1992年にPlan9で提案実装したものを1996年に
Unicodeで規格化した

どっちも実装が先

**デフォルトの名無しさん** · 2023/02/28(火) 00:05:34.32

そろそろ議論を終わろう。テンプレに
Q. UTF-8 に BOM は必要ですか？
A. 不要です。規格書にそう明記されています。
とか入れとけば良いやろ。ここまでなら確定事実なので。

**デフォルトの名無しさん** · 2023/02/28(火) 00:10:17.26

どの規格書かも明記しておいて。

**デフォルトの名無しさん** · 2023/02/28(火) 03:25:44.83

>>909
> お前は、赤信号横断するやつに遭遇する可能性があるって書いてあったら、赤信号で渡って良いって考える？

何言ってるんだ？「赤信号は渡っていけない」って書いてあるだろ
赤信号のどこにMAYが出てくるんだよ？

**デフォルトの名無しさん** · 2023/02/28(火) 03:26:52.16

>>913
勝手に実装しているものはShiftJISではない
名前が違う

**デフォルトの名無しさん** · 2023/02/28(火) 18:09:24.12

>>916
日本語読めない人かな？
日本語勉強中の外国人かもしれないので丁寧に説明すると、日本語の
「AだったらBですか？」という文はAという仮定のもとでBが成り立つかの論理を問う構文だよ。Aは仮定なんだから真偽とかは誰も問題にしてない。日本人なら小学校低学年の国語で習うよ。
今回のは「Xに遭遇する可能性がある」という命題から「Xしても良い」という結論が導けるかが問われている。Xは任意の変数(BOMでも赤信号横断でも、自己矛盾してなければ何でも可)
あと日本語苦手なら条件反射で書き込む前にさかのぼって話の流れを確認した方がいいね。がんばれ

**デフォルトの名無しさん** · 2023/02/28(火) 21:07:59.09

>>856
なわけない

**デフォルトの名無しさん** · 2023/02/28(火) 22:51:31.47

>>918
つまり、UTF-8にBOMを付けてはならないと規格に明記されているなら付けるべきじゃないってことだろ。

**デフォルトの名無しさん** · 2023/02/28(火) 23:38:31.89

長文君と論破将軍

**デフォルトの名無しさん** · 2023/03/01(水) 00:21:41.81

>>918

お前のいう喩えはおかしい

× 赤信号横断するやつ（UTF-8 BOM）に遭遇する可能性がある
○ 赤信号で横断しても良い（UTF-8 BOMを使っても良い）が非推奨

赤信号で横断しても良いが非推奨なんてどこにも書いてないのだから
UTF-8 BOMのたと終えになってない

頭悪いならレスバ仕掛けてくるなよｗ

**デフォルトの名無しさん** · 2023/03/01(水) 01:31:29.23

>>922
規格には「BOM使って良い」とは書かれないぞ。
規格に書かれてるのは「不要かつ非推奨だがBOMに遭遇するかもしれない」だけだぞ。

**デフォルトの名無しさん** · 2023/03/01(水) 04:49:48.76

https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf

ここの40ページにBOMが許可されてるって書いてある

Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme: UTF-8
Endian Order: N/A
BOM Allowed?: yes

**デフォルトの名無しさん** · 2023/03/01(水) 07:32:03.44

その仕様書の130ページ
UTF-8 encoding scheme に
While there is obviously no need for a byte order signature when using UTF-8,
の項目を読んでみたら？

**デフォルトの名無しさん** · 2023/03/01(水) 07:51:50.58

>>925
許可（BOM Allowed）は書いてありますが、禁止とは書かれてませんね。
非推奨は禁止という意味ではないですね

**デフォルトの名無しさん** · 2023/03/01(水) 07:56:52.79

翻訳しときますよ

While there is obviously no need for a byte order signature when using UTF-8,
there are occasions when processes convert UTF-16 or UTF-32 data containing a byte order mark into UTF-8.

UTF-8を使用する場合、バイトオーダー署名は明らかに不要（訳注禁止ではない）であるが、
プロセスがバイトオーダーマークを含むUTF-16やUTF-32のデータをUTF-8に変換する場合がある。
（訳注つまり UTF-8 に BOM が含まれることがある）

Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard,
but its presence does not affect conformance to the UTF-8 encoding scheme.

UTF-8データストリームの冒頭で使用することは UTF-8データストリームの先頭での使用は、
Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
（訳注ここからも必須でも推奨でもないだけで、適合性に影響を与えないと書いてある）

Identification of the <EF BB BF> byte sequence at the beginning of a data stream can, however,
be taken as a near-certain indication that the data stream is using the UTF-8 encoding scheme.

データストリームの先頭の<EF BB BF>バイト列の識別は、そのデータストリームがUTF-8エンコーディング方式を
使用していることをほぼ確実に示すものと見なすことができる。
（訳注 UTF-8を使用していると確実に示すという意味だから使っていいということ）

**デフォルトの名無しさん** · 2023/03/01(水) 09:10:35.41

結局
禁止とも使えとも明記されてない
書かれているには「不要で非推奨」だな。

**デフォルトの名無しさん** · 2023/03/01(水) 09:12:03.02

Unicodeの仕様としてはBOMは合法
もし禁止してるとしたらそれはそのアプリやサービスの独自仕様

**デフォルトの名無しさん** · 2023/03/01(水) 09:17:42.66

>>929
合法とはまた変な表現を出して来たな。規格の準拠性に影響を与えないと言いたいのならそれは正しい。
でも「不要で非推奨」な。つまり「利用者や通信相手の許可無く使うこうとは

**デフォルトの名無しさん** · 2023/03/01(水) 10:03:24.48

>>923
+1

**デフォルトの名無しさん** · 2023/03/01(水) 10:07:23.21

>>927
>プロセスがバイトオーダーマークを含むUTF-16やUTF-32のデータをUTF-8に変換する場合がある。
>（訳注つまり UTF-8 に BOM が含まれることがある）

訳注を善意的に解釈すると
間抜けな変換ツールによる変換時にそのまま先頭のBOMが残ることはあるかも知れないが
新たなプレーンテキストにはBOMは入れないでくれって読めるな

**デフォルトの名無しさん** · 2023/03/01(水) 10:10:47.18

>>627
>Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
>の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
>（訳注ここからも必須でも推奨でもないだけで、適合性に影響を与えないと書いてある）

漏れは改行コードは LF だけ派なんだけど
君は CR+LF 必須だと思ってる？

**デフォルトの名無しさん** · 2023/03/01(水) 10:11:39.61

安価ミスすまそ

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

読み手がBOM付きデータをどう扱うかは、経営の話であって技術の話ではない。
サービスサポートするファイル形式を減らすことで生じる機会損失の軽重を判断するのは経営の領分であって技術の領分ではないから。

**デフォルトの名無しさん** · 2023/03/01(水) 12:40:14.45

>>935
規格書の話してるのに経営とか言い出すアホ。規格書に「BOMは不要」って書かれてたのがよっぽど悔しいのかね。
規格は法律じゃないんだから、お前は経営判断wで無視してもいいよ。利用者や通信相手が納得してるのなら規格なんて読まなくて良い。オレオレ実装でOK。
ただし技術の話しないんならスレチ、よそでやれ。

**デフォルトの名無しさん** · 2023/03/01(水) 14:20:00.05

>>936
逆だよ。
「BOMをつけるな」は経営の話。
BOMつきにうまく対処することは技術の話。

**デフォルトの名無しさん** · 2023/03/01(水) 15:32:04.65

技術的に対応できるのであれば、
それに対応するのに割くリソースというかコストをどう考えるかが問題になるもんな
BOMなしで統一しているところにBOM付きが紛れ込めば、
必然的にそれに対応しなければならない
その対応分のリソースを他に振り分けることが有用であるから、
「BOMをつけるな」というのはコストの話ではある

**デフォルトの名無しさん** · 2023/03/01(水) 15:47:34.03

切符を買わずに乗ってきた客がいた場合、切符を売ることなく摘まみだすかどうかは鉄道会社や車掌が決めることであって、技術者である機関士の領分じゃないんだよ

**デフォルトの名無しさん** · 2023/03/01(水) 18:23:02.55

鐵ヲタさんいらっしゃい

**デフォルトの名無しさん** · 2023/03/01(水) 18:30:00.14

>>937
技術者「BOMは不要かつ非推奨」

**デフォルトの名無しさん** · 2023/03/01(水) 19:22:22.84

「非推奨のものを他人に勧めるな。隠れてこっそり使う分には誰も困らないので、こっそりやれ、ここに書き込むな」
ここまでの結論。

**デフォルトの名無しさん** · 2023/03/01(水) 20:40:41.27

>>932
解釈する余地はない
許可されてるって書いてあるんだから

https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf

ここの40ページにBOMが許可されてるって書いてある

Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme: UTF-8
Endian Order: N/A
BOM Allowed?: yes

**デフォルトの名無しさん** · 2023/03/01(水) 21:06:32.67

うわー、まだやってんのか？
とっくに結論は出ただろうに、、、

**デフォルトの名無しさん** · 2023/03/01(水) 21:25:20.33

お互いが自分の意見こそ結論だって言いあってるからね

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

結論はBOM Allowed?: yesとでてるのに
それを認めたくないのでしょう

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

もともと BOM をつけろというやつと BOM は不要というやつがいて、規格に BOM は不要で非推奨と書かれていることが判明した。
BOM をつけろと言ってた側が互換性のために BOM を付けても規格準拠というのを理由に土俵際でねばってる。
どうやっても BOM は不要という結論にしかならないのに。

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

つけろ派と不要派じゃなくて
つけてもいい派とつけるな派の争いに見えるんだけど

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

>>948
つけろ派は押されてトーンダウンした。
勝手につける分には一人も反対していない。
人に推奨して良いかどうかが今の境界線

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

すでに原理主義の突き合わせでしかないだろ

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

>>950
技術的に何が正しいか議論してるのに、話を逸して誤魔化そうとしてるやつがいるだけ。技術的には
「規格では不要、ついでに非推奨。非推奨のものを他人に勧めるな。勝手に使う分には好きにしろ」
で合意が取れるはずなんだが。

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

>>947
> 規格に BOM は不要で非推奨と書かれていることが判明した。
ちゃんと基礎知識を身につけろ

BOMはバイトオーダーマークの略で、UTF-16などのために作られた仕様
互換性のためじゃねーよ。Unicodeで必要だからBOMが作られたんだろ

でUTF-8は1バイト単位の可変長だから、BOMはいらないはずだって主張するやつが出てきた
ところがどっこいBOMにははUnicode Signatureの意味があることが判明した
（知っている人にとっては常識）

そしてUTF-8でBOMは仕様違反だとか禁止とか言ってるやつのトーン下がって
「非推奨だから付けたらだめ」みたいな屁理屈を言い始めたが
PDFにBOM Allowed?: yesという文言が見つかって、ゲームオーバーっていうのが
これまでの流れだ

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

>>951
ちゃんと「規格で許可されている」って書こうね
これは事実なんだから
それができないから、嘲笑されてる

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

お前ら何もわかってないな
各サービスに複雑な文字コード自動判定処理が追加されたことで、
UTF-8/16/32であることをオレオレ自己申告して複雑な文字コード自動判定をスキップするBOMの存在価値はかえって高まったのだ

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

>>952
脳内で歪んだか？
過去レス見直しても「規格に禁止と書いてある」と主張してるやつは一人もいないぞ
「規格に不要かつ非推奨って書いてある」と主張してるやつは多数いる

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

>>953
だから勝手につける分にはつけていいだろ。
「許可、不要、非推奨」なのは認めるんだな？復唱してみろ。

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

>>955
だからなんで「規格で許可されている」を消すんだよ？
「規格で許可されているが、必須ではなく推奨もしていないと書いてある」だろうが

Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard,
but its presence does not affect conformance to the UTF-8 encoding scheme.

UTF-8データストリームの冒頭で使用することは UTF-8データストリームの先頭での使用は、
Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。

neither required nor recommended
→ neither 必須 nor 推奨
→ 必須ではなく、推奨でもない

不要は unnecessary だ
訳ぐらい間違えんな

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

>>956
「許可されている。必須ではない。推奨されていない。」と認めるわけだぞ。

BOM Allowed?: yes
neither required nor recommended

書いてあるとおりだ。

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

>>946
付けろとは描いてないだろ
それがすべてだ

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

>>958
それでいいよ。技術的には不要でも必須でもないでも同じ意味だ。
必須でなくて非推奨なものの他人につけろっていったり、対応を要求したりしなければOK。

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

>>948
つけてもいいということはつけなくてもいいということだ
要らないものをつけるためには理由が必要
その理由があまりにもくらだんから全部却下されてるのが今の流れ

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

> 要らないものをつけるためには理由が必要

だから何度もUnicode Signatureって
書いてあるって話をしてるんだがな

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

文字コードが統一されているシステムなら(意味が無いから)BOMは付けない
他の文字コードも扱うシステムなら(識別子として)BOMを付けるか検討する
で良いじゃん

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

https://ascii.jp/elem/000/004/058/4058837/2/
https://ths.ashigeki.net/2008/01/utf-8bom.php

**963** · 2023/03/02(木) 12:05:55.59

書き忘れた
他の文字コードも扱うシステムでも、文字列以外から文字コードが分かるならそちらを使い、BOMは付けない

BOMが欲しくなるのはSJISとUTF-8等が混在するWindowsのファイル
ファイルのメタデータとして文字コードが設定出来れば良いのに

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

windowsなら
hoge.utf8.txt
hoge.sjis.txt
で解決
しらんけど

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

ファイルの拡張属性にでも，TextEncoding を加えておけば良いんでは？

**デフォルトの名無しさん** · 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.