92

s を動的に生成する PHP スクリプトがあるので、属性<input>内の文字をフィルタリングする必要があるかどうか疑問に思っていました。name

名前は文字で始めなければならないことは知っていますが、それ以外のルールは知りません。PHP は角括弧を使用してフォーム データから配列を作成するため、角括弧を許可する必要があると思います。括弧はどうですか？スペース？

4

5 に答える 5

59

フォームフィールドの属性にすべての文字が送信されるわけではないことに注意してくださいname（POSTを使用している場合でも）。

空白文字はトリミングされ、内側の空白文字と文字.は。に置き換えられ_ます。（Chrome 23、Firefox 13、Internet Explorer 9、すべてWin7でテスト済み。）

于 2012-12-13T11:15:41.430 に答える
39

[X]HTML ファイルに含めることができる任意の文字を<input name>. Alllain のコメントが言うように、<input name>は含むと定義されてCDATAいるため、そこに入れることができないのは、制御コードと、基礎となる標準 (SGML または XML) が許可しない無効なコードポイントだけです。

Allain は HTML4 仕様から W3 を引用しました。

ノート。「get」メソッドは、フォーム データ セットの値を ASCII 文字に制限します。ISO10646 文字セット全体をカバーするために、"post" メソッド (enctype="multipart/form-data" を使用) のみが指定されています。

ただし、これは実際には当てはまりません。

理論的には、application/x-www-form-urlencodedデータにはフォームの名前または値のエンコーディングを指定するメカニズムがないため、いずれかで非 ASCII 文字を使用することは「指定されていない」ため、代わりに POSTed を使用する必要がありますmultipart/form-data。

multipart/form-data残念ながら、現実の世界では、 POST リクエスト本文のサブパート ヘッダーで、理論的に可能な場合でも、フィールドのエンコーディングを指定するブラウザーはありません。(Mozilla は一度実装しようとしたと思いますが、サーバーが壊れたので取りやめました。)

また、エンコードされた非 ASCII フィールド名をマルチパートのサブパート ヘッダーに挿入するために必要な、驚くほど複雑で醜いRFC2231標準を実装しているブラウザはありません。いずれにせよ、定義する HTML 仕様はmultipart/form-data、RFC2231 を使用する必要があると直接述べているわけではありません。

そのため、実際には、フォームの種類に関係なく、フォーム送信の名前と値にどのエンコーディングが使用されているかを知る方法はありません。ブラウザが非 ASCII 文字を含むフィールド名と値に対して行う処理は、GET と両方のタイプの POST フォームで同じです: 使用されるフォームを含むページのエンコーディングを使用してそれらをエンコードします。非 ASCII の GET フォーム名は、他のすべてのものと同じように壊れていません。

DLH:

name は、他の要素とは異なるデータ型を持っていますか?

実際、name属性が でない唯一の要素CDATAは です<meta>。;のさまざまな用途については、HTML4 仕様の属性リストを参照してください。nameこれはオーバーロードされた属性名であり、さまざまな要素でさまざまな意味を持ちます。これは一般的に悪いことと考えられています。

ただし、最近では通常、nameフォーム フィールド (コントロール名の場合) とparam(プラグイン固有のパラメーター識別子の場合) 以外は避けます。取り組むべき意味は2つだけです。ページ上のや などのname要素を識別するための昔ながらの の使用は避ける必要があります (代わりに使用してください)。<form><a>id

于 2010-08-06T15:47:02.830 に答える
32

フォーム コントロール名に表示できる文字に関する唯一の実際の制限は、フォームが GET で送信された場合です。

「get」メソッドは、フォーム データ セットの値を ASCII 文字に制限します。参照

ここに良いスレッドがあります。

于 2010-08-06T14:56:20.170 に答える
0

HTML入力タグのid属性とname属性を意味しますか？

もしそうなら、許可された「入力」名文字をaz（AZ）、0〜9、および句読点の制限された範囲（ "。"、 "、"など）のみに制限（または変換）したくなるでしょう。 XSSエクスプロイトなどの可能性を制限するためだけの場合。

さらに、なぜユーザーが入力タグの任意の側面を制御できるようにするのですか？（検証の観点から、入力タグ名を「custom_1」、「custom_2」などに保ち、必要に応じてこれらをマップすることは、最終的には簡単ではないかもしれません。）

于 2010-08-06T14:49:58.313 に答える