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()返回的是Python str（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），才能准确定位是发送端没转，还是接收端解错了。