UTF8（Notepad ++で）として保存されたファイルのc ++プログラムで開いたfstreamの先頭に、この文字が含まれているのはなぜですか？
´╗┐
私はそれが何であるかわかりません、私がASCIIに保存するときそれがそこにないことを知っているだけです。更新：UTF8（BOMなし）に保存すると、そこにはありません。
c ++でファイルのエンコーディングを確認するにはどうすればよいですか（ASCIIまたはUTF8、それ以外はすべて拒否されます;））。まさにこれらのキャラクターですか？
ありがとう！
ファイルを UTF-16 として保存すると、各値は 2 バイトになります。コンピューターが異なれば、使用するバイト順序も異なります。最上位バイトを最初に配置するものもあれば、最下位バイトを最初に配置するものもあります。Unicode は、バイト オーダー マーク (BOM) と呼ばれる特別なコードポイント (U+FEFF) を予約しています。プログラムが UTF-16 でファイルを書き込むとき、この特別なコードポイントをファイルの先頭に置きます。別のプログラムが UTF-16 ファイルを読み取ると、そこに BOM があるはずであることがわかります。実際のバイトを予想される BOM と比較することで、リーダーがライターと同じバイト順序を使用しているかどうか、またはすべてのバイトを交換する必要があるかどうかを判断できます。
UTF-8 ファイルを保存すると、バイト オーダーにあいまいさはありません。ただし、一部のプログラム、特に Windows 用に作成されたプログラムでは、依然として UTF-8 としてエンコードされた BOM が追加されます。BOM コードポイントを UTF-8 としてエンコードすると、0xEF 0xBB 0xBF の 3 バイトが得られます。これらのバイトは、ほとんどの OEM コード ページ (Windows のコンソール ウィンドウの既定値) のボックス描画文字に対応します。
これを行うことを支持する議論は、他のネイティブエンコーディングとは対照的に、ファイルを真の UTF-8 としてマークすることです。たとえば、西側の Windows の多くのテキスト ファイルはコードページ 1252 です。UTF-8 でエンコードされた BOM でファイルにタグを付けると、違いを見分けやすくなります。
これを行うことに対する議論は、多くのプログラムが ASCII または UTF-8 を期待しており、余分な 3 バイトを処理する方法がわからないということです。
UTF-8 を読み取るプログラムを作成する場合、最初にこの 3 バイトを正確にチェックします。それらがそこにある場合は、それらをスキップしてください。
更新:U+FEFF ZERO WIDTH NO BREAKファイルの先頭を除いて文字を 変換できU+2060 WORD JOINERます [Gillam, Richard, Unicode Demystified , Addison-Wesley, 2003, p. 108]。私の個人的なコードはこれを行います。UTF-8 をデコードしているときに、ファイルの先頭に 0xEF 0xBB 0xBF が表示される場合は、本当に UTF-8 を持っていることを嬉しく思います。ファイルがこれらのバイトで始まらない場合は、通常どおりデコードを続行します。ファイルの後でデコード中に U+FEFF に遭遇した場合、U+2060 を発行して続行します。つまり、U+FEFF は BOM としてのみ使用され、非推奨の意味としては使用されません。
2番目のポイントに関しては、すべての有効なASCII文字列も有効なUTF-8文字列であるため、ASCIIを明示的にチェックする必要はありません。UTF-8を使用してファイルを読み取るだけです。ファイルに有効なUTF-8文字列が含まれていない場合、エラーが発生します。
UTF8として保存されたファイルの最初にこの文字がないのはなぜですか[...]それが何であるかわかりません。ASCIIに保存したときにファイルがないことを知っています。
U+FEFF幅がゼロで改行しないスペース文字であるバイト順マーク（BOM）を参照していると思います。ここ（notepad ++ 5.4.3）では、UTF-8として保存されたファイルEF BB BFの先頭に文字があります。それがUTF-8でエンコードされたBOMだと思います。
ファイルのエンコーディングを確認するにはどうすればよいですか
それはいけません。ファイルがどのエンコーディングで書き込まれたかを知る必要があります。UnicdeでエンコードされたファイルはBOMで始まる場合がありますが、そうする必要はないと思います。
これらの文字が実際に何であるかわからない (つまり、16 進ダンプがない) のは推測にすぎませんが、私の当面の推測では、あなたが見ているのは、バイト オーダー マーク (BOM) と (一種の) エンコーディングの結果です。それをUTF-8として。技術的には、それを行うことは許可されていません/想定されていますが、実際にはかなり一般的です。
明確にするために、これは実際にはバイトオーダーマークではないことに注意してください。バイト順マークの基本的な考え方は、UTF-8 には当てはまりません。理論的には、UTF-8 エンコーディングが BOM に適用されることは想定されていませんが、必要に応じて、それを無視して、BOM を構成する値に通常の UTF-8 エンコーディング ルールを適用することができます。
あなたが尋ねるつもりだったと思います、なぜそれはそれらのキャラクターを持っているのですか？これらの文字はおそらくバイト順マークであり、UTF-8のそのリンクによれば、バイトEFBBBFです。
ファイルがどのエンコーディングであるかを知ることに関しては、ファイル自体からそれを導き出すことはできません。事前に知っておく必要があります（またはファイルを提供するユーザーに尋ねてください）。多くのことを読まなくてもエンコーディングをよりよく理解するために、私はJoelSpolskyの絶対最小すべてのソフトウェア開発者がUnicodeと文字セットについて絶対に積極的に知っている必要があることを強くお勧めします（言い訳はありません！）