文字コード総合スレ 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/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.

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