utf-8和gbk的“张三”md5结果不同，是因为md5()只处理字节流：utf-8下“张三”为6字节（\xe5\xbc\xa0\xe4\xb8\x89），gbk下为4字节（\xd5\xc5\xc8\xfd），输入字节不同导致哈希值必然不同。
PHP 7.0 的 md5() 函数本身没有编码感知能力，它只处理字节流；所谓“不同编码字符串结果不一致”，根本不是函数问题，而是你传给它的字节序列本来就不同。
为什么 UTF-8 和 GBK 的“张三” md5 结果不同
MD5 不认识“字符”，只认字节。md5() 输入是 string 类型，而 PHP 7.0 中的 string 就是一串原始字节 —— 它不会自动转码。所以：
-
md5("张三")的结果，完全取决于这 2 个汉字在当前脚本文件里实际保存成什么字节 - 如果 PHP 文件用 UTF-8 编码保存，“张三”是
\xe5\xbc\xa0\xe4\xb8\x89（6 字节），md5()算的就是这 6 字节 - 如果文件用 GBK 编码保存，“张三”变成
\xd5\xc5\xc8\xfd（4 字节），算出来哈希值必然不同 - 同理，HTTP 请求体、数据库查询结果、JSON 解析后的字段，只要编码链路中某处用了非 UTF-8，字节就已失真
如何确保所有环境输入字节一致
统一到 UTF-8 字节流是最直接、最可控的做法。关键不是“告诉 PHP 用什么编码”，而是**在调用 md5() 前，把数据强制转成 UTF-8 字节**：
- 检查 PHP 文件本身：用编辑器确认保存编码为 UTF-8 无 BOM
- 处理 HTTP 输入：
$str = mb_convert_encoding($_GET['name'], 'UTF-8', 'auto');（'auto'能识别 GBK/GB2312/UTF-8） - 处理数据库字段：连接时加
charset=utf8mb4，或查出后用mb_convert_encoding($row['name'], 'UTF-8', 'GBK') - 处理 JSON：
json_decode($json, true, 512, JSON_UNESCAPED_UNICODE)确保中文不被转义，再确认源 JSON 是 UTF-8 编码 - 避免隐式截断：
iconv('GBK', 'UTF-8//IGNORE', $str)比iconv('GBK', 'UTF-8', $str)更安全，可跳过非法字符
调试时怎么快速验证字节是否真的一致
别只看 echo $str，要观察真实字节：
- 打印十六进制：
bin2hex($str)—— 两边都执行，对比输出是否完全一样 - 检查长度：
strlen($str)和mb_strlen($str, 'UTF-8')若不等，说明含多字节字符且编码可能错位 - 排查不可见字符：
var_dump(str_split($str))看每个字符的 ASCII 或 Unicode 码点，尤其注意\x00、\xef\xbb\xbf（BOM）、\r\n与\n差异 - 跨语言对接时，让对方也提供
bin2hex(input)结果，比对源头字节
真正难的不是写对一行 md5()，而是保证从用户输入、网络传输、存储读取到最终喂给 md5() 的那串字节，在整个流程中没被任何环节悄悄改写 —— 这种一致性必须靠编码链路的每一步显式控制，而不是依赖“默认”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
