URLで大文字と小文字が区別されるのはなぜですか？
私の質問：URLが最初に設計されたとき、大文字と小文字の区別が機能になったのはなぜですか？私（素人）にとっては、不必要なエラーを防ぎ、すでに複雑なテキスト文字列を単純化するために、大文字と小文字を区別しない方が好ましいと思われるため、これを尋ねます。
また、大文字と小文字を区別するURLを使用することに本当の目的/利点があります（大文字と小文字に関係なく同じページを指すURLの大部分とは対照的ですか）。
たとえば、ウィキペディアは、大文字と小文字を区別するWebサイトです（最初の文字を除く）。
URLで大文字と小文字が区別されないのはなぜですか？
私はそれが挑発的な（そして「悪魔の擁護者」）タイプの修辞的な質問のように見えるかもしれないことを理解していますが、私はそれを考慮することは有用だと思います。 HTTPの設計では、一般に「Webブラウザ」と呼ばれる「クライアント」が「Webサーバー」にデータを要求します。
リリースされているWebサーバーは多数あります。 MicrosoftはIISをWindows Serverオペレーティングシステム（およびWindows XP Professionalを含むその他）と共にリリースしました。 Unixには、OpenBSDの内部httpd、thttpd、またはlighttpdのような小規模な製品は言うまでもなく、nginxやApacheのようなヘビーウェイトがあります。さらに、ルーター（多くのWi-Fiアクセスポイント、DSLモデムを含む）やプリンターやその他のデバイスなど、ネットワーク固有の目的を持つデバイスを含む、多くのネットワーク対応デバイスにはデバイスの構成に使用できるWebサーバーが組み込まれていますネットワーク接続が可能な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's answer の5番目の番号のポイントは、1つの技術的利点について言及しています。URLは、WebブラウザーがWebサーバーに少しの情報を送信する効果的な方法であり、制限が少ないため、大文字と小文字の区別の制限により、含めることができる情報の量が減少します。
ただし、多くの場合、大文字と小文字の区別に大きな魅力的な利点はありません。これは、通常IISが気にしないという事実によって証明されます。
要約すると、最も説得力のある理由は、特にUnixのような大文字と小文字を区別するプラットフォームで、Webサーバーソフトウェアを設計した人にとっての単純さです。 （UnixはHTTPよりも著しく古いため、HTTPはUnixの元の設計に影響を与えるものではありませんでした。）
シンプル。 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は、IISやO'Reillyなど非常に人気のあるものもありましたが、支配的なWebサーバーでした。当時は、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のパス/ファイル部分とファイルシステムの間には絶対的な関係があります。
URLは、UNIFORMリソースロケーターであると主張し、Webより前のリソースを指すことができます。これらの一部は大文字と小文字が区別され（たとえば、多くのftpサーバー）、URLは合理的に直感的な方法でこれらのリソースを表すことができる必要があります。
大文字と小文字を区別しない場合、一致を検索するときに（OSまたはそれ以上で）より多くの作業が必要です。
大文字と小文字を区別するようにURLを定義すると、個々のサーバーは必要に応じて大文字と小文字を区別しないようにURLを実装できます。その逆は当てはまりません。
大文字と小文字を区別しないことは、国際的な文脈では簡単ではありません： https://en.wikipedia.org/wiki/Dotted_and_dotless_I また、RFC1738では、エンコードされたが文字セットを指定しなかった場合、ASCII範囲外の文字の使用が許可されました。これは、それ自体がワールドワイドウェブと呼ばれるものにとって非常に重要です。大文字と小文字を区別しないURLを定義すると、バグの可能性が広がります。
大量のデータをURI（たとえば、 Data URI ）にパックしようとしている場合、大文字と小文字が区別される場合は、さらにパックできます。
私はブログから「なぜ新しいことがあるのか」という形式の質問にアプローチする習慣を昔のことを盗みました。 「もしそうでなければ、世界はどのようなものになるでしょうか？」
たとえば、オフィスにいるときに電話でドキュメントファイルを読むことができるように、フォルダからドキュメントファイルを提供するようにWebサーバーをセットアップしたとします。これで、ドキュメントフォルダに、todo.txt、ToDo.txt、TODO.TXTの3つのファイルがあります（知っていますが、ファイルを作成したときに意味がありました）。
これらのファイルにアクセスするために、どの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エラーページを変更する価値があるとは誰も考えていません...
「なぜこのように設計されたのか」をどのように読むべきでしょうか？質問？あなたは意思決定プロセスの歴史的に正確な説明を求めていますか、それとも「誰かがこのように設計するのはなぜですか」と尋ねていますか？
歴史的に正確なアカウントを取得することはほとんど不可能です。時には、標準化委員会で決定が下されるとき、議論がどのように行われたかについてのドキュメンタリートレイルがありますが、ウェブ決定の初期には数人の個人によって急いで決定されました-この場合はおそらく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プログラマでした。
上記の答えは正しいですが、良いです。さらにポイントを追加したいと思います。
よりよく理解するには、Unix（Linux）とWindowsサーバーの基本的な違いを理解する必要があります。 Unixは大文字と小文字を区別し、Windowsは大文字と小文字を区別しないOSです。
HTTPプロトコルは、1990年頃に進化または実装が開始されました。HTTPプロトコルは、CERN研究所で働くエンジニアによって設計されました。当時の科学者のほとんどは、WindowsではなくUnixマシンを使用していました。
ほとんどの科学者はUnixに精通していたため、Unixスタイルのファイルシステムに影響を受けていた可能性があります。
Windowsサーバーは2000年以降にリリースされました。Windowsサーバーが普及するかなり前に、HTTPプロトコルは十分に成熟し、仕様が完成しました。
これが理由かもしれません。
これは、ドメインを購入した場所とは関係ありません。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を表示する理由です。