如何生成编码签名值的256位二进制表示？

首先明确基础长度对应关系：

• SHA256算法的原生输出为256比特（即32字节）长度的原始二进制数据，和你解码signature字段得到的长度完全匹配。你之前复现得到的32位长度结果，本质是操作环节存在偏差：要么是误将MD5输出的32字符长度十六进制串当成了SHA256结果，要么是错误地对SHA256输出做了额外格式转换。

你复现失败的核心原因基本集中在以下几类：

• 编码流程错误：目标signature是直接对32字节的原始哈希二进制结果做Base64编码得到，没有将哈希值转十六进制字符串的中间步骤，如果你先把SHA256结果转成十六进制串再做Base64，最终长度和内容都会完全不匹配。
• 签名算法类型错误：这类接口签名几乎不会使用无密钥的裸SHA256，绝大多数采用的是HMAC-SHA256算法，需要传入接口分配的专属Secret密钥参与运算，无密钥运算得到的结果不可能匹配。
• 签名原文拼接规则错误：服务端不会直接对完整请求裸做哈希，会遵循固定的拼接规则：比如将请求参数按ASCII码排序后按key=value&key=value格式拼接、追加请求方法、请求路径、时间戳、随机nonce值等，字段顺序错误、遗漏字段、大小写不匹配、JSON序列化格式差异（比如多余空格、键顺序不一致）都会导致最终哈希结果完全不同。
• 遗漏隐式参与签名的字段：部分签名逻辑会把特定请求头（比如User-Agent、Content-Length）、当前时间戳、客户端设备标识等不在请求体里的字段纳入签名计算范围，漏加这类字段也无法复现结果。

复现验证步骤 #

1. 对目标signature字段做Base64解码，直接读取解码后的字节长度，确认其为32字节，不要将解码结果转成普通字符串查看。
2. 运算哈希时不要做十六进制转换，直接读取哈希函数输出的原始二进制字节流，和上一步解码得到的字节做逐位对比。
3. 优先排查HMAC-SHA256算法的密钥正确性，再逐字段核对签名原文的拼接规则，从最简参数组合开始逐步加字段验证。

内容的提问来源于stack exchange，提问作者Martijn Deleij