645(1): デフォルトの名無しさん [sage] 2022/10/11(火) 20:10:00.97 ID:JrNqb+g1(1) AAS
1文字ずつつけるんじゃなくて新たに囲み用の言語指定マーク作ってもいいんでは？
既にLTR/RTL指定とか「ここからここまでルビ」みたいなマークがあるんだから。

どっちの方法でも実効性が現れるかどうかは「メジャーな環境が(入力ユーザーが気にしていなくても)デフォルトで付けるかどうか」次第だけど、
完全IVS化だと漢字圏のテキストがほぼ倍になる、そんなのをデフォルトにする判断を各社が果たしてするんだろうか？

785(1): デフォルトの名無しさん [sage] 2023/02/24(金) 08:06:25.11 ID:liuYehNm(1/2) AAS
文字コードを自動判別するためにBOMを使うってのがダメだな
BOMと思ったコードが違うエンコーディングの可能性があるんだから
Windows だけで閉じておいてほしいから、通信回線には流さないで

804(1): デフォルトの名無しさん [sage] 2023/02/24(金) 18:22:32.64 ID:BmT/WJ86(8/8) AAS
BOMを信じた時点でもはや自動判別ではないだろ。

927(1): デフォルトの名無しさん [sage] 2023/03/01(水) 07:56:52.79 ID:OaPBPWBe(4/4) AAS
翻訳しときますよ

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を使用していると確実に示すという意味だから使っていいということ）