問題タブ [rfc2396]

rfc2396 に準拠するように URL 文字列をエンコードし、たとえば %20 がスペース文字に置き換えられるように rfc2396 準拠の文字列をデコードする最良の方法は何ですか?

編集: URLEncoder および URLDecoder クラスは、rfc2396 準拠の URL をエンコード/デコードしません。それらは、HTML フォーム パラメーター データのエンコードに使用される application/x-www-form-urlencoded の MIME タイプにエンコードします。

クエリ/マトリックス パラメータの値として URI を送信したいと考えています。既存の URI に追加する前に、RFC 2396 に従ってエンコードする必要があります。たとえば、入力が与えられた場合:

http://google.com/resource?key=value1 & value2

出力が期待されます：

http%3a%2f%2fgoogle.com%2fresource%3fkey%3dvalue1%2520%26%2520value2

どちらjava.net.URLEncoderもjava.net.URI正しい出力を生成しません。URLEncoderRFC 2396 とは異なる HTML フォーム エンコーディング用です。URI一度に 1 つの値をエンコードするメカニズムがないため、value1 と value2 が同じキーの一部であることを知る方法がありません。

RFC2396とURL/URI全体をよりよく理解したいと思います。また、CocoaのNSURLはRFC 2396に基づいているため、概要を探します。RFC自体は私には読みにくいです。

RFC2396 - Uniform Resource Identifiersのセクション 3.3、パス コンポーネントによると、

パスは、単一のスラッシュ「/」文字で区切られた一連のパス セグメントで構成される場合があります。パス セグメント内では、文字「/」、「;」、「=」、および「?」予約されています。各パス セグメントには、セミコロン「;」で示される一連のパラメータを含めることができます。キャラクター。パラメータは、相対参照の解析には重要ではありません。

ただし、最後のセグメント以外のセグメントにクエリ パラメータを含む URL は見たことがありません。したがって、これを正しく読んでいるかどうかはわかりません。

http://www.url.com/segment1?seg1param1=val1/page.html?pageparam1=val2有効な URL ですか?

まず、いくつかの簡単な背景... サード パーティ ベンダーとの統合の一環として、クエリ文字列に一連の情報を含む 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 オクテットに変換する簡単な方法はありますか?

.NET Framework 4.5の機能を調べているうちに、RFC 準拠の URI がサポートされていることがわかりました。RFC 準拠の URI サポートがあるとはどういう意味ですか?

In shord：HTTP1.1標準に準拠した方法で、http：//example.com/？queryのようなURLへのGETクエリをrfc2616にどのように適用しますか？

ウィキペディアは言う

rfc2616ではそれは言う

GETリクエストに関連するのはabs_pathとabsoluteURIのみです。

abs_path

ここで、abs_pathは実際には「？」を禁止するuri rfcからのものです。これは、abs_pathが実際にはクエリ部分の前にあるuriの一部であるためです。したがって、ウィキペディアの変種は構文的に正しくないようです。

絶対URI

このためにurirfcは言います

したがって、そのようなクエリをRequest-URIに入れることは可能ですが、残念ながら、rfc2616は、プロキシと通信していないクライアントのabsoluteURIの送信を許可していません。これは、Webサーバーによって標準に準拠した方法で受信することは可能ですが、実際には、ブラウザーやその他のクライアントに準拠して標準で送信することはできません。

rel_path

驚いたことに、rfc2616は「？」と言っています。rel_pathにありますが、これはrfc2396では許可されていません。また、rel_pathルールはrfc2616のどこにも構文的に使用されていないため、httpリクエストのどこかにrel_pathを配置することはできません。

だから私の質問は、どのように標準に準拠してそのような要求を行うのか、そしてすべてのブラウザが標準を破っていますか？

URLでRFC2396を読んでいます

多くの URI には、特定の特殊文字で構成された、または特殊文字で区切られたコンポーネントが含まれています。これらの文字は、URI コンポーネント内での使用が予約された目的に限定されるため、「予約済み」と呼ばれます。

しかし、url のクエリ部分 (? と # の間) のセクションには、

3.4。クエリ コンポーネント クエリ コンポーネントは、リソースによって解釈される情報の文字列です。

クエリ コンポーネント内では、文字「;」、「/」、「?」、「:」、「@」、「&」、「=」、「+」、「,」、および「$」は予約されています。

これらの各文字の「予約済みの目的は何ですか?クエリで &、=、および + が使用されていることは理解していますが、他の文字はどうですか?

より実際には、これらの文字がクエリにあるときは常に URL エンコードする必要がありますか? 私が見たブラウザとサーバーは、 : と ; を処理しています。およびエンコードされていないその他の文字

Actionscript/Flex 3 を使用して、RFC 2396 に従って文字列をエンコードするにはどうすればよいですか?

前もって感謝します！

URL パスをパス コンポーネントに分割する特定の (標準化された) 方法はありますか? RFC 2396 を見てきましたが、そうするためのルーチンが見つかりません。

もともと、私は PHP のexplode()メソッドを使用して、それぞれに遭遇したときに文字列を配列に分割しました/が、Cocoa のクラスに対してテストするとNSURL、2 つの異なる結果が得られました。

テスト URL: https://example.com/rest/api///v2.1.1/noun/verb////12345/additional/stuff///

NSURL:

私のPHPメソッド:

RFC 2396 が RFC 3986 に置き換えられたことは認識していますが、NSURL は 2396 を使用しており、クライアント側の実装になるため、それに対してテストしています。