application/x-www-form-urlencoded 和 URL 查询串差在哪？
很多接口文档只写「POST 表单」，却没写清是 urlencoded 还是 JSON，导致前端 axios 默认发 JSON、网关却按表单解析，日志里全是空 body。表单体编码与 query 语法相似，但出现在 HTTP 实体里，并受 Content-Type 与 charset 双重约束；UTF-8 与 ISO-8859-1 混用一次，中文姓名就变成 replacement character。自动化用例、Webhook 重放、老系统对接常要手写这一串；用在线工具按 key 排序或按文档顺序生成，再贴进 curl「--data-urlencode」，能和对端抓包逐字节对齐。对项目经理与业务接口人，这是把「参数到了吗」变成可验收事实的关键一步，而不是群里互相甩截图。支付回调、爬虫模拟登录、老网关只认表单体时，大家会搜「application x-www-form-urlencoded 中文乱码」「post 表单 验签 失败」：把 charset、键是否重复、空格用加号还是百分号三条写进联调清单，比会后再开复盘便宜得多，也能让外包与内网 QA 用同一套黄金样例回归。再补一条：凡是「日志里 body 为空但状态码仍是 200」的工单，十有八九是内容类型与字节流对不上，先别急着改业务代码。把「先核对 Content-Type 与原始字节」写成一级排障步骤，可少误伤数据库。
如何按接口文档组装 urlencoded 请求体并通过抓包验收
- 确认 Content-Type 是否必须带 charset=UTF-8，以及是否禁止 chunked 以外的传输编码；列出全部键名与是否允许多值，空字符串与缺省字段在文档中的语义要标红。
- 对每个 value 单独做百分号编码（含空格与换行），再按文档约定用「&」连接；若签名要求「原始表单字节流」，切勿在签名后再改键序或插入额外空格。
- 用 curl 与对端提供的沙箱各发一次，对比服务端日志中的 raw body；通过后把样例请求与解码表写入联调 wiki，并给 QA 一条可复制的负例（如缺 charset）用于回归。
表单体编码常见问题
Spring 把数组解析成单个字符串，是不是我们 urlencoded 里不该写重复键名？
应以消费端绑定规则为准：有的框架要「id=1&id=2」，有的要「id[]=1」；在契约测试里固定一种写法并写进 OpenAPI 或内部接口表，不要靠口头约定。用在线解码验证服务端实际收到的键重复次数。
同一字段既要 JSON 字符串又要外层表单，内层引号要不要二次编码，否则 Tomcat 报非法字符？
内层 JSON 作为单一 value 时应整体编码一次；若框架自动 JSON 序列化又自动 urlencode，需关闭其中一层以免双重转义。以服务端反序列化结果为准做 golden test。
大文本超过网关 body 限制，改成 multipart/form-data 后旧签名算法还能用吗？
multipart 的字节布局与 urlencoded 完全不同，签名算法通常要重新定义边界与包含哪些 part；不能沿用「对整个 x-www-form-urlencoded 串 HMAC」的旧脚本。与网关同事确认最大 body 与超时。
Webhook 回调要求「application/x-www-form-urlencoded」且带 HMAC 头，重放攻击防护里时间戳字段要不要也编进签名字节？
一般将「方法 + path + 排序后的表单键值 + 时间戳」按文档拼接待签串；时间戳本身若作为表单字段出现，应与文档示例同一编码规则。用固定时钟向量在 CI 里校验签名，避免线上漂移。
PHP 里 magic_quotes 已废弃，为何仍出现反斜杠被吃掉导致 JSON value 断裂？
多为中间层再次 stripslashes 或错误 charset 解码；应在最早入口记录 raw bytes 再分析。不要用「肉眼对两个字符串像不像」验收，应用十六进制 diff。