5

内部でSaxonを使用するProbatron4jを使用して、 Schematronスタイルシートに対していくつかのXMLファイルを検証しています。ほとんどの場合、これは正常に機能しますが、エラーが発生して処理がクラッシュする場合があります

org.xml.sax.SAXParseException：1バイトのUTF-8シーケンスの無効なバイト1。

私の調査によると、このメッセージは通常（順不同）を示しています

  • 明らかに無効なデータ（たとえば、ZIPファイルをXMLファイルであるかのように読み取ろうとする）。
  • バイト順マークの存在;
  • UTF-8で無効な文字の存在。また
  • UTF-8でエンコードされていると主張するときに嘘をついているドキュメント。

これらはどれも、私が処理しているドキュメントには当てはまりません。プログラムの実行中にバイト配列形式の入力を検査しましたが、BOMまたは非ASCII文字が含まれていません。

処理は、私の30kbドキュメントの約5分の1で、目立たない英語の文（「目立たない」とは、すべてのバイトが32（スペース）から122（小文字のz）の間であることを意味します）、つまり標準のキーボード文字でクラッシュする前に行われます。 ）。問題があると思われる要素のバイトは、この投稿の最後にあります。

奇妙なことに、失敗したドキュメントは、同じコードできれいに処理される大きなドキュメントからいくつかの要素を削除することによって生成されました。

parse(InputSource input)インターフェイスを実装するオブジェクトのメソッドで例外がスローされていることを知っていorg.xml.saxXMLReaderます。JavadocによるとSAXException、

SAX例外、場合によっては別の例外をラップします。

デバッガーで例外を調べると、ラップされた例外がないことがわかります。

このエラーの原因は何ですか？

編集：

[60, 80, 97, 114, 97, 103, 114, 97, 112, 104, 62, 69, 120, 101, 99, 117, 116,
 105, 118, 101, 32, 83, 117, 109, 109, 97, 114, 121, 58, 32, 70, 114, 111, 109,
 32, 49, 55, 53, 52, 32, 116, 111, 32, 49, 55, 54, 51, 13, 10, 32, 32, 32, 32,
 32, 32, 32, 32, 32, 32, 32, 32, 69, 117, 114, 111, 112, 101, 32, 97, 110, 100,
 32, 116, 104, 101, 32, 65, 109, 101, 114, 105, 99, 97, 115, 32, 119, 101, 114,
 101, 32, 99, 97, 117, 103, 104, 116, 32, 117, 112, 32, 105, 110, 32, 97, 32, 99,
 111, 110, 102, 108, 105, 99, 116, 32, 98, 101, 116, 119, 101, 101, 110, 32, 69,
 110, 103, 108, 97, 110, 100, 44, 32, 117, 110, 100, 101, 114, 32, 75, 105, 110,
 103, 32, 71, 101, 111, 114, 103, 101, 32, 73, 73, 44, 32, 97, 110, 100, 32, 70,
 114, 97, 110, 99, 101, 44, 32, 117, 110, 100, 101, 114, 32, 75, 105, 110, 103,
 32, 76, 111, 117, 105, 115, 32, 88, 86, 46, 32, 73, 110, 32, 69, 117, 114, 111,
 112, 101, 13, 10, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 116, 104, 105,
 115, 32, 112, 101, 114, 105, 111, 100, 32, 119, 97, 115, 32, 107, 110, 111, 119,
 110, 32, 97, 115, 32, 116, 104, 101, 32, 83, 101, 118, 101, 110, 32, 89, 101,
 97, 114, 115, 39, 32, 87, 97, 114, 59, 32, 105, 110, 32, 78, 111, 114, 116, 104,
 32, 65, 109, 101, 114, 105, 99, 97, 32, 105, 116, 32, 99, 97, 109, 101, 32, 116,
 111, 32, 98, 101, 32, 99, 97, 108, 108, 101, 100, 32, 116, 104, 101, 32, 70,
 114, 101, 110, 99, 104, 32, 97, 110, 100, 32, 73, 110, 100, 105, 97, 110, 32,
 87, 97, 114, 46, 32, 73, 116, 32, 119, 97, 115, 32, 97, 32, 99, 111, 110, 102,
 108, 105, 99, 116, 32, 111, 118, 101, 114, 13, 10, 32, 32, 32, 32, 32, 32, 32,
 32, 32, 32, 32, 32, 116, 114, 97, 100, 101, 32, 97, 110, 100, 32, 108, 97, 110,
 100, 46, 60, 47, 80, 97, 114, 97, 103, 114, 97, 112, 104, 62]

例外は、の3回目の出現後にスローされ109ます。

4

2 に答える 2

4

私はこれを解決しました。StringJava はオブジェクトに対して内部的に UTF-8 を使用しますが、StringクラスのgetBytes()メソッドは、UTF-8 (またはそれが理解できる他のエンコード方式) が必要であることを明示的に指定しない限り、システムのデフォルトのエンコード方式でバイトを生成します。

例外がスローされた場所の近くのバイト（質問の最後のバイト）はすべて有効なUTF-8バイトであったため、これが問題を解決する方法または理由は完全にはわかりませんが、それは物事を固定すること。

これについて考えられる唯一の潜在的な原因は、ファイルの前半で無効なバイトを見逃したため、問題が発生しましたが、すぐにクラッシュすることはありませんでした。からバイトを読み取っているByteArrayInputStreamため、プログラムがバッファから一度に大きなチャンクを読み取った可能性があります。これposにより、仮想の悪い文字が配置されていた場所を超えた場所にマーカーが設定されました。

于 2012-12-04T21:52:54.403 に答える
0

あなたのバイト配列を待っている間、私は少しグーグルをしました。

あなたが言った

奇妙なことに、失敗したドキュメントは、同じコードによってきれいに処理される大きなドキュメントからいくつかの要素を削除することによって生成されました。

そのことから、このスレッドの問題はおそらくあなたの問題だと思います

于 2012-12-04T17:07:25.753 に答える