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

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

それは挑発的な（そして「悪魔の支持者」）タイプの反語のように見えるかもしれませんが、検討することは有用だと思います。HTTPの設計は一般に「Webブラウザ」と呼ばれる「クライアント」が「Webサーバー」にデータを要求します。

リリースされるWebサーバーは非常に多くあります。MicrosoftはWindowsを搭載したIISをリリースしました。サーバーオペレーティングシステム（およびWindows XP Professionalを含むその他）。Unixには、OpenBSDの内部httpd、thttpd、またはlighttpdなどの小規模な製品は言うまでもなく、nginxやApacheなどの大物があります。さらに、多くのネットワーク対応デバイスには、デバイスの構成に使用できるWebサーバーが組み込まれています。これには、ルーター（多くの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の回答は、技術的な利点の1つに言及しています。URLは、WebブラウザがWebサーバーに少しの情報を送信するための効果的な方法であり、少ない場合はより多くの情報を含めることができます。制限があるため、ケースの感度を制限すると、含めることができる情報の量が減ります。

ただし、多くの場合、ケースの感度には非常に魅力的なメリットはありません。 IISは通常、IISを気にしないという事実によって証明されています。

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

コメント

• “異なるウェブブラウザ間で動作が異なる主な理由は、おそらく単純さの問題に要約されます。”-私はあなたを推測します”ウェブブラウザivid = “0b599e20a1ではなく、”ウェブサーバー”を意味します”>

URLは大文字と小文字を区別せず、その一部のみです。
たとえば、URL https://google.comでは大文字と小文字を区別しないものはありません。

RFC 3986を参照-Uniform Resource Identifier（URI）：一般的な構文

まず、 Wikipedia 、URLは次のようになります：

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

（user:password面白くなく、めったに使用されないため）

• scheme ：

スキームでは大文字と小文字が区別されません

• host ：

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

• path ：

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

• query ：

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

• fragment ：

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

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

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

これが主な質問のようです。
答えるのが難しい「なぜ」文書化されていない場合に何かが行われたが、非常に良い推測ができる。
data 。
URLをもう一度見てみましょう：

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

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

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

役に立ちますか？

大文字と小文字を区別します-大文字と小文字の区別には、キャッシュと正規URLに関しては落とし穴がありますが、確かに役立ちます。いくつかの例：

• Base64 、これは、データURI で使用されます。
• サイトは、URLでBase64データをエンコードできます（例： http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL短縮機能では大文字と小文字が区別されます：/a5Bは

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

[更新]

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

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

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

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

初期のウェブサーバーは非常にシンプルでした。現在でもそうです。ハードドライブに存在するHTTPリクエストを介してリソースに対して行われたリクエストはすべて、OSファイルシステムを介してウェブサーバーによって行われました。

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

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

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

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

コメント

• あなたの議論には欠陥があると思います。 Berners-Leeは’ ftpURLの大文字と小文字の区別について選択できませんでした。彼はhttpURLを設計する必要がありました。彼はそれらをUS-ASCIIのみとして指定し、大文字と小文字を区別しない可能性があります。 URLパスをファイルシステムに渡したばかりのWebサーバーがあった場合、それらは安全ではなく、URLエンコードの導入によりそれらとの互換性が失われました。 OSスマッシングケースに渡す前にパスが処理されていることを考えると、実装は簡単でした。したがって、これは実装の癖ではなく、設計上の決定と見なす必要があると思います。
• @WilliamHayこれはBerners-LeeやWebの設計とは関係ありません。それはOSの制限と要件についてです。私は引退したシステム内部エンジニアです。当時、私はこれらのシステムに取り組んでいました。 URLで大文字と小文字が区別される理由を正確に説明します。それは推測ではありません。意見ではありません。事実です。私の答えは意図的に単純化されました。もちろん、openステートメントを発行する前に実行できるファイルチェックやその他のプロセスがあります。その結果、Yes（！）Webサーバーは今日でも部分的に安全ではありません。
• URLで大文字と小文字が区別されるかどうかは、Webの設計とは関係ありませんか？本当に？権威からの議論とそれに続く主張による議論。WebサーバーがURLのパスコンポーネントを多かれ少なかれ直接オープンコールに渡すのは、URLの設計の結果であり、その原因ではありません。サーバー（またはFTPの場合はスマートクライアント）は、ファイルシステムの大文字と小文字を区別するユーザーから隠されている可能性があります。彼らが’ tしないことは、設計上の決定です。
• @WilliamHayバッタの速度を落とし、私が書いたものを読み直す必要があります。私は、ARPA-NetなどのOSコンポーネント、プロトコルスタック、ルーターコードを作成する、退職したシステム内部エンジニアです。Apache、O ‘ Reilly、およびIIS内部で作業しました。同じ理由で少なくとも主要なFTPサーバーでは大文字と小文字が区別されるため、FTPの議論は水を保持しません。 URL / URIのデザインについては何も言わなかった。 Webサーバーが処理せずに値を渡したとは決して言いませんでした。 OSサービスが一般的に使用されており、ファイルシステムが成功するには完全に一致する必要があると言いました。
• @WilliamHayあなたと私は目的を超えて考えていることを理解してください。私の答えで言っていたのは、一部のOSでは、ファイルシステムコールは設計上大文字と小文字を区別するということだけです。システムコールを使用するアプリケーションは、ほとんどの場合、OSルールの適用に制限されています。この場合は大文字と小文字が区別されます。このルールを回避することは不可能ではありません。実際、これは実用的ではありませんが、場合によっては些細なことかもしれません。以前は、何らかの理由でkablooieになったハードドライブのスクランブルを解除したり、データベースファイルの内部を分析したりするために、仕事でファイルシステムを定期的にバイパスしていました。

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

