URLは大文字と小文字を区別する必要がありますか？

きがついた

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

そして

http://stackoverflow.com/questions/ask

どちらも正常に機能します-実際には、前のものは小文字に変換されます。

これはユーザーにとって理にかなっていると思います。

Googleを見ると、次のURLは問題なく機能します。

http://www.google.com/intl/en/about/corporate/index.html  

しかし、「ABOUT」のあるものは機能しません：

http://www.google.com/intl/en/ABOUT/corporate/index.html   

URLは大文字と小文字を区別する必要がありますか？

W3の「HTMLとURL」によると、次のようにする必要があります。

URL、またはURLの一部が存在する場合もありますが、それらは問題ではありませんが、これらの特定は簡単ではない場合があります。ユーザーは常に、URLで大文字と小文字が区別されることを考慮する必要があります。

すべての「インセンシティブ」は読みやすくするために太字になっています。

RFC 4343によれば、ドメイン名は大文字と小文字を区別しません。残りのURLは、GETメソッドを介してサーバーに送信されます。これは、大文字と小文字が区別される場合とそうでない場合があります。

このページを例にとると、stackoverflow.comはGET文字列/ questions / 7996919 / should-url-be-case-sensitiveを受け取り、HTMLドキュメントをブラウザーに送信します。Stackoverflow.com では、/ QUEStions / 7996919 / Should-url-be-case-sensitiveと同じ結果が生成されるため、大文字と小文字は区別されません。

一方、ウィキペディアはタイトルの最初の文字を除いて大文字と小文字を区別します。URL https://en.wikipedia.org/wiki/Case_sensitiveivityおよびhttps://en.wikipedia.org/wiki/case_sensitiveivityは同じ記事につながりますが、https：//en.wikipedia.org/wiki/CASE_SENSITIVITYは戻ります404。

ホスティングOSによって異なります。Windowsでホストされているサイトでは、基になるファイルシステムでは大文字と小文字が区別されないため、大文字と小文字が区別されない傾向があります。Unixタイプのシステムでホストされているサイトは、基礎となるファイルシステムで通常大文字と小文字が区別されるため、大文字と小文字が区別される傾向があります。URLのホスト名部分は常に大文字と小文字を区別しません。変化するのはパスの残りの部分です。

DNSは大文字http://en.example.org/と小文字を無視するため、URLのドメイン名部分は大文字と小文字が区別されません HTTP://EN.EXAMPLE.ORG/。両方とも同じページを開きます。

パスは、要求されたリソースを指定し、おそらく見つけるために使用されます。一部のサーバー、特にMicrosoft Windowsベースのサーバーでは、大文字と小文字が区別されない場合がありますが、大文字と小文字は区別されます。

サーバが大文字と小文字が区別され、場合にhttp://en.example.org/wiki/URL正しいこと、そして、http://en.example.org/WIKI/URLまたはhttp://en.example.org/wiki/urlこれらのURLが有効なリソースに自分自身を指していない限り、HTTP 404エラーページが表示されます。

私は古い記事をぶつけることのファンではありませんが、これはこの特定の問題に対する最初の応答の1つだったので、何かを明確にする必要性を感じました。

@Bhavin Shahの回答では、URLのドメイン部分では大文字と小文字が区別されないため、

http://google.com 

そして

http://GOOGLE.COM 

そして

http://GoOgLe.CoM 

すべて同じですが、ドメイン名の部分以降はすべて大文字と小文字が区別されます。

そう...

http://GOOGLE.COM/ABOUT

そして

http://GOOGLE.COM/about

異なっています。

注：私は多くの場合、「技術的に」であり、「文字通り」ではありません。ほとんどの場合、サーバーはこれらのアイテムを同じように処理するように設定されていますが、同じように処理されないように設定することは可能です。

異なるサーバーはこれを異なる方法で処理し、場合によっては大文字と小文字を区別する必要があります。多くの場合、クエリ文字列値はエンコードされます（クエリ文字列値として渡されるセッションIDまたはBase64エンコードデータなど）。これらのアイテムはその性質から大文字と小文字を区別するため、サーバーはそれらを処理する際に大文字と小文字を区別する必要があります。

したがって、質問に答えるために、サーバーはこのデータを取得する際に大文字と小文字を区別する必要があります。答えは「はい、最も間違いなく」です。

もちろん、すべてが大文字と小文字を区別する必要はありませんが、サーバーはそれが何であるか、およびそれらのケースを処理する方法を認識している必要があります。

@ハート・シマのコメントは基本的に同じことを言っています。投稿する前にそれを逃したので、クレジットが期日までにクレジットを与えたいです。

