PHP将整型转为十六进制的技巧分享

本文深入解析了PHP中整型转十六进制的多种方法及其实际应用陷阱：dechex()虽性能最优但仅限非负整数且无格式控制；sprintf()灵活支持前缀、补零与负数（补码形式，但跨平台不可靠）；超大整数必须依赖GMP或BCMath扩展避免精度丢失；更关键的是，开发者常忽视转换后的使用场景——大小写不一致、缺失0x前缀、二进制存储误用字符串、未校验输入合法性等细节，往往导致数据库查询失败、前后端校验不通过或存储空间浪费等隐蔽问题，真正考验功力的不是“怎么转”，而是“转完之后如何安全、一致、高效地落地”。

用 dechex() 最快，但只支持非负整数

PHP 里最直接的整型转十六进制字符串方法就是 dechex()，它把十进制整数转成小写、无前缀的 hex 字符串。比如 dechex(255) 返回 "ff"。

注意它不处理负数：传入 -1 会返回 "0"（不是补码表示），也不接受浮点数——传 3.14 会被截断为 3，然后转成 "3"。

• 只适用于 0 到 PHP_INT_MAX 范围内的整数（32 位系统上限约 21 亿，64 位约 9×10¹⁸）
• 结果不含 "0x" 前缀，也不补零；需要大写可用 strtoupper(dechex($n))
• 性能极好，底层 C 实现，比格式化函数快一个数量级

要带前缀、补零或处理负数？用 sprintf()

当需要控制输出格式（比如固定 8 位、加 "0x"、支持负数补码语义），sprintf() 更灵活。它本质是格式化输出，"%x" 对应小写 hex，"%X" 对应大写，"%08x" 表示至少 8 位、不足左补零。

对负数，sprintf("%x", -1) 在大多数系统上会按补码解释（例如 64 位 Linux 返回 "ffffffffffffffff"），但这依赖平台和编译器，**不可跨平台保证**。

• sprintf("%04x", 255) → "00ff"；sprintf("0x%02X", 10) → "0x0A"
• 传入浮点数会自动截断（不是四舍五入），sprintf("%x", 3.9) 得 "3"
• 比 dechex() 略慢，但差异在纳秒级，日常完全可忽略

超大整数（> PHP_INT_MAX）必须用 gmp_strval() 或 bcmod() 手动拆解

PHP 的整型有平台限制，一旦数字超过 PHP_INT_MAX（比如 100! 或某些哈希值），原生函数会静默转成 float，精度丢失，dechex() 和 sprintf() 都不可靠。

这时得用任意精度扩展：启用 GMP 后，gmp_strval($gmp_num, 16) 是最稳的方案；没 GMP 就只能靠 bcmod() + 循环取余模拟，代码更长、速度更慢。

• gmp_strval(gmp_init("123456789012345678901234567890"), 16) 安全返回完整 hex
• 别试图用 (string)$bigInt 再喂给 dechex() —— 字符串转整型时已溢出
• Web 环境中未启用 GMP 时，这个坑非常隐蔽：看起来有输出，但末几位全是错的

常见错误：混淆字符串和数值、忽略大小写与前缀需求

很多人卡在“为什么我存进数据库的 hex 查出来不对”，其实问题不在转换函数，而在后续使用环节。

比如用 dechex() 得到 "ff"，直接拼 SQL："WHERE hash = '$hex'"，如果字段是 BINARY 类型，就得确保传的是 "\xff" 而不是字符串 "ff"；又或者前端期望大写 "FF"，后端却返回小写，导致校验失败。

• hex 字符串比较时注意大小写：MySQL 的 HEX() 默认大写，PHP dechex() 小写，混用会匹配不上
• 存二进制数据别用 hex 字符串代替 pack("H*", $hex)，否则占三倍空间
• 从 URL 或表单拿到的 hex 字符串（如 "a1b2c3"），别漏掉验证是否全为 [0-9a-fA-F]，否则 hexdec() 可能返回 0

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。