これらは廃止されていますか？これまでで最悪のアイデアのようです。ファイルの内容に、誰にも見えないものを埋め込んでください。ただし、ファイルの機能に影響を与えます。なぜ欲しいのかわかりません。
質問する
7733 次
8 に答える
17
UTF-16にはリトルエンディアンとビッグエンディアンの両方の実装があるため、場合によっては必要になります。
不明なUTF-16ファイルを読み取る場合、2つのうちどちらが使用されているかをどのように判断できますか？唯一の解決策は、ファイルにある種の簡単に識別できるマーカーを配置することです。これは、使用されるエンディアンに関係なく、他のものと間違えられることはありません。
それがBOMが行うことです。
そして、あなたはそれが必要ですか？1）エンディアンが問題となるUTFエンコーディングを使用している場合（UTF-16では重要ですが、UTF8はエンディアンに関係なく常に同じように見えます）、ファイルは外部アプリケーションと共有されます。
自分のアプリだけがファイルの読み取りと書き込みを行う場合は、BOMを省略して、使用するエンディアンを一度だけ決定することができます。ただし、別のアプリケーションがファイルを読み取る必要がある場合は、エンディアンが事前にわからないため、BOMを追加することをお勧めします。
于 2009-06-25T19:13:27.750 に答える
9
ユニコードコンソーシアムのUTFおよびBOMFAQからの抜粋が役立つ場合があります。
Q：BOMとは何ですか？
A：バイトオーダーマーク（BOM）は、データストリームの先頭にある文字コードU + FEFFで構成され、主にマークされていないプレーンテキストファイルのバイトオーダーとエンコード形式を定義する署名として使用できます。一部の高レベルプロトコルでは、そのプロトコルで定義されているUnicodeデータストリームでBOMの使用が必須（または禁止）になっている場合があります。（エンファシスマイン。）
バイトオーダーマークがデータに埋め込まれているとは正確には言えません。むしろ、データのプレフィックスになります。文字は、データストリームの最初のものである場合、バイト順マークにすぎません。他のどこでも、それはゼロ幅のノーブレークスペースです。バイトオーダーマークを尊重しないUnicode対応プログラムは、文字が表示されないため、その存在によって実際に害を受けることはありません。テキストブロックの先頭にある単語結合子は、次の文字を何にも結合しません。したがって、効果はありません。
Q：BOMはどこで役立ちますか？
A： BOMは、テキストとして入力されているが、ビッグエンディアン形式かリトルエンディアン形式かがわからないファイルの先頭で役立ちます。ファイルがUnicodeであることを示すヒントとしても機能します。従来のエンコーディングとは対照的に、さらに、使用される特定のエンコーディング形式の署名として機能します。
したがって、プログラムがUnicodeの複数のエンコーディングを処理できる場合は、BOMが必要になります。プログラムは、入力を解釈するときに使用するエンコーディングを他にどのように知ることができますか？
Q：BOMを使用する場合、16ビットのUnicodeテキストのみですか？
A：いいえ、Unicodeテキストがどのように変換されてもBOMを署名として使用できます：UTF-16、UTF-8、UTF-7など。BOMを構成する正確なバイトは、Unicode文字U+FEFFになります。その変換形式によって変換されます。その形式では、BOMは、それがUnicodeファイルであることと、それがどの形式であるかを示すのに役立ちます。
これはおそらく、BOMが今日最も頻繁に使用されているケースです。UTF-8でエンコードされたテキストを他のエンコードと区別します。UTF-8の順序は1つしかないため、実際にはバイトの順序をマークしていません。
独自のプロトコルまたはデータ形式を設計している場合は、BOMを使用する必要はありません。FAQからの別の質問はそれに触れています：
Q：U + FEFFをBOMとして解釈しないデータにタグを付けるにはどうすればよいですか？
A：タグUTF-16BEを使用してビッグエンディアンのUTF-16テキストを示し、UTF-16LEを使用してリトルエンディアンのUTF-16テキストを示します。BOMを使用する場合は、テキストに単純なUTF-16のタグを付けます。
データの形式にタグを付けるという概念について説明しています。これは、データ自体から帯域外の形式を指定することを意味します。そのような機能が利用できる場合は素晴らしいことですが、特に古いシステムがUnicodeに後付けされている場合は、そうでないことがよくあります。
于 2009-06-25T19:55:16.667 に答える
3
BOMは、ファイルがどのUnicodeのエンコーディングであるかを示します。この区別がないと、Unicodeリーダーはファイルの読み取り方法を知りません。
ただし、UTF-8はBOMを必要としません。
ウィキペディアの記事をチェックしてください。
于 2009-06-25T19:13:07.843 に答える
3
これにUTF-8のタグを付けたので、BOMは必要ないと言います。Byto Order Marksは、ファイルがビッグエンディアンかリトルエンディアンかをコンピューターに通知するため、UTF-16とUTF-32でのみ役立ちます。一部のテキストエディタは、バイト順マークを使用してドキュメントが使用するエンコーディングを決定する場合がありますが、これはUnicode標準の一部ではありません。
于 2009-06-25T19:27:41.013 に答える
3
「BOM」は、Unicodeを使用することは16ビット文字を使用することを意味すると想定されていたUnicodeの初期からの遺物です。1バイトオーダーしかないUTF-8のようなエンコーディングではまったく意味がありません。U + FEFFの選択も、UTF-32には最適ではありません。これは、考えられるすべてのミドルエンディアンのバイト順序を区別できないためです（そのためには、4つの異なるバイトでエンコードされたBOMが必要になります）。
1つを使用する唯一の理由は、バイト順序が異なるプラットフォーム間でUTF-16またはUTF-32データを送信する場合ですが、（1）ほとんどの人はとにかくUTF-8を使用し、（2）MIMEcharsetパラメーターはより優れたメカニズムを提供します。
于 2010-08-14T22:32:37.517 に答える
0
UTF16とUTF32は、ビッグエンディアンとリトルエンディアンの両方の形式で記述できます。どちらかのエンディアンでファイルを処理した結果を分析することで、エンディアンをヒューリスティックに判断することもできますが、面倒な作業をすべて省くために、BOMはすぐに通知します。
ただし、UTF-8はバイトごとにデコードするため、実際にはBOMは必要ありません。
于 2009-06-25T19:14:09.400 に答える
0
テキストファイルを作成するときにこれらを自分で使用するかどうかに関係なく、テキストファイルを読むときに注意することはおそらく価値があります。つまり、ファイルの先頭でBOMを検出してスキップします（理想的にはそれに応じて処理します）。私はそれを持っていて、何が起こっているのかを理解するまで最初にいくつかの問題を引き起こしたいくつかに遭遇しました。
于 2011-11-08T18:24:33.613 に答える
0
UTF16およびUTF32BOMは、コンテンツがビッグエンディアン形式かリトルエンディアン形式かを示し、コンテンツがUnicodeであるため、UTF-8BOMはファイルをutf-8エンコードとして分類します。UTF-8 BOMがない場合、それがANSIファイルなのかUTF-8エンコードされたファイルなのかをどうやって知ることができますか？utf-8は常にバイトストリームであるため、UTF-8 BOMはもちろんエンディアンを通知しませんが、コンテンツがutf-8でエンコードされたUnicodeまたはANSIであるかどうかは通知します。もちろん、有効なutf-8シーケンスをスキャンすることもできますが、私の意見では、ファイルの最初の3バイトをチェックする方が簡単です。
于 2016-03-03T10:53:41.803 に答える