PHP Randomizer shuffleBytes 为什么会把中文打乱成乱码

我第一次看到 Random\Randomizer::shuffleBytes() 把中文变成乱码时，直觉是随机引擎“算错了”。其实它完成的是函数名承诺的事情：把输入字符串里的字节做均匀置换。中文在 UTF-8 中通常由多个连续字节组成，顺序一旦被拆散，输出就不再是原来的字符序列。

官方地址：https://www.php.net/manual/en/random-randomizer.shufflebytes.php

如果目标是打乱中文、emoji 或其他多字节文本，不能直接用 shuffleBytes()。先用 mb_str_split($text, 1, 'UTF-8') 拆成字符数组，再用 shuffleArray() 打乱，最后拼回字符串。

先看清 shuffleBytes() 到底在打乱什么

PHP 手册把这个方法定义为“按字节获取字符串的一个排列”。它不会把输入识别成汉字、单词或 emoji，也不会维护字符边界。ASCII 文本的字节通常各自就是一个字符，所以看起来可能“正常”；中文、日文、重音字符和 emoji 则由多个字节共同编码，风险会立刻暴露。

可以把一段 UTF-8 文本看成两层：外层是 PHP 字符串保存的字节序列，内层才是解码器解释出来的字符。shuffleBytes()只在外层工作。它保证的是每个输入字节都参与一次置换，不保证结果仍然能被 UTF-8 解码。

为什么中文会变成乱码，而不是“随机换位置”

一个中文字符的 UTF-8 编码由多个字节组成，首字节和后续字节各有自己的位置规则。将这些字节与其他字符的字节混合后，解码器可能遇到三种结果：序列无效并显示替换字符；字节碰巧组成了另一个合法字符；部分 ASCII 标点仍然可以正常显示。于是输出看起来像是“只坏了一部分”，但根因仍是字符内部的字节关系被破坏。

下面的示例只用于展示 API 的语义，不应把输出当成固定结果。随机置换每次都可能不同，乱码的具体形态也会变化。

shuffleBytes($text);

// 这里检查的是编码合法性，不是检查文本是否仍然有原来的语义。
$isValidUtf8 = mb_check_encoding($shuffled, 'UTF-8');
echo $isValidUtf8 ? '仍是合法 UTF-8' : 'UTF-8 字节序列已损坏';
?>

按字符打乱：mb_str_split() 配合 shuffleArray()

需要打乱中文字符顺序时，应先把字符串转换成字符数组。mb_str_split()会依据指定编码按字符切分，而不是像 str_split() 那样按单个字节切分；随后 shuffleArray()只交换数组元素，中文字符内部的 UTF-8 字节不会被拆开。

shuffleArray($characters);
$result = implode('', $shuffledCharacters);

echo $result;
?>

这里的随机结果仍然不可预测，但每个数组元素都是完整字符，因此不会出现“半个汉字被搬走”的情况。shuffleArray()返回新的排列，原始数组不会被修改；这也让原文和随机结果可以分别保留。

还要注意 code point 和用户感知字符的区别

mb_str_split()适合中文、普通拉丁字符和大多数独立 emoji 的字符级重排，但它处理的是编码字符单元，不等于所有用户眼中的“一个字”。带组合音标、肤色修饰符或 ZWJ 的 emoji 可能由多个 Unicode code point 组成。若产品要求“一个看起来的符号始终整体移动”，应改用支持 grapheme cluster 的方案，并确认运行环境启用了相应扩展。

另外，打乱文字只适合演示、游戏效果或非语义展示。它不适合把密码、令牌、验证码或原始二进制数据当作文本处理；需要生成随机字符串时，应使用面向该任务的安全随机 API，而不是把现有文本打乱。

常见的两个误区

误区一：把乱码归咎于随机引擎。引擎只负责提供随机性，破坏字符边界的是调用者选择了字节级 API。误区二：用 mb_check_encoding() 修复乱码。它只能告诉你字节流是否符合指定编码，不能把已经丢失的字符顺序还原。修复应回到输入端，选择正确的拆分单位。

延伸问题

为什么英文看起来没问题？基础 ASCII 字符通常对应一个字节，字节置换不会拆开多字节字符，所以更容易保持可显示状态。

用 str_split() 能替代 mb_str_split() 吗？不能把它当作中文安全方案；str_split()按字节切分，仍可能把一个 UTF-8 字符拆成多个元素。

乱码出现后还能恢复吗？如果只剩损坏后的字节流，通常无法可靠恢复。保留原文，并在展示层按合适的字符边界打乱，才是稳妥做法。