ファイルに問題はありません。「ANSIasUTF-8」は、BOMがないことを意味しますが、Notepad ++は、バイトパターンを分析することにより、エンコーディングをUTF-8として確実に識別しました。ロシア語、ギリシャ語、ポーランド語のテキストを含むファイルを作成し、BOMなしでUTF-8として保存することでこれをテストしました。ここにあります:
# Russian
Следующая
# Greek
Επόμενη
# Polish
Więcej
これを別のエディター(EditPad Pro)で行い、16進モードを使用してBOMが存在しないことを確認しました。NPPで開くと、エンコーディングが「ANSI as UTF-8」と表示され、すべての文字が正しく表示されました。次に、まだ16進モードで、最初のロシア文字の最初のバイトを削除しました。もう一度NPPで開くと、エンコーディングが「ANSI」と表示され、テキストの非ASCII部分が文字化けとして表示されました。
; Russian
¡Ð»ÐµÐ´ÑƒÑŽÑ‰Ð°Ñ
; Greek
Επόμενη
; Polish
Więcej
EditPadに戻り、今回はBOMを追加しましたが、キリル文字は修復しませんでした。今回、NPPはエンコーディングを「UTF-8」として報告し、以下に示すように、最初のロシア文字を除いてすべてが正しく表示されました。「A1」は、UTF-8でその文字の2番目のバイトであるはずの16進表現です。エラーを示すために、反転した配色で表示されました。
# Russian
A1ледующая
# Greek
Επόμενη
# Polish
Więcej
7F
要約すると、BOMがない場合、Notepad ++は、値が127(または16進数)より大きいためにASCII文字を表すことができないバイトを探します。見つかったが、それらがすべてUTF-8で必要なパターンに準拠している場合は、ファイルをUTF-8としてデコードし、ステータスバーに「ANSIasUTF-8」としてエンコードを報告します。
ただし、UTF-8行に対応していないバイトが1つでも見つかった場合は、ファイルを「ANSI」としてデコードします。これは、基盤となるプラットフォームのデフォルトのシングルバイトエンコーディングを意味します。ファイルが破損している場合は、それが表示されます。
編集:ファイルはそれがなくても有効ですが、ファイルの先頭に3バイトを手動で書き込むことで、BOMを追加でき"EF BB BF"
ますが、より良い方法があるはずです。今、どのようにコンテンツを生成していますか?これはUTF-8であるため、どこかに少なくとも1つの非ASCII文字があります。それ以外の場合、NPPはそれを「ANSI」として報告します。
考慮すべきもう1つの可能性:CSVファイルを消費するプロセスに影響がある場合は、BOMなしでUTF-8を期待するように構成できます。技術的には、UTF-8をBOMでデコードできるが、BOMなしではデコードできないソフトウェアはすべて壊れています。ユニコードコンソーシアムは、実際にはUTF-8 BOMの使用を推奨していませんが、誰もが聞いているわけではありません。