UTF-8とBOMなしのUTF-8の違いは何ですか？

UTF-8とBOMなしのUTF-8の違いは何ですか？どちらが良いですか？

UTF-8 BOMは、テキストストリーム（）の先頭にある一連のバイトで0xEF, 0xBB, 0xBF、リーダーがファイルをUTF-8でエンコードされているとより確実に推測できるようにします。

通常、BOMはエンコードのエンディアンを示すために使用されますが、エンディアンはUTF-8とは無関係であるため、BOMは不要です。

よると、Unicode標準、UTF-8のファイルのためのBOMはお勧めしません。

2.6エンコーディングスキーム

... BOMの使用は必須でも推奨でもありませんが、UTF-8データがBOMを使用する他のエンコード形式から変換される場合、またはBOMがUTF-8署名として使用される場合に発生する可能性があります。 。詳細については、セクション16.8、スペシャルの「バイトオーダーマーク」サブセクションを参照してください。

他の優れた答えはすでにそれに答えました：

• UTF-8とBOMされたUTF-8の間に公式の違いはありません
• BOMされたUTF-8文字列は、次の3バイトで始まります。 EF BB BF
• これらのバイトが存在する場合、ファイル/ストリームから文字列を抽出するときに無視する必要があります。

しかし、これに関する追加情報として、UTF-8のBOMは、文字列がUTF-8でエンコードされている場合に「匂い」を与える良い方法になる可能性があります。

たとえば、データ[EF BB BF 41 42 43]は次のいずれかになります。

• 正当なISO-8859-1文字列「ABC」
• 正当なUTF-8文字列「ABC」

したがって、最初のバイトを確認してファイルコンテンツのエンコーディングを認識するのはクールですが、上記の例に示すように、これに依存しないでください。

エンコーディングは、神聖ではなく、知られている必要があります。

UTF-8でエンコードされたファイルにBOMを配置するには、少なくとも3つの問題があります。

1. テキストを保持していないファイルは、常にBOMが含まれているため、空ではなくなりました。
2. UTF-8のASCIIサブセット内にあるテキストを保持するファイルは、BOMがASCIIではないため、それ自体がASCIIではなくなります。これにより、既存のツールの一部が故障し、ユーザーがそのようなレガシーツールを置き換えることが不可能になる場合があります。
3. 各ファイルの先頭にBOMがあるため、複数のファイルを連結することはできません。

そして、他の人が述べたように、何かがUTF-8であることを検出するためにBOMを持つことは十分でも必要でもありません：

• 任意のバイトシーケンスが、BOMを構成する正確なシーケンスで始まる場合があるため、これでは不十分です。
• UTF-8であるかのようにバイトを読み取ることができるため、これは必要ありません。それが成功した場合、それは定義上、有効なUTF-8です。

これは実際に実際の問題を引き起こす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など）を置くと、ファイルには別のマジック番号が付いているように見え、問題が発生する可能性があります。

ウィキペディア、記事：シバン、セクション：マジックナンバーを参照してください：

シバン文字は、拡張ASCIIエンコーディングで同じ2バイトで表されます。UTF-8は、現在のUnixライクなシステムでスクリプトやその他のテキストファイルに一般的に使用されています。ただし、UTF-8ファイルはオプションのバイトオーダーマーク（BOM）で始まる場合があります。「exec」機能がバイト0x23および0x21を明確に検出する場合、シバンの前にBOM（0xEF 0xBB 0xBF）が存在すると、スクリプトインタープリターが実行されなくなります。一部の当局は、POSIX（Unixのような）スクリプトでバイトオーダーマークを使用しないことを推奨しています[14]。この理由と、より広い相互運用性と哲学的な懸念からです。さらに、エンコーディングにエンディアンの問題がないため、UTF-8ではバイトオーダーマークは必要ありません。エンコーディングをUTF-8として識別するためにのみ機能します。【強調追加】

JSONではBOMは不正です

RFC 7159のセクション8.1を参照してください。

実装では、JSONテキストの先頭にバイトオーダーマークを追加しないでください。

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

ご了承ください：

1. UTF-32BEは3つのNULで始まっていないため、認識されません
2. UTF-32LE最初のバイトの後に3つのNULがないため、認識されません
3. UTF-16BEの最初の4バイトにはNULが1つしかないため、認識されません
4. UTF-16LEの最初の4バイトにはNULが1つしかないため、認識されません

