1

XML パーサーをデバッグする必要があり、開始タグと終了タグを正しく認識しない「悪意のある」入力を構築できるかどうか疑問に思っています。

さらに、この種の一般的な情報はどこで見つけることができますか? &この後、使用しているパーサーが、=、などの他の特殊文字に問題がないことも確認したいと思います"。

4

3 に答える 3

3

UTF-8 を使用すると、コード単位 (バイト) の役割を簡単に把握できます。

  • 最上位ビットが設定されていない場合、つまりコード単位が0xxxxxxxである場合、これはバイトであり、その値は ですxxxxxxx(つまり、7 ビットの情報)。

  • 最上位ビットが設定され、コード単位が10xxxxxxの場合、これはマルチバイト シーケンスの継続部分であり、6 ビットの情報を伝送します。

  • それ以外の場合、コード単位は次のようにマルチバイト シーケンスの最初のバイトです。

    • 110xxxxx: 2 バイト (1 継続バイト)、5 + 6 = 11 ビット。
    • 1110xxxx: 3 バイト (連続する 2 バイト)、4 + 6 + 6 = 16 ビットの場合。
    • 11110xxx: 4 バイト (3 連続バイト)、3 + 6 + 6 + 6 = 21 ビットの場合。

ご覧のとおり、値 60 は value00111100のシングルバイト コードポイントで60あり、同じバイトがマルチバイト シーケンスの一部として発生することはありません。

このスキームは実際には最大 7 バイトまで拡張でき、最大 36 ビットまでエンコードできますが、Unicode は 21 ビットしか必要としないため、4 バイトで十分です。標準では、コード ポイントを最小数のコード単位で表す必要があります。

更新: @Mark Tolonen が正しく指摘しているように、エンコードされた各コード ポイントが実際に最小数のコード単位でエンコードされているかどうかを慎重に確認する必要があります。ブラウザがそのような入力をうっかり受け付けてしまうと、ユーザーは、バイトごとの分析では見つけられない何かをこっそり通り過ぎる可能性があります。出発点として、 のようなバイトを探すことができますが10111100、それが一部であるマルチバイト シーケンス全体をチェックする必要があります (もちろん、異なるコード ポイントの一部として正当に発生する可能性があるため)。最終的に、ブラウザーを信頼できない場合は、すべてをデコードして、結果のコード ポイント シーケンスで U+3C などの発生をチェックするだけではうまくいかず、バイト ストリームを確認することさえしません。

于 2013-01-27T17:12:32.660 に答える
1

設計が不十分なUTF-8デコーダーは、バイトとasおよびを解釈する可能性があります。@KerrekSBが彼の答えで述べたように：C0 BCC0 BEU+003CU+003E

この規格では、コードポイントを最小限のコード単位で表す必要があることが義務付けられています。

ただし、アルゴリズムが不十分な場合でも、コードユニットの最小数ではない不正な形式の2バイトUTF-8シーケンスをデコードする可能性があります。

C0 BC = 110 00000 10 111100 = 00000111100 = 3C hex = 60 dec ='<'

したがって、テストには必ず不正な形式のUTF-8シーケンスを含め、それらが拒否されることを確認してください。

于 2013-01-27T19:17:43.403 に答える
1

UTF-8 では、いいえ。他のエンコーディングでは、はい。

UTF-8 では、設計上、マルチバイト文字のすべてのバイトに常に最上位ビットが設定されます。逆に、最上位ビットが設定されていないバイトは常に ASCII 文字です。

ただし、これは XML にも有効な他のエンコーディングには当てはまりません。

UTF-8 の詳細については、wikipediaなどを確認してください。

于 2013-01-27T17:05:51.263 に答える