URIの解剖学(URL、URNなどとは何ですか?)

これは、「何でもプログラムする方法:インターネット」という大きなシリーズの一部です。

URI、URL、URNなどとは何ですか?

その年は2017年であり、インターネットは多くの人にとって日常生活のユビキタスな部分になっています。 NetflixやHuluのようなストリーミングサービスを利用して自分の好きなショーを見たり、人生を一日に何度もツイートしたりしているインターネットは、ほとんどの人に支えられています。 だから、インターネットの初期の時代やアダプターに直面した問題を忘れるのは簡単かもしれません。

これらの問題の1つは、インターネット上で見つかる可能性のあるリソースを参照する機能でした。インターネット上の何かにアクセスする方法を説明したければ、プログラムを開いたり、このユーザーとしてログインしたり、この場所に移動したり、その情報を入力したりするように指示する必要がありました。画像、メールアドレス、またはMUCKなどのリソースに対処する実際の方法はありませんでした。これは、「snail mail」を使用して封筒で行うようなものでした。はい、それはそれが呼ばれていたものです。それは手紙を書くようなものです。 そしてあなたは郵便配達員の指示をあなたの友人の家に人に話してください。 その後、それは配信されます。それはほとんど実用的ではありません。

幸運なことに、多くのアイディアが浮かび上がって、現実の世界で見つけたのと同じタイプのアドレッシングが「情報スーパーハイウェイ」で使用できるようになりました。 はい、それはそれが呼ばれていたものです。 これらのアイデアの1つはURI(Uniform Resource Identifier)です。 あなたは、URLという用語、またはURIの一形態であるUniform Resource Locatorに精通しているかもしれません。 あまり知られていないURN、またはUniform Resource Nameもあります。これについても説明します。

本質的に、URIは、インターネット上のある種の「リソース」を「タグ付け」する方法です。 これは少し抽象ですが、私は説明します。 URIは必ずしもURLなどのネットワーク上の場所を指定するとは限りませんが、リソースにタグを付けるために使用するフォーマット仕様です。 ここのリソースは、何か、PDF、JPG、HTMLファイル、テルネット接続などの単なる接続ですらあります。 リソースは、人や給与計算レコードなどのREST APIによって取得されるデータオブジェクトでもあります。 ここでの主な考え方は、URIを持つリソースに「識別子」を割り当てることができるということです。 そのURIは、そのリソースを「参照」し、実際には、非相対URI(以下参照)を「解決する」行為は、そのリソースの表現を取得します。この表現は、イメージファイルなどの実際のデータです。

たとえば、Instagramに画像をアップロードします。 Instagramサーバーでは、この特定のイメージはあらゆる場所に配置されている可能性があります。 これは、世界中の複数のサーバーに複製でき、おそらくサーバーのファイルシステム上の特にネストされたフォルダに配置されています。 しかしInstagramはその特定のイメージのURIをhttps://www.instagram.com/p/xxxxxxxxxxの形式で私に提供しています。ここで「xxxxxxx」は一見無作為な文字(文字)の束です。 技術的なこの特定のビットはURIです。つまり、インターネット上の特定のリソース(イメージ)を識別します。 このURIはまた、ネットワークロケーションを指定するという点でURLであるが、それはURIであっても関係ない。

もう1つの例は、書籍のISBN番号です。 書籍のISBN番号は、さまざまな国固有の組織によって書籍に割り当てられた一意の識別子です。 それらは様々な商業目的で使用されており、米国では非公開会社のR. R. Bowkerがそれらを発行している。 私の好きな本の1つであるMichael Endeによる “The Neverending Story”は現在ISBN 0140386335となっています。URNは “名前空間”内のリソースの名前を識別するURIの一種です。 それは左から右に細分化されて細分化されています。 「isbn」などの名前空間識別子は、IANA(Internet Assigned Numbers Authority)に登録する必要があります。 この場合、本のURNはurn:isbn:0140386335となります。

これら両方の例はURIの例であり、特定のリソースを参照する識別子です。 しかし、URIが有形の文書やリソースを「参照する」必要がないということを複雑にするリスクがあることを指摘しておく必要があります。 たとえば、「セマンティックWeb」として知られるようになったURIでは、ドキュメントだけでなく、現実世界で見られる抽象概念、概念、エンティティを識別するためにURIが使用されます。 リソース記述フレームワークは、インターネット上でのリソース表現の検索を暗示する必要がないような方法でURIを使用し、実際にはネットワークベースのリソースを示すことさえできません。 ここでの鍵は、URIがリソースを識別することです。

より技術的には、この記事の残りの部分で私が描いているドキュメントは、URIを最初に定義したRFCです。 これらはRFC2396RFC3986(URIの構造の最終化)です。 これらは、インターネットの仕組みと基準を定義するのに役立つ「コメントの要求」と呼ばれる文書です。

