8

ユーザーがコンテンツをアップロードして処理できるようにするWebアプリケーションがあります。処理エンジンはUTF8を想定しているため（複数のユーザーのファイルからXMLを作成しています）、アップロードされたファイルを適切にデコードできることを確認する必要があります。

私のユーザーの誰かが自分のファイルがエンコードされていることさえ知っていたら驚いたので、使用するエンコード（デコーダー）を正しく指定できることを期待することはほとんどありません。そのため、私のアプリケーションには、デコードする前に検出するタスクが残されています。

これはそのような普遍的な問題のように思えます。フレームワーク機能もソリューションの一般的なレシピも見つからないことに驚いています。意味のある検索用語で検索していないのでしょうか？

BOM対応の検出（http://en.wikipedia.org/wiki/Byte_order_mark）を実装しましたが、エンコードを示すためにBOMを使用してファイルがアップロードされる頻度がわかりません。これは、ほとんどの非UTFファイル。

私の質問は要約すると次のようになります。

  1. 大多数のファイルに対してBOM対応の検出で十分ですか？
  2. BOM検出が失敗した場合、別のデコーダーを試して、それらが「有効」であるかどうかを判断することは可能ですか？（私の試みは答えが「いいえ」であることを示しています。）
  3. 「有効な」ファイルがC＃エンコーダー/デコーダーフレームワークで失敗するのはどのような状況ですか？
  4. テストに使用するさまざまなエンコーディングのファイルが多数あるリポジトリはどこにありますか？
  5. 特にC＃/。NETについて質問していますが、次回これを行う必要がある場合に備えて、Java、Python、およびその他の言語の答えを知りたいと思います。

これまでのところ私は見つけました：

  • Ctrl-S文字を含む「有効な」UTF-16ファイルにより、UTF-8へのエンコードで例外（不正な文字？）がスロー されました（これはXMLエンコードの例外でした）。
  • 有効なUTF-16ファイルをUTF-8でデコードすると成功しますが、ヌル文字のテキストが返されます。は？
  • 現在、UTF-8、UTF-16、およびおそらくISO-8859-1ファイルのみを期待していますが、可能であればソリューションを拡張できるようにしたいと考えています。
  • 私の既存の入力ファイルのセットは、ライブファイルで発生するすべての問題を明らかにするのに十分な広さではありません。
  • 私がデコードしようとしているファイルは「テキスト」ですが、ファイルにガベージ文字を残すメソッドを使用して作成されることが多いと思います。したがって、「有効な」ファイルは「純粋」ではない可能性があります。ああ、喜び。

ありがとう。

4

5 に答える 5

3

絶対に信頼できる方法はありませんが、ヒューリスティックを使用して「かなり良い」結果を得ることができる場合があります。

  • データが BOM で始まる場合は、それを使用します。
  • データに 0 バイトが含まれている場合は、utf-16 または ucs-32 である可能性があります。0 バイトの位置を見ることで、これらを区別することができます。
  • データを utf-8 (エラーなし) としてデコードできる場合、utf-8 (または US-ASCII、ただしこれは utf-8 のサブセット) である可能性が非常に高くなります。
  • 次に、国際化する場合は、ブラウザーの言語設定をその言語の最も可能性の高いエンコーディングにマップします。
  • 最後に、ISO-8859-1 を想定します。

もちろん、「かなり良い」が「十分に良い」かどうかは、アプリケーションによって異なります。確認する必要がある場合は、結果をプレビューとして表示し、データが正しく表示されることをユーザーに確認してもらいます。そうでない場合は、ユーザーが満足するまで、次の可能性のあるエンコーディングを試します。

注: データに不要な文字が含まれている場合、このアルゴリズムは機能しません。たとえば、有効な utf-8 に 1 つのガベージ バイトがあると、utf-8 のデコードが失敗し、アルゴリズムが間違ったパスに進みます。これを処理するには、追加の措置が必要になる場合があります。たとえば、可能性のあるガベージを事前に特定できる場合は、エンコーディングを決定する前にそれを取り除きます。(ストリップが積極的すぎても問題ありません。エンコーディングを決定したら、元のストリップされていないデータをデコードできます。例外をスローする代わりに、無効な文字を置き換えるようにデコーダを構成するだけです。) または、デコードエラーをカウントし、適切に重み付けします。 . しかし、これはおそらくガベージの性質、つまり、どのような仮定を立てることができるかに大きく依存します。

于 2010-02-22T21:16:09.197 に答える
2

ユーザーからファイルの代表的な断面を読み取り、プログラムで実行し、テストし、エラーを修正して先に進みましたか?

File.ReadAllLines() は、すべてのエンコーディングを気にすることなく、非常に幅広いアプリケーションで非常に効果的であることがわかりました。かなりうまく処理できているようです。

Xmlreader() を適切に使用する方法を理解すると、Xmlreader() はかなりうまく機能しました。

データの特定の例をいくつか投稿して、より良い応答を得ることができるかもしれません。

于 2010-02-22T21:03:31.103 に答える
1

chardetと呼ばれる Python ベースのソリューションを参照してください。これは、Mozilla コードの Python ポートです。直接使用することはできないかもしれませんが、ドキュメントが参照している元の Mozilla の記事と同様に、そのドキュメントは読む価値があります。

于 2010-03-08T01:35:58.263 に答える
1

これはよく知られた問題です。Internet Explorer が行っていることを試すことができます。これは、問題に対する Microsoft の解決策を説明している The CodeProjectのすばらしい記事です。ただし、すべてがヒューリスティックに基づいているため、100% 正確なソリューションはありません。また、BOM が存在すると想定するのも安全ではありません。

于 2010-02-22T21:04:28.700 に答える
0

同様の問題に遭遇しました。ファイルが（一般的なエンコーディングで）テキストエンコードされているかどうかを判断するpowershellスクリプトが必要でした。

それは間違いなく網羅的ではありませんが、ここに私の解決策があります...

バイナリ ファイルを無視する PowerShell 検索スクリプト

于 2010-03-08T01:41:25.230 に答える