実装によっては、これらすべてがUTF-8として誤って解釈され、誤って解釈されるか、無効なUTF-8として拒否されるか、まったく認識されない場合があります。

さらに、私が推奨するように実装が有効なJSONをテストする場合、実際にはUTF-8としてエンコードされている入力でさえ、RFCに従って必要な128文字未満のASCII文字で始まっていないため、拒否されます。

その他のデータ形式

JSONのBOMは不要であり、違法であり、RFCに従って正しく動作するソフトウェアを破壊します。それを使用しないのは当然ですが、BOM、コメント、さまざまな引用ルール、またはさまざまなデータ型を使用してJSONの破壊を主張する人々は常にいます。もちろん、必要に応じてBOMやその他のものを自由に使用できます。その場合は、JSONと呼ばないでください。

JSON以外のデータ形式については、実際の形式を見てください。エンコーディングがUTF- *のみで、最初の文字が128未満のASCII文字である必要がある場合、エンコーディングとデータのエンディアンの両方を決定するために必要なすべての情報がすでにあります。オプション機能としてBOMを追加しても、複雑でエラーが発生しやすくなります。

BOMの他の用途

JSONやスクリプト以外での使用に関しては、ここにはすでに非常に良い答えがあると思います。実際の問題を引き起こすBOM文字の例であるため、スクリプトとシリアライゼーションに関するより詳細な情報を追加したかったのです。

UTF-8とBOMなしのUTF-8の違いは何ですか？

短い答え：UTF-8では、BOMはEF BB BFファイルの先頭のバイトとしてエンコードされます。

長い答え：

当初、UnicodeはUTF-16 / UCS-2でエンコードされると予想されていました。BOMは、このエンコード形式用に設計されました。2バイトのコード単位がある場合、2バイトの順序を示す必要があります。これを行うための一般的な規則は、データの先頭に「バイトオーダーマーク」として文字U + FEFFを含めることです。文字U + FFFEは永続的に割り当てられないため、その存在を使用して誤ったバイト順序を検出できます。

UTF-8はプラットフォームのエンディアンに関係なく同じバイトオーダーを持っているので、バイトオーダーマークは必要ありません。ただし、（バイトシーケンスとしてEF BB FF）UTF-16からUTF-8に変換されたデータ、またはデータがUTF-8であることを示す「シグネチャ」として発生する場合があります。

どちらが良いですか？

なし。Martin Coteが答えたように、Unicode標準はそれを推奨していません。非BOM対応ソフトウェアで問題が発生します。

ファイルがUTF-8であるかどうかを検出するより良い方法は、有効性チェックを実行することです。UTF-8には有効なバイトシーケンスに関する厳密なルールがあるため、誤検知の可能性はごくわずかです。バイトシーケンスがUTF-8のように見える場合、それはおそらくそうです。

BOMを使用したUTF-8がより適切に識別されます。私はこの結論にたどり着きました。結果の1つがCSVであるプロジェクトに取り組んでいます Unicode文字を含むファイルでます。

CSVファイルがBOMなしで保存された場合、ExcelはそれをANSIであると見なし、意味不明な表示をします。「EF BB BF」を前面に追加すると（たとえば、UTF-8を使用したメモ帳またはBOMを使用したUTF-8を使用したNotepad ++を使用して保存し直すと）、Excelで正常に開きます。

BOM文字をUnicodeテキストファイルに付加することは、RFC 3629で推奨されています：「UTF-8、ISO 10646の変換フォーマット」、2003年11月http://tools.ietf.org/html/rfc3629（この最後の情報は次の場所にあります：http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html）

BOMは、どこか、どこかでブームになる傾向があります（しゃれた意図はありません（シック））。そして、ブームになると（たとえば、ブラウザー、エディターなどで認識されなくなる）、ドキュメントの先頭に変な文字（HTMLファイル、JSON応答、RSSなど）として表示されます。そして、ツイッターでのオバマ氏の講演中に経験された最近のエンコーディングの問題のような一種の恥ずかしさを引き起こします。

デバッグが難しい場所に表示されたり、テストが無視されたりすると、非常に煩わしくなります。したがって、使用する必要がない限り、それを回避することをお勧めします。

