BOMなしのUTF-8とUTF-8の違いは何ですか?どちらが良いですか?
21 に答える
UTF-8 BOMは、テキストストリーム()の先頭にある一連のバイト0xEF, 0xBB, 0xBF
であり、リーダーがファイルをUTF-8でエンコードされているとより確実に推測できるようにします。
通常、BOMはエンコーディングのエンディアンを通知するために使用されますが、エンディアンはUTF-8とは無関係であるため、BOMは不要です。
Unicode標準によると、UTF-8ファイルのBOMは推奨されていません。
2.6エンコーディングスキーム
... BOMの使用はUTF-8に必須でも推奨でもありませんが、UTF-8データがBOMを使用する他のエンコード形式から変換される場合、またはBOMがUTF-8署名として使用される場合に発生する可能性があります。 。詳細については、セクション16.8、スペシャルの「バイトオーダーマーク」サブセクションを参照してください。
他の優れた回答は、すでに次のように答えています。
- UTF-8 と BOM 化された UTF-8 の間に公式の違いはありません
- BOM 化された UTF-8 文字列は、次の 3 バイトで始まります。
EF BB BF
- これらのバイトが存在する場合は、ファイル/ストリームから文字列を抽出するときに無視する必要があります。
ただし、これに対する追加情報として、文字列が UTF-8 でエンコードされている場合、UTF-8 の BOM は「におい」の良い方法である可能性があります...または、他のエンコーディングの正当な文字列である可能性があります...
たとえば、データ [EF BB BF 41 42 43] は次のいずれかになります。
- 正当なISO-8859-1文字列 "ABC"
- 正当なUTF-8文字列「ABC」
したがって、最初のバイトを見てファイル コンテンツのエンコーディングを認識するのはクールなことですが、上記の例に示すように、これに頼るべきではありません。
エンコーディングは知っておくべきであり、推測するべきではありません。
UTF-8 でエンコードされたファイルに BOM を配置する場合、少なくとも 3 つの問題があります。
- テキストを保持しないファイルは、常に BOM が含まれているため、空ではなくなりました。
- UTF-8 の ASCII サブセット内にあるテキストを保持するファイルは、BOM が ASCII ではないため、それ自体が ASCII ではなくなります。これにより、一部の既存のツールが機能しなくなり、ユーザーがそのようなレガシー ツールを置き換えることができなくなる可能性があります。
- 各ファイルの先頭に BOM があるため、複数のファイルを連結することはできません。
そして、他の人が述べたように、何かが UTF-8 であることを検出するために BOM を持つことは十分でも必要でもありません:
- BOM を構成する正確なシーケンスで任意のバイト シーケンスが開始する可能性があるため、これでは十分ではありません。
- UTF-8 であるかのようにバイトを読み取ることができるため、これは必要ありません。それが成功した場合、それは定義上、有効な UTF-8 です。
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 は、プラットフォームのエンディアンに関係なく同じバイト オーダーを持つため、バイト オーダー マークは必要ありません。ただし、UTF-16 から UTF-8 に変換されたデータで (バイト シーケンスとしてEF BB FF
)、またはデータが UTF-8 であることを示す「署名」として発生する場合があります。
どちらが良いですか?
それなし。Martin Cote が答えたように、Unicode 標準はそれを推奨していません。これにより、BOM を認識しないソフトウェアで問題が発生します。
ファイルが UTF-8 かどうかを検出するより良い方法は、有効性チェックを実行することです。UTF-8 には有効なバイト シーケンスに関する厳密な規則があるため、誤検出の可能性はごくわずかです。バイト シーケンスが UTF-8 のように見える場合は、おそらく UTF-8 です。
BOMを使用したUTF-8はより適切に識別されます。私はこの結論に苦労して到達しました。結果の1つがUnicode文字を含むCSVファイルであるプロジェクトに取り組んでいます。
CSVファイルがBOMなしで保存されている場合、ExcelはそれがANSIであると見なし、ぎこちないものを表示します。前面に「EFBBBF」を追加すると(たとえば、メモ帳とUTF-8を使用して再保存するか、メモ帳++とUTF-8とBOMを使用して)、Excelで正常に開きます。
Unicodeテキストファイルの前にBOM文字を付けることは、RFC 3629で推奨されています:「UTF-8、ISO 10646の変換形式」、2003年11月https://www.rfc-editor.org/rfc/rfc3629(この最後の情報が見つかりましたで:http ://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )
BOM は、どこかでブームになる傾向があります (しゃれた意図はありません (原文のまま))。そしてそれが急増すると (たとえば、ブラウザやエディタなどで認識されない場合)、
ドキュメントの先頭に奇妙な文字として表示されます (たとえば、HTML ファイル、JSON応答、RSSなど)。そして、Twitter でのオバマ氏の講演中に経験した最近のエンコーディングの問題のような恥ずかしさを引き起こします。
デバッグが難しい場所に現れたり、テストがおろそかになったりすると、非常に厄介です。したがって、使用する必要がない限り、使用しないことをお勧めします。
質問: UTF-8 と BOM なしの UTF-8 の違いは何ですか? どちらが良いですか?
バイト オーダー マーク (BOM)に関するウィキペディアの記事からの抜粋をいくつか紹介します。
BOM と UTF-8 の意味について:
Unicode 標準では、 UTF-8のBOMを許可していますが、その使用を要求または推奨していません。UTF-8 ではバイト オーダーは意味を持たないため、UTF-8 での唯一の用途は、テキスト ストリームが UTF-8 でエンコードされていることを開始時に通知することです。
BOM を使用しない 場合の引数:
BOM を使用しない主な理由は、Unicode を認識しないソフトウェアとの下位互換性です... BOM を使用しないもう 1 つの理由は、「デフォルト」エンコーディングとして UTF-8 を奨励することです。
BOM を使用するための引数:
BOM を使用する理由は、BOM がないと、ファイルが使用している文字エンコーディングを判断するためにヒューリスティック分析が必要になるからです。歴史的に、さまざまな 8 ビット エンコーディングを区別するためのこのような分析は複雑で、エラーが発生しやすく、時には時間がかかります。Mozilla Universal Charset Detector や International Components for Unicode など、タスクを容易にするための多数のライブラリを利用できます。
プログラマーは、UTF-8 の検出も同様に難しいと誤って想定しています (これは、バイト シーケンスの大部分が無効な UTF-8 であるためではありませんが、これらのライブラリが区別しようとしているエンコーディングでは、考えられるすべてのバイト シーケンスが許可されています)。したがって、すべての Unicode 対応プログラムがそのような分析を実行するわけではなく、代わりに BOM に依存します。
特に、Microsoftのコンパイラとインタープリター、およびメモ帳などの Microsoft Windows 上の多くのソフトウェアは、UTF-8 テキストが ASCII 文字のみであるか、BOM で始まる場合を除き、UTF-8 テキストを正しく読み取らず、保存時に先頭に BOM を追加します。テキストは UTF-8 です。Google ドキュメントは、Microsoft Word ドキュメントがプレーン テキスト ファイルとしてダウンロードされるときに BOM を追加します。
BOM の有無に かかわら ず、どちらが優れているか:
IETFは、プロトコルが (a) 常に UTF-8 を使用するか、(b) 使用されているエンコーディングを示す他の方法がある場合、「署名としての U+FEFF の使用を禁止すべきである」ことを推奨しています。</ p>
私の結論:
BOMは、ソフトウェア アプリケーションとの互換性が絶対に必要な場合にのみ使用してください。
また、参照されているウィキペディアの記事では、多くの Microsoft アプリケーションが BOM に依存して UTF-8 を正しく検出していることを示していますが、これはすべてのMicrosoft アプリケーションに当てはまるわけではありません。たとえば、 @barlopで指摘されているように、UTF-8 †で Windows コマンド プロンプトを使用する場合、type
やなどのコマンドmore
は BOM が存在することを想定していません。BOMが存在する場合、他のアプリケーションと同様に問題になる可能性があります。
BOMなしのUTF-8にはBOMがないため、ファイルのコンシューマーがファイルがUTF-8でエンコードされているかどうかを知る必要がある(または知ることでメリットが得られる)場合を除いて、BOMを使用したUTF-8よりも優れているわけではありません。か否か。
BOMは通常、エンコーディングのエンディアンを判断するのに役立ちます。これは、ほとんどのユースケースでは必要ありません。
また、BOMは、それを知らない、または気にしない消費者にとって不必要なノイズ/苦痛であり、ユーザーの混乱を招く可能性があります。
BOMのウィキペディアページの下部に引用されています:http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2
「UTF-8ではBOMの使用は必須でも推奨でもありませんが、UTF-8データがBOMを使用する他のエンコード形式から変換される場合、またはBOMがUTF-8署名として使用される場合に発生する可能性があります。」
私はこれを別の視点から見ています。ファイルに関するより多くの情報を提供するため、BOM 付きの UTF-8 の方が優れていると思います。問題が発生した場合にのみ、BOM なしで UTF-8 を使用します。
ページで複数の言語 (キリル文字も含む) を長い間使用しており、ファイルを BOM なしで保存し、エディターで編集するためにそれらを再度開くと ( cherouvimも指摘したように)、一部の文字が破損します。
新しく作成されたファイルを UTF-8 エンコーディングで保存しようとすると、 Windows の従来のメモ帳はファイルを BOM とともに自動的に保存することに注意してください。
私は個人的に、BOM 付きのサーバー側スクリプト ファイル (.asp、.ini、.aspx) と BOMなしの.html ファイルを保存しています。
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 ファイルに保存できませんでした。
実質的な違いの 1 つは、Mac OS X 用のシェル スクリプトを作成し、プレーンな UTF-8 として保存すると、次のような応答が得られることです。
#!/bin/bash: No such file or directory
使用するシェルを指定するシバン行に応答して:
#!/bin/bash
UTF-8 として保存すると、BOM はありません (たとえば、BBEditで) すべてがうまくいきます。
前述のように、BOM 付きの UTF-8 は、BOM を認識しない (または互換性のある) ソフトウェアで問題を引き起こす可能性があります。UTF-8 + BOM としてエンコードされた HTML ファイルを Mozilla ベースのKompoZerで編集したことがあります。これは、クライアントがWYSIWYGプログラムを必要としていたためです。
保存すると必ずレイアウトが破壊されます。これを回避するのに少し時間がかかりました。これらのファイルは 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]。この理由と、より広い相互運用性と哲学的懸念からです。
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 にはこれらのタイプのバイトマークが表示されないことが判明したため、プル リクエストに含まれる可能性が高く、これは Visual Studio の方法であるため問題ありません。 2017 は現在、新しいファイルをエンコードしているため、Bitbucket はこれを無視するか、別の方法で表示する必要があります。詳細はこちら:
HTML ファイルで UTF-8 を使用し、同じページでセルビア語のキリル文字、セルビア語のラテン語、ドイツ語、ハンガリー語、またはエキゾチックな言語を使用する場合は、BOM 付きの UTF の方が適しています。
それが私の意見です (コンピューティングおよび IT 業界での 30 年の経験)。