WebSocket传输过程中的中文字符乱码解决方法字符集编码设置教程-js教程-PHP中文网

websocket中文乱码主因是utf-8字节流在某环节被错误解码，而非单纯编码设置错误；根本在于各环节（js字符串转utf-8、bom处理、多帧解析、url编码、json转义等）的字节与解码方式不匹配。

websocket传输过程中的中文字符乱码解决方法字符集编码设置教程

乱码不是编码没设对，而是 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

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