19

以前に別のプロセスで生成されたCSVファイルを生成するPHPスクリプトを作成しました。次に、CSVファイルをさらに別のプロセスでインポートする必要があります。

古いCSVファイルのインポートは正常に機能しますが、新しいCSVファイルをインポートすると、特殊文字に関する問題が発生します。

Notepad ++で古いCSVを開くと、エンコーディングはUTF-8であると表示され、新しいCSVを使用して開くと、エンコーディングは「ANSIasUTF-8」と表示されます。

2つの違いは何ですか?

そして、どうすればfopenとfputcsvに「純粋」を使用させることができますか?UTF-8エンコーディング?

ありがとう!

4

4 に答える 4

42

ファイルに問題はありません。「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-8BOMでデコードできるが、BOMなしではデコードできないソフトウェアはすべて壊れています。ユニコードコンソーシアムは、実際にはUTF-8 BOMの使用を推奨していませんが、誰もが聞いているわけではありません。

于 2009-09-05T03:56:07.637 に答える
6

ここここのNotepad++関連のスレッドによると、「ANSI as UTF-8」はBOMなしのUTF-8を示し、プレーンな「UTF-8」はBOM付きのUTF-8を意味します。したがって、CSVを読み取るプロセスでは、CSVをUTF-8として正しく読み取るためにバイト順マークが必要になる場合があります。

ただし、その前に、スクリプトが実際にUTF-8を記述していることを確認してください。Notepad ++で新しいCSVを開くと(「ANSIas UTF-8」と表示されます)、すべての「特殊」文字が正しく表示されますか?そうでない場合は、実際にUTF-8を作成するようにスクリプトを調整する必要があります。そうである場合は、BOMの違いを確認してください。

于 2009-09-04T18:11:24.453 に答える
1

PHPスクリプトもUTF-8に変更してみてください。場合によっては(バイパスできるにもかかわらず)、データの同じ文字エンコードでスクリプトを使用する必要があります。

同様の問題:PHP:特殊文字を使用して爆発する

于 2009-09-04T18:04:14.250 に答える
0

PHPファイルをUTF-8としてフォーマットする場合は、ANSIをUTF-8として、つまりBOMを含まないUTF-8が役立つことに注意してください。PHPファイルがブラウザにhtmlを出力している場合、BOMはHTML出力に含まれ、w3cバリデーターは明示的に警告します。

UTF-8ファイルで見つかったバイト順マーク。

UTF-8でエンコードされたファイルのUnicodeバイト順マーク(BOM)は、一部のテキストエディタや古いブラウザで問題を引き起こすことが知られています。より適切にサポートされるまで、その使用を避けることを検討することをお勧めします。

これに加えて、BOMがFirefoxのFirebugを混乱させていることに気づきました。これにより、すべての<head>コンテンツが実際に<body>タグに含まれていると見なされます。

于 2012-03-06T22:14:59.120 に答える