私のURLはあなたのURLではありません

1996年、Curlプロジェクトの前身であるhttpgetプログラムの作業を始めたとき、最初のURLパーサーを作成しました。 そのとき、このユニバーサルアドレスはURL ：Uniform Resource Locatorと呼ばれていました。 その仕様は、1994年にIETFによって公開されました。 「URL」という略語は、ツールの名前とCurlプロジェクトのインスピレーションの源として使用されました。



「URL」という用語は後に変更されました。 2005年に公開された仕様によると、 URI （Uniform Resource Identifier）と呼ばれるようになりましたが、主なものは保持されていました。オンラインリソースを定義し、このリソースを取得するプロトコルを示す行の構文です。 このRFC 3986仕様で定義されているURLを受け入れるには、curlが必要です。



IRIを説明する関連RFCもありました：国際化リソース識別子。 IRIは基本的にURIと同じですが、IRIでは非ASCII文字を使用できます。



WHATWGコンソーシアムは後に独自のURL仕様を作成し、主にブラウザーに重点を置いてURIとIRIの形式とアイデアをまとめました（これは驚くことではありません）。 述べられている目標の 1つは、「最新の実装に従ってRFC 3986およびRFC 3987を近代化し、それらを段階的に廃止すること」です。 彼らは「URL」という用語の使用に戻りたいと思っており、URIとIRIという用語は状況を単純に混乱させ、人々はまだそれらを理解していない（またはこれらの用語が存在することさえ知らない）ことを正しく述べています。



WHATWG仕様は古き良きブラウザのマントラの精神に基づいて書かれています。ユーザーに対して可能な限り寛大になるように、常に意味を推測して裏返し、それを実行しようとします。 しかし、それと同時に、 ポステルの法則がビジネスへの最善のアプローチではないことを私たちは皆知っています。 実際、これは、仕様でURLに使用するスラッシュ、スペース、非ASCII文字が多すぎることを意味します。



私の観点からすると、そのような仕様は構文や形式を詳細に説明していないが、同時に必須の解析アルゴリズムを課しているため、読み読みすることも非常に困難です。 私の声明を確認するには：URLのホスト名の後に、この仕様がエンドポイントについて何と言っているかを見てください。



これらのすべての標準と仕様に加えて、すべてのブラウザーのインターフェースには、ユーザーが任意の種類の面白い行を入力してURLに変換できるアドレスバー（別名）があります。 アドレスバーに「 http://localhost/%41



」と入力すると、パーセンテージセクションは「A」に変換されます（16進数で41はASCIIの大文字Aであるため）が、「 http://localhost/AA



"、そして実際、" /A%20A



"（URLエンコードにスペースを含む）が、発信HTTP GET要求に送信されます。 このことについて話しているのは、この行に入力できるものはすべてURLであると人々がよく考えるからです。



上記は基本的に、どの仕様と標準をまだ使用する必要があるかについての私の（歪んだ）アイデアです。 次に、現実を追加して、URLがURLでない場合にどのような問題が発生するかを見てみましょう。

では、URLとは何ですか？

またはより具体的に-それらをどのように書くのですか？ どの構文を使用していますか？



WHATWG仕様の最大の誤りの1つ（および、この仕様が間違っていると固く信じて現在の形式で反対している理由）は、彼らだけがURLとそれらに定義を与えます。 URLの表示をブラウザ、HTML、およびアドレス行のみに制限します。 もちろん、WHATWGはほとんどすべてのユーザーが使用するブラウザーを代表する大企業によって作成され、URLはこれらのブラウザーで広く使用されていますが、URL自体ははるかに大きな現象です。



WHATWGに存在するURLの概念は、ブラウザ以外では広く受け入れられていません。

コロンスラッシュスラッシュ

プロトコルやネットワークに関する特別な知識を持たない一般の人々にユーザーに尋ねると、URLとは何ですか？ シーケンス "：//"（コロン-スラッシュ-スラッシュ）は回答リストの先頭にあります。 数年前、ブラウザがURLをより完全に表示したとき、それはさらに顕著になりました。 このシーケンスを見ると、これがまさにURLであることがすぐにわかります。



しかし、ユーザーから離れて見て回ってみましょう-世界中にメールクライアント、ターミナルエミュレータ、テキストエディタ、Perlスクリプトなど、URLを認識して操作できるものがたくさんあります。 たとえば、ブラウザでURLを開き、生成されたHTMLでアクティブなリンクに変換します。 これらの膨大な数のスクリプトとプログラムは、「コロンスラッシュスラッシュ」シーケンスを主な機能として使用します。



WHATWG仕様では、少なくとも1つのスラッシュが必要であり、パーサーは任意の数のスラッシュを受け入れなければならないと規定されています。 これは、「 http:/example.com



