博客 (3)

今天发现在 .NET Framework 和 .NET 9 中使用 System.Uri.EscapeDataString() 方法对字符串进行编码，会产生不同的结果。

譬如“(”符号，前者视其为非保留字符，不进行转义，后者视为保留字符，转义为“%28”。

原因是 .NET Framework 4.8 主要遵循 RFC 2396，而 .NET 9 遵循 RFC 3986。

在跨平台签名验证场景中，对 URL 编码的一致性要求极高，任何细微差别都会导致签名校验失败。

以下是以 RFC 3986 标准为核心、优先使用各平台内置的高一致性方案。

对于 .NET 9，直接使用 Uri.EscapeDataString()。

string encodedData = System.Uri.EscapeDataString(dataToEncode);

对于 .NET Framework，以下是一个遵循 RFC 3986 严格标准的自定义编码方法示例。

static string Rfc3986EscapeDataString(string input)
{
    // 定义 RFC 3986 中明确的未保留字符集（不编码）
    var unreservedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";

    var result = new StringBuilder();
    byte[] data = Encoding.UTF8.GetBytes(input); // 统一转换为 UTF-8 字节

    foreach (byte b in data)
    {
        char currentChar = (char)b;
        // 如果是未保留字符，直接输出
        if (unreservedChars.IndexOf(currentChar) != -1)
        {
            result.Append(currentChar);
        }
        else
        {
            // 否则，进行百分号编码（%XX，大写）
            result.Append('%').Append(b.ToString("X2"));
        }
    }
    return result.ToString();
}

对于 PHP，直接使用内置的 rawurlencode() 函数。这个函数的设计初衷就是严格遵循 RFC 3986 标准。

$encoded_data = rawurlencode($data_to_encode);

对于 JavaScript，encodeURIComponent 函数严格遵循 RFC 3986 标准。

let encodedData = encodeURIComponent(dataToEncode);

重要提示：无论使用哪种语言，务必在编码前明确指定字符串使用 UTF-8 编码。编码不一致是导致乱码和签名失败最常见的原因之一 。

实例化方法一：DbSearcher(String dbFile, QueryType queryType, String key)

实例化方法二：DbSearcher(InputStream is, QueryType queryType, String key)

• 方法一通过传入文件路径来实例化，方法二通过传入文件流来实例化；

• 当 queryType 为 MEMORY 时，方法一和方法二只有在实例化时有性能差别，差别在于将指定路径的文件读到内存中保存；在执行 Search 方法时无性能差别，因为都是在内存中执行查找；

• queryType 为 MEMORY 和 BTREE 的差别在于前者是在内存中查找，速度快但占内存，后者是在文件中查找，速度慢但省内存。

错误：Padding is invalid and cannot be removed.

原因：可能是数据库文件与密钥不一致。