問題タブ [rfc3986]

人々はURL、URI、およびURNについて、あたかも別のものであるかのように話しますが、肉眼では同じように見えます。

それらの間の区別可能な違いは何ですか？

RFC 3986に準拠するために、既存の http://URL 解析コードをテストする必要があります。

車輪を再発明したり、さまざまなコーナーケースにぶつかったりしたくありません。

そのための既存の包括的なテストスイートはありますか?

使用する言語は指定しません。テスト スイートは汎用性が高く、順応性があると考えているからです。私は正気なら何でも解決します。

URL を無効にする文字はどれですか?

これらの URL は有効ですか?

• example.com/file[/].html
• http://example.com/file[/].html

RFC 3986 URI: Generic Syntax仕様には、セミコロンが予約済み (サブデリム) 文字としてリストされています。

「;」の予約された目的は何ですか URI のセミコロンの? さらに言えば、他のサブデリムの目的は何ですか (「&」、「+」、および「=」の目的しか認識していません)。

関連する RFC であるIETF RFC 3986でこれを見つけようとしましたが、わかりませんでした。

HTTP の URI は Unicode または非 ASCII を許可しますか?

あなたの答えをサポートするセクションとRFCを引用してください。

NB: これはプログラミング関連ではないと思うかもしれない人のために - それは関連しています。これは、私が構築している ISAPI フィルターに関連しています。

補遺

私は RFC 3986 のセクション 2.5 を読みました。しかし、現在の HTTP プロトコルであると私が信じている RFC 2616 は、3986 よりも前のものであり、そのため、3986 に準拠することはできないと思います。さらに、HTTP RFC がが更新されても、まだ合理化の問題があります。つまり、HTTP URI は、非 US-ASCII 文字を含めるのに適切なものを含め、RFC3986 のすべての条件をサポートしていますか?

PHP で、2 つの相対 URL が等しいか比較したいと考えています。問題: URL はパーセント エンコーディングが異なる場合があります。

• /dir/file+file対。/dir/file%20file
• /dir/file(file)対。 /dir/file%28file%29
• /dir/file%5bfile対。 /dir/file%5Bfile

RFC 3986によると、サーバーはこれらの URI を同じように扱う必要があります。でも==比べてしまうとズレてしまうんですよね。

だから私は2つの文字列を受け入れTRUE、それらが同じURIを表す場合に返すPHP関数を探しています（同じ文字のエンコード/デコードされたバリアント、エンコードされた文字の大文字/小文字の16進数、および+対%20スペース)、およびFALSEそれらが異なる場合。

これらの文字列にはASCII文字のみが含まれていることを事前に知っています.Unicodeはありません。

form[action]とa[href]の値を調べて、それらを絶対URLに解決する必要があるJSライブラリを構築しています。

たとえば、私はhttp：// a / b / c / d; p？qにいて、「../ g」というhref値に遭遇しました（<base>要素がないと仮定します）。結果の絶対値は次のようになります：http：// a / b/g。

これをすでに行っているJSライブラリはありますか？私はそう信じなければならないでしょう。

必要なものの詳細については、仕様： https ://www.rfc-editor.org/rfc/rfc3986#section-5.4

StringRFC 3986 仕様に従ってジェネリックをエンコードするクラスはありますか?

つまり: "hello world"=> "hello%20world" Not (RFC 1738) :"hello+world"

ありがとう

hrefURIを生成する必要があります。パーセントエンコーディングが必要な予約文字を除いて、すべて簡単です。たとえば、へのリンクは次の/some/path;elementように表示されます（単一のエンティティを表す<a href="/some/path%3Belement">ことはわかっています）。path;element

最初はこれを行う Java ライブラリを探していましたが、自分で何かを書くことになりました (この質問は Java 固有ではないため、Java で失敗したものについては以下を参照してください)。

したがって、RFC 3986は、いつエンコードしないかを提案しています。私が読んだように、これは、キャラクターがunreserved (ALPHA / DIGIT / "-" / "." / "_" / "~")クラスに分類されるときに発生するはずです。ここまでは順調ですね。しかし、逆の場合はどうでしょうか。%RFC では、パーセント ( ) は常にエンコードが必要であるとのみ言及されています。しかし、他の人はどうですか？

質問:予約されていないものはすべて、パーセントでエンコードできる/すべきであると仮定するのは正しいですか? たとえば、左大括弧(は必ずしもエンコードする必要はありませんが、セミコロンは必要です;。/firstエンコードしないと、次のときに *を探すことになります<a href="/first;second">。しかし、次のよう<a href="/first(second">にすると、予想どおり、常に を探してしまい/first(secondます。私を混乱させているのは、RFC に関する限り、 と の両方が同じクラス(に;あるということです。sub-delims私が想像するように、予約されていないものすべてをエンコードすることは安全な賭けですが、ローカライズされた URI に関しては、SEO 性、ユーザー フレンドリ性についてはどうでしょうか?

さて、Java ライブラリで何が失敗したか。私はそれをやってみまし
new java.net.URI("http", "site", "/pa;th", null).toASCIISTring()
たが、これhttp://site/pa;thは良くありません。同様の結果が観察されました:

• javax.ws.rs.core.UriBuilder
• Spring の UriUtils - 私は両方を試しましencodePath(String, String)たencodePathSegment(String, String)

[*]をクリックしたときにサーバー側/firstで呼び出した結果ですHttpServletRequest.getServletPath()<a href="/first;second">

編集:おそらく、この動作は Tomcat で観察されたことに言及する必要があります。また、Tomcat 6 と 7 の両方が同じように動作することを確認しました。

まず、いくつかの簡単な背景... サード パーティ ベンダーとの統合の一環として、クエリ文字列に一連の情報を含む URL を受け取る C# .Net Web アプリケーションを使用しています。その URL は、MD5 ハッシュと共有秘密鍵で署名されています。基本的に、クエリ文字列を取得し、それらのハッシュを削除し、残りのクエリ文字列に対して独自のハッシュを実行し、提供されたものと一致することを確認します。

次の方法で Uri を取得しています...

私の問題は、ウムラウト (ü) などの特殊文字を含むクエリ文字列に起因しています。ベンダーは、RFC 2396 表現に基づいてハッシュを計算しています%FC。私のC＃.Netアプリは、RFC 3986表現に基づいてハッシュを計算しています%C3%BC. 言うまでもなく、ハッシュが一致せず、エラーがスローされます。

不思議なことに、.Net の Uri クラスのドキュメントには、 RFC 3986 に設定されていない限り、RFC 2396 に従う必要があると書かれていますが、私のweb.configファイルには、この動作に必要であるというエントリがありません。

Uri コンストラクターが RFC 2396 規則を使用するように強制するにはどうすればよいですか?

それに失敗した場合、RFC 3986 オクテット ペアを RFC 2396 オクテットに変換する簡単な方法はありますか?