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 434 によると、ドメイン名は大文字と小文字を区別しません。残りのURLはGETメソッドを介してサーバーに送信されます。大文字と小文字が区別される場合とそうでない場合があります。
このページを例にとると、stackoverflow.comはGET文字列 / questions/7996919 /大文字と小文字を区別する を受け取り、HTMLドキュメントをブラウザに送信します。 Stackoverflow.comは大文字と小文字を区別しません - - と同じ結果が得られます / QUEStions/7996919/Should-url-be-case-sensitive 。
一方、ウィキペディアでは、タイトルの最初の文字を除いて大文字と小文字が区別されます。 URL https://en.wikipedia.org/wiki/Case_sensitivity と https://en.wikipedia.org/wiki/case_sensitivity は同じ記事になりますが、 https://en.wikipedia.org/wiki/CASE_SENSITIVITY は404を返します。
ホスティングOSに依存します。基盤となるファイルシステムでは大文字と小文字が区別されないため、Windowsでホストされているサイトでは大文字と小文字が区別されない傾向があります。 UNIXタイプのシステムでホストされているサイトでは、基盤となるファイルシステムでは通常大文字と小文字が区別されるため、大文字と小文字が区別される傾向があります。 URLのホスト名の部分では常に大文字と小文字が区別されません。パスの残り部分は異なります。
DNSは大文字と小文字を区別しないので、URLのドメイン名部分は大文字と小文字を区別しません：http://en.example.org/とHTTP://EN.EXAMPLE.ORG/は両方とも同じページを開きます。
パスは、要求されたリソースを指定して、おそらく見つけるために使用されます。大文字と小文字が区別されますが、一部のサーバー、特にMicrosoft Windowsベースのサーバーでは、大文字と小文字が区別されない場合があります。
サーバーの大文字と小文字が区別され、http://en.example.org/wiki/URLが正しい場合、これらのURLが有効なリソース自体を指していない限り、http://en.example.org/WIKI/URLまたはhttp://en.example.org/wiki/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エンコードデータなど）。これらの項目は、その性質上大文字と小文字が区別されるため、サーバーでは大文字と小文字が区別されます。
この質問に答えるために、サーバーはこのデータを取得する際に大文字と小文字を区別する必要があります。その答えは「はい、最も確実です」です。
もちろん、すべてが大文字と小文字を区別する必要があるわけではありませんが、サーバはそれが何であるか、そしてそれらのケースをどのように処理するかを認識している必要があります。
@ハートSimhaのコメントは基本的に同じことを言います。私は投稿する前にそれを逃したので、私は信用が支払われるべきところに信用を与えたいと思います。
ここで仕様を見てください：セクション2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19
schemeとHostは大文字と小文字を区別せず、通常小文字で提供されます。他のすべてのコンポーネントは大文字と小文字を区別して比較されます
それらがそうであるべきではないという正当な理由がない限り、URLは大文字と小文字を区別しないべきです。
これは必須ではありません（RFCの一部ではありません）が、URLの通信と保存をはるかに信頼性の高いものにします。
Webサイトに2ページある場合
http://stackoverflow.com/ABOUT.html
そして
http://stackoverflow.com/about.html
どう違いますか。たぶん1つは「叫び声のスタイル」（大文字）と書かれています - しかしIAの観点からは、区別はURLの場合の変更によって行われるべきではありません。
さらに、Apacheでこれを実装するのは簡単です - mod_SpelingからCheckSpelling Onを使うだけです。
次の点を考慮してください。
https://www.example.com/createuser.php?name=Paul%20McCartney
この架空の例では、HTMLフォーム（GETメソッドを使用）が、 "name"パラメータを新しいユーザーアカウントを作成するPHPスクリプトに送信します。
そしてこの例で私が強調しているのは、 "McCartney"の大文字使用を維持するために（または他の方法として "Walter d'Isney"を維持するために）このGETパラメータは大文字と小文字を区別する必要があるということです。名前が通常の大文字/小文字の区別規則を破るため）.
SchemeとHostは大文字と小文字を区別しないというW3Cの勧告を導くのはこのようなケースですが、それ以降はすべて大文字と小文字が区別される可能性があり、サーバーに任されます。標準で大文字と小文字を区別しないと、上記の例ではGETクエリパラメータとして渡されたユーザー入力の大文字と小文字を区別できなくなります。
しかし、私は、これは必然的にそのような事件に対処するための法の書簡であるが、法の精神は、事件が無関係である場合には、事件に鈍感な方法で行動するということである。しかしながら、私が与えた例のように、それは文脈依存的なものであるので、標準は、ケースが無関係であるところをあなたに言うことができません。
（たとえば、「User123」と「user123」は別のアカウントであるため混乱を招く可能性があるため、たとえアカウントのユーザー名では大文字と小文字が区別されないことをお勧めします。
関連性がある場合もありますが、ほとんどの場合は関係ありません。しかし、これらのことを決定するのはサーバー/ Web開発者に任されなければなりません - そして標準によって規定されることはできません - そのレベルでだけ文脈が知られることができたので。
スキームとホストは、大文字と小文字を区別しません（これは、大文字と小文字を区別しないという規格の優先順位を示しています。これは、広く規定されている場合があります）。あなたが文脈をよりよく理解するので、残りはあなたに決めることに任されます。しかし、議論されてきたように、あなたは法律の精神において、あなたがそうしない正当な理由がない限り、大文字と小文字を区別しないことをデフォルトにすべきです。
昔の質問ですが、私はここでつまずいたので、質問はさまざまな視点を求めており、決定的な答えではないので、それを試してはいけません。
w3cはその勧告を持っているかもしれません - 私はとても気にかけています - しかし質問がここにあるので再考したいです。
W3cがドメイン名の大文字と小文字を区別せず、その後の大文字と小文字を区別しないのはなぜですか。
その理由は、URLのドメイン部分がユーザーによって手動で入力されたことにあると私は考えています。ハイパーテキストになった後のすべてのものは、マシンによって解決されます（ブラウザとサーバーは背面にあります）。
機械は人間よりも大文字と小文字を区別しないで対処することができます（技術的な種類ではありません:)）。
しかし、問題は、マシンがそれを処理できるという理由だけで、そうするべきですか？
hereIsTheResourceとhereistheresourceの間にあるリソースに名前を付けてアクセスすることの利点は何ですか？
側面はより読みやすいラクダケースよりも非常に判読不能です。人間に読める（技術的なものも含む）
だからここに私のポイントがあります： -
リソースパスは、プログラミング構造の途中でブラウザの背後にあるエンドユーザーの近くにいることがあります。
あなたのURL（ドメイン名を除く）は、ユーザがそれを触ったり入力したりすることを想定している場合、大文字と小文字を区別しないようにすべきです。
あなたのURL（ドメイン名を除く）はあなたのユーザーが決してそれを手でタイプしないならば大文字と小文字を区別するべきです。
結論
パスは大文字と小文字を区別する必要があります。私の論点は、大文字と小文字を区別するパスを重視しています。
症例保存
URLは、クライアントとサーバー間のcase-preservingです。ただし、URLの一部は、サーバーに応じて、いくつかの理由でcase-sensitiveである場合とそうでない場合があります。
大文字と小文字の区別
次のbold URLの一部は、サイトやサーバーの構成に応じて、大文字と小文字が区別される場合があります。
http：// www。 example.com / abc/def.ghi？jkl = mno＃pqr
ユーザー @ example.com
根拠
URLの大文字と小文字の区別には、いくつかの用途があります。主に：
- 大文字と小文字を区別するファイルシステムとのネイティブ互換性。
- シリアル化、ハッシュ、ID、パーマリンク、URL短縮など、URL内のよりコンパクトなデータエンコーディング。
開発者としては、上記の方が多くの場合より良い方法で処理できると信じていますが、状況によってこれが許可されない場合もあると理解しています。
たとえば、「GET」URLに大量のデータを配置する必要があるが、すべての主要なサーバー、ブラウザー、およびキャッシュ/プロキシメカニズムの最大URL長と互換性がある必要がある既存の製品を想像してください。中程度の長さのコマンド文字列（一部の古いブラウザーでは1,024文字未満）にも適合するには、可能な限りすべての一意のURLセーフ文字を使用する必要があります（これは基本的にbase64urlエンコーディングです）。
理想の世界で
URLshouldが大文字と小文字を区別するかどうかは議論の余地があります。私は個人的にはそうすべきではないと信じています（簡単にするために長いURLを作成する可能性がありますが、正確な文字の保存を保証する必要がある場合を簡単に処理するためのパーセントエスケープがあり、URL以外のデータを転送する方法があります） 。
多くの人は、使いやすさを向上させるために、多くの人気サイトやサービスで大文字と小文字を区別しないURLが明示的に有効になっているという事実に基づいて同意しているようです。最も顕著な例は、電子メールアドレスのユーザー名部分です。ほとんどの電子メールプロバイダーは大文字と小文字を無視し、場合によってはドットや他の記号（「[email protected]」が「[email protected]」と同じであるなど）さえも無視します。仕様によると、電子メールのユーザー名はデフォルトで大文字と小文字が区別されますが。
しかし、実際には、私や他の人が何を望んでいるにせよ、これが現在の仕組みの状態です。そして、大文字と小文字を区別しないURL標準への最終的な世界的な移行は確かに可能ですが、大文字と小文字の区別は現在さまざまな目的でWebで広く使用されているため、かなり長い時間がかかる可能性があります。
ベストプラクティス
ベストプラクティスに関する限り、ユーザーとしては、ほとんどの状況で小文字を合理的に使用し、機能することを期待できます。主な例外は、大文字小文字ベースのエンコードを使用するURL、または直接ファイルシステムに相当するドキュメントパスです。ただし、このような複雑なURLは通常、手動で入力するのではなく、コピーアンドペースト（または単にクリック）します。
Web開発者は、URLの大文字と小文字をできるだけ区別しないことを検討する必要があります。ただし、上記のように、状況に応じて、回避するのが難しい状況があることは明らかです。
URL文字は16進コードに変換され（URLのスペースが％20などで表示されていることに気付いたことがあれば）、小文字の大文字と大文字の大文字小文字は異なるため、URLでは大文字と小文字が区別されます。しかし、質問の精神は標準であるべきであると思われるので、私は「いいえ」と言いますが、そうです。エンドユーザーに関係なく機能させたい場合は、開発者/プロバイダがコードでこれを考慮します。
私はこれと、仕様が何を言おうとしていないかについての答えの多くは質問のポイントを逃していると思います。[should大文字と小文字を区別するべきですか？それは本当にロードされた質問です。ユーザーの観点からすると、大文字と小文字の区別は問題であり、すべてが違いをもたらすことがわかっているわけではありません。 URIがあるべきであるべきであるべきであるべきでないかどうかの問題は質問の文脈によります。技術的な柔軟性のために、はい、そうです。使いやすさのために、いいえ、そうであってはいけません。