HttpUtility.UrlEncode 是否符合“x-www-form-urlencoded”的规范？

Per MSDN http://msdn.microsoft.com/en-us/library/ms525738.aspx

URLEncode 转换字符如下：

• 空格 ( ) 转换为加号 (+)。
• 非字母数字字符将转义为其十六进制表示形式。

与以下类似，但不完全相同W3C http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1

应用程序/x-www-form-urlencoded

这是默认的内容类型。使用此内容类型提交的表单必须按如下方式编码：

1. 控件名称和值被转义。空格字符被替换 按“+”，然后保留字符 如中所述被转义RFC1738 http://www.w3.org/TR/html401/references.html#ref-RFC1738, 第 2.2 节：非字母数字 字符被替换为 '%HH'，a 百分号和两个十六进制 代表 ASCII 码的数字 人物。换行符是 表示为“CR LF”对（即 ‘%0D%0A’)。

2. 控件名称/值按照它们在列表中出现的顺序列出 文档。名字是分开的 '=' 和名称/值对的值 彼此之间用“&”分隔。

我的问题是，有没有人做过确定 URLEncode 是否生成有效的 x-www-form-urlencoded 数据的工作？

好吧，您链接到的文档适用于 IIS 6 Server.UrlEncode，但您的标题似乎询问有关 .NETSystem.Web.HttpUtility.UrlEncode http://msdn.microsoft.com/en-us/library/system.web.httputility.urlencode.aspx。使用Reflector这样的工具，我们可以看到后者的实现并确定它是否符合W3C规范。

这是最终调用的编码例程（注意，它是为字节数组定义的，以及采用字符串的其他重载最终将这些字符串转换为字节数组并调用此方法）。您可以为每个控件名称和值调用它（以避免转义保留字符= &用作分隔符）。

protected internal virtual byte[] UrlEncode(byte[] bytes, int offset, int count)
{
    if (!ValidateUrlEncodingParameters(bytes, offset, count))
    {
        return null;
    }
    int num = 0;
    int num2 = 0;
    for (int i = 0; i < count; i++)
    {
        char ch = (char) bytes[offset + i];
        if (ch == ' ')
        {
            num++;
        }
        else if (!HttpEncoderUtility.IsUrlSafeChar(ch))
        {
            num2++;
        }
    }
    if ((num == 0) && (num2 == 0))
    {
        return bytes;
    }
    byte[] buffer = new byte[count + (num2 * 2)];
    int num4 = 0;
    for (int j = 0; j < count; j++)
    {
        byte num6 = bytes[offset + j];
        char ch2 = (char) num6;
        if (HttpEncoderUtility.IsUrlSafeChar(ch2))
        {
            buffer[num4++] = num6;
        }
        else if (ch2 == ' ')
        {
            buffer[num4++] = 0x2b;
        }
        else
        {
            buffer[num4++] = 0x25;
            buffer[num4++] = (byte) HttpEncoderUtility.IntToHex((num6 >> 4) & 15);
            buffer[num4++] = (byte) HttpEncoderUtility.IntToHex(num6 & 15);
        }
    }
    return buffer;
}

public static bool IsUrlSafeChar(char ch)
{
    if ((((ch >= 'a') && (ch <= 'z')) || ((ch >= 'A') && (ch <= 'Z'))) || ((ch >= '0') && (ch <= '9')))
    {
        return true;
    }
    switch (ch)
    {
        case '(':
        case ')':
        case '*':
        case '-':
        case '.':
        case '_':
        case '!':
            return true;
    }
    return false;
}

该例程的第一部分计算需要替换的字符数（空格和非 URL 安全字符）。该例程的第二部分分配一个新的缓冲区并执行替换：

1. URL 安全字符保持原样：a-z A-Z 0-9 ()*-._!
2. 空格转换为加号
3. 所有其他字符都转换为%HH

RFC1738 声明（强调我的）：

因此，只有字母数字、特殊字符“$-_.+!*'(),”和
保留字符用于其保留目的may be used
URL 中未编码。

另一方面，不需要编码的字符
（包括字母数字）可以在特定于方案的内部进行编码
URL 的一部分，只要它们不被用于保留
目的。

允许的 URL 安全字符集UrlEncode是 RFC1738 中定义的特殊字符的子集。也就是说，人物$,丢失并将被编码UrlEncode即使规范说它们是安全的。自从他们may未编码使用（并且不must），它仍然符合对它们进行编码的规范（第二段明确指出了这一点）。

对于换行符，如果输入有CR LF那么将被转义的序列%0D%0A。但是，如果输入只有LF那么就会被逃脱%0A（因此此例程中没有换行符的标准化）。

底线：它满足规范，同时附加编码$,，调用者负责在输入中提供适当规范化的换行符。