2. 大文字と小文字を区別しない場合は、探すときにさらに作業が必要です。一致（OS内またはその上）。

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

4. 大文字と小文字を区別しないことは、国際的な状況では重要です： https://en.wikipedia.org/wiki/Dotted_and_dotless_I 。また、RFC1738は、エンコードされているが文字セットを指定していなければ、ASCII範囲外の文字の使用を許可していました。これは、それ自体をWORLD Wide Webと呼ぶものにとって非常に重要です。大文字と小文字を区別しないURLを定義すると、バグ。

5. 多くのデータをURIにパックしようとしている場合（例：データURI ）大文字と小文字が異なる場合は、さらに詰め込むことができます。

コメント

• I ‘ URLは歴史的にASCIIに制限されていたと確信しています。したがって、国際化が本来の理由である可能性は低いです。大文字と小文字を区別するUnixの歴史であるOTOHは、おそらく大きな役割を果たしました。
• URLでエンコードせずに使用できるのはASCIIのサブセットのみですが、RFC1738では、ASCII範囲外の文字をエンコードして使用できると具体的に述べています。文字セットを指定しないと、’を知ることはできません。どのオクテットが同じ文字を表すかケースを除いて俳優。更新されました。
• Re＃4：’は実際にはそれよりも悪いです。ドット付きとドットなし私は、すべてがUTF-8 （または他のUTF）であっても、テキストが属するロケールを知らなければ、大文字または小文字を正しく使用できないという、より一般的な原則のデモンストレーションです。 。デフォルトのロケールでは、大文字のラテン文字Iは小文字のラテン文字iに小文字になります。これは、ドットが追加されるため、トルコ語では正しくありません（”トルコ語の大文字のドットなしI “コードポイント; ‘はASCIIコードポイントを使用することを意図しています）。エンコーディングの違いを投げ込むと、これは”本当に難しい”から”完全に手に負えないものになります。”

ブログから盗んだOld New Thingは、「なぜ何かが起こっているのか」という形の質問に取り組む習慣があります。 「そうでなかったら、世界はどうなるだろうか」という反対の質問で

フォルダからドキュメントファイルを自分で提供するようにWebサーバーを設定して、それらを読むことができるとしましょう。私が外出中の電話。これで、ドキュメントフォルダに、todo.txt、ToDo.txt、TODO.TXTの3つのファイルがあります。 （私は知っていますが、ファイルを作成したときは理にかなっています。）

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

アドレス帳に連絡先を追加できるスクリプトがあるとします。これにより、次のことができます。ウェブ上でも行います。それはどのようにそのパラメータを取るべきですか？ http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reillyのように使用したいのですが、大文字と小文字を区別して名前を指定する方法がない場合は、どうすればよいですか？

CatとCAT、TextとTEXT、latexとLaTeXのwikiページをどのように区別しますか？ページの曖昧さを解消しますが、私は要求したものを取得することを好みます。

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

あなたが本当に尋ねていたと思う質問は、「Webサーバーは、コンピューターの場合、人生をよりシンプルにするように設計されているのに、なぜケースの違いのために404するのですか？ 、そして、私が入力したURLで、少なくとも最も明白なケースバリエーションを見つけることができますか？」

その答えは、一部のサイトがこれを行っている間（そしてより良いことに、他のタイプミスもチェックしてください）、ウェブサーバーのデフォルトの404エラーページを変更する価値があるとは誰も考えていませんでした…しかし、おそらくそうすべきでしょうか？

コメント

