2

私のクローラーエンジンは、特定の顧客のサイトに問題があるようです。

そのサイトには、次のようなURLへのリダイレクトがあります。

http://example.com/dir/aaa$0081 aaa.php (URLをエンコードされていないものとして表示します。$ 0081はHEXを使用して表された2バイトです。)

これは、WinInet Windows API呼び出しHttpQueryInfoを使用した後に返されたバッファを検査する場合であるため、この時点で2バイトは実際にはWideCharを表します。

これで、たとえば$ 0081が非視覚的な制御文字であることがわかります。Latin -1Supplement(Unicodeブロック)

問題は、サーバーへの今後のリクエストに「現状のまま」(URLエンコード)のURLを使用すると、400または404で応答することです(一方、完全に削除されている場合は機能し、サーバーは正しいページと応答...)

FireFox / IE/etcだと思います。HTTPリクエストを行う前にURL内の非表示のコントロール文字を削除しています...(少なくともIEHTTPHeadersおよびFF Live HTTPヘッダーアドインは非表示の文字を表示しません。)

誰かがこれの基準を指摘できるかどうか疑問に思いましたか?私が見ることができるものについては、目に見えない文字はURLで見つからないはずなので、解決策は(この場合および将来の場合)これらを削除することであると考えています。しかし、それはネット上で広く議論されているように見えるトピックではありません。

4

1 に答える 1

3

上記の例では、$0081 は 5 つの Ascii 文字です。しかし、これが見た目だけで、実際の URL に U+0081 が含まれていると (どういうわけか) 推測した場合、起こるべきこと、少なくとも Firefox では実際に起こることは、それが % エンコードされていることです (" U+0081 の UTF-8 エンコード形式の 2 バイトを % エンコードすることによって形成されます。Firefox では、U+0081 は制御文字であるため、これはアドレス バーに空として表示されますが、サーバーは実際に %C2%81 を取得し、そこから取得する必要があります。

スペースがどこから来るのかわかりませんが、% エンコード (%20) を除いて、URL にスペースを含めてはなりません。

関連する標準は、インターネット標準STD 66URI Generic Syntaxです。(現在は RFC 3986 です。注意: この問題では、古い RFC を「標準」と呼んでいる人がいまだによくあります。)

于 2012-09-17T08:21:34.717 に答える