WebSocket发送消息：encoding convertto与chan configure使用困惑

1. 套接字配置UTF-8 vs 直接编码字符串 #

两种方式都可行，但直接编码字符串为UTF-8字节串并保持套接字二进制模式更靠谱，具体分析：

• WebSocket文本帧要求 payload 是UTF-8编码的字节流，你需要准确计算发送的字节数来生成帧头。如果用套接字-encoding utf-8，提前用string length $response得到的是Tcl字符串的字符数，而非UTF-8编码后的字节数（比如弯引号U+2019占2个字节，但字符数是1），这会导致帧头长度和实际发送的字节数不匹配，浏览器解析时丢数据。
• 如果非要用套接字UTF-8配置，必须先计算编码后的字节数，示例代码：

  set response_str "0 $id settle $result"
  set utf8_bytes [encoding convertto utf-8 $response_str]
  set len [string length $utf8_bytes]
  # 生成帧头逻辑...
  chan configure $sock -encoding utf-8 -translation lf -eofchar {}
  chan puts -nonewline $sock $response_str
  

  但这种方式多了一次编码计算，反而不如直接用编码后的字节串发送简洁。
• 保持套接字二进制模式的优势：WebSocket本身就是基于二进制帧的协议，帧头是二进制结构，发送帧头和payload都用二进制模式，逻辑统一，避免编码切换带来的状态混乱。

2. 编码切换期间收到消息的影响 #

WebSocket的传入消息是二进制帧结构（包含opcode、掩码、长度等二进制字段），当你把套接字配置为-encoding utf-8时：

• Tcl会自动将收到的字节流解码为UTF-8字符串，但帧头的二进制数据（比如0x81、0x7E这些控制字节）不是合法的UTF-8序列，解码会出错，导致你无法正确解析WebSocket帧的结构。
• 即使解码没报错，你也无法区分帧头和payload的边界，最终读不到正确的传入消息。测试里发现只有二进制模式能读取，就是因为二进制模式下Tcl不会解码，你可以直接处理原始字节流，按WebSocket协议解析帧结构。

内容的提问来源于stack exchange，提问作者Gary