統一、リソース、識別子の意味

URIはUniform Resource Identifierの略です。 それは、それが3つの名前の特徴、すなわち、統一性、その指示対象の資源、およびその識別の性質のためにこのように呼ばれます。

例えば、統一性は、各識別子が特定のデザインに従っており、それを統一的にしているという事実です。 つまり、URIは特定の構文に従い、さまざまなプログラムやユーザーによって解析され、理解され、問題のリソースの良いアイデアを提供することができます。 これにより、他のコンテキスト、つまり1つのフォーマットで異種のリソースを識別する能力でそれらを使用できる独自のコンテキストが与えられます。 私はRFC3986を引用します:

均一性にはいくつかの利点があります。 これにより、たとえそのリソースにアクセスするために使用されるメカニズムが異なる場合であっても、異なるタイプのリソース識別子を同じコンテキストで使用することができます。 これは、異なるタイプのリソース識別子にわたる共通の構文規則の統一された意味論的解釈を可能にする。 既存の識別子の使用方法を妨げずに新しいタイプのリソース識別子を導入することができます。 これにより、識別子を多くの異なるコンテキストで再利用することができ、新しいアプリケーションやプロトコルが既存の大規模かつ広く使用されているリソース識別子のセットを活用できるようになります。

はじめにで説明したように、リソースはまさに何でもよい。 私たちは、PDFや画像など、インターネットを介してアクセスするリソースに最も精通しています。 これは実際には少し抽象化することができ、また「今日のI-25のトラフィック」などの「一貫した目的」を果たすリソースを指し示すこともできます。 しかし、導入の最後の段落で述べたように、リソースは必ずしもこの伝統的な意味で常にアクセス可能であるとは限らず、実際には人、書籍、企業、抽象的な概念などの識別子である可能性があります。

したがって、識別子は正確に何ですか? 私は再びRFC3986を引用しています。

… 識別子は、識別されているものとその識別の範囲内の他のすべてのものとを区別するために必要な情報を具体化する。 「識別する」および「識別する」という用語の使用は、その目的がどのように達成されたか(名前、住所、またはコンテキストなど)にかかわらず、あるリソースを他のすべてのリソースと区別するというこの目的を指します。 …

つまり、識別子は基本的にID参照の形式です。 つまり、指定されたリソースの名前です。 たとえば、あなたの身元は人間のものであり、おそらくあなたの識別子は私のようなあなたの名前です、アッシャー・ウォルフシュタイン(Asher Wolfstein)。 私たちは何かを何らかの名前で呼び出すことができ、それがその識別子になります。 これは、識別子や名前が参照するものを定義しているとは想定できないことを意味します。 例えば、本シリーズのDuneのHouse Atreidesは、実際の単一の家または本拠地を必ずしも特定するのではなく、個々のグループ全体を特定するものではありません。 また、前述したように、リソースは必ずしもインターネット上で「アクセス可能」であるとは限らないため、識別子にアクセスする意思や意思を持たずに識別子を定義することができます。 このようにして、数字0または赤色の識別子を作成することができました。 あなたはあなたのウェブブラウザ上の赤い色に “アクセス”しません!

グローバル性と「エンドユーザコンテキスト」

URIは、通常、参照しているリソースのすべての識別子を終了することを意味します。 これは、URIがURIを理解するための追加のコンテキストがないことを意味します。 たとえば、URI “http://wunk.me/”は私のブログの私のホームページを識別します。あなたがアクセスする方法は関係なく、私のホームページを識別します。 あなたはそれにアクセスするために使用するものに応じて異なる結果を得ません、それは追加の文脈の例です。

しかし、特定のURIの解釈の結果は、エンドユーザのコンテキストに依存する可能性があります。 RFCは、エンドユーザ自身のホストマシンを指すURI “http://localhost/”を例として挙げています。

… たとえば、 “http://localhost/”は、 “localhost”に対応するネットワークインタフェースが各エンドユーザごとに異なる場合でも、その参照のすべてのユーザに対して同じ解釈をします。 …

この場合、localhostは、ユーザーが実行しているローカルホストマシンを示すためのものであり、世界中の特定の特定のコンピュータではありません。 同様に、この仕様では、「エンドユーザーのローカルコンテキストに関連してリソースを識別するURIは、コンテキスト自体がリソースの定義上の側面である場合にのみ使用する必要があります。 “file://”で始まるファイルシステムURIの場合、これを見ることができます。このタイプのURIは、ユーザのマシン上の特定のフォルダ内のファイルを識別し、非常に定義はユーザのマシンのファイルシステムに依存します。 仕様が示唆しているように、このタイプのURIをユーザのマシンにインストールするときにヘルプマニュアルに使用するかもしれませんが、他のドキュメントを参照するためのウェブサイトにあるオンラインヘルプマニュアルでは使用しません ウェブサイト上で