ここの仕様を見てください：セクション2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

スキームとホストは大文字と小文字を区別せず、通常は小文字で提供されます。他のすべてのコンポーネントは、大文字と小文字を区別して比較されます。

以下を検討してください。

https://www.example.com/createuser.php?name=Paul%20McCartney

この架空の例では、GETメソッドを使用するHTMLフォームが「name」パラメーターを、新しいユーザーアカウントを作成するPHPスクリプトに送信します。

そして、この例で私が指摘している点は、このGETパラメーターは、「McCartney」の大文字を保持するために大文字と小文字を区別する必要があるということです（または、別の例として、「Walter d'Isney」を保持するには、他の方法があります）名前が通常の大文字使用規則に違反する場合）。

スキームとホストは大文字と小文字を区別しないというW3Cの推奨事項を導くのはこのようなケースですが、その後はすべて大文字と小文字が区別される可能性があり、サーバーに委ねられます。標準で大文字と小文字を区別しないと、上記の例では、GETクエリパラメータとして渡されたユーザー入力の大文字と小文字を維持できなくなります。

しかし、私が言いたいのは、これはそのようなケースに対応するための法律の書簡である必要があるが、法律の精神は、ケースが無関係である場合、ケースに依存しない方法で行動するということです。ただし、標準は、大文字と小文字が区別されない場所を特定することはできません。これは、私が示した例のように、状況に依存するものだからです。

（たとえば、アカウントのユーザー名は、大文字と小文字を区別しないように強制するのが最善です。 "User123"と "user123"が異なるアカウントであると、混乱を招く可能性があるためです。

時々それは関連しています、ほとんどの場合それはそうではありません。しかし、これらのことを決定するのはサーバー/ Web開発者に任されなければなりません-そして、標準によって規定することはできません-そのレベルでのみコンテキストを知ることができるからです。

スキームとホストは大文字と小文字を区別しません（これは、大文字と小文字を区別しないという標準の優先順位を示します。残りの部分は、コンテキストをよりよく理解するために、あなたが決定することに任されています。ただし、すでに説明したように、法律上の精神から、正当な理由がない限り、デフォルトでは大文字と小文字を区別しないようにする必要があります。

URLは、大文字と小文字を区別しないという正当な理由がない限り、大文字と小文字を区別しないでください。

これは必須ではありません（RFCの一部ではありません）が、URLの通信と保存の信頼性が大幅に向上します。

Webサイトに2つのページがある場合：

http://stackoverflow.com/ABOUT.html

そして

http://stackoverflow.com/about.html

それらはどのように違いますか？多分1つは「叫びのスタイル」（大文字）と書かれています-しかし、IAの観点からは、URLの場合の変更によって区別されるべきではありません。

さらに、これをApacheに実装するのは簡単CheckSpelling Onです-mod_Spelingから使用するだけです。

古い質問ですが、ここでつまずきました。質問はさまざまな視点を求めており、明確な答えではないので、試してみませんか。

w3cには推奨事項があるかもしれません-私はこれを大いに気にします-質問がここにあるので再考したいと思います。

なぜw3cはドメイン名を大文字と小文字を区別せず、その後大文字と小文字を区別しないと見なすのですか？

根拠は、URLのドメイン部分がユーザーによって手動で入力されたということです。ハイパーテキストになった後のすべては、マシン（ブラウザとサーバーの背面）によって解決されます。

マシンは、人間よりも大文字と小文字の区別を処理できます（技術的な種類ではありません:)）。

しかし問題は、マシンがそれを処理できるので、それはそのように行われるべきですか？

つまり、hereIsTheResourcevsにあるリソースに名前を付けてアクセスすることの利点は何hereistheresourceですか？

側面は、読みやすいキャメルケースよりも非常に読みにくいです。人間にも読める（技術的な種類を含む）

だからここに私のポイントがあります：-

リソースパスは、プログラミング構造の途中のどこかにあり、ブラウザーの背後にあるエンドユーザーの近くにある場合があります。

ユーザーがURLに触れたり入力したりすることが予想される場合、URL（ドメイン名を除く）は大文字と小文字を区別しません。ユーザーがパスをできるだけ入力するようにアプリケーションを開発する必要があります。

ユーザーがURLを手動で入力しない場合は、URL（ドメイン名を除く）で大文字と小文字を区別する必要があります。

結論

パスは大文字と小文字を区別する必要があります。私のポイントは、大文字と小文字を区別するパスに重点を置いています。

