web-dev-qa-db-ja.com

なぜurlencodeを使用する必要があるのですか？

私はウェブアプリケーションを書いて、htmlリンクをurlencodeする方法を学んでいます...

ここにあるすべてのurlencodeの質問（以下のタグを参照）は「How to ...？」です。質問。

私の質問は「方法」ではありません。しかし、なぜ？"。

ウィキペディアの記事でさえ、その仕組みのみを扱っています。
http://en.wikipedia.org/wiki/Urlencode not notwhyurlencodeを使用する必要があります私のアプリケーションではまったく。

securityurlencodeを使用する（または使用しない）意味は何ですか？

urlencodeの使用に失敗すると、exploited？

どのようなバグまたはエラーがエンコードされていないURLで発生する可能性がありますか？

Urlencodeがなくても、次のようなアプリケーション開発Webサイトへのリンクが期待どおりに機能するため、私は尋ねています：http://myapp/my%20test/ée/ràé

なぜurlencodeを使用する必要がありますか？

または別の言い方をすれば：

whenurlencodeを使用する必要がありますか？どんな状況ですか？

urlencode
53
augustin

更新：さらに上に（imo）より良い説明があります：

URIは、オクテットのシーケンスとしてではなく、文字のシーケンスとして表されます。これは、URIがコンピューターネットワークを経由しない手段によって「トランスポート」される可能性があるためです。たとえば、紙に印刷したり、ラジオで読んだりするなどです。

そして

ただし、非ASCII文字を含む元の文字シーケンスの場合、状況はより困難です。文字シーケンスを表すことを意図したオクテットシーケンスを送信するインターネットプロトコルは、複数の[RFC2277]がある場合、使用される文字セットを識別する何らかの方法を提供することが期待されます。ただし、現在、この識別を実現するための汎用URI構文には規定がありません。個々のURIスキームでは、単一の文字セットが必要な場合、デフォルトの文字セットを定義する場合、または使用する文字セットを示す方法を提供する場合があります。

[〜＃〜] rfc [〜＃〜] に記載されているため：

2.4。エスケープシーケンス

予約されていない文字を使用した表現がない場合、データをエスケープする必要があります。これには、以下で説明するように、US-ASCIIコード化文字セットの印刷可能文字に対応しないデータ、または許可されていないUS-ASCII文字に対応するデータが含まれます。

そして

2.4.2。脱出するとき

完成したURIをエスケープまたはアンエスケープすると、そのセマンティクスが変わる可能性があるため、URIは常に「エスケープされた」形式です。通常、エスケープエンコーディングを安全に作成できるのは、コンポーネントパーツからURIを作成するときだけです。各コンポーネントには予約された独自の文字セットがあるため、そのコンポーネントの生成または解釈を担当するメカニズムのみが、文字をエスケープすることでセマンティクスを変更するかどうかを決定できます。同様に、URIは、コンポーネント内のエスケープされた文字を安全にデコードする前に、コンポーネントに分離する必要があります。

場合によっては、予約されていない文字で表されるデータがエスケープされているように見える場合があります。たとえば、予約されていない「マーク」文字の一部は、一部のシステムによって自動的にエスケープされます。指定されたURIスキームが正規化アルゴリズムを定義している場合、予約されていない文字はそのアルゴリズムに従ってエスケープされない可能性があります。たとえば、http URLパスでは「〜」の代わりに「％7e」が使用されることがありますが、この2つはhttp URLに相当します。

パーセント「％」文字は常にエスケープインジケータとしての目的を持っているため、URI内のデータとして使用するには「％25」としてエスケープする必要があります。実装者は、同じ文字列を複数回エスケープまたはエスケープ解除しないように注意する必要があります。すでにエスケープされていない文字列をエスケープ解除すると、パーセントデータ文字が別のエスケープ文字として誤って解釈されるか、すでにエスケープされた文字列をエスケープする場合に逆になる可能性があるためです.

12
Felix Kling

主な理由は、基本的にエスケープ文字をWebページのURLに含めることです。

ユーザーがユーザーフォームフィールドに「＆joe」と入力し、URLエンコードを使用してURLの一部としてその名前を含むページにリダイレクトするとします。

localhost/index.php?name=%26joe //note how the ampersand is escaped

Urlencodingを使用しなかった場合、次のようになります。

localhost/index.php?name=&joe

そしてそのアンパサンドはあらゆる種類の予測不可能性を引き起こすでしょう

5
Dean P

URLの形式を定義するRFC（ http://www.faqs.org/rfcs/rfc1738.html など）があり、ブラウザ/ Webサーバーの開発者はこれを標準として使用していますデータの解釈。従わない場合、結果は予測できない場合があります。

HTTP URLには仕様があり、実質的にすべての非ラテン文字をエンコードする必要があると記載されています。

4
Dennis Kreminsky

私が考えることができる2つの理由：

  • クエリサーバー側の解析方法に大きく依存します。例えば。 HTTPのGETリクエストを使用してパラメーターを渡すと、パラメーター内に&などの文字が含まれている場合に問題が発生します。
  • これにより、非ANSI文字を思いどおりに処理できます（エンコードを指定します）。そうしないと、ブラウザはそれらをランダムなエンコーディングで渡す可能性があります（標準で実際に定義されているとは思わないでください。間違っている場合は修正してください）。
4
Mario

あなたの2つのパスがこのようなものである場合、どのように区別しますか

http://myapp/my%20test/

そして

http://myapp/my test/

スペースと％20はURLの一部です。

2
hungryMind