」と「 http:///////////////example.com



」が完全に適切なオプションであることを意味します。 RFC 3986およびその他の多くの意見は一致しません。 確かに、過去数日間で私が議論した人々のほとんど、たとえばWebで働いている人々でさえ、URLに2つのスラッシュがあると考え、確信しています。 この記事の上記の「URL」リクエストのGoogle画像検索結果のスクリーンショットをよく見てください。



URLには2つのスラッシュがあることを知っています（ただし、ファイルタイプのURL：通常は3つのスラッシュがありますが、今のところこれを無視しましょう）。 1つではありません。 3つではありません。 二。 しかし、WHATWGは同意しません。



「ファイル以外のURLに3つ以上のスラッシュを使用する本当の理由はありますか？」（WHATWGメンバーに迷惑をかけます）



「 事実は、すべてのブラウザがこれを行うということです。 」



ブラウザがそのように実装したので、仕様はこれを述べています。



この文は間違っており、すべてのブラウザがこれを行うわけではないと指摘した後でも、これ以上の説明はありませんでした。 おそらく、この議論のスレッドはあなたにとって非常に有益であると思われるでしょう。



Curlプロジェクトでは、「Location：」ヘッダーにそのようなURLを送り返すサーバーが既に存在し、一部のブラウザーが受け入れるため、それら。 Curlは、他の多くのライブラリおよびコマンドラインツールのほとんどとは異なり、そうではありません。 誰をサポートしますか？

スペース

スペース文字（32 ASCIIコード、0x20 16進コード）をURLの一部にすることはできません。 送信する場合は、URLの一部にする必要がある他の無効な文字と同様に、URLエンコードを使用する必要があります。 URLエンコードは、パーセント記号が前に付いた16進数のバイト値です。 したがって、「％20」はスペースを意味します。 また、URLのテキストをクロールするなどのパーサーは、無効な文字を検出するとURLの最後に到達したことを検出することも意味します。 たとえば、スペース。



ブラウザは通常、リンクが適切に見えるように、アドレス行のすべての20％をスペース文字に変換します。 アドレスをバッファにコピーしてテキストエディタに貼り付けると、％20のようなスペースが表示されます。これは必須です。



これが理由かどうかはわかりませんが、ブラウザはURLの一部としてスペースを受け入れます。たとえば、HTTP応答でリダイレクトを受信します。 これらのURLは、Location：ヘッダーでサーバーからクライアントに渡されます。 問題のないブラウザはURLにスペースを許可し、％20としてエンコードして次のリクエストを送信します。 これにより、curlはリダイレクトされた「URL」のスペースを受け入れます。

非アスキー

ASCII以外の文字を含む言語のURLをサポートすることは、特に非西洋コミュニティにとってはもちろん重要であり、IRI仕様が十分ではなかったことに同意します。 私は個人的には国際化の専門家ではないので、他の人から聞いたことを参考にしています。 しかし、もちろん、非ラテン系アルファベットおよび印刷システムのユーザーは、リソースに「インターネットアドレス」を書き留めて、リンクとして使用できる必要があります。



理想的には、ユーザーに表示するための国際化バージョンと、ネットワーク要求で内部的に使用するためのASCIIバージョンを用意します。



国際的なドメイン名の場合、名前はpunycodeに変換されるため、非ASCIIエンコード名について何も知らない通常のDNSサーバーで読み取ることができます。 URIにはIDNがありません。 IRIとWHATWGによるURL-があります。 SurlはホストIDNをサポートしています。



WHATWGは、URLはUTF-8を使用できるが、URIはASCIIのみであると述べています。 Curlは、パスを指定するアドレスの部分で非ASCII文字を受け入れませんが、発信要求でパーセンテージでエンコードします。 これにより、非ASCII文字が、たとえばWindowsの標準であるUTF-8以外のコードで表示されると、「興味深い」副作用が生じます。



上記で書いたものと同様に、これはサーバーがHTTPヘッダー内の非ASCIIコードを送り返し、ブラウザーが受け入れることを望んでおり、非ブラウザーもそれらを操作する必要があります。

URL標準は存在しません

私は問題や矛盾の完全なリストを提供しようとはしませんでした-ここで私が最近遭遇した困難の一部を紹介します。 もちろん、ある場所で発行された「URL」は、別の場所で「URL」として受け入れられたり、理解されたりするわけではありません。



最近では、curlでさえ公開された仕様に厳密には準拠していません。「Web互換性」のために徐々に品質が低下しています。



単一のURL標準はなく、この方向で作業は行われていません。 WHATWGは、これを行うための真の努力をしているとは考えられません。より広いコミュニティを引き付けるための真剣な試みなしに、仕様を閉じたグループで書いているからです。