URI（具体的にはHTTP URL）に1つ以上のスペース文字を含めることはできますか？URL がエンコードするがある+単に一般的な慣習に従っているか、それとも正当な代替案ですか？
特に、スペースのあるURLはエンコードする必要があることを示すRFCを誰かが指摘できますか？
質問の動機： Webサイトのベータテスト中に、一部のURLにスペースが含まれていることに気付きました。Firefoxは正しいことをしているようだったので、驚いた！しかし、開発者がRFCを参照できるようにして、開発者がそれらのURLを修正する必要性を感じられるようにしたいと思いました。
回答:
あたりとしてRFC 1738：
安全ではない：
文字はいくつかの理由で安全ではない可能性があります。 スペース文字は安全ではありません。URLが転記またはタイプセットされるか、ワープロプログラムの処理を受けると、重要なスペースが消えたり、重要でないスペースが導入されたりする可能性があるためです。 文字
"<"と">"は、フリーテキストのURLの区切り文字として使用されるため、安全ではありません。"""一部のシステムでは、引用符（）を使用してURLを区切ります。文字"#"は安全ではなく、常にエンコードする必要があります。WorldWide Webやその他のシステムでは、それに続くフラグメント/アンカー識別子からURLを区切るために使用されるためです。キャラクター"%"他の文字のエンコーディングに使用されるため、安全ではありません。他の文字は安全ではありません。ゲートウェイや他のトランスポートエージェントがそのような文字を変更することがあることが知られているためです。これらの文字は"{"、"}"、"|"、"\"、、 、、と。"^"、"~""[""]""`"安全でない文字はすべてURL内で常にエンコードする必要があります。たとえば、
"#"通常はフラグメントまたはアンカー識別子を処理しないシステムであっても、URL内で文字をエンコードする必要があるため、URLをそれらを使用する別のシステムにコピーした場合、URLエンコーディングを変更する必要はありません。
なぜエンコードする必要があるのですか？リクエストは次のようになります。
GET /url HTTP/1.1
(Ignoring headers)空白で区切られた3つのフィールドがあります。あなたのURLにスペースを入れた場合：
GET /url end_url HTTP/1.14つのフィールドがあることがわかっている場合、HTTPサーバーはそれが無効な要求であることを通知します。
GET /url%20end_url HTTP/1.13つのフィールド=>有効
注：クエリ文字列（？の後）では、スペースは通常+としてエンコードされます
GET /url?var=foo+bar HTTP/1.1 のではなく
GET /url?var=foo%20bar HTTP/1.1 より短い答え：いいえ、スペースをエンコードする必要があります。スペースをとしてエンコードすることは正しい+ですが、クエリ文字列でのみです。パスで使用する必要があります%20。
URLにはスペース文字を含めることができ、ほとんどのブラウザでは％20として表示されますが、ブラウザのエンコードルールは頻繁に変更され、ブラウザがURLを表示する方法に依存することはできません。
そのため、代わりに、URLのスペース文字を、URLをより読みやすくし、 'Pretty'にすると思われる任意の文字に置き換えることができます。 "+" ....しかし、これらは強制ではないので、URLに含まれていないはずの任意の文字を使用できます。
％、＆、}、{、]、[、/、>、<は、特定のブラウザやプラットフォームでエラーを引き起こす可能性があるため、URLスペース文字の置換として使用しないでください。
ご覧のとおり、Stakオーバーフロー自体はスペース（％20）の置換として「-」文字を使用しています。
幸せな質問をしてください。
スペースのあるURLはエンコードする必要があることを示すRFCを誰かが指すことができますか？
URI、つまりURLはRFC 3986で定義されています。
そこに定義されている文法を見ると、スペース文字は構文的に正当なURLの一部にはなり得ないことに気付くでしょう。したがって、「スペースのあるURL」という用語はそれ自体が矛盾しています。
あなたの質問に答えるために。アプリケーションでURLで使用される値のスペースを置き換えることはかなり一般的だと思います。これは、通常、発生するパーセント（URI）エンコーディングの読み取りが困難になるのを避けるためです。
パーセントエンコーディングに関するウィキペディアの記事をご覧ください。