質問： BOMなしのUTF-8とUTF-8の違いは何ですか？どちらが良いですか？

バイトオーダーマーク（BOM）に関するWikipediaの記事からの抜粋を以下に示します。この質問には確かな答えが得られると思います。

BOMとUTF-8の意味について：

Unicode規格では、BOMをUTF-8で許可していますが、その使用を要求または推奨していません。バイト順はUTF-8では意味がないため、UTF-8での唯一の用途は、テキストストリームがUTF-8でエンコードされていることを最初に通知することです。

BOMを使用しない 場合の引数：

BOMを使用しない主な動機は、Unicodeに対応していないソフトウェアとの下位互換性です... BOMを使用しない別の動機は、「デフォルト」のエンコーディングとしてUTF-8を推奨することです。

引数 FOR BOMを使用しました：

BOMを使用する場合の議論は、BOMがないと、ファイルが使用している文字エンコーディングを判別するためにヒューリスティック分析が必要になるということです。従来、このような分析は、さまざまな8ビットエンコーディングを区別するために複雑で、エラーが発生しやすく、場合によっては遅くなります。タスクを容易にするために、Mozilla Universal Charset DetectorやUnicode用のInternational Componentsなど、多数のライブラリーを利用できます。

プログラマーは、UTF-8の検出も同様に困難であると誤って想定します（バイトシーケンスの大部分が無効なUTF-8であり、これらのライブラリーがすべてのバイトシーケンスを許可することを区別しようとしているためです）。したがって、すべてのUnicode対応プログラムがこのような分析を実行するわけではなく、代わりにBOMに依存します。

特に、Microsoftコンパイラーとインタープリター、およびメモ帳などのMicrosoft Windows上の多くのソフトウェアは、ASCII文字しか含まれていないか、BOMで始まる場合を除いて、UTF-8テキストを正しく読み取らず、保存時にBOMを先頭に追加します。 UTF-8形式のテキスト。Microsoft Word文書がプレーンテキストファイルとしてダウンロードされると、GoogleドキュメントはBOMを追加します。

、より良いされている WITH または WITHOUT BOM：

IETFは、もしプロトコルのいずれか（）は、常にUTF-8を使用し、または（b）使用されているものエンコーディングを示すためにいくつかの他の方法を有し、それは「署名としてU + FEFFの使用を禁止すべきである。」ことをお勧めします

私の結論：

BOM のみを使用は、ソフトウェアアプリケーションとの互換性が不可欠である場合に。

また、参照されているウィキペディアの記事は、多くのMicrosoftアプリケーションがBOMに依存してUTF-8を正しく検出することを示していますが、これはすべての Microsoftアプリケーションに当てはまるわけではないことにも注意してください。たとえば、@ barlopで指摘されているように、UTF-8 ^†でWindowsコマンドプロンプトを使用するtypeと、そのようなコマンドmoreはBOMの存在を予期しません。BOM が存在する場合、他のアプリケーションと同様に問題が発生する可能性があります。

†このchcpコマンドは、コードページ65001を介して（BOM なしで）UTF-8のサポートを提供します。

この質問にはすでに100万と1つの回答があり、それらの多くは非常に優れていますが、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が推奨されないのはなぜですか？

1. 非Unicode対応または準拠性の低いソフトウェアは、latin-1またはANSIであると想定し、文字列からBOMを削除しないため、明らかに問題が発生する可能性があります。
2. 実際には必要ありません（コンテンツが準拠しているかどうかを確認し、準拠するエンコーディングが見つからない場合のフォールバックとして常にUTF-8を使用してください）

いつBOMでエンコードする必要がありますか？

他の方法（文字セットタグまたはファイルシステムメタを介して）でメタデータを記録できず、プログラムがBOMのように使用されている場合は、BOMでエンコードする必要があります。これは、BOMがないものは通常、レガシーコードページを使用していると想定されるWindowsで特に当てはまります。BOMはOfficeなどのプログラムに、このファイルのテキストはUnicodeであることを伝えます。これが使用されているエンコーディングです。

つまり、私が本当に問題を抱えているのはCSVだけです。プログラムに応じて、BOMが必要な場合とそうでない場合があります。たとえば、WindowsでExcel 2007+を使用している場合、データをインポートせずにスムーズに開くには、BOMでエンコードする必要があります。