ユニフォームリソース識別子(URI)の構造

URI仕様は、URIの解析と理解のための「一般的な構文」を提供したいと考えています。 これは、異なるスキームのURIであるURIの特定の “タイプ”(下記参照)が、それ自身の構文やフォーマットをさらに制限または再定義する可能性があることを意味しますが、一般的にガイドラインと一般的なフォーマットは同じです。 たとえば、mailto:test@test.comのURIとftp://ftp.test.com/remotefolderというURIは、2つの異なるスキームの2つの異なるフォーマットですが、基本的な一般的なフォーマットに依存しています。

URIの一般的な構文は、次の文字列で指定します。

これはURIに関する優れた記事を持っているウィキペディアのものです。 アイデアは、各単語がそのURIの特定のコンポーネントの名前を示し、括弧が必ずしも存在しないかもしれないネストされたコンポーネントを示すということです。 たとえば、すべてのWebページにアクセスするためにuser:passwordコンポーネントを用意する必要はありません。

予約済みの文字

上記の一般的な構文からわかるように、一般的にはURIが使用する特定の文字があり、特定のURIを実装しているシステムは使用を避けるべきです。 これらの文字はRFCで次のように定義されています。

引用符で囲まれた上記のものは、スキームの書式で別途指定されていない限り、URIで使用すべきではありません。 また、慣習的には、あなたのURI内のスペースが避けるべきです。そうすることで、別のURIまたは別のURIを示すことができます。 これらの文字をパスコンポーネントなどのURIのコンポーネントで使用する必要がある場合は、その文字の「パーセント符号化」表現を使用します。

符号化率

URIに解読するアルゴリズムが予約文字を侵害することなく使用できる文字をURIに含める方法は、パーセント符号化によるものです。 RFCを引用するには:

パーセンテージエンコーディングメカニズムは、オクテットの対応する文字が許可されたセットの外にあるか、コンポーネントの区切り文字として、またはその内部で使用されている場合、コンポーネントのデータオクテットを表すために使用されます。

これは通常、次の形式をとります。

これが変換するのは、16進数字(0-F)と別の16進数字(0-F)が続くパーセント記号です。 16進数は、0〜9の数字とA〜Fの数字を使用する16進数のシステムです。 16進数の詳細は、このチュートリアルのチュートリアルを参照してください。

本質的には、US-ASCIIでエンコードされた文字を完全に入力するのではなく、16進数で指定します。 たとえば、US-ASCIIでバイナリシーケンス “00100000”で表されるスペースを表すには、 “%20″を使用します。

構文とコンポーネント

RFCは、実際には以下のようにURIの一般的な構文を定義しています。

