RFC2396とURL/URI全体をよりよく理解したいと思います。また、CocoaのNSURLはRFC 2396に基づいているため、概要を探します。RFC自体は私には読みにくいです。
3 に答える
RFC 3305が役立つ場合があります。
このドキュメント [...] は、URI に関する問題に対処し、明確にすることを試みます。このドキュメントでは、URI 空間がどのように分割されるか、および URI、URL、および URN 間の関係について説明し、URI スキームと URN 名前空間 ID がどのように登録されるかを説明し、この主題に関する継続的な作業の推奨事項を提示します。
あなたの本当の質問は、URI / URL / URN の分割全体に関するものだと思います。まず、これは単なる用語であり、多くの場合、それらは交換可能であると言うことから始めましょう。
URL は Uniform Resource Locatorです。URL は などのアクセス「スキーム」を識別し、そのスキームを使用してそのリソースを見つけるhttp:のに十分な情報を含んでいます。リソースにアクセスするのに十分な情報が含まれているとは限りません。たとえば、HTTP URL でページにアクセスできますが、そのページにはアクセスのための認証要件がある場合があります。
URN は Uniform Resource Nameです。これも「スキーム」で始まり、そのスキームに適した任意の情報が含まれます。URN は、"uuid" などの事前定義されたスキームがいくつかありますが、それらのスキームには (たとえば HTTP とは異なり) 特定の用途がないため、混乱を招きます。これは必ずしも悪いことではありません。私は XML 名前空間のようなものに URN を使用するのが好きですが、その名前空間に関連する何かを実際に取得できるという暗示を望んでいません。
URI は Uniform Resource Identifierであり、URL、URN、およびその他のいくつかの識別子タイプを含むスーパーセットです。RFCは URL と URN について言及していますが、詳細には触れていません。これは、使用法ではなく、URI の物理的な構造 (一般的な形式、エンコード方法など) に焦点を当てているためです。
ニッチピッカーの編集:「スキームで始まる」と言うとき、「(現在のコンテキストによって暗示される可能性がある)」というテキストがあると仮定します。
概要については、実際のRFCの要約と紹介で十分です。あなたがよりよく理解したいRFCの特定のセクションを選ぶことができます。
基本的に、RFC 2396をよりよく、またはより完全に理解するために-これはあなたが求めていることです(そして概要..)、正直に言うとRFC自体を読むよりもはるかにうまくいくことはできません。私には論理的なようです。