一部のファイルについては、WindowsであってもBOMがあってはならないことに注意してください。例はSQL*plusまたはVBScriptファイルです。そのようなファイルにBOMが含まれている場合、それらを実行しようとするとエラーが発生します。

BOMを使用したUTF-8は、ファイルに実際に非ASCII文字が含まれている場合にのみ役立ちます。それが含まれていて何もない場合は、ファイルをプレーンASCIIとして解釈していた古いアプリケーションが壊れる可能性があります。これらのアプリケーションは、ASCII以外の文字に遭遇すると間違いなく失敗するので、私の意見では、BOMはファイルが可能な場合にのみ追加すべきであり、もはやプレーンASCIIとして解釈されるべきではありません。

BOMをまったく使用しないほうがよいことを明確にしたいと思います。それなしで古いゴミが壊れた場合は追加してください。そのレガシーアプリケーションを置き換えるのは現実的ではありません。

UTF-8のBOMを期待しないでください。

BOMのWikipediaページの下部に引用：http : //en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

「BOMの使用は必須でも推奨でもありませんが、UTF-8データがBOMを使用する他のエンコード形式から変換される場合、またはBOMがUTF-8署名として使用される場合に発生する可能性があります。」

BOMなしのUTF-8にはBOMがありません。これは、ファイルのコンシューマーがファイルがUTF-8エンコードされているかどうかを知る必要がある（または知っていることから利益が得られる）場合を除いて、BOM付きUTF-8より優れているわけではありません。か否か。

BOMは通常、エンコーディングのエンディアンを決定するのに役立ちます。これは、ほとんどのユースケースでは必要ありません。

また、BOMは、それを知らないか気にしていない消費者にとって不要なノイズ/痛みであり、ユーザーを混乱させる可能性があります。

これを別の視点から見てみます。BOM付きのUTF-8の方が良いと思います、ファイルに関する詳細情報を提供する、ているます。問題が発生した場合にのみ、BOMなしでUTF-8を使用します。

私のページで複数の言語（キリル文字も含む）を長い間使用しています。ファイルをBOMなしで保存し、エディターで編集するためにそれらを再度開くと（cherouvimも指摘）、一部の文字が破損しています。

Windowsの従来のメモ帳では、新しく作成されたファイルをUTF-8エンコーディングで保存しようとすると、BOMでファイルが自動的に保存されることに注意してください。

私は個人的に、サーバー側のスクリプトファイル（.asp、.ini、.aspx）をBOM付きで保存し、.htmlファイルをBOMなしで保存しています。

UTF-8でエンコードされた情報を表示したい場合、問題に直面しないかもしれません。たとえば、HTMLドキュメントをUTF-8として宣言すると、ドキュメントの本文に含まれるすべてがブラウザに表示されます。

しかし、これはテキスト、CSVの場合には当てはまりません、WindowsまたはLinuxのいずれかに、および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ファイルに保存できませんでした。

実用的な違いの1つは、Mac OS X用のシェルスクリプトを作成してプレーンUTF-8として保存すると、応答が得られることです。

#!/bin/bash: No such file or directory

使用するシェルを指定するシバン行に応じて：

#!/bin/bash

UTF-8として保存した場合、BOM（たとえば、BBEdit）はどれも問題ありません。

上記のように、BOMを使用したUTF-8は、BOM非対応（または互換性のある）ソフトウェアで問題を引き起こす可能性があります。クライアントがWYSIWYGプログラムを必要とするため、かつて、MozillaベースのKompoZerでUTF-8 + BOMとしてエンコードされたHTMLファイルを編集しました。

保存すると、必ずレイアウトが破壊されます。これを回避するのに少し時間がかかりました。その後、これらのファイルはFirefoxでうまく機能しましたが、Internet ExplorerでCSSの癖があり、レイアウトが破壊されました。リンクされたCSSファイルを何時間もいじって無駄にした後、Internet ExplorerがBOMfed HTMLファイルを気に入らないことに気付きました。二度と。

また、私はこれをウィキペディアで見つけました：