ここでは、[//[user[:password]@]host[:port]]が実際にURIの “hier-part”(階層)に対応することがわかります。 階層部分は、権限コンポーネントとパスコンポーネントで構成されています。 2つの二重スラッシュがない場合は、権限部分が省略されており、パスコンポーネントのみに依存していることがわかります。

権限

RFCは、以下を使用してURIのauthority要素を定義します。

権限要素は、「命名権限」に委任されているため、authority要素と呼ばれます。 たとえば、インターネットの大部分については、145.23.43.78などのサーバーに対処するための不思議で難解な番号に頼るのではなく、ドメイン名を使用します。 ドメイン名は、この場合、ドメイン名をカーテンの背後にあるネットワークアドレスに変換するさまざまな方法を採用しているICANN(Internet Corporation for Assigned Names and Numbers)によって管理されています。 ICANNは、そのURIを解決する権限としてそれらを使用してURIの解決を指示する「権限」である。 つまり、私のURI http://wunk.me/home/では、「wunk.me」はURIの権限要素であり、URIが解決されると、authority要素の解決はICANNまたは適切なものになります (つまり、この場合はアクセスされます)。

インターネット上の多くのサービスは、ウェブページ文書などのようなネットワーク上でリソースを「提供」できるようにする特別なコンピュータのセットアップであるサーバーによって運営されています。 だから、多くの当局にとっては、登録された名前がどこに通じるのか、そのサービスにアクセスするポート、そしていつどのユーザーがそのポートにアクセスしているのかという問題です。

たとえば、私がドメイン名wunk.meのユーザ “asher”であって、サーバポート80にアクセスしている(ポートWebサーバが一般的に使用している)のなら、私のURIに私の権限要素として次のものを使用します: “asher@wunk.me:80 “私のURIは完全に” http://asher@wunk.me:80/home/”と読むことができます。

典拠要素がURIに存在する場合、それは二重スラッシュ “//”で始まり、次のスラッシュ、疑問符、または数字記号、またはURIの終わりで終了します。 権限がURIに存在しない場合、二重スラッシュの先例は必要ありません。

ですから、wikipediaで提供されている構文で構築するには、URIを次のように読むことができます:

階層

RFC3986は、URIフォーマットの「階層」に言及しています。

URI構文は階層的に構成され、コンポーネントは左から右に向かって重要度が減少する順にリストされます。

これは、スキーム、権限(HTTPなどのドメイン名など)、ファイルなどの特定のアイテムへのパスなど、URIで一般的に最も重要な記述を定義することになります。インターネット上では、ファイルやリソースは階層型に整理されていることが多く、その仕組みに応じてURIを活用することができます。ウェブのハイパーテキスト転送プロトコル(HTTP)やファイル転送プロトコル(FTP)などの多くのポピュラーなURI形式は抽象化されたファイルシステムの仕組みに基づいています。つまり、各リソースは、フォルダ内に閉じ込められている可能性があります。一般に、ほとんどのファイルシステムでは、「..」(1つのフォルダを上に移動)などのインジケータを使用してファイル構造を上下にトレースできます。これらの種類のURIは、パスコンポーネントで同じです。これは、URIがドキュメントやリソースのシステム内で相対的である可能性があることを意味します。すなわち、ウェブサイト内の1つのHTMLページは、「../about/index.html」を参照することができ、これは本質的に「1つのフォルダを上に移動し、約フォルダに入り、index.htmlにアクセスする」

これが重要な理由は、経路コンポーネントをスキームや権限などのより基本的なコンポーネントにいくらか混合して一致させることができるからです。 これは、http://wunk.me/about/asher.htmlなどのWebブラウザで表示するためにHTTPを使用してWebページにアクセスする可能性があることを意味しますが、 ftp://ftp.wunk.me/about/asher.html。 file://home/asher/wunk/about/asher.htmlを使用して、ローカルコンピュータ上でアクセスすることもできます。 スキームと権限が変更されている間もパスのコンポーネントは変わりません。

これらの場合、URIのスキームと特定のフォーマットに応じて、特定性の階層を区別するのに役立つ特定の文字があります: “/”、 “?” と “#”。 これらの正確な文字の使い方は、URIの形式とスキームによって異なりますが、これらの文字はリソースシステム内の階層関係を区別するのに役立つURI全体で共通です。 たとえば、 “/”文字は、特定のフォルダまたはディレクトリがアクセスされていることを示すために、file、ftp、およびhttpスキームで便利です。

特定のコンポーネント

左から順に、URIの特定の各コンポーネントを調べることができます。

スキーム

RFCでは、スキームの構文は次のように定義されています。

これは、基本的にはスキームが文字で始まり、その後に別の文字、数字、または文字「+」、「 – 」または「.」が続きます。 上記で定義されていないが、他の定義ではさらに上に、URIのスキームの後にコロン “:”が続きます。

URIのスキームコンポーネントは、そのスキーム内の識別子を割り当てるための仕様を参照することに注意してください。 これは注意することが重要であり、スキームがプロトコル(HTTPなど)と同じ名前を共有する可能性があることを意味しますが、プロトコルと同等のものであるとは限りません。 URIに関するスキームは、 “urn”スキームがどのようにフォーマットを変更するか(以下に示すように)URIのフォーマットを定義する。 これは、スキーム名が、その検索方法で使用されるプロトコルと同じでない可能性があることを意味します。 mailto:で始まるURIは、電子メールアドレスを示すかもしれないが、その電子メールアドレスにアクセスするためのmailtoプロトコルを定義していない。

ユーザーとパスワード

これはURIの典拠要素の一部であり、問題のサービスに自分自身を認証する手段として提供されます。 このコンポーネントのパスワード部分は非難されています。これは、使用することが意図されていないことを意味します。非常に安全ではありません(オープンでパスワードを出力するものはどれも安全です)。 これは、ユーザーアカウントで動作するサービスやサーバーに役立ちます。 それには “@”予約文字が続きます。

ホスト

これは、URIの典拠要素の主要部分です。 ホストは、IPv4アドレス(この例:10.0.0.1など)、IPv4アドレスに解決されるドメイン名、IPv6アドレス(角括弧内にある必要があります)など、さまざまな形式にすることができます。 主な仕事は、URIを特定のリソースにさらに解決できるサービスまたはサーバーを指すことです。 特定のネットワークリソースにマップされていないURIの場合、ホスト名はURNの多く(以下を参照)として機能したり、URIの一般的な使用方法を説明しているドキュメントを指したりする可能性があります。

ポート

これは、URIの典拠要素のオプションの部分であり、存在する場合はコロンで始まります。 最近のほとんどのコンピュータシステムは、ポートと呼ばれるものを実装することによって、ネットワークを介してお互いに話し合います。 ポートは、本質的に、2つのエンティティが通信する「チャネル」の識別情報です。 特定のフロント・レンジのラジオ局を聞くために私のラジオにチャンネル94.3にダイヤルするのと同じように、コンピュータ上のプログラムはコンピュータを特定のポート(例えばポート8080)にバインドし、コンピュータ それはポート8080がそのプログラムにリダイレクトされることを意図しています。 たとえば、コンピュータ上でWebサーバーを実行しているとします。 私はそれをポート80にバインドします。http:// mycomputer:80 /を要求するコンピュータは、コンピュータのポート80にHTTP GET要求を送信します。 ポート80はWebサーバーのデフォルトポートであり、Webブラウザーでドメイン名を指定すると、「http」スキームとポート80を意味すると想定されることがよくあります。

その他のデフォルトのポートで実行されるサービス。 特定のプロトコルはデフォルトと異なるポート番号を持ち、これらのサービスを実行するサーバープログラムは、既定ではこれらのポートにバインドされることがよくあります。 また、MUDやMUCKなどの特殊なサービス用のサーバープログラムを237911などのカスタムポートで実行することもできます。サーバーでこのようなMUDを実行していたとします。telnet://wunk.me:237911 /。

パス

パスコンポーネントには、通常、ファイルシステムのサブフォルダにあるファイルなどの階層情報が含まれています。 そのため、URI仕様の階層要素の一部です。 パスは必ずしも階層的である必要はなく、特定のファイルへのパスである必要はありません。 しかし、通常は、左から右へ、最も重要な/最小のものから最も重要なもの/最も重要でないものまでのパス情報フォームを読みます。 それは、あなたが特定のものを指し示すまで、経路の構成要素が特異性を低下させることです。 パスとクエリコンポーネント(下記参照)を組み合わせると、特定のURIが得られます。

パスは、最初の疑問符または数字記号、またはURIの終わりで終了します。 URIに典拠要素がある場合、パス要素はスラッシュで始まらなければならず、空でなければなりません。 典拠要素がURIにない場合、パスは二重スラッシュで始めることはできません。 URI参照が相対パス参照である場合、最初のパスセグメントにはコロン文字を含めることはできません。 コロンが必要な場合は、エンコーディングのパーセントが有効であることがわかります。

クエリ

これは、物事がURIに関してもう少し面白くなる場所です。 クエリは、基本的にURIにエンコードされた非階層情報です。 この情報はサービスに渡されます。通常、サービスを処理して特定のものをレンダリングします。

Googleを例に取る。 Googleに検索を入力すると、次のURLに移動します。

https://www.google.com/search?q=your+search+here

ご覧のとおり、httpsがスキーム、www.google.comは権限(ホスト)、/ searchはパス、それは私たちのリソースです。 疑問符の後のすべてがクエリです。 検索語は情報構造の階層的な部分ではなく、代わりに/ searchリソースに渡すパラメータです。 「q =your+search+here」は、Googleドメインの検索リソースによって処理され、ブラウザに表示されるHTMLページが作成されます。

クエリはサービスのパラメータとしてのみ使用する必要はなく、識別子に関連する非階層データを表すことができます。 ただし、URLのRFC仕様ではなく、クエリパラメータの書式設定の「標準」があります。 一般に、クエリパラメータは次の形式であることが理解されています。

基本的には、キーに値を複数回割り当てます(したがって、複数の異なるキーに割り当てます)。 アンパサンドは、キーと値のペアのセパレータです。 ただし、これは一般的に受け入れられている概念ですが、サーバーがクエリ値をどのように解釈するかによって、これは石で設定されていません。 さらに、アクセス不能なURI(疑問に思われるかもしれません)のクエリ値は、特定の書式設定の概念を実際に持たないものです。

RFCでは、クエリ値の書式設定について警告されています。

しかし、クエリーコンポーネントはしばしば “key = value”ペアの形で識別情報を運ぶために使用され、頻繁に使用される値は別のURIへの参照であるため、これらの文字のパーセントエンコードを避けることは使い勝手が良い場合があります。

断片

URIのフラグメント識別子コンポーネントは、プライマリリソース内のセカンダリリソース、またはその他の追加の識別情報を間接的に識別する方法です。 リソースURIにコンテキストを持たせたい場合は、これを行う方法です。 フラグメントの前のプライマリURIはプライマリURIであり、フラグメントは「セカンダリ」または従属識別子です。 フラグメントは、プライマリリソースの一部、またはプライマリリソースの表現に関する特定の「ビュー」を参照することができます。 理論的には、プライマリリソースによってさらに定義される他のリソースでもあります。

この識別子は、シャープ記号文字の存在によって示され、URIの終わりで終了します。 それは常にURIの終わりに来ます。

セカンダリリソース識別子としての性質のため、フラグメント識別子は、プライマリリソースに応じて意味的に定義されます。 これは、「プライマリ・リソースに対する検索アクションから生じる可能性のある表現のセットによって定義されます」。 したがって、フラグメントのフォーマットは、取り出した表現のメディアタイプに依存します。必ずしもそのスキーム自体のフォーマットではありません。

フラグメントは、ドキュメントのサブリファレンスの形式、または問題のリソースのクエリとして考えることができます。 URIの一部であるURIの手元にあるリソースにクエリが適用されるのに対し、フラグメントはURIの一部ではなくリソース自体に適用されます。 このフラグメントは、URIの解決に使用されることを意図しています。 そのようなリソースの表現が存在しない場合、フラグメント識別子は未知であるとみなされ、「拘束されない」。 このようにフラグメント識別子は、URIスキームとは独立しています。これは、HTMLなどのドキュメント書式に関連付けられているため、スキームによって再定義できません。

したがって、フラグメント識別子の独自の制限または構造を定義することは、メディアタイプに依存します。 たとえば、HTMLは、HTML文書の “a”(アンカー)要素を指すフラグメントを指定します。 http:schemeは、http:URIがHTML文書だけでなく画像を参照する可能性があるため、これとは何の関係もありません。

ユニフォームリソースロケータ

Uniform Resource Locator(URL)はURIの一種です。 この用語は多くの技術者によって時代遅れになっていると考えられていますが、それでも広く普及しています。 URLは本質的にはURIを構成するものに関してカバーしたものですが、そのスコープは少し異なります。

URLは、あなたが識別しているものがネットワーク、特にインターネット上で到達可能で適用可能であることを指定します。 つまり、URIが識別しているものはすべて、インターネットを介してアクセス可能であり、取得可能であることを意味します。

URLには1つの特殊性があり、それはスキームレスURLまたはプロトコルレスURLです。 これは、権限要素を持つ二重スラッシュで始まるURLですが、スキームが欠落しています。 ウェブブラウザがその特定の種類のURLを見つけると、それは親またはリソースをアクセスしたのと同じスキームを使用してアクセスします。

統一リソース名

Uniform Resource NameまたはURNは、RFC1737およびRFC2141で最初に記述され、定義されました。彼らはRFC8141で現代に向けて更新されました。インターネットの初期の時代には、人々はまだ、すべてのことがうまくいくかどうかと厳密に闘っていました。 URNはもともと一般的なインターネット、さらにはWebの3つの部分のアーキテクチャの1つとして考えられていました。 3つの部分は、URL、URN、およびUniform Resource Characteristics(URC)です。リソースの場所とアクセス方法(URLやFTPなどのプロトコルへのスキームのマッピングを介して)を指定するURLとは対照的に、URNは、グローバルにユニークで永続的な識別子を使用して定義された識別子であると考えられています名前空間。興味のある人たちのために、URCはアイデア段階を過ぎてしまったことはありませんでした。リソース記述フレームワークなどの他のテクノロジが採用されました。

ドメイン名は技術的にURNではありませんが、URNはドメイン名に非常によく似ています。しかし、この類推によって私が意味することは、それぞれが “名前空間”を使用して識別子を指定することです。その識別子は、現在存在していてもいなくてもアクセス可能な永続的なものを指すか、「ポイントする」。それがそれらを永続的にし、その性質によってグローバルにするものです。

たとえば、右から左へドメイン名を読み、特異性が増す順に表示します。たとえば、www.wunk.meは最初に読み込まれ、me名前空間(トップレベルドメイン)、私の名前空間でその特定の名前として覚えている、wwwはwunk.meで実行されている特定のサービスです。左から右へと同様に、urn:isbn:0140386335のように、同じ種類の特異性の高い壷を読むでしょう。最初にisbnの名前空間を特定し、名前空間isbn内で数値コードを特定します。この場合、これはマイケル・エンデの本「The Neverending Story」の壺です。そのURN(URI)を使用して本を実際にプルアップ、検索、アクセスすることはできませんが、いつでも他の名前で存在する可能性のある書式を「識別」することができます:urn:isbn:0140386335 。

この意味では、マイケル・エンデとurn:isbn:0140386335の “The Neverending Story”は同じエンティティの2つの “名前”です。上記のURIに関する情報のコンテキストでは、 “urn:”はURIをフォーマットするための別のスキームであることがわかります。最新バージョンのURN仕様には、qコンポーネントとfコンポーネントを含むURIが後で定義されるいくつかの要素が含まれています(下記参照)。

解決

URLのようなURNは、何らかの解決サービスがあれば “解決”することができます。 解決サービスは、名前空間ID(下記参照)の提供者であってもよく、または図書館のような汎用サービスであってもよい。 たとえば、図書館のURNをアーカイブ内の書籍のリストを指し示すURLに解決するか、またはその書籍がアーカイブ内に存在しない場合は、おそらくオンラインの書籍のリストへのURL 本棚。 同様に、他のURIと同様に、一部のURNは解決可能でも解決可能でもありません。純粋に抽象エンティティを参照する識別子として存在します。

ユニフォームリソース名(URN)の構造

RFC8141は、次のように拡張されたbackus-naur形式を使用してURN構文とフォーマットを定義します。

これをもっと以前のように(URIの場合と同じように)展開することができます:

“nid”は名前空間の識別子であり、文字、数字、および ” – “ダッシュ文字を含むことができる。 名前空間固有の文字列 “nss”は、名前空間識別子に従ってフォーマットされた文字列です。 ネームスペース識別子をURNの「スキーム」と考えるのに対し、NSSはその「スキーム」に固有の形式の特定の識別子です。 たとえば、URN urn:isbn:0140386335では、 “isbn”は名前空間の識別子であり、名前空間固有の文字列は0140386335または10桁の文字列です。

名前空間

urn URI形式の “nid”部分である正式な名前空間は、IANAに登録する必要があります。 名前空間は「正式」または「非公式」である可能性があります。 形式的な名前空間は、実際には “isbn”のような識別子です。 約60の正式なURN名前空間識別子があり、さまざまなトピックと根拠をカバーしています。 一般的な考え方は、ユーザーが「彼らの出版から恩恵を受ける」ということです。 形式的な名前空間はいくつかの方法で制限されていますが、そのほとんどは明白です。 彼らはすでに登録されていることはできません。 “urn-“で始めることはできません。2文字以上の長さでなければなりません(ダッシュ、つまり “ab-“または “xy-“は許されません) 推奨されない理由のために、 “x-“接頭辞で始めることはできません。

「非形式的な」名前空間は単なる数字であり、表面検査の目的を裏切らない。 非公式の名前空間は、 “urn-0123456789″または “urn-#”の形式で “urn-“形式で存在します。 この番号は、IANAによって先着順に割り当てられます。

廃止予定のURNの種類は、 “x-“で始まる実験的なURN名前空間です。 これはRFC8141で推奨されておらず、代わりにurn:example namespaceを使用することをお勧めします。

正式、非公式、および実験的なすべての名前空間は、特定のリソースの識別子としてURIが期待される場所であればどこでも使用できます。

名前空間固有の文字列

名前空間固有の文字列、またはURN仕様の「nss」部分は、問題の名前空間によって決まります。 実行中の例では、10桁の数字が “isbn”名前空間の名前空間固有の文字列を構成します。 他の名前空間には、名前空間固有の文字列で許される幅広い形式とさまざまな形式があります。 NSSには、ASCII文字、数字、および多くの句読点やその他の特殊文字が含まれる場合があります。 上のようなURIの場合と同様に、NSSで許可されていない文字はパーセント符号化されます(上記参照)。 RFC8141では、NSSでスラッシュ文字「/」を含めることができる文字数が増加しました。 このスラッシュ文字は、パス要素のように必ずしも階層データを示すとは限りません。スラッシュを使用する非URNシステムの名前を単純に含めることができます。

Q成分

RFC8141は、 “q要素”として知られているものを追加しました。 これは、上記のような一般的なURIのクエリコンポーネントに似ています。 実際には、URNが別のURIに解決可能な場合など、q要素をURIのクエリにコピーすることになります。 URN識別子をq要素に依存させることはできません。つまり、識別子は、それが表すものをカプセル化するためのq要素なしで独立して立つことができなければなりません。 これは、RFCが言いたいことです:

URNのqコンポーネントはURIクエリコンポーネントと同じ構文を持ちますが、 “?”ではなく “?”で導入されています。 単独で。 ロケータであるURIに解決される可能性のあるURNについては、qコンポーネントのセマンティクスは、そのURIのクエリコンポーネントのセマンティクスと同じです。 したがって、qコンポーネントを持つURNのロケータであるURIを返すURNリゾルバは、qコンポーネントをURNからURIのクエリコンポーネントにコピーすることによってこれを行います。

ただし、一般的な構文のURIのクエリコンポーネントとの1つの違いは、RFC:

スラッシュ( “/”)と疑問符( “?”)は、qコンポーネント内のデータを表します。 ASCII範囲外の文字はパーセント符号化されなければならない

パーセントエンコーディングの詳細については、上の一般的なURI構文のセクションを参照してください。

F成分

f-成分は、一般的な構文URIのフラグメント成分によく似ています。 実際、URNがURIに解決する場合、fコンポーネントはそのURIのフラグメントとして適用できます。 フラグメントコンポーネントと同様に、fコンポーネントは、URNによって識別されるリソースの構成部分を参照するために使用されます。 たとえば、本のURNは、fコンポーネントを使用して章を分割することがあります。 のような、urn:isbn:0140386335#chapter5、第5章を参照するにはNeveyrending Story。

一般的な構文URIのフラグメント成分に対するf成分の類似性に関するRFCを引用するために:

URNのfコンポーネントは、URIフラグメントコンポーネントと同じ構文を持ちます。 fコンポーネントを含むURNが、指定されたリソースに関連付けられたロケータである単一のURIに解決された場合、URNのfコンポーネントは、そのURIのフラグメントとして(通常はクライアントによって)適用されます。 URNがロケータであるURIに解決されない場合、f-componentの解釈はこの仕様では定義されていません。 したがって、ロケータであるURIに解決される可能性のあるURNの場合、fコンポーネントのセマンティクスは、そのリソースのフラグメントのセマンティクスと同じです。

R成分

“r要素”は現在標準化されていませんが、URNの “リゾルバ”に渡すパラメータが含まれています。 r要素の使用法は、その形式と使用法がよりよく理解されるまで遅らせるべきですが、特定のURNの検索表現を制御するのではなく、rコンポーネントを使用してリゾルバを制御することが考えられます。 これは難読化されて聞こえるが、幸いなことにRFC8141が例を挙げると、私は引用している:

書籍の物理的なコピーを検索する優先国を選択するために、解決サービス(例えば、ISO alpha-2国コード…)にパラメータを渡す仮説的な例を考えてみましょう。 これはおそらく、rコンポーネントに国コードを指定することで実現できます。その結果、次のようなURNが生成されます。

urn:example:foo-bar-baz-qux?+ CCResolve:cc = uk

上記はrコンポーネントの意図の一般的な説明と実例として機能するはずですが、登録時に特定のURN名前空間に関連する解決メカニズムとの関係を含め、多くの未解決の問題があります。 したがって、セマンティクスが標準化される前に、r-componentsをURNに使用すべきではない(SHOULD NOT)。

その他のURIとURNスキーム

今日使用されている一般的な構文と “urn:”スキームだけでなく、URN / URIスキームが増えています。 これらの他のURIスキームには、tag :, info :, ni:などがあり、URLとは対照的に一般的にURNです。 “tag:” URNはYAMLでよく使用されますが、 “info:”は “urn:”と非常に似ていますが、他のニーズに対応するスキームです。 “info:”は2010年に廃止され、ユーザーは必要に応じて他のフォーマットを採用することを推奨しました。

結論

そのため、URI(Uniform Resource Identifiers)は、上で定義した特定の「リソース」を「識別する」文字列です。 URIは、特定のリソースにアタッチまたはアクセスできるという意味で「解決可能」である場合とそうでない場合があり、実際には存在しない可能性のある抽象的なものを示す場合もあります。 Uniform Resource Locatorは、ネットワーク上でアクセス可能な実際のリソースを「見つける」ために、インターネットやWebブラウザで使用されるURIの例です。 URLという用語は、技術者によって廃止されましたが、広く普及しています。 ユニフォームリソース名は、リソースを永続的に識別するが、必ずしもそのリソースの「ロケータ」であるとは限らない。 たとえば、Dewey Decimal表記、または本のISBN番号を持ち、それをurn:isbn:0140386335のようなURNにカプセル化することができます。 このURNは、特定のWebサイト、ネットワーク、図書館などに存在するかどうかに関係なく、特定の書籍を参照します。

URIを使って、本、ビデオ、サイト、ゲームからインターネット上で必要なものすべてを参照して見つけることができます。 URIがなければ、私たちは依然として特定のクライアントやメソッドを使って特定のものにアクセスする特定の厄介な方法に悩まされていました。 今、それは簡単です:http://wunk.me/

どうもありがとう!

あなたが私の執筆を感謝するなら、私のパトロンを通して私を支えてください。( パトロン )

毎月コミットメントがあなたの路地を上回っていない場合は、いつでも「コーヒーを買う」ことができます。

photo credit: tedxblanquerna TEDxBlanquerna via photopin (license)

Liked it? Take a second to support kadar on Patreon!

あわせて読みたい

コメントを残す

%d人のブロガーが「いいね」をつけました。