文字コード総合スレ 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/26(日) 23:13:02.63

>>862
じゃあメモ帳のデフォルトがBOM無しに変更された理由は何？
妄想くんには説明できんだろw

**デフォルトの名無しさん** · 2023/02/26(日) 23:31:02.55

>>863
Windows Subsystem for Linuxのためじゃないかな？
上にもあるとおりunix系のアプリの中にはutf8のBOM未対応のまま（というか今更いじれない？）の状態になっているからな
良くも悪しくも歴史的にメモ帳は機能がしょぼすぎてその他の一般業務向けでの影響力はほとんどない状態だから、
Excelとかに比べれば変更しやすいという後ろ向きな理由もあるだろう

**デフォルトの名無しさん** · 2023/02/26(日) 23:35:43.20

https://blogs.windows.com/windows-insider/2018/12/10/announcing-windows-10-insider-preview-build-18298/
マイクロソフトはそんなこと言ってないけどなあ

**デフォルトの名無しさん** · 2023/02/26(日) 23:40:56.18

ていうかあれか、パイプを使ったテキストのやりとり等とBOMの相性が悪そうだから、コンソール系のアプリでBOM対応は面倒だわな

**デフォルトの名無しさん** · 2023/02/26(日) 23:42:12.69

>>865
いや、webの標準はunix系のコンソールアプリでしょ？

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

リンク貼った人がいるので正解は
Microsoft の主張は「WEBの標準はASCIIと互換性のある BOM 無しの UTF-8 だから、それに合わせるため変更した。これは重要な改善である。後方互換性のためにBOMつきも可能にしといた」

BOMなしは改善、BOMつき後方互換性って明言してる。

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

ASCIIのような化石との互換性は要らない。UTF16以上を推奨し、UTF8はASCII文字出現率が
99.5%以上のファイルに限り許容するのが良い。

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

Windows10では、デバッグ機能で別のエディタを起動してるから
メモ帳を使ったことないというか、どんなだったかも思い出せない

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

MSはデフォルトを変更しただけで
BOMにも対応している
つまり完璧にUnicodeに対応している

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

大正義じゃないか

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

もうUTF－16にはWindowsの内部コード以外の役割はないんだ
文字コード戦争はとっくにUTF-8の勝利で終結したんだネットの普及が決め手だった
残念ながら負け犬がどんだけ吠えても現実は変わらないんだ
ほら、どんどん吠えて、（愉悦

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

恥ずかしい無知野郎だなぁｗ
JavaもJavaScriptも内部コードはUTF-16だってーのに

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

>>873
UTF-16でどうやって絵文字処理してるのか不思議なんだよなあ
サロゲート処理必要なのに 🪟🍎🐧

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

無知二匹目ｗ

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

>>868
>これは重要な改善である。

甘いなあ
文字コードの自動判定を入れた、ということは、今後はUTF-8と認識できない可能性が生じる事を意味する
皮肉な話だが、文字コード自動判定のせいで事実上、BOM必須になる

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

JavaのStringとか、もう開き直っちゃってる感じで「文字とはUTF-16のバイトのことでーす」
って感じじゃん。ただの16ビットの配列と何が違うんだっけあれ
まともな文字列処理をするには別途ライブラリが確実にいる。面倒じゃのう

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

BOMは文字コード自動判定をスキップする顔パスのようなもの。BOMを無くしたいという意向とは裏腹に、今後BOMは益々増える。
それが現実。

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

関所を沢山作ったせいで、ますます関所破りのバッドノウハウが普及する

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

>>874
通りすがりだが、お前は論外
ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、BOMつけるか論争をしている人達割り込むツッコミ方じゃねぇw
他人を煽る前に自身の読解力と理解力を見直して出直してこいw

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

外部コードは自動認識うんぬんより ASCII との互換性が重要なのだ
Linux だの Mac だのの Unix 系は ASCII との互換性が必須なので BOM 無し UTF-8 以外に選択肢がないし
RFC とかネットの標準もそれに引きずられてるし
Windows 外部コードの unicode 化はこれから本番だけど、今まで CP932, CP1252 みたいにASCII互換は大前提で来たので互換維持した方がトータルのコストは低い
結局ASCIIと互換性のないBOM付きのUTF-8だの、UTF-16だのが外部コードとして主流になる世界は来ないのだよ

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

UTF-8を使い始めたのは、
Fedora 1でデフォルトのシステム・ロケールになったときだから、
もう19年か、早いもんだ
RedHatの頃のEUC-JPに戻す誘惑にも負けずに苦労したことを思い出す

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

>>881
> ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、

それはお前だろｗ
JavaやJavaScriptがUTF-16を使っていることなんか
ちょっと昔のことを知ってりゃ誰だってわかることなんだよ
そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから

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

そもそもUnicodeといえばUTF-16のことで、いまでもUTF-16のことをUnicodeと呼ぶことが多い。

Windows、JavaなどはUTF-16を先進的だと思って取り入れたから、UTF-8への対応が難しい。

UTF-8も一長一短があって、容量とマシンスペックの問題がなんとかなってきたから、UTF-8に向かっているが、この面倒くさいキャラクタセットは、1バイト文字がどのキャラクタセットなのかわからないというデメリットがある。

2バイト以上使う文字では、何のメリットもなく、言葉を表現するには明らかに退化している。

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

> Windows、JavaなどはUTF-16を先進的だと思って取り入れたから、UTF-8への対応が難しい。
いや難しくはないぞｗ
Windowsは現にUTF-8に対応している

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

>>885
>１バイト文字がどのキャラクタセットなのかわからないというデメリットがある。
>2バイト以上使う文字では、何のメリットもなく、言葉を表現するには明らかに退化している。

全く意味がわからない。誰か理解できる人いる？

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

理解できるぞｗ

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

配列の添え字での文字編集はUTF32でもだめな場合があるから諦めるべき
可変長なコードとして扱うようにしないどこかで破綻するよ
まぁ、そういう文字列操作のライブラリでこれ使えみたいのはたぶんないから、自前で用意する必要があると思うが

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

>>888
でも、どうせちゃんとした説明できないんでしょ。規格の用語使って技術的に正確に言える？
文字集合(chatacter set)と符号化(encoding)の違い理解してる？

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

ちょっと前まで文字コード総合スレは名ばかりの実質絵文字スレだったのに
今は文字コード総合スレは名ばかりの実質BOMスレになったのか

**デフォルトの名無しさん** · 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って
書いてあるって話をしてるんだがな