UrlEncode 不能直接套用 HttpUtility.UrlEncode 是因默认 UTF-8 编码与老系统 GB2312 解码不一致，导致乱码；需显式指定 Encoding.GetEncoding("GB2312") 或改用 Uri.EscapeDataString（仅 UTF-8）。
UrlEncode 为什么不能直接套用 HttpUtility.UrlEncode？
因为默认编码是 UTF-8，但老系统、某些 WebForm 页面或遗留接口可能按 GB2312 解码——两边不一致就显示乱码。不是函数错了，是编码契约没对齐。
常见错误现象：%C4%FA%C3%F7 这种 URL 片段在浏览器地址栏里显示成“”或方块，在服务端解出来是乱码字节；或者本地调试正常，上线后中文参数全变问号。
- 如果目标服务明确要求 GB2312 编码（比如某些老版 IIS + ASP.NET WebForms 接口），必须显式传入
Encoding.GetEncoding("GB2312") -
Uri.EscapeDataString是严格按 RFC 3986 的 UTF-8 实现，不接受编码参数，别拿来替代HttpUtility.UrlEncode - .NET Core / .NET 5+ 中
HttpUtility不再默认可用，需安装System.Web.HttpUtilityNuGet 包，且仅限 Windows 兼容模式下行为稳定
ASP.NET Core 里怎么安全做 URL 中文编码？
别碰 HttpUtility，它在跨平台场景下行为不可靠。优先用 Uri.EscapeDataString，但它只认 UTF-8，所以前提是前后端都约定 UTF-8 —— 这是现代系统的事实标准。
使用场景：API 请求拼接、重定向跳转、生成带中文参数的链接（如 /search?q=张三）。
- 拼接前先确保原始字符串是
string类型，不要从byte[]或非 UTF-8 字符串误转而来 - 避免对整个 URL 调用
EscapeDataString，只编码参数值部分，比如"q=" + Uri.EscapeDataString(query)，否则/和?也会被转义 - 如果必须兼容 GBK 系统，得自己封装：先用
Encoding.GetEncoding("GBK").GetBytes(str)，再逐字节转%XX格式，HttpUtility.UrlEncode在 .NET Core 中无法直接支持该编码
解码时 HttpUtility.UrlDecode 报“无效的 URI: 未找到标签”的错？
这不是编码问题，是传了非法字符串进去——比如 URL 片段里混入了未编码的空格、换行、控制字符，或者 % 后面跟的不是两个十六进制字符（如 %G1、% 单独出现）。
典型触发点：前端 JS 用 encodeURI 编码后，后端用 UrlDecode 解，但两者规则不等价（encodeURI 不编码 / ? : @ & = + $ , #，而 UrlEncode 会）。
- 永远校验输入：解码前检查字符串是否为
null、空或含非法%序列（可用正则%[0-9A-Fa-f]{2}预扫） - 若来源不可控（如日志回放、第三方回调），改用
TryDecode类辅助方法，或捕获ArgumentException后降级处理 - 不要在未验证的 query string 上直接调用
UrlDecode，尤其当参数来自Request.QueryString以外渠道时
前后端联调时中文参数总对不上？先盯住这三点
90% 的乱码问题其实出在链路中间某个环节悄悄做了二次编码或错误解码，而不是最开始那步。
- 浏览器地址栏显示的是已解码后的可读文本，但实际发出的请求 URL 是编码过的，用开发者工具 Network 标签页看
Request URL原始值，别信地址栏 - ASP.NET 的
Request.QueryString["key"]默认已自动解码（按当前页面编码），不要再套一层UrlDecode，否则会解两次，中文变乱码 - Postman 或 curl 测试时，如果手动拼 URL，记得只编码 value 部分；如果用 form-data 或 raw JSON，就根本不用 URL 编码——那是 GET 才需要的事
最易被忽略的是：IIS 或反向代理（如 Nginx）可能对 URL 做预处理，特别是开启 requestNormalization 或启用了某些安全模块时，会静默修正或拒绝含“可疑”编码的请求。真遇到死活对不上的情况，先抓包看 wire 上的真实字节流。
