WebSocket中文乱码主因是UTF-8字节流在某环节被错误解码，而非单纯编码设置错误；根本在于各环节（JS字符串转UTF-8、BOM处理、多帧解析、URL编码、JSON转义等）的字节与解码方式不匹配。
乱码不是编码没设对，而是 UTF-8 字节流在某个环节被当成别的编码解了——WebSocket 协议本身不协商 charset，只强制要求 payload 是合法 UTF-8 字节序列。
WebSocket send() 传字符串时为什么还会乱码？
浏览器调用 ws.send("你好") 看似简单，但背后有隐式编码：JavaScript 字符串内部是 UTF-16，send() 会自动转成 UTF-8 字节再发。问题出在中间环节：
- 若字符串含 BOM（如
\uFEFF），某些服务端解析器会把它当普通字符吞掉，导致后续字节偏移错乱 - 若字符串来自
input.value且页面 meta 编码声明错误（比如声明为 GBK 但实际存的是 UTF-8），JS 读到的已是损坏值 - 用
JSON.stringify()拼消息但漏了JSON_UNESCAPED_UNICODE，中文变成"\u4f60\u597d"，虽合法但增大体积、触发弱解析器失败
更稳妥的做法是显式控制字节流：const uint8 = new TextEncoder().encode("你好")，再 ws.send(uint8)。
服务端收不到中文或报 invalid frame header
这类错误大概率不是编码问题，而是帧结构被破坏。常见真实原因：
- PHP 手写 WebSocket 时，
unseal()函数没处理多帧合并：一个 TCP 包里塞了 3 个帧，但函数只解第一个，剩下两个的头部被当成了 payload 解，直接错乱 - 客户端发送前没加掩码（mask=1），或 mask key 没参与 payload 异或——协议强制要求客户端发帧必须 mask，服务端校验失败就断连
- 字符串开头混入不可见字符：用
bindec(decbin(ord($str[0])))检查首字节是否为0xEF（UTF-8 BOM），是就用ltrim($str, "\xEF\xBB\xBF")剥离
别急着改编码，先用 Wireshark 抓包看原始十六进制数据：如果服务端收到的是 EF BB BF E4 BD A0（标准 UTF-8），但解出来是乱码，说明解码端用了 GBK；如果收到的是 C4 E3 C0 D2（GBK 字节），那问题出在发送端没转 UTF-8。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
PHP/Python/Java 各语言的 UTF-8 转换关键点
不同语言对“字符串编码”的理解差异极大，不能套用同一套逻辑：
- PHP：变量本身无编码属性，
mb_convert_encoding($str, 'UTF-8', 'GBK')是必须的；utf8_encode()只能转 ISO-8859-1，对 GBK 输入会彻底错乱 - Python3：
str默认 Unicode，发前用.encode('utf-8')得 bytes；接收后若为 bytes，必须用.decode('utf-8')，不能依赖默认编码 - Java：Base64 解码后要指定 charset，
new String(Base64.decode(msg), StandardCharsets.UTF_8)；若用旧 API 如new String(Base64.decode(msg.getBytes("ISO-8859-1")), "utf8")，第一步getBytes("ISO-8859-1")就已损坏原始字节
所有语言都需在发送前做 mb_check_encoding($str, 'UTF-8')（PHP）、isinstance(data, bytes)（Python）或 StandardCharsets.UTF_8.newEncoder().canEncode(str)（Java）校验，而不是等服务端报错才回头查。
URL 参数里的中文怎么传才不乱？
WebSocket 连接 URL 中的 query string（如 ws://host/path?name=张三）必须手动编码，浏览器不会自动处理：
- 前端 JS 必须用
encodeURIComponent("张三")，不能只用encodeURI()（它不编码=和&） - 后端 Java 获取
session.getQueryString()后，要用URLDecoder.decode(qry, "UTF-8")，不是new String(qry.getBytes("ISO-8859-1"), "UTF-8") - Node.js 的
url.parse()默认按 UTF-8 解析 query，但若客户端用了encodeURI错误编码，服务端拿到的仍是损坏字节，得先修复再 decode
最保险的方式是根本不在 URL 里传中文参数，改用连接建立后的第一条文本消息携带认证信息——这样全程可控，且能走完整 UTF-8 校验链。
真正难的不是选哪个编码函数，而是确认每个环节的输入字节和预期解码方式是否严格匹配。BOM、多帧、URL 编码、JSON 转义、Base64 解码……任何一个环节的隐式转换没被意识到，乱码就会出现。
