PHP中URL编码解码需根据场景选择函数：urlencode()将空格转为+，适用于表单数据；rawurlencode()将空格转为%20，符合RFC标准，适用于URL路径。两者均用于防止特殊字符破坏URL结构。使用时应避免重复编码、确保字符串为UTF-8编码，并匹配对应的解码函数以保证正确解析。
PHP中对URL进行编码和解码，主要依赖于内置的几个函数：
urlencode()、
rawurlencode()进行编码，以及
urldecode()、
rawurldecode()进行解码。它们的核心作用是确保URL在传输过程中不会因为特殊字符而损坏或产生歧义，让浏览器和服务器都能正确理解URL的意图。
解决方案
在PHP里处理URL的编码和解码，这事儿说起来简单，但实际操作中，特别是当你遇到各种奇奇怪怪的字符或者不同系统间的交互时，还是有些门道的。最常用的就是
urlencode()和
urldecode()这对组合，它们主要遵循的是
application/x-www-form-urlencoded这种编码规范，也就是我们在HTML表单提交时经常遇到的那种。比如，空格会被转换成加号（
+），而其他非字母数字的字符则会被转换为百分号（
%）后面跟着两位十六进制数。
举个例子，假设你有个字符串叫做
我的名字是 John Doe & Co.，如果直接把它作为URL参数，那
空格、
&这些字符肯定会搞砸URL的结构，导致解析错误。
$originalString = "我的名字是 John Doe & Co.!"; $encodedString = urlencode($originalString); echo "编码后: " . $encodedString; // 预期输出: 编码后: %E6%88%91%E7%9A%84%E5%90%8D%E5%AD%97%E6%98%AF+John+Doe+%26+Co.%21
你看，中文字符被编码了，空格变成了
+，
&也变成了
%26。这就能安全地放到URL里了。 解码的时候，就用
urldecode()：
$decodedString = urldecode($encodedString); echo "解码后: " . $decodedString; // 预期输出: 解码后: 我的名字是 John Doe & Co.!
一切又回到了原点。
立即学习“PHP免费学习笔记（深入）”；
但有时候，你会遇到另一种情况，比如要构建一个RESTful API的路径，或者处理HTTP请求头中的某些字段，这时候
+代表空格可能就不是你想要的了，你可能更希望空格也被编码成
%20。这时，
rawurlencode()和
rawurldecode()就派上用场了。它们遵循的是RFC 3986（或者更早的RFC 1738和RFC 2396）标准，也就是URL的路径部分通常使用的编码方式。
$originalStringRaw = "我的名字是 John Doe & Co.!"; $encodedStringRaw = rawurlencode($originalStringRaw); echo "Raw编码后: " . $encodedStringRaw; // 预期输出: Raw编码后: %E6%88%91%E7%9A%84%E5%90%8D%E5%AD%97%E6%98%AF%20John%20Doe%20%26%20Co.%21
注意看，这里的空格变成了
%20，这才是符合URL路径语义的。 解码当然就是
rawurldecode()：
$decodedStringRaw = rawurldecode($encodedStringRaw); echo "Raw解码后: " . $decodedStringRaw; // 预期输出: Raw解码后: 我的名字是 John Doe & Co.!
所以，简单来说，这两对函数就是PHP处理URL编码解码的基石。选择哪一对，就看你具体的使用场景和遵循的规范了。
JTBC网站内容管理系统5.0.3.1
下载
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
urlencode()与rawurlencode()：细微之处的差异何在？
这大概是PHP开发者在处理URL编码时最常遇到的一个“小坑”了，或者说，是一个需要理解清楚的知识点。表面上看，它们都把特殊字符转换成
%xx的形式，但核心区别就在于如何处理空格。
urlencode()函数，它的设计初衷更多是为HTML表单的
application/x-www-form-urlencoded类型服务。在这种编码规范下，空格（space）会被编码成加号（
+）。这其实是一种历史遗留，因为在早期的网页表单提交中，用
+来表示空格比
%20更节省字节（虽然现在看来这点优化微不足道了）。但问题是，当这个
+号出现在URL的路径部分时，它并不会被浏览器或服务器解析成空格，反而可能被当作一个普通的字符
+。这就容易导致一些意想不到的路径错误或者资源找不到的问题。
而
rawurlencode()则更严格地遵循了RFC 3986（URI通用语法）标准。在这个标准里，URL中的空格必须被编码成
%20。它不会将空格转换为
+，也不会对一些“安全”字符（如
-,
_,
.,
~）进行编码。这使得
rawurlencode()在构建URL的路径部分、或者需要严格遵守RFC规范的场景（比如OAuth签名、一些RESTful API请求）时，是更安全、更推荐的选择。
我个人在工作中，如果不是明确知道对方系统期望
+作为空格，我通常会倾向于使用
rawurlencode()。因为
%20的语义更清晰，也更符合现代Web开发的规范。比如，你在构建一个包含空格的文件名下载链接时，用
rawurlencode()就能避免很多麻烦。当然，如果你正在处理从HTML表单提交过来的数据（通过
$_GET或
$_POST），PHP会自动帮你对这些数据进行解码，所以你直接使用通常是没问题的。但如果你要自己手动构建URL参数，并且这些参数可能包含空格，那么记住这个区别就非常重要了。
处理URL参数时常见的编码陷阱与规避策略
URL编码这事儿，看起来简单，但实际操作中还是有不少坑的。我见过最常见的几个问题，往往都和“过度编码”或者“编码不一致”有关。
一个经典的陷阱是重复编码。想象一下，你有一个已经经过
urlencode()编码的字符串，然后你又把它作为参数传递给另一个需要
urlencode()的函数或系统。结果就是，原本的
%号可能被再次编码成
%25。例如，
%20变成了
%2520。当最终解码时，你可能只解码了一次，导致内容仍然是乱码或者不正确。 规避策略：
- 只编码一次，且只在需要时编码。 在将数据放入URL之前进行编码，在从URL中取出数据之后立即解码。不要在中间环节反复编码。
- 明确输入数据的状态。 在处理任何字符串时，先确定它是否已经编码过。如果是不确定，可以尝试解码一次，然后判断是否需要再次编码。当然，这有点笨，最好的方式是建立清晰的编码/解码流程。
-
使用正确的解码函数。 如果你用
rawurlencode()
编码，就用rawurldecode()
解码；如果用urlencode()
编码，就用urldecode()
解码。虽然它们在处理%xx
上是相似的，但在+
和%20
上是不同的。
另一个陷阱是字符集问题。PHP的
urlencode()和
rawurlencode()默认是基于ISO-8859-1（或称为Latin-1）进行操作的。但现在绝大多数网页和系统都使用UTF-8。如果你的字符串是UTF-8编码的，而PHP在编码时却按ISO-8859-1来处理，那么中文字符或者其他非ASCII字符就会出现乱码。 规避策略：
-
确保所有字符串都是UTF-8编码。 这是现代Web开发的黄金法则。在进行URL编码之前，确保你的字符串已经是UTF-8。如果不是，可以使用
mb_convert_encoding()
函数进行转换。// 假设 $str 是 GBK 编码的 // $str = mb_convert_encoding($str, 'UTF-8', 'GBK'); $encoded = urlencode($str); // 此时 $str 应该是 UTF-8
-
明确告知浏览器或服务器字符集。 虽然URL编码本身不直接包含字符集信息，但在HTTP响应头中设置
Content-Type: text/html; charset=UTF-8
，或者在HTML `
