スペースは、符号にURLエンコードされる場合も+あれば、にエンコードされる場合もあります%20。違いは何ですか？なぜこれが起こるのですか？
回答:
+URLのクエリ部分など、コンテンツ内のみのスペースを意味しapplication/x-www-form-urlencodedます。
http://www.example.com/path/foo+bar/path?query+name=query+value
このURLでは、パラメーター名にはquery nameスペースが含まれ、値にはquery valueスペースが含まれていますが、パス内のフォルダー名はfoo+barでなく、 foo barです。
%20これらのコンテキストのいずれかでスペースをエンコードする有効な方法です。したがって、URLの一部に含めるために文字列をURLエンコードする必要がある場合は、スペースを%20プラスに、プラスをプラスに置き換えても常に安全%2Bです。これは例です。encodeURIComponent()JavaScriptで行います。残念ながら、それはurlencodeがPHPで行うことではありません（rawurlencodeの方が安全です）。
query+name=query+value使用してフォームからパラメータを作成します<input name="query name" value="query value">。query%20nameフォームからは作成されませんが、代わりにそれを使用することは完全に安全です。自分でフォーム送信をまとめる場合XMLHttpRequest。のようにスペースが含まれているURLがある場合<a href="http://www.example.com/foo bar/">、ブラウザーはそれをエンコードし%20て間違いを修正しますが、これはおそらく信頼されません。
foo barにfoo+bar？
encodeURIComponent(s).replace(/%20/g, '+')本当に必要な場合は当然行うことができます+
http://www.example.com/some/path/to/resource?param1=value1
疑問符の前の部分は％エンコーディングを使用する必要があるため（%20スペースの場合）、疑問符の後にはスペース%20または+スペースのいずれかを使用できます。+疑問符の後に実際が必要な場合は、を使用してください%2B。
decodeURIComponentデコードしません。
+は予約文字であるため、ブラウザによって保持されます。
+デフォルトでスペースをデコードします（{ foo: 'bar bar'}.to_query=> foo=bar+bar）
だから、ここでの答えはすべて少し不完全です。URLのスペースをエンコードするための '％20'の使用は、URIの構築方法を定義するRFC3986で明示的に定義されています。この仕様では、スペースのエンコードに「+」を使用することについての言及はありません。この仕様のみで行く場合、スペースは「％20」としてエンコードする必要があります。
スペースのエンコードに「+」を使用することについての言及は、HTML仕様のさまざまな具体化、特にコンテンツタイプ「application / x-www-form-urlencoded」を説明するセクションから来ています。これはフォームデータの投稿に使用されます。
現在、HTML 2.0仕様（RFC1866）は、セクション8.2.2で、GETリクエストのURL文字列のクエリ部分を「application / x-www-form-urlencoded」としてエンコードする必要があることを明確に述べています。理論的には、これはクエリ文字列のURLで「+」を使用することが合法であることを示唆しています（「？」の後）。
しかし...それは本当にですか？HTMLはそれ自体がコンテンツ仕様であり、クエリ文字列を含むURLはHTML以外のコンテンツでも使用できます。さらに、HTML仕様の新しいバージョンでは、「+」を「application / x-www-form-urlencoded」コンテンツで合法として定義し続けていますが、GETリクエストのクエリ文字列がそのタイプとして定義されているという部分は完全に省略されています。実際、HTML 2.0仕様以降のクエリ文字列のエンコーディングについては何も触れられていません。
どちらが私たちに質問を残します-それは有効ですか？確かに、クエリ文字列で「+」をサポートする多くのレガシーコードと、それを生成する多くのコードがあります。したがって、オッズは「+」を使用しても壊れることはありません。（そして、実際、私は最近、GETクエリで '％20'をスペースとして受け入れられない主要なサイトを発見したため、これに関するすべての調査を行いました。実際には、パーセントエンコードされた文字のデコードに失敗しました。サービス使用していることも関連する場合があります。）
しかし、仕様を純粋に読むだけで、HTML 2.0仕様の言語が後のバージョンに引き継がれることなく、URLは完全にRFC3986でカバーされます。つまり、スペースは '％20'に変換する必要があります。そして、HTMLドキュメント以外のものをリクエストする場合は、間違いなくそうです。
%20（<a href="?q=a b">）としてエンコードしますが、フォームを送信するときは、+記号を使用します。明示的に+記号（<a href="?q=a+b">）を使用するか、を使用してフォームを送信することで、これをオーバーライドできますXMLHTTPRequest。
スペースを常に「+」ではなく％20としてエンコードすることをお勧めします。
これはRFC-1866（HTML 2.0仕様）で、「application / x-www-form-urlencoded」コンテンツタイプのキーと値のペアでスペース文字を「+」としてエンコードする必要があることを指定していました。（パラグラフ8.2.1を参照。サブパラグラフ1）。このフォームデータのエンコード方法は、後のHTML仕様にも記載されています。application/ x-www-form-urlencodedに関する関連する段落を探してください。
RFC-1866がスペースをプラスとしてエンコードできるURLのそのような文字列の例は次のとおりです： "http://example.com/over/there?name=foo+bar"。したがって、RFC-1866によれば、「？」の後にのみ、スペースをプラス記号で置き換えることができます。その他の場合、スペースは％20にエンコードする必要があります。ただし、コンテキストを判別するのは難しいため、スペースを「+」としてエンコードしないことがベストプラクティスです。
RFC-3986、p.2.3で定義されている「予約されていない」以外のすべての文字をパーセントエンコードすることをお勧めします。
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
違いは何ですか：他の回答を参照してください。
+代わりに使用する場合%20？+何らかの理由で、URLクエリ文字列（?.....）またはハッシュフラグメント（#....）を読みやすくする場合に使用します。例：実際にこれを読むことができます：
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
（%2B= +）
しかし、以下は読みにくいです：（少なくとも私にとって）
+Googleが使用しており+（上記の最初のリンクを参照）、おそらくこれについて考えているため、何も壊すことはないと思います。+可読性+ Googleが大丈夫だと思っているからといって、自分を使用します。