シバン文字は、UTF-8を含む拡張ASCIIエンコーディングで同じ2バイトで表されます。UTF-8は、現在のUnixライクなシステムでスクリプトやその他のテキストファイルに一般的に使用されています。ただし、UTF-8ファイルはオプションのバイトオーダーマーク（BOM）で始まる場合があります。「exec」機能がバイト0x23 0x21を明確に検出する場合、シバンの前にBOM（0xEF 0xBB 0xBF）が存在すると、スクリプトインタープリターが実行されなくなります。一部の当局は、POSIX（Unixのような）スクリプトでバイトオーダーマークを使用しないことを推奨しています。[15]この理由と、より広い相互運用性と哲学的な懸念から

Unicode Byte Order Mark（BOM）FAQは簡潔な答えを提供します：

Q：BOMの扱い方は？

A：ここに、従うべきいくつかのガイドラインがあります。

1. 特定のプロトコル（.txtファイルに関するMicrosoftの規則など）では、ファイルなどの特定のUnicodeデータストリームでBOMを使用する必要がある場合があります。このようなプロトコルに準拠する必要がある場合は、BOMを使用します。

2. タグ付けされていないテキストの場合、一部のプロトコルではオプションのBOMが許可されます。それらの場合、

   • テキストデータストリームがプレーンテキストであることがわかっているが、エンコードが不明である場合、BOMを署名として使用できます。BOMがない場合、エンコードは何でもかまいません。

   • テキストデータストリームがプレーンなUnicodeテキストであることがわかっている（ただし、どのエンディアンではない）場合は、BOMを署名として使用できます。BOMがない場合、テキストはビッグエンディアンとして解釈されます。

3. 一部のバイト指向プロトコルでは、ファイルの先頭にASCII文字が必要です。これらのプロトコルでUTF-8を使用する場合は、BOMをエンコード形式の署名として使用しないでください。

4. データストリームの正確なタイプがわかっている場合（UnicodeビッグエンディアンやUnicodeリトルエンディアンなど）、BOMは使用しないでください。特に、データストリームがUTF-16BE、UTF-16LE、UTF-32BE、またはUTF-32LEであると宣言されている場合は常に、BOMを使用してはなりません。

http://en.wikipedia.org/wiki/Byte-order_markから：

バイトオーダーマーク（BOM）は、テキストファイルまたはストリームのエンディアン（バイトオーダー）を通知するために使用されるUnicode文字です。そのコードポイントはU + FEFFです。BOMの使用はオプションであり、使用する場合は、テキストストリームの先頭に表示する必要があります。BOM文字は、バイトオーダーインジケーターとしてのその特定の用途を超えて、テキストがエンコードされているいくつかのUnicode表現のどれを示しているかもしれません。

ファイルで常にBOMを使用すると、UTF-8およびBOMをサポートするエディターで常に正しく開くことが保証されます。

BOMがないという私の本当の問題は次のとおりです。次の内容を含むファイルがあるとします。

abc

BOMがない場合、これはほとんどのエディターでANSIとして開きます。したがって、このファイルの別のユーザーがファイルを開き、いくつかのネイティブ文字を追加します。次に例を示します。

abg-αβγ

エラーが発生しました。ファイルはまだANSIであり、「αβγ」は6バイトを占めていませんが、3です。これはUTF-8ではなく、開発チェーンの後半で他の問題を引き起こします。

Visual Studio、Sourcetree、およびBitbucketのプルリクエストに関する私の経験は次のとおりです。

そのため、プルリクエストを確認すると、署名付きのBOMの各ファイルに赤いドット文字が含まれていることがわかります（非常に煩わしい場合があります）。

それにカーソルを合わせると、「ufeff」のような文字が表示されますが、Sourcetreeはこれらのタイプのバイトマークを表示しないため、プルリクエストで終了する可能性が高くなります。 2017は新しいファイルをエンコードするので、Bitbucketはこれを無視するか、別の方法で表示する必要があります。詳細はこちら：

赤いドットマーカーのBitBucket差分ビュー

HTMLファイルでUTF-8を使用し、同じページでセルビア語のキリル文字、セルビア語のラテン語、ドイツ語、ハンガリー語、またはエキゾチックな言語を使用する場合、BOMを使用したUTFの方が優れています。

それが私の意見です（30年間のコンピューティングおよびIT業界）。