https://www.unicode.org/versions/Unicode10.0.0/UnicodeStandard-10.0.pdf [unicode.org] > Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature.
元コメントもそうだけど、 UTF-16 (の) Little Endian と UTF-16LE では意味が違ってくる。 UTF-16LE は最初からそう宣言して Little Endian に決め打ちする方式で これこそ BOM は付けないし付けてはいけない。 UTF-16LE の先頭に U+FEFF があったらそれは BYTE ORDER MARK ではなく ZERO WIDTH NO-BREAK SPACE であるとしている。
BOM (スコア:0)
これまでと変わらず、先頭に 0xEF 0xBB 0xBF を付けたものになるのでしょうか。
UTF-8 にはバイトオーダの概念がないのと、Unix系との互換性を壊すので止めて欲しいのですが。
Re:BOM (スコア:4, 参考になる)
そう、これ私も気になった!
Windowsは疑似BOMを付けた独自UTF-8を「UTF-8」と呼び、
本来の(BOMなどない)UTF-8 を「UTF-8N」と呼んでいるので
不具合の元なんですよね。
まがい物を作るだけならまだしも、それに本家の名を名乗らせちゃあ
混乱の元になるだけです。
この記事で言うこところのUTF8がMS独自UTF8だったら最悪、
でなければ良いニュースですが、どっちでしょうね。
# データI/F仕様書に「文字コードはUTF8」と書いてあっても
# Win向けソフトウェア&&書いた人がWindows畑の人だと疑似BOMありが
# 正解だったりするから、本来のUTF8(BOMなし)で正しく実装したら
# 他所とデータがやりとりできなくなるという・・・
Re:BOM (スコア:1)
あーそこデタラメ言わないように。
UTF-8Nの呼び方はWindows用サードパーティソフトで使われているだけ。
MS自身がUTF-8Nの呼び方をしている文献は見たことがない。
メモ帳がBOM付けているのは知っている。
WideCharToMultiByte等のAPIはBOM付けないよ。
Re: (スコア:0)
>本来の(BOMなどない)UTF-8 を「UTF-8N」と呼んでいるので
呼んでねーよハゲ
Re: (スコア:0)
UTF-8にBOMを付けることは、Microsoft独自ではありません。
https://www.unicode.org/versions/Unicode10.0.0/UnicodeStandard-10.0.pdf [unicode.org]
> Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature.
必須でも推奨でもないとは書かれているものの、その下の表に"BOM Allowed"と明記
Re: (スコア:0)
どっちかって言うとWindowsがBOM付ける実装を普及させてしまったので仕方なく追認した感じだとは思う。
まぁ個人的には今となってはどっちが正しいじゃなくBOMの有無は文化の違いだと思ってますが。
お互いの環境に閉じてる分にはその環境に合わせれば良いし、渡す場合は相手方の環境に合わせる。
厄介なのは共有する場合だけど、Windows上でBOM無しを扱えるソフトを用意する方が楽なので
BOM無しにしておくのが無難だと思う。
Re: (スコア:0)
今回の変更は、他所とやりとりをするための変更と信じて待つことにしました。
Re: (スコア:0)
なあにUTF-8MACがあるんだしUTF-8MSが増えてもいいじゃないか
Re: (スコア:0)
> Windowsは疑似BOMを付けた独自UTF-8を「UTF-8」と呼び、
> 本来の(BOMなどない)UTF-8 を「UTF-8N」と呼んでいる
BOMのようなものが入っていてもUTF-8としては許容されるんじゃない?
それよりも、UTF-8で検索していると「UTF-8N」って表記をたまに見るけどWindowsで正式にそう呼んでましたっけ?
ほぼ日本ローカルな表記だと思ってました。
# 個人的にはBOMのようなものが付いていたほうが便利な場合が多いのであまり嫌わないでほしい
Re: (スコア:0)
Microsoftは全く使ってないですね。
出典というかUTF-8Nの名の由来はMark Davisが書いたこの記事 [archive.org]だと思いますが、
Unicode Consortiumの公式資料ではなくIBMの記事を引っ張り出して来て日本で(だけ)やけに広まった経緯は謎。
# 某テキストエディタの保存オプションにあったから?
Re: (スコア:0)
「BOMのようなものが付いていたほうが便利な場合」を思いつかないのですが、
どんなときでしょうか。
US-ASCII を UTF-8 と誤認する可能性があることについては、開いた後保存するときに
UTF-8 (BOM のようなものを付けない) で保存しても実害はないと思われるので、
US-ASCII の自動判別を諦めることでよいのではないかと思います。 それを諦めると、
UTF-8 の判別は比較的容易ではないかと思います。
もっとも、文字コードの自動判別に頼るよりは、あらかじめ文字コードを決めておくのがよいと思うのですが。
MS Excel で Unicode 文字を含む CSV ファイルを読み込ませるためであれば、 UTF-16LE (BOM 付き ) で十分かと。
Re:BOM (スコア:2)
で、BOM付きUTF-8食わせるとCSVのように扱われはするけど、上書き保存すると悲惨なことに。
Re: (スコア:0)
元コメントもそうだけど、
UTF-16 (の) Little Endian と UTF-16LE では意味が違ってくる。
UTF-16LE は最初からそう宣言して Little Endian に決め打ちする方式で
これこそ BOM は付けないし付けてはいけない。
UTF-16LE の先頭に U+FEFF があったらそれは BYTE ORDER MARK ではなく ZERO WIDTH NO-BREAK SPACE であるとしている。
FAQ - UTF-8, UTF-16, UTF-32 & BOM
http://www.unicode.org/faq/utf_bom.html [unicode.org]
Re: (スコア:0)
とりあえずメモ帳の場合、「ANSI」で保存したときはBOMがつかないみたいですね。「UTF-8」だと(従来通り)BOM付き。
Re: (スコア:0)
BOM付きUTF-8が仕様で許容されてるんだから、それはUnix側の問題だよね
どうぞ、Unix系で修正してください
Re: (スコア:0)
BOM 付き UTF-8 が仕様で許容されていても、 BOM 付きと BOM 無しで
異なる扱いをすることが禁止されている訳じゃないよね。
BOM 付きと BOM 無しで挙動が異なるのは Unix 系の仕様だから、
ちゃんと BOM 無しにしてください。
Re: (スコア:0)
BOM付きUTF-8を正しく処理できないのはUnix系のバグです。
Re: (スコア:0)
ASCII互換という最大のメリットをわざわざ潰す方がどうかと思う。
Re: (スコア:0)
文字コード判定の癌でしかない
Re: (スコア:0)
そもそも文字コードの情報なんて可能な限りメタデータとして持たせるべきもので、
判定のために必ず BOM を持たせようなんて発想の方が邪道。