区别在于返回值，即:

urlencode ():

返回一个字符串，其中all 非字母数字字符，-_除外。 已替换为百分比(%) 符号后面跟着两个十六进制数字和 空格编码为加号(+)。它 的编码方式与 从WWW表单发布的数据是 编码，这和 应用程序/ x-www-form-urlencoded 媒体类型。这与»不同 RFC 1738编码(参见rawurlencode()) 因为历史原因，空间 编码为加号(+)。

rawurlencode ():

返回一个字符串，其中all 非字母数字字符，-_除外。 已替换为百分比(%) 符号后面跟着两个十六进制数字。这 编码是否在»RFC中描述 保护文字字符 避免被解释为特殊URL 分隔符，以及用于保护url 避免被传播破坏 具有字符转换的媒体(如 一些电子邮件系统)。

两者非常相似，但后者(rawurlencode)将用'%'和两个十六进制数字替换空格，这适用于编码密码等，其中'+'不是例如:

echo '<a href="ftp://user:', rawurlencode('foo @+%/'),
     '@ftp.example.com/x.txt">';
//Outputs <a href="ftp://user:foo%20%40%2B%25%2F@ftp.example.com/x.txt">

选择其中一种而不是另一种的一个实际原因是，如果您将在另一种环境中使用结果，例如JavaScript。

在PHP中urlencode('test 1')返回'test+1'，而rawurlencode('test 1')返回'test%201'作为结果。

但如果你需要在JavaScript中使用decodeURI()函数“解码”这个，那么decodeURI(“test+1”)会给你“test+1”，而decodeURI(“test%201”)会给你“test 1”作为结果。

换句话说，在PHP中由urlencode编码到加号("+")的空格(" ")将不会被JavaScript中的decodeURI正确解码。

在这种情况下，应该使用rawurlencode PHP函数。

1. 到底有什么不同

唯一的区别是对待空格的方式:

基于遗留实现的Urlencode -将空格转换为+

rawurlencode -基于RFC 1738将空格转换为%20

造成这种差异的原因是因为+在url中是保留且有效的(未编码)。

2. 首选哪种?

我真的很想知道选择一个而不是另一个的一些原因……我希望能够选择一个，并永远使用它，而不是大惊小怪。

有道理，在做这些决定时，我有一个简单的策略，我将与你分享，希望它能有所帮助。

我记得是HTTP/1.1规范RFC 2616，它要求“宽容应用程序”

客户端应该容忍状态行和服务器的解析 当解析Request-Line时。

当面对这样的问题时，最好的策略总是尽可能多地消费和生产符合标准的产品。

所以我的建议是使用rawurlencode来生成符合标准的RFC 1738编码字符串，并使用urldecode来向后兼容并容纳您可能遇到的任何消费。

现在你可以相信我的话，但让我们证明一下，好吗?

php > $url = <<<'EOD'
<<< > "Which, % of Alice's tasks saw $s @ earnings?"
<<< > EOD;
php > echo $url, PHP_EOL;
"Which, % of Alice's tasks saw $s @ earnings?"
php > echo urlencode($url), PHP_EOL;
%22Which%2C+%25+of+Alice%27s+tasks+saw+%24s+%40+earnings%3F%22
php > echo rawurlencode($url), PHP_EOL;
%22Which%2C%20%25%20of%20Alice%27s%20tasks%20saw%20%24s%20%40%20earnings%3F%22
php > echo rawurldecode(urlencode($url)), PHP_EOL;
"Which,+%+of+Alice's+tasks+saw+$s+@+earnings?"
php > // oops that's not right???
php > echo urldecode(rawurlencode($url)), PHP_EOL;
"Which, % of Alice's tasks saw $s @ earnings?"
php > // now that's more like it

PHP似乎就是这么想的，尽管我从来没有遇到过有人拒绝这两种格式中的任何一种，但我想不出更好的策略来作为您的实际策略，不是吗?

nJoy !

简单的 * rawurlencode路径 - path是“?”之前的部分。 -空格必须编码为%20 * urlencode查询字符串 —查询字符串为?后的部分。 -空格更好地编码为“+” = rawurlencode通常更兼容

空格编码为%20 vs. +

在大多数情况下，我看到使用rawurlencode()的最大原因是因为urlencode将文本空格编码为+(加号)，而rawurlencode将它们编码为常见的%20:

echo urlencode("red shirt");
// red+shirt

echo rawurlencode("red shirt");
// red%20shirt

我特别见过某些接受编码文本查询的API端点期望看到空格%20，因此，如果使用加号则失败。显然，这在不同的API实现之间是不同的，您的里程可能会有所不同。

urlencode:这与 »RFC 1738编码(见 Rawurlencode())用于历史 原因是，空格被编码为加号 (+)的迹象。