websocket中文乱码根本原因是utf-8字节流在某环节被错误解码或截断，而非单纯编码设置错误；中括号[]等特殊字符未url编码会导致400错误，必须用encodeuricomponent()对整个路径编码。
WebSocket发送含特殊字符的消息，乱码或解析失败，根本不是“编码没设对”，而是字节流在某个环节被错误解释或提前截断——比如&被当URL分隔符、[被Tomcat拒绝、
被JSON解析器误判为语法错误。
WebSocket路径里有[或]导致400错误
中括号[和]在HTTP URI里属于保留字符，未编码时Tomcat等容器会直接拒收，返回400 Bad Request，跟WebSocket协议本身无关。
- 前端必须对整个路径做URL编码：
ws://host/chat/[room1]→ws://host/chat/[room1] - 不要只编码括号：用
encodeURIComponent('[room1]')，而不是手动拼[room1]，避免漏掉其他非法字符（如空格、^） - 服务端收到的路径已是解码后结果，无需再
urldecode()；但若你用$_SERVER['REQUEST_URI']取原始路径，它可能含未解码部分，得先rawurldecode()
消息体里含&、=、?等符号被当查询参数解析
这些字符只有在URL query string里才需转义；一旦连上WebSocket，它们就是普通payload字节，不参与HTTP解析——但前提是：你没把它们错塞进URL里。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 错误写法：
new WebSocket('wss://api.com?msg=hello&world')→&会让服务端以为是另一个参数 - 正确做法：所有业务数据走
ws.send()，URL只传必要路由标识，如wss://api.com/v1/chat?token=abc - 如果非要在URL传简单键值，必须
encodeURIComponent()每个值：?name='张三'&type='public'→?name=%E5%BC%A0%E4%B8%89&type=public
JSON消息里含"、
、
这类问题几乎全出在客户端拼JSON字符串时没走标准序列化，而是字符串拼接+手动转义，极易漏掉边界情况。
- 永远用
JSON.stringify()生成消息体，别自己.replace(/"/g, '\"') - 服务端接收后，若用
json.loads()报JSONDecodeError，先检查是否收到的是原始字节流（如recv_data()返回bytes），要显式.decode('utf-8') - Python服务端若从
input()或文件读配置再发WebSocket，必须指定encoding='utf-8'，否则Windows下默认GBK会导致"你好"变成b''，发出去就是乱码
用TextEncoder发中文比直接send(string)更稳
浏览器调用ws.send("你好")虽自动转UTF-8，但无法控制BOM、代理对、多帧边界。一旦服务端解析库弱（比如PHP手写unseal），就容易因首字节或surrogate pair拆分错乱。
- 显式编码：
const encoder = new TextEncoder(); ws.send(encoder.encode("你好")); - 发送前可剥离BOM：
encoder.encode("你好").slice(3)（仅当确认源字符串含BOM时） - 若需加自定义头（如2字节长度字段），必须用
Uint8Array拼接：new Uint8Array([...lenHeader, ...encoder.encode(msg)])，字符串没法直接操作字节
真正麻烦的从来不是“怎么转”，而是哪一环悄悄动了你的字节——比如PHP里file_get_contents()没设encoding、Python终端input()返回GBK、或者Wireshark里看到的已是C4 E3（GBK）而非E4 BD A0（UTF-8）。抓包看十六进制，比改十次charset都管用。
