問題タブ [noncharacter]

したがって、XSS フィルタリングをテストするためのXSS チート シートがありますが、問題のないページの例以外に、UTF-8 コードが正しく動作しないデータを処理できることを確認するための悪質または不正な形式のテスト データを見つけることができません。

テストに使用できる良いデータはどこにありますか? または、トリッキーな文字列とは何ですか?

java.text.CharacterIteratorドキュメントからの抜粋は次のとおりです。

• これinterfaceは、テキストに対する双方向反復のプロトコルを定義します。イテレータは、限定された一連の文字を繰り返し処理します。[...] メソッドprevious()とnext()は反復に使用されます。[...] の場合に返さDONEれ、イテレータがシーケンスの最後に到達したことを示します。

• static final char DONE: 反復子がテキストの末尾または先頭に到達したときに返される定数。値は、有効な Unicode 文字列に出現してはならない\uFFFF「文字ではない」値です。

イタリック体の部分は、私が理解するのに苦労しているものです。私のテストでは、JavaにStringは が含まれている可能性が最も高い\uFFFFように見えCharacterIteratorます。誤検知 (たとえば、実際には「完了」していない場合にnext()返されます)。'\uFFFF' == DONE

「問題」を説明するためのスニペットを次に示します ( ideone.com も参照)。

それで、ここで何が起こっているのですか？

• 規定されたトラバーサル イディオムは「壊れている」の\uFFFFでしょうか?
• たとえば、有効な Unicode 文字列で実際に禁止されていない場合、StringCharacterIterator実装は「壊れている」のでしょうか?throwIllegalArgumentException\uFFFF
• 有効な Unicode 文字列に が含まれてはならないというのは本当\uFFFFですか?
• それが本当なら、(ほとんどの部分で)とにかくString含むことを許可することによって、Unicode 仕様に違反するために Java は「壊れている」のでしょうか?\uFFFF

バイト オーダー マークを機能させるには、U+FFFE を非文字にする必要があります。

U+FFFF は、The Unicode Standardで「センチネルとしての内部目的に役立つ」と説明されています。理にかなっています。

しかし、私には理解できず、Unicode 標準では、非文字のセットに「Arabic Presentation Forms-A」内にランダムなブロックが含まれている理由が実際には説明されていません。これらは何のためですか？（バジリスクの目以外に？）

HTML5 仕様(表の直後) によると、次の文字は禁止されています。

それ以外の場合は、コード ポイントがその数値である Unicode 文字の文字トークンを返します。さらに、数値が0x0001〜0x0008から0x000dから0x001f、0x007fから0x009f、0xfdd0〜0xfdefの範囲にある場合、または0x000b、0xffffe、0xffff、0x1fffe、0x1ffff、0x2ffffffffffffe、0x3ffffffffe、0x2ffffffffeのいずれかです。 、0x5fffe、0x5fffffff、0x6fffe、0x6ffff、0x7fffe、0x7ffff、0x8fffe、0x8ffff、0x9fffe、0x9ffff、0xafffe、0xaffff、0xbfffe、0xbffff、0xfffffe、0xfffffe、0xffffe、0xffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、0xfffffe、これは解析エラーです。

この除外の背後にある理由または動機は何でしたか?

Unicode Character Encoding Modelで定義されているように、コード化された文字セットは、文字を非負の整数にマップします (たとえば、 _{^{LATIN SMALL LETTER A}}から 97 まで、従来の ASCII と UCS の両方によって)。

注:文字と抽象文字には違いがあります。後者の用語は、文字の概念をより厳密に指しますが、最初の用語は、コード化された文字セットのコンテキストにおける概念です。一部の抽象文字は、複数の文字で表されます。ウィキペディアの Unicode の記事では、例を挙げています。

たとえば、リトアニア語で必要とされる、オゴネク、上にドット、鋭いアクセント [抽象的な文字] を含むラテン語の小文字 "i" は、文字シーケンス U+012F、U+0307、U+ で表されます。 0301。

UCS (Universal Coded Character Set) は、国際標準 ISO/IEC 10646 で定義されたコード化文字セットであり、参照用に、この公式リンクからダウンロードできます。

当面のタスクは、指定された非負の整数がUCS (Universal Coded Character Set)によって文字にマップされているかどうかを判断することです。

実際には UCS によって予約されているにもかかわらず、文字が割り当てられていない非負の整数を最初に考えてみましょう。UCS (§ 6.3.1、分類、表 1、リンクされたドキュメントの 19 ページ) には、対応する基本タイプに基づいて 3 つの可能性がリストされています。

• サロゲート(範囲 D800–DFFF)

• 非文字 (範囲FDD0 –FDEF と、値 FFFE または FFFF で終わる任意のコード ポイント)

  Unicode 標準では、非文字を次のように定義しています。

  非文字は、永久に予約されているコード ポイントであり、文字が割り当てられることはありません。

  このページでは、非文字をより正確にリストしています。

• 予約済み(このカテゴリに属する​​非負の整数を見つけられませんでした)

一方、基本型が次のいずれかであるコード ポイント:

• グラフィック
• フォーマット
• コントロール
• 私的使用

キャラクターに割り当てられます。ただし、これは議論の余地があります。たとえば、私用のコード ポイントには実際に文字が割り当てられていると見なすべきでしょうか。まさしく UCS (§ 6.3.5, Private use characters ; リンクされたドキュメントの 20 ページ) では、次のように定義されています。

私用文字は、この国際規格によっていかなる形でも制限されません。私用文字は、ユーザー定義文字を提供するために使用できます。

さらに、UCS がマップまたは予約する非負の整数の範囲を知りたいです。最大値は？一部のページで、UCS がマップする非負の整数の範囲全体が、おそらく 0 ～ 0x10FFFF であることを発見しました。これは本当ですか？

理想的には、この情報は、アルゴリズムを構築できる機械可読形式で公開されます。たまたまですか？

明確にするために: 必要なのは、非負の整数を引数として受け取り、UCS によって文字にマップされているかどうかを返す関数です。さらに、公式の機械可読情報に基づいていることを希望します。この質問に答えるには、関数を自分で構築できるようなリソースを 1 つ指摘するだけで十分です。

補足 PUA (F0000-FFFFD および 100000 10FFFD) は、FFFFE、FFFFF、10FFFE、および 10FFFF を非文字として定義することにより、明示的に除外しています。なぜこれが行われたのですか？これがなければ、それらは 65536 ポイントのブロックになります。