unicode - 確認 - BOMのないUTF-8とUTF-8の違いは何ですか?
文字コード 変換 (14)
BOMのないUTF-8とUTF-8の違いは何ですか？
短い答え：UTF-8では、ファイルの先頭にBOMがバイトEF BB BFとしてエンコードされます。
長い答え：
もともと、 UnicodeはUTF-16 / UCS-2でエンコードされることが予想されていました。 BOMはこのエンコード形式用に設計されています。 2バイトのコード単位がある場合、その2バイトがどの序列であるかを示す必要があります。これを行うための共通の慣習は、データの先頭に文字「U + FEFF」を「バイトオーダーマーク」として含めることです。 文字U + FFFEは、その存在が間違ったバイト順序を検出するために使用できるように、永久に割り当て解除されます。
UTF-8は、プラットフォームのエンディアンに関係なく、バイトオーダーが同じであるため、バイトオーダーマークは必要ありません。 ただし、UTF-16からUTF-8に変換されたデータに（バイトシーケンスEF BB FF ）、またはデータがUTF-8であることを示す「署名」として発生することがあります。
どちらが良いですか？
なし。 Martin Coteが答えたように、Unicode標準はそれを推奨していません。 BOM非対応ソフトウェアで問題が発生します。
ファイルがUTF-8であるかどうかを検出するより良い方法は、有効性チェックを実行することです。 UTF-8には、バイトシーケンスが有効であることに関する厳密なルールがあるため、誤検出の可能性はごくわずかです。 バイトシーケンスがUTF-8のように見える場合は、おそらくそうです。
BOMないUTF-8とUTF-8の違いは何ですか？ どちらが良いですか？
質問： BOMのないUTF-8とUTF-8の違いは何ですか？ どちらが良いですか？
ここでは、Wikipediaのバイトオーダーマーク（BOM）に関する記事の一部を抜粋しています 。
BOMとUTF-8の意味について：
Unicode標準では、 BOMはUTF-8で許可されていますが、その使用は必須ではありません。 バイトオーダーはUTF-8では意味がありません。したがって、UTF-8での使用は、テキストストリームがUTF-8でエンコードされていることを最初に通知することです。
BOMを使用 し ない 場合の 引数 ：
BOMを使用しない主な動機は、Unicode対応ではないソフトウェアとの下位互換性です.BOMを使用しないもう一つの動機は、UTF-8を「デフォルト」エンコードとして推奨することです。
BOMを使用するための 引数 ：
BOMを使用するための引数は、ファイルが使用している文字エンコーディングを判別するためのヒューリスティックな分析が必要であることです。 歴史的に、様々な8ビットエンコーディングを区別するためのこのような分析は、複雑でエラーが起こりやすく、時には遅くなることがあります。 Mozilla Universal Charset DetectorやUnicodeの国際化コンポーネントなど、いくつかのライブラリがこのタスクを容易にするために利用できます。
プログラマは、誤ってUTF-8の検出が困難であると想定しています（バイトシーケンスの大部分が無効なUTF-8であるのに対し、これらのライブラリが区別しようとしているエンコードがすべてのバイトシーケンスを許可しているためではありません）。 したがって、すべてのUnicode対応プログラムがこのような分析を実行せず、BOMに依存するわけではありません。
特に、 Microsoftのコンパイラとインタプリタ、およびメモ帳などのMicrosoft Windows上のソフトウェアの多くは、ASCII文字のみまたはBOMで始まる場合を除いて、UTF-8テキストを正しく読み込むことはできず、保存時にBOMを最初に追加しますUTF-8としてのテキスト Microsoft Word文書をプレーンテキストファイルとしてダウンロードすると、GoogleドキュメントはBOMを追加します。
BOMの 有無にかかわらず 、より良い方法 ：
IETFは、（a）プロトコルが常にUTF-8を使用する場合、または（b）どのエンコーディングが使用されているかを示す他の方法がある場合は、「U + FEFFをシグネチャとして使用することを禁止する」ことを推奨します。
私の結論：
BOMは、ソフトウェアアプリケーションとの互換性が不可欠な場合にのみ使用してください。
参照されているWikipediaの記事では、多くのMicrosoftアプリケーションがBOMを使用してUTF-8を正しく検出していることが示されていますが、これはすべての Microsoftアプリケーションでは当てはまりません。 たとえば、 @barlopによって指摘されている@barlop 、UTF-8でWindowsコマンドプロンプトを使用すると、そのようなtypeコマンドなどは、BOMが存在するとは限りません。 BOM が存在する場合は、他のアプリケーションの場合と同様に問題があります。
BOMのないUTF-8にはBOMがありません。これは、ファイルの消費者がファイルがUTF-8でエンコードされているかどうかを知る必要がある（または知っている）必要がある場合を除いて、BOMのUTF-か否か。
通常、BOMはエンコードのエンディアンを決定するのに便利です。エンコードのエンディアンは、ほとんどのユースケースでは必須ではありません。
また、BOMは、それを知らないか気にかけていない消費者にとっては不必要なノイズ/痛みとなり、ユーザの混乱を招く可能性があります。
BOM付きのUTF-8がよりよく識別されます。 私はこの結論に苦労しました。 私は、結果の1つがUnicode文字を含むCSVファイルであるプロジェクトに取り組んでいます。
CSVファイルがBOMなしで保存されている場合、ExcelはそれをANSIとみなし、不器用さを示します。 正面に「EF BB BF」を追加すると（たとえば、メモ帳をUTF-8で、メモ帳++をUTF-8でBOMで再保存して）、Excelが正常に開きます。
BOM文字をUnicodeテキストファイルに追加することは、RFC 3629：2003年11月のhttp://tools.ietf.org/html/rfc3629で「ISO 10646の変換フォーマットであるUTF-8」によって推奨されています（この最後の情報は、 http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html ）
BOM付きのUTF-8は、ファイルにASCII以外の文字が実際に含まれている場合にのみ役立ちます。 それが含まれていて、何もない場合は、ファイルをプレーンなASCIIとして解釈する古いアプリケーションを中断する可能性があります。 これらのアプリケーションは、非ASCII文字に遭遇したときには必ず失敗するので、私の意見では、BOMはファイルが平易なASCIIとして解釈されなくてはならないときにのみ追加されるべきだと考えています。
編集：ちょうど私がBOMを全く持っていない方が好きであることを明確にしたいのですが、古くなったゴミがそれで壊れてしまった場合に追加して、そのレガシーアプリケーションを置き換えることは実行可能ではありません。
UTF8のBOMを期待しないでください。
UTF-8でエンコードされた情報を表示する場合は、問題に直面することはありません。 たとえば、HTML文書をUTF-8として宣言すれば、文書の本文に含まれるすべてがブラウザに表示されます。
しかし、WindowsやLinux上にテキスト、 CSV 、XMLファイルがある場合はそうではありません。
たとえば、WindowsやLinuxのテキストファイル（想定される最も簡単なものの1つ）は、（通常は）UTF-8ではありません。
XMLとして保存し、UTF-8として宣言します。
<?xml version="1.0" encoding="UTF-8"?>
UTF-8として宣言されていても、正しく表示されません（読み取られません）。
フランス語の文字を含む一連のデータがありました。これはシンジケーションのためにXMLとして保存する必要がありました。 最初からUTF-8ファイルを作成せずに（IDE内のオプションの変更と「新規ファイルの作成」）、ファイルの先頭にBOMを追加することなく
$file="\xEF\xBB\xBF".$string;
フランス語の文字をXMLファイルに保存できませんでした。
この質問にはすでに百万円の回答があり、その多くは非常に良いものですが、BOMをいつ使用すべきか、使用すべきではないかを明確にしたいと考えました。
前述したように、文字列がUTF-8であるかどうかを判断する際のUTF BOM（バイトオーダーマーク）の使用は、推測された推測です。 利用可能な適切なメタデータがある場合（ charset="utf-8" ）、あなたはあなたが使用するはずのものをすでに知っていますが、そうでなければ、いくつかの前提をテストして判断する必要があります。 これは、文字列が来るファイルが16進バイトコード、EF BB BFで始まるかどうかをチェックすることを含む。
UTF-8 BOMに対応するバイトコードが見つかると、その確率はUTF-8であると想定できるほど高くなり、そこから行くことができます。 しかし、この推測を強制的に行うと、何かが文字化けしてしまった場合でも、読み込み中の追加のエラーチェックが良い考えになります。 入力が UTF-8であるべきでない場合は、BOMはUTF-8（すなわちlatin-1またはANSI）でないと仮定してください 。 ただし、BOMがない場合は、エンコーディングに対して検証することで、UTF-8であるはずかどうかを判断できます。
BOMが推奨されないのはなぜですか？
- Unicode対応でないか、準拠していないソフトウェアは、それがlatin-1またはANSIであると想定している可能性があり、BOMを文字列から取り除くことはできません。
- それは本当に必要ではありません（コンテンツが準拠しているかどうかをチェックし、準拠しているエンコーディングが見つからない場合は常に代替としてUTF-8を使用します）
いつBOMでエンコードする必要がありますか？
他の方法（文字セットタグやファイルシステムのメタを使用）でメタデータを記録できない場合や、BOMのように使用されているプログラムをBOMでエンコードする必要があります。 これは、BOMのないものが一般的にレガシーコードページを使用していると想定されているWindowsの場合に特に当てはまります。 BOMはOfficeのようなプログラムに、このファイルのテキストがUnicodeであることを伝えます。 ここで使用されるエンコーディングがあります。
それが下に来るとき、私が本当に問題を抱えている唯一のファイルはCSVです。 プログラムに応じて、BOMを持っている必要があります。 たとえば、Windows上でExcel 2007+を使用している場合、スムーズに開き、データをインポートする必要がない場合は、BOMでエンコードする必要があります。
それは多くの良い答えがある古い質問ですが、1つ追加する必要があります。
すべての答えは非常に一般的です。 私が追加したいのは実際には本当の問題を引き起こすBOMの使用例ですが、まだ多くの人がそれについて知りません。
BOMがスクリプトを壊す
シェルスクリプト、Perlスクリプト、Pythonスクリプト、Rubyスクリプト、Node.jsスクリプト、またはインタプリタで実行する必要があるその他の実行可能ファイルはすべて、 シバン線で始まります。
#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node
そのようなスクリプトを呼び出すときにどのインタプリタを実行する必要があるかをシステムに通知します。 スクリプトがUTF-8でエンコードされている場合は、最初にBOMを含めることができます。 しかし、実際には "＃！" 文字は単なる文字ではありません。 実際には2つのASCII文字で構成されているマジックナンバーです。 これらの文字の前に（BOMのような）何かを置くと、そのファイルは異なるマジックナンバーを持つように見え、問題が発生する可能性があります。
Wikipedia、 記事：Shebang、セクション：Magic番号 ：
シバン文字は、現在のUnixライクなシステム上のスクリプトやその他のテキストファイルでよく使われるUTF-8を含む、拡張ASCIIエンコーディングで同じ2バイトで表されます。 ただし、UTF-8ファイルはオプションのバイトオーダーマーク（BOM）で始まることがあります。 "exec"関数がバイト0x23と0x21を特に検出した場合、 シバンの前にBOM（0xEF 0xBB 0xBF）が存在すると、スクリプトインタープリタは実行されません。 いくつかの当局は、POSIX（Unixのような）スクリプトでバイトオーダーマークを使用しないことを推奨しています[14]。この理由から、相互運用性と哲学的関心が広がります。 さらに、エンコーディングにエンディアンの問題がないため、バイトオーダーマークはUTF-8では必要ありません。 エンコーディングをUTF-8として識別するためだけに使用されます。 [強調された]
BOMはJSONで違法です
RFC 7159、セクション8.1を参照してください：
実装ではJSONテキストの先頭にバイトオーダーマークを追加してはいけません（MUST NOT）。
BOMはJSONで重複しています
JSONでは違法であるだけでなく、JSONストリームで使用される文字エンコーディングとエンディアンの両方を明確に判断する信頼性の高い方法があるため、文字エンコーディングを決定する必要もありません （詳細はこの回答を参照してください）。
BOMがJSONパーサーを分割する
JSONでは不正であり、不要であるだけでなく 、実際には 、 RFC 4627に示されているメソッドを使用してエンコーディングを決定するすべてのソフトウェアが破られます 。
JSONのエンコーディングとエンディアンを決定し、NULバイトの最初の4バイトを調べます。
00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8
さて、ファイルがBOMで始まる場合、次のようになります：
00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8
ご了承ください：
- UTF-32BEは3つのNULで始まらないため、認識されません
- UTF-32LE最初のバイトの後に3つのNULがないため、認識されません
- UTF-16BEは最初の4バイトにNULを1つしか持たないため、認識されません
- UTF-16LEは最初の4バイトにNULが1つしかないため、認識されません
実装によっては、それらのすべてがUTF-8として誤って解釈され、無効なUTF-8として誤って解釈または拒否されるか、まったく認識されないことがあります。
さらに、私が推奨する有効なJSONの実装がテストされている場合、それはRFCにしたがって、ASCII文字<128で始まらないため、実際にUTF-8としてエンコードされた入力さえも拒否します。
その他のデータ形式
JSONのBOMは不要であり、違法であり、RFCに従って正しく動作するソフトウェアを破壊します。 それを使用していないだけでなく、BOM、コメント、異なる引用規則、または異なるデータ型を使用してJSONを破棄しようとする人が常にいます。 もちろん、誰でもBOMやその他のものを自由に使用することができます。必要な場合はJSONと呼んではいけません。
JSON以外のデータフォーマットについては、実際の見た目を見てください。 唯一のエンコーディングがUTF- *で、最初の文字が128より小さいASCII文字でなければならない場合は、データのエンコーディングとエンディアンの両方を判断するために必要なすべての情報がすでに用意されています。 オプション機能としてBOMを追加すると、より複雑でエラーが発生しやすくなります。
BOMのその他の用途
JSONやスクリプト以外の用途については、既に非常に良い答えがあると思います。 実際の問題を引き起こすBOM文字の例であるため、スクリプティングとシリアライゼーションについての詳細な情報を追加したかったのです。
一部のファイルでは、Windows上でもBOMを持ってはいけないことに注意してください。 例はSQL*plusまたはVBScriptファイルです。 このようなファイルにBOMが含まれている場合、それらを実行しようとするとエラーが発生します。
私はこれを別の観点から見る。 私は 、ファイルについてのより多くの情報を提供するので、BOM付きのUTF-8が優れていると思います。 私が問題に直面する場合に限り、BOMなしでUTF-8を使用します。
長い間、私のページで複数の言語（ Cyrillic ）を使用しています。ファイルがBOMなしで保存され、エディタ（ cherouvimも記載されているように）で編集用に再度開いたときに、一部の文字が壊れています。
UTF-8エンコーディングで新しく作成したファイルを保存しようとすると、Windowsの古典的なNotepad自動的にBOM付きのファイルが保存されることに注意してください。
私は個人的にサーバ側スクリプトファイル（.asp、.ini、.aspx）をBOMの ないBOMファイルと.htmlファイルで保存します 。
http://en.wikipedia.org/wiki/Byte-order_markから：
バイトオーダーマーク（BOM）は、テキストファイルまたはストリームのエンディアン（バイトオーダー）を通知するために使用されるUnicode文字です。コードポイントはU + FEFFです。BOMの使用はオプションで、使用する場合は、テキストストリームの先頭に表示する必要があります。バイトオーダーインジケータとしての特定の使用以外にも、BOM文字は、テキストがエンコードされているいくつかのUnicode表現のどれかを示すことがあります。
ファイル内のBOMを常に使用すると、UTF-8およびBOMをサポートするエディタで常に正しく開くようになります。
BOMが存在しないという私の本当の問題は次のとおりです。次のものを含むファイルがあるとします。
abc
BOMがなければ、これはほとんどのエディタでANSIとして開きます。このファイルの別のユーザーがそれを開き、いくつかのネイティブ文字を追加します（例：
abg-αβγ
Oops ...ファイルはまだANSIのままで、 "αβγ"は6バイトを占めていませんが、3であると推測します。これはUTF-8ではないため、後で開発チェーンで他の問題が発生します。
あなたがセルビア語キリル文字、セルビア語ラテン語、ドイツ語、ハンガリー語または何か異国的な言語を同じページで使用する場合、UTF-8をHTMLファイルで使用するとBOM付きUTFが優れています。それは私の意見です（コンピューティングとIT業界の30年）。
前述のように、BOM付きUTF-8は、非BOM対応（または互換）ソフトウェアで問題を引き起こす可能性があります。かつてMozillaベースのKompoZerでUTF-8 + BOMとしてエンコードされたHTMLファイルを編集しましたWYSIWYGプログラムが必要でした。
常にレイアウトは保存時に破壊されます。これを回避するために私の時間がかかりました。これらのファイルはFirefoxでうまくいきましたが、Internet ExplorerでCSSを使ってレイアウトを破棄していました。リンクされたCSSファイルを何時間も使っていなくても、Internet ExplorerはBOMfed HTMLファイルが気に入らないことが分かりました。もう一度。
また、私はWikipediaでこれを見つけました：
シバン文字は、現在のUnixライクなシステム上のスクリプトやその他のテキストファイルでよく使われるUTF-8を含む、拡張ASCIIエンコーディングで同じ2バイトで表されます。ただし、UTF-8ファイルはオプションのバイトオーダーマーク（BOM）で始まることがあります。"exec"関数がバイト0x23 0x21を特に検出した場合、シバンの前にBOM（0xEF 0xBB 0xBF）が存在するとスクリプトインタープリタが実行されなくなります。いくつかの当局はPOSIX（Unixのような）スクリプトでバイトオーダーマークを使用することを推奨しています[15]。この理由から、より広い相互運用性と哲学的懸念があります
