URLで大文字と小文字が区別されるのはなぜですか？

私の質問：URLが最初に設計されたとき、大文字と小文字の区別が機能になったのはなぜですか？私（つまり、素人）には、不必要なエラーを防ぎ、すでに複雑なテキスト文字列を単純化するために、大文字と小文字を区別しないことが好ましいと思われるため、これを尋ねます。

また、大文字と小文字を区別するURLを使用することに本当の目的/利点はありますか（大文字と小文字に関係なく同じページを指すURLの大部分とは対照的ですか）？

たとえば、ウィキペディアは、大文字と小文字を区別するWebサイトです（最初の文字を除く）。

https://en.wikipedia.org/wiki/St ck_Exchangeは DOAです。

URLで大文字と小文字が区別されないのはなぜですか？

私はそれが挑発的な（そして「悪魔の擁護者」）タイプの修辞的な質問のように見えるかもしれないことを理解していますが、私はそれを考慮することは有用だと思います。HTTPの設計では、一般に「Webブラウザ」と呼ばれる「クライアント」が「Webサーバー」にデータを要求します。

リリースされている多くの異なるWebサーバーがあります。Microsoftは、Windows Serverオペレーティングシステム（およびWindows XP Professionalを含むその他）を備えたIISをリリースしました。Unixには、OpenBSDの内部httpd、thttpd、またはlighttpdのような小さな製品は言うまでもなく、nginxやApacheのようなヘビーウェイトがあります。さらに、多くのネットワーク対応デバイスには、ルーター（多くのWi-FiアクセスポイントやDSLモデムを含む）などのネットワーク固有の目的を持つデバイスや、プリンターやネットワーク接続が可能なUPS（バッテリバックアップ式無停電電源装置）。

そのため、「URLで大文字と小文字が区別される理由」という質問は、「WebサーバーがURLを大文字と小文字を区別するのはなぜですか？」そして、実際の答えは次のとおりです。かなり人気のある少なくとも1つのWebサーバーは通常、大文字と小文字を区別しません。（WebサーバーはIISです。）

異なるWebサーバー間で異なる動作をする主な理由は、おそらく簡単さの問題に帰着します。Webサーバーを作成する簡単な方法は、コンピューター/デバイスのオペレーティングシステムがファイルを検索する方法と同じ方法です。多くの場合、Webサーバーは応答を提供するためにファイルを見つけます。Unixはハイエンドコンピューターを中心に設計されているため、Unixは大文字と小文字を許可する望ましい機能を提供しました。Unixは大文字と小文字を異なるものとして扱うことにしました。それは簡単で自然なことです。Windowsには、すでに作成されたソフトウェアをサポートしたいという理由から、大文字と小文字を区別しないという歴史があります。この歴史は、単に小文字をサポートしていなかったDOSにまで遡ります。おそらく、メモリの使用量が少なく、性能の低いコンピューターで物事を単純化するための努力です。これらのオペレーティングシステムは異なるため、結果として、単純に設計された（初期バージョンの）Webサーバーは同じ違いを反映します。

ここで、すべての背景を踏まえて、特定の質問に対する具体的な回答を次に示します。

URLが最初に設計されたとき、なぜ大文字と小文字の区別が機能になったのですか？

何故なの？すべての標準Webサーバーで大文字と小文字が区別されない場合、それはWebサーバーが標準で指定された一連のルールに従っていることを示します。ケースを無視する必要があると言うルールはまったくありませんでした。ルールがない理由は、そのようなルールが存在する理由がなかったからです。なぜ不要なルールを作成するのが面倒ですか？

私（つまり、素人）には、不必要なエラーを防ぎ、すでに複雑なテキスト文字列を単純化するために、大文字と小文字を区別しないことが好ましいと思われるため、これを尋ねます。

URLは、マシンが処理するために設計されました。ユーザーは完全なURLをアドレスバーに入力できますが、これは意図した設計の主要部分ではありませんでした。意図した設計は、人々がハイパーリンクをたどる（「クリックする」）ことです。平均的な素人がそうしている場合、目に見えないURLが単純か複雑かは本当に気にしません。

また、大文字と小文字を区別するURLを使用することに本当の目的/利点はありますか（大文字と小文字に関係なく同じページを指すURLの大部分とは対照的ですか）？

William Hayの答えの5番目のポイントは、1つの技術的利点に言及しています：URLはWebブラウザーがWebサーバーに少しの情報を送信する効果的な方法であり、制限が少ない場合により多くの情報を含めることができるため、大文字と小文字の区別制限により、含めることができる情報量が減少します。

ただし、多くの場合、大文字と小文字の区別に大きな魅力的な利点はありません。これは、IISが通常は気にしないという事実によって証明されています。