URL文字は16進コードに変換され（URLのスペースが％20として表示されていることに気付いた場合など）、小文字と大文字の16進値が異なるため、URLで大文字と小文字が区別されることは間違いありません。ただし、質問の精神は標準である必要があるようであり、私はノーと言いますが、そうです。エンドユーザーに関係なく機能するようにしたい場合は、開発者/プロバイダーがコードでこれを考慮する必要があります。

これと、仕様で行われていることや言われていないことに関する多くの回答には、質問の要点が欠けていると思います。大文字と小文字を区別する必要がありますか？それは本当に読み込まれた質問です。ユーザーの観点から見ると、大文字と小文字を区別することは難点です。URIをすべきかそうでないべきかという問題は、問題のコンテキストによって異なります。技術的な柔軟性については、そうです。使いやすさのために、彼らはそうであってはなりません。

ケース保存

URLは、クライアントとサーバー間で大文字と小文字を区別します。ただし、URLの一部では、サーバーによって、いくつかの理由で大文字と小文字が区別される場合とされない場合があります。

大文字と小文字の区別

次のURLの太字部分は、サイトやサーバーの構成によっては、大文字と小文字が区別される場合があります。

    http：// www。example.com /abc/def.ghi?jkl=mno#pqr

    user @ example.com

根拠

URLの大文字と小文字の区別にはいくつかの用途があります。主に：

1. 大文字と小文字を区別するファイルシステムとのネイティブな互換性。
2. シリアル化、ハッシュ、ID、パーマリンク、URL短縮など、URL内のよりコンパクトなデータエンコーディング。

開発者として、上記はより良い方法で処理できることが多いと思いますが、状況によってはこれが許可されない場合があることも理解しています。

たとえば、「GET」URLに多くのデータを配置する必要がある既存の製品を想像してください。ただし、すべての主要なサーバー、ブラウザ、およびキャッシュ/プロキシメカニズムの最大URL長と互換性がある必要があります。中程度の長さのコマンド文字列（一部の古いブラウザーでは1,024文字未満）にも適合させるには、可能な限り一意のURLセーフ文字を使用する必要があります（これは基本的にはbase64urlエンコーディングです）。

理想的な世界で

かどうかURLが必要があり、大文字と小文字を区別議論の余地があること。私は個人的には、そうすべきではないと信じています（より長いURLを作成する可能性がありますが、正確な文字を保持する必要がある場合に簡単に処理できるようにパーセントエスケープがあり、URL以外でデータを転送する方法があります）。 。

使いやすさを向上させるために、多くの人気のあるサイトやサービスで大文字と小文字を区別しないURLが明示的に有効になっているという事実に基づいて、多くの人が同意しているようです。最も顕著な例は、電子メールアドレスのユーザー名の部分です。ほとんどの電子メールプロバイダーは、大文字と小文字、場合によってはドットやその他の記号も無視します（ "j.smith@example.com"は "JSMITH@example.com"と同じ）。仕様によると、メールのユーザー名はデフォルトで大文字と小文字が区別されます。

ただし、実際には、私や他の人が望んでいることにも関わらず、これが現在の状態です。そして、大文字と小文字を区別しないURL標準への最終的な世界的な移行は確かに可能ですが、現在、大文字と小文字の区別がさまざまな目的でWeb全体で広く使用されているため、かなり長い時間がかかる可能性があります。

ベストプラクティス

ベストプラクティスに関する限り、ユーザーとしては、ほとんどの状況で小文字に固執し、物事が機能することを期待できます。主な例外は、大文字と小文字をベースにしたエンコードを使用するURL、または同等のファイルシステムのドキュメントパスです。ただし、このような複雑なURLは通常、手動で入力するのではなく、コピーして貼り付けます（または単にクリックします）。

Web開発者は、URLの大文字と小文字をできるだけ区別しないことを検討する必要があります。ただし、上記のように、状況によっては避けられない状況がいくつかあります。

問題は、URLで大文字と小文字が区別されるべきかどうかです。

大文字と小文字を区別するURLの背後に、使用法がないか、良い習慣があると思います。それは愚かな、それは吸うと常に避けられるべきです。

私の意見を裏付けるために、誰かがどのURLを尋ねたときに、URLのどの文字が大文字または小文字であるかをどのように説明できますか？それはナンセンスであり、他に誰もあなたに言うべきではありません。

LinuxサーバーでホストされているWebサイトの場合、URLでは大文字と小文字が区別されます。 http://www.google.com/aboutおよびhttp://www.google.com/Aboutは別の場所にリダイレクトされます。Windowsサーバーでは、FOLDERの命名と同様に、URLは大文字と小文字を区別せず、同じ場所にリダイレクトされます。

大文字と小文字を区別しないURLを作成することが可能です

RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

Google.com..GOOGLE.comなどをgoogle.comにダイレクトする