WebSocket中文乱码主因是UTF-8字节流在某环节被错误解码，而非编码设置错误；根本在于JS字符串来源、BOM处理、多帧解析、URL编码、JSON转义等环节的字节与解码方式不匹配。
WebSocket中文乱码不是编码没设对，而是某环节把UTF-8字节流当别的编码解了——协议本身不协商charset，只强制要求payload是合法UTF-8字节序列。
为什么ws.send("你好")还会乱码
浏览器确实会自动把JS字符串（UTF-16）转成UTF-8字节再发，但问题常出在“字符串来源”上：
- 页面meta声明为
GBK，但实际HTML文件存的是UTF-8，JS读到的已是损坏值 -
input.value或textarea.value来自用户粘贴，可能含BOM（\uFEFF），某些服务端解析器会把它当普通字符吞掉，导致后续字节偏移错乱 - 用
JSON.stringify()拼消息却漏了JSON_UNESCAPED_UNICODE，中文变成"\u4f60\u597d"，虽合法但体积大、弱服务端易拒收 - 更隐蔽的是：字符串开头混入不可见控制字符（如Windows换行
\r\n或BOM），服务端解帧时头部错位
真正稳妥的做法是绕过隐式编码，显式控制字节流：const uint8 = new TextEncoder().encode("你好"); ws.send(uint8);
Python websocket-client收到中文是乱码
关键不在WebSocket库，而在你传给ws.send()的那个字符串本身是否已是UTF-8。常见于Windows环境：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 读取本地文件用
open('config.txt').read()，没指定encoding='utf-8'，默认走locale.getpreferredencoding()（通常是cp936/GBK） - 终端输入
input()，在Windows上返回的就是GBK编码的str，需先.encode('gbk').decode('utf-8')（仅当确定源是GBK时） - 接收端无需额外解码：
ws.recv()返回的是Pythonstr（Unicode），直接用即可；若收到bytes（比如调用recv_data()），先剥离BOM：data.lstrip(b'\xef\xbb\xbf').decode('utf-8')
PHP服务端收中文报invalid frame header
这类错误大概率不是编码问题，而是帧结构被破坏：
- PHP字符串里混入BOM：
bindec(decbin(ord($str[0])))检查首字节是否为0xEF，是就用ltrim($str, "\xEF\xBB\xBF")剥离 - 手写WebSocket时，
unseal()函数没处理多帧合并：一个TCP包里塞了3个帧，函数只解第一个，剩下两个的头部被当成了payload解 - 客户端发送前没加掩码（
mask=1），或mask key没参与payload异或——协议强制要求客户端发帧必须mask，服务端校验失败就断连 - 发送前务必校验：
mb_check_encoding($data, 'UTF-8')返回false就别发；数组结构用json_encode($data, JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE)
Java @OnMessage里中文变"???"
这是典型的字符集透传错误——HTTP握手阶段无编码可设，但Tomcat/Jetty在解析URL查询参数时可能用错了默认编码：
- 连接URL带中文参数（如
ws://host/path?name=张三），容器用ISO-8859-1解码，结果就是??? - 不要依赖容器自动decode；Tomcat 8+需在
server.xml中为Connector加上URIEncoding="UTF-8" - 更安全的做法是：URL参数先
encodeURIComponent("张三")，服务端再用URLDecoder.decode(param, "UTF-8") - 若消息体是JSON，确保
Content-Type: application/json; charset=utf-8——虽然WebSocket握手不支持body，但部分代理或网关会检查这个头
最易被忽略的是：乱码问题往往藏在BOM、多帧、URL参数、JSON转义这四个交叉点里，而不是笼统地“改编码设置”。抓包看原始十六进制数据（Wireshark），确认服务端收到的是EF BB BF E4 BD A0（UTF-8）还是C4 E3 C0 D2（GBK），才能准确定位是发送端没转，还是接收端解错了。
