PHP二进制处理乱码本质是误将字节流当字符串输出；关键要区分二进制与文本：unpack/pack格式须精准（c/C、n/v、e/f等），禁用echo/print/json_encode，文件读写用rb模式并校验BOM，数据库存BLOB且禁用字符集转换。
PHP处理二进制数据时出现的“乱码”，本质不是字符乱码，而是把二进制字节流误当作字符串去 echo、print 或直接拼接——结果浏览器或终端用 UTF-8 解释一串非文本字节，自然显示为 、 或一堆不可见控制符。关键不在“解码”，而在“别当字符串用”。
unpack 时格式字符串写错导致解析值异常
这是最隐蔽也最常踩的坑：格式字符大小写敏感，且隐含字节序和符号规则。
-
c是有符号字符（-128 ~ 127），C是无符号（0 ~ 255）；混用会导致温度、电压等传感器值突然变成负数 -
n（大端无符号短整）和v（小端无符号短整）不能互换；网络协议多用n，x86 设备日志常用v - 浮点数必须用
e（小端单精度）或f（大端单精度）；用N/V强转会得到完全错误的整数值 - 示例：设备返回
"\x00\x00\x80\x3F"是 float 1.0（IEEE 754 大端），应写unpack('f', $data)，而非unpack('N', $data)
pack/unpack 后直接 echo 二进制字符串
一旦 pack() 出来的是纯二进制（比如图片头、加密密文、协议包），绝不能 echo 或 print ——它不是给人读的，是给 socket、file 或硬件发的。
- 若要调试查看内容，先用
bin2hex($binary)转成可读十六进制字符串，再输出 - 若需保存为文件（如生成 PNG），用
file_put_contents('out.png', $binary)，而非file_put_contents('out.png', (string)$binary) - 若误将二进制当字符串传给
json_encode()，会触发 warning 并返回null - 用
strlen()检查长度是安全的，但mb_strlen()在默认编码下可能截断或报错
从文件/fread 读取二进制时被自动转码
PHP 默认以文本模式打开文件，某些系统（尤其 Windows）可能对 \r\n 做自动转换；更危险的是，若文件含 BOM 或编辑器偷偷加了 UTF-8 BOM（\xEF\xBB\xBF），fread() 读出的字节流开头就多了 3 个非法前缀。
立即学习“PHP免费学习笔记（深入）”；
- 务必用
fopen($path, 'rb')（b表示 binary mode），禁用所有换行/编码转换 - 读取后第一件事：用
ord($data[0]) === 0xEF && ord($data[1]) === 0xBB && ord($data[2]) === 0xBF检查 BOM；如有，用substr($data, 3)切掉 - 不要依赖
file_get_contents()的默认行为；如需确保二进制，显式加stream_context_create(['http' => ['binary' => true]])（仅限 HTTP 流） - 用
hexdump -C your_file.bin | head -n 3在终端确认原始字节，比 PHP 输出更可信
与数据库/HTTP 交互时混淆二进制和文本字段
MySQL 的 BLOB 和 TEXT 类型底层都是字节流，但驱动层可能按连接 charset 自动转码——尤其是用 PDO 插入 pack 出来的二进制时，若没设 PDO::ATTR_EMULATE_PREPARES => false，PDO 可能把它当 UTF-8 字符串二次编码。
- 存二进制数据进 MySQL，字段必须是
BLOB/TINYBLOB，而非TEXT/VARCHAR - PDO 连接 DSN 中加
;charset=binary（部分驱动支持），或执行$pdo->exec("SET NAMES binary") - 从数据库读出 BLOB 后，别用
mb_convert_encoding()或iconv()处理——它们只适用于文本，对二进制是破坏性操作 - HTTP POST 上传二进制（如固件），用
php://input直接读原始流，别碰$_POST或$_FILES（后者已走 multipart 解析）
真正容易被忽略的点：二进制处理全程不涉及任何“字符集转换函数”（iconv、mb_convert_encoding、utf8_encode）。只要你在 unpack 之后、pack 之前，对变量做了任何这类调用，基本就等于往二进制里掺沙子——不是乱码，是数据损坏。