要約すると、最も説得力のある理由は、特にUnixなどの大文字と小文字を区別するプラットフォームでWebサーバーソフトウェアを設計した人にとっては、単純であることです。（HTTPはUnixの元の設計に影響を与えるものではありませんでした。UnixはHTTPよりも著しく古いためです。）

URLは大文字と小文字を区別せず、その一部のみです。
たとえば、URL https://google.comでは大文字と小文字が区別されません。

参照してRFC 3986 -統一資源識別子（URI）：一般的な構文

まず、Wikipediaから、URLは次のようになります。

 scheme:[//host[:port]][/]path[?query][#fragment]

（user:password面白くなく、めったに使用されないため、この部分を削除しました）

• scheme：

スキームは大文字と小文字を区別しません

• host：

ホストサブコンポーネントは大文字と小文字を区別しません。

• path：

パスコンポーネントにはデータが含まれています...

• query：

クエリコンポーネントには、非階層データが含まれています...

• fragment：

個々のメディアタイプは、さまざまなタイプのサブセット、ビュー、または外部参照を指定するためのフラグメント識別子構文内の独自の制限または構造を定義できます

したがって、schemeand hostは大文字と小文字を区別しません。
URLの残りの部分では大文字と小文字が区別されます。

path大文字と小文字が区別されるのはなぜですか？

これが主な質問のようです。文書化されていない場合、「なぜ」行われたか
を答えることは困難ですが、非常に良い推測ができます。データに 重点を置いて、仕様から非常に具体的な引用を選びました。 もう一度URLを見てみましょう。

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• 場所-場所には標準形式があり、大文字と小文字は区別されません。どうして？おそらく、何千ものバリアントを購入することなくドメイン名を購入できるでしょう。

• データ-データはターゲットサーバーによって使用され、アプリケーションはその意味を選択できます。データの大文字と小文字を区別しないことは意味がありません。アプリケーションにはさらにオプションが必要です。仕様で大文字と小文字を区別しないように定義すると、これらのオプションが制限されます。
  これは、HTTPSの便利な区別でもあります。データは暗号化されますが、ホストは表示されます。

便利ですか？

キャッシングと正規URLに関しては、大文字と小文字の区別に落とし穴がありますが、確かに便利です。いくつかの例：

• データURIで使用されるBase64。
• サイトは、URLにBase64データをエンコードできます。例：http : //tryroslyn.azurewebsites.net/#f : r / A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgA4A
• URL短縮サービス大文字と小文字の区別を利用：/a5Bとは異なる場合があります/a5b
• あなたが述べたように、ウィキペディアは「エイズ」と「エイズ」を区別できます。

シンプル。OSは大文字と小文字を区別します。通常、Webサーバーは、ある時点でファイルシステムにアクセスする必要がある場合を除き、気にしません。これは、Linuxおよび他のUnixベースのオペレーティングシステムがファイルシステムのルールを強制する場所であり、大文字と小文字の区別が主要な部分です。これが、IISが大文字と小文字を区別したことがない理由です。Windowsでは大文字と小文字が区別されなかったためです。

[更新]

私が述べたように、URLがファイルシステムと何らかの関係を持っているかどうかについて、コメントには（削除されたために）いくつかの強い議論がありました。これらの議論は白熱しています。関係がないと信じることは非常に近視眼的です。絶対にあります！さらに説明させてください。

一般に、アプリケーションプログラマはシステム内部プログラマではありません。私はin辱されていません。これらは2つの異なる分野であり、アプリケーションがOSを単に呼び出すことができる場合、アプリケーションを記述するためにシステム内部の知識は必要ありません。アプリケーションプログラマはシステム内部プログラマではないため、OSサービスをバイパスすることはできません。これは、これらが2つの別々のキャンプであり、めったに交差しないためです。アプリケーションは、OSサービスを原則として使用するように作成されています。もちろん、いくつかの例外はまれです。

Webサーバーが登場し始めた頃、アプリケーション開発者はOSサービスをバイパスしようとしませんでした。これにはいくつかの理由がありました。1つは、必要ではありませんでした。2つ目は、アプリケーションプログラマは一般にOSサービスをバイパスする方法を知りませんでした。3つ目は、ほとんどのOSが非常に安定して堅牢であるか、非常にシンプルで軽量でコストに見合わないということです。

初期のWebサーバーは、DEC VAX / VMSサーバーなどの高価なコンピューターや、メインフレームまたはミッドフレームコンピューター上のその日のUnix（BerkeleyとUltrixなど）で実行され、その後すぐに実行されたことに留意してくださいPCやWindows 3.1などの軽量コンピューター。1997/8年にGoogleのような最新の検索エンジンが登場し始めたとき、WindowsはWindows NTに移行し、NovellやLinuxなどの他のOSもWebサーバーを実行し始めました。Apacheが主要なWebサーバーでしたが、IISやO'Reillyなど、他にも非常に人気があったものがありました。当時は、OSサービスをバイパスしていませんでした。今日でもWebサーバーはどれも実行していない可能性があります。

初期のWebサーバーは非常にシンプルでした。彼らはまだ今日です。ハードドライブに存在するHTTPリクエストを介してリソースに対して行われたリクエストは、OSファイルシステムを介してWebサーバーによって行われました。

ファイルシステムはかなり単純なメカニズムです。ファイルへのアクセス要求が行われると、そのファイルが存在する場合、要求は許可サブシステムに渡され、許可される場合、元の要求は満たされます。リソースが存在しないか、許可されていない場合、システムによって例外がスローされます。アプリケーションが要求を行うと、トリガーが設定され、アプリケーションが待機します。要求に応答すると、トリガーがスローされ、アプリケーションが要求応答を処理します。今日でもそのように機能します。アプリケーションは、要求が満たされたことを確認した場合、続行し、失敗した場合、コード内でエラー状態を実行するか、処理されない場合は終了します。シンプル。

Webサーバーの場合、パス/ファイルのURL要求が行われたと仮定すると、WebサーバーはURL要求（URI）のパス/ファイル部分を取得し、ファイルシステムに要求を行い、それが満たされるまたは例外をスローします。次に、Webサーバーが応答を処理します。たとえば、要求されたパスとファイルが見つかり、認証サブシステムによってアクセスが許可された場合、WebサーバーはそのI / O要求を通常どおり処理します。ファイルシステムが例外をスローした場合、ファイルが見つからない場合はWebサーバーは404エラーを返し、理由コードが許可されていない場合は403 Forbiddenを返します。

一部のOSでは大文字と小文字が区別され、このタイプのファイルシステムは完全に一致する必要があるため、Webサーバーに要求されるパス/ファイルはハードドライブに存在するものと正確に一致する必要があります。その理由は簡単です。Webサーバーは、意味を推測しません。プログラミングされていないコンピュータはそうしません。Webサーバーは、要求を受け取ったときに処理するだけです。ファイルシステムに直接渡されるURL要求のパス/ファイル部分がハードドライブ上のものと一致しない場合、ファイルシステムは例外をスローし、Webサーバーは404 Not Foundエラーを返します。

それは本当にその単純な人々です。それはロケット科学ではありません。URLのパス/ファイル部分とファイルシステムの間には絶対的な関係があります。

1. URLは、UNIFORMリソースロケーターであると主張し、Webより前のリソースを指すことができます。これらの一部は大文字と小文字が区別され（たとえば、多くのftpサーバー）、URLは合理的に直感的な方法でこれらのリソースを表すことができる必要があります。

2. 大文字と小文字を区別しない場合、一致を検索するときに（OSまたはそれ以上で）より多くの作業が必要です。

3. 大文字と小文字を区別するようにURLを定義すると、個々のサーバーは必要に応じて大文字と小文字を区別しないようにURLを実装できます。その逆は当てはまりません。

4. ケース非感受性は、国際的な文脈で非自明なことができます： https://en.wikipedia.org/wiki/Dotted_and_dotless_I。また、RFC1738では、エンコードされていても文字セットを指定していなければ、ASCII範囲外の文字を使用できました。これは、WORLDワイドウェブと呼ばれるものにとって非常に重要です。大文字と小文字を区別しないURLを定義すると、バグの可能性が広がります。

5. 多数のデータをURI（Data URIなど）にパックしようとしている場合、大文字と小文字が区別される場合はさらにパックできます。

私はブログから「何か新しいことがあるのはなぜか」という形式の質問に近づいてくるという習慣を古いものから盗みました。「もしそうでなければ、世界はどのようなものになるでしょうか？」

たとえば、オフィスにいるときに電話でドキュメントファイルを読むことができるように、フォルダからドキュメントファイルを提供するようにWebサーバーをセットアップしたとします。さて、マイドキュメントフォルダに、私は、3つのファイルを持っているtodo.txt、ToDo.txtとTODO.TXT（私は知っているが、私はファイルを作ったとき、それは私には意味を成していました）。

これらのファイルにアクセスするために、どのURLを使用できるようにしますか？を使用して、直感的な方法でそれらにアクセスしたいと思いますhttp://www.example.com/docs/filename。

アドレス帳に連絡先を追加できるスクリプトがあるとします。これはWebでも実行できます。それはどのようにパラメータを取るべきですか？まあ、私は好き、それを使用したいです：http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly。しかし、ケースごとに名前を指定する方法がない場合、どうすればいいですか？

CatとCAT、TextとTEXT、latexとLaTeXのWikiページをどのように区別しますか？ページの曖昧さをなくすと思いますが、私が求めたものを手に入れることを好みます。

とにかく、それは間違った質問に答えているように感じます。

私があなたが本当に求めていたと思う質問は、「なぜウェブサーバーは、単にケースの違いのために、彼らが人生をより簡単にするために設計されたコンピュータであり、少なくとも最も明白なケースの違いを見つけることができるのですか？入力したURLは機能しますか？」

これに対する答えは、一部のサイトはこれを行っていますが（さらに良いことに、他のタイプミスもチェックしています）、Webサーバーのデフォルトの404エラーページを変更する価値があるとは誰も考えていません...

上記の答えは正しいですが、良いです。さらにポイントを追加したいと思います。

よりよく理解するには、Unix（Linux）とWindowsサーバーの基本的な違いを理解する必要があります。Unixは大文字と小文字を区別し、Windowsは大文字と小文字を区別しないOSです。

HTTPプロトコルは、1990年頃に進化または実装が開始されました。HTTPプロトコルは、CERN研究所で働くエンジニアによって設計されました。当時の科学者のほとんどは、WindowsではなくUnixマシンを使用していました。

ほとんどの科学者はUnixに精通していたため、Unixスタイルのファイルシステムに影響されていた可能性があります。

Windowsサーバーは2000年以降にリリースされました。Windowsサーバーが普及するかなり前に、HTTPプロトコルは十分に成熟し、仕様は完全でした。

これが理由かもしれません。

「なぜこのように設計されたのか」をどのように読むべきでしょうか？質問？あなたは意思決定プロセスの歴史的に正確な説明を求めていますか、それとも「だれかがこのように設計するのでしょうか？」と尋ねていますか？

歴史的に正確なアカウントを取得することはほとんど不可能です。時には、標準化委員会で決定が下されると、議論がどのように行われたかについてのドキュメンタリートレイルがありますが、Webの初期には、数人の個人によって急いで決定が行われました-この場合は、おそらくTimBL自身によって-理論的根拠はほとんどありません書き留められた。しかし、TimBLはURLの設計に間違いを犯したことを認めています-http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-addressを参照してください-mistake.html

初期のURLはファイル名に非常に直接マッピングされ、ファイルは一般的にUnixライクなマシン上にあり、Unixライクなマシンは大文字と小文字を区別するファイル名を持っています。したがって、実装の利便性のためにそのようになったのではないかと推測し、（エンドユーザーの）ユーザビリティも考慮されていませんでした。繰り返しますが、初期の段階では、ユーザーはすべてUnixプログラマーでした。

これは、ドメインを購入した場所とは関係ありません。DNSは大文字と小文字を区別しません。ただし、ホスティングに使用しているサーバー上のファイルシステムは次のとおりです。

これは実際には問題ではなく、* nixホストではかなり一般的です。ページに書くすべてのリンクが正しいことを確認し、問題がないことを確認してください。簡単にするために、リンクの作成時にページの名前を常にすべて小文字にすることをお勧めします。そうすることで、リンクの作成時に名前を再確認する必要がなくなります。

ClosetnocはOSについて正しいです。一部のファイルシステムは、大文字と小文字が異なる同じ名前を異なるファイルとして扱います。

また、大文字と小文字を区別するURLを使用することに本当の目的/利点はありますか（大文字と小文字に関係なく同じページを指すURLの大部分とは対照的ですか）？

はい。重複コンテンツの問題を回避するため。

たとえば、次のURLがある場合：

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

全員がまったく同じコンテンツのまったく同じページを指していた場合、コンテンツが重複することになります。Google検索コンソール（ウェブマスターツール）アカウントをお持ちの場合は、Googleがそのことをお知らせします。

そのような状況にある場合、私が提案することは、すべて小文字のURLを使用し、少なくとも1つの大文字を含むURLを小文字バージョンにリダイレクトすることです。したがって、上記のURLのリストで、すべてのURLを最初のURLにリダイレクトします。

大文字と小文字の区別には価値があります。

26文字があり、それぞれ大文字で入力できる場合は、52文字です。

4文字は、52 * 52 * 52 * 52の組み合わせの可能性があり、7311616の組み合わせに相当します。

文字を大文字にできない場合、組み合わせの量は26 * 26 * 26 * 26 = 456976です

26文字より52文字の組み合わせが14倍以上多いため、データを保存するために、Urlを短くして、より少ないデータ転送でより多くの情報をネットワークに渡すことができます。

これが、https：//www.youtube.com/watch？v = xXxxXxxXなどのURLを使用してyoutubeを表示する理由です。