• 一部のサイトでは、何らかのメカニズムを使用してすべて小文字または一貫性のあるものへのクエリ。ある意味、これは賢明です。
• いいえ、’ tするべきではありません。この機能は、必要なときに追加できます（たとえば、apacheのモジュールによって）。この種の変更をデフォルトの動作（さらに悪いことに、不変の動作）として課すと、比較的まれな動作よりも混乱が生じます。誰かがホスト名以外のURLを手動で入力しなければならない場合。これを行わない理由の良い例として、Network Solutions “がパブリックDNSからの存在しないドメインエラーを”修正したときの大失敗を思い出してください。クエリ。
• @SirNickity誰もどのレベルでも不変性を提案していませんでした。ウェブサーバーのエラーページは、これまでに使用したすべてのウェブサーバーで構成できます。’ 404を30 *コードに置き換えることを提案している人は誰もいませんでしたが、エラーページに人間がクリックできる提案リンクのリストを追加していました。ドメイン名は、大文字と小文字を区別せず、セキュリティコンテキストが異なる、非常に異なるトピックと問題です。およびIISは、URIのパスまたはファイル名部分の大文字と小文字の違いを（無視して）自動的に”修正”します。
• 1996年以来、Apacheでは mod_speling を使用してこれを行うことができます。 ‘非常に人気のあることではないようです。 Unix / Linuxの人々は、大文字と小文字を区別しないことを原則として、大文字と小文字を区別しないことを例外と見なしています。

上記の答えは正解です&良いです。もう少しポイントを付け加えたいと思います。

理解を深めるには、Unix（Linux）とWindowsサーバーの基本的な違いを理解する必要があります。 Unixでは大文字と小文字が区別されます& Windowsでは大文字と小文字が区別されません。

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

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

Windowsサーバーは2000年以降にリリースされました。Windowsサーバーが普及するずっと前に、HTTPプロトコルは十分に成熟し、仕様は完成していました。

これが理由である可能性があります。

コメント

• ” Windowsサーバーは2000年以降にリリースされました。” Windows NT 3.1 チームは、1993年にあなたと意見が一致しなかったでしょう。1995年のNT 3.51は、おそらくNTが成熟しており、ビジネスクリティカルなサーバーアプリケーションをサポートするのに十分な確立が確立されています。
• NT3.51にはWin3.1インターフェイスがありました。 WindowsはWindows95まで実際に離陸せず、同じインターフェイスを取得するにはNT4.0が必要でした。
• Michael Kj ö rlingは同意しました。変更させてください。
• @Thorbj ø rnRavnAndersenサーバー市場では、NT3.51はかなり成功しました。消費者/プロシューマー市場では、NTラインが本格的な牽引力を獲得し始めるまでにWindows 2000（NT 5.0）までかかりました。
• 実際、WorldWideWebは当初、大文字と小文字を区別するUnixベースのシステムで開発されました。ファイルシステム、およびファイルシステム上のファイルに直接マップされたほとんどのURL。

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

歴史的に正確なものを入手することはめったにありません。アカウント。標準委員会で決定が下されるとき、討論がどのように行われたかについての記録的な証跡があることがありますが、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プログラマーでした。

コメント

• エンドユーザーも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 

すべてがまったく同じコンテンツのまったく同じページを指していると、コンテンツが重複することになります。GoogleSearchConsoleをお持ちの場合は確かです。 （ウェブマスターツール）アカウント、Googleがこれを示します。

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

コメント

• “はい。重複コンテンツの問題を回避するため。”-しかし、その逆は本当のように思われますか？ URLで大文字と小文字が区別される可能性があるという事実（これが検索エンジンによるURLの処理方法です）は、言及したコンテンツの重複の問題を引き起こします。 URLで大文字と小文字が区別されない場合は、大文字と小文字が異なる重複コンテンツの問題は発生しません。 page-1はPAGE-1と同じになります。
• サーバー構成が不十分だと思いますケーシングに関しては、コンテンツの重複を引き起こす可能性があります。たとえば、.htaccessに格納されているステートメントRewriteRule ^request-uri$ /targetscript.php [NC]は、http://example.com/request-uriおよびhttp://example.com/ReQuEsT-Uriと一致します。 [NC]は、その1つの正規表現を評価するときに大文字と小文字が重要ではないことを示します’。

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

26文字あり、それぞれに大文字を使用できる場合、52文字です。

4文字の場合、52 * 52 * 52 * 52の組み合わせが可能です。 7311616の組み合わせに相当します。

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

52文字の組み合わせの数は52文字の14倍を超えます。データを保存するために、Urlを短くして、転送するデータを減らしてより多くの情報をネットワーク経由で渡すことができます。

これが、 https://www.youtube.com/watch?v=xXxxXxxX