WebSocket编码配置与SQLite弯引号显示：正确处理方式咨询

核心逻辑 #

WebSocket协议默认要求文本帧使用UTF-8编码，从规范合理性和长期维护性来看，调整WebSocket连接的编码配置才是根本解决路径，而非依赖SQL替换实体或手动编码的临时绕路方案。

具体操作步骤 #

1. 修正WebSocket连接配置
   务必在WebSocket握手完成后（即向客户端发送完101切换协议响应后），设置正确的编码与转换规则：

   chan configure $sock -encoding utf-8 -buffering full -blocking 0 -translation crlf
   

   此前直接修改配置导致第一条消息失败，大概率是以下原因：

   • 配置时机错误：不能在TCP刚建立连接时就设置编码，必须等握手流程完成；
   • 重复编码：之前手动用encoding convertto utf-8处理过查询结果，现在配置-encoding utf-8后，Tcl会自动将文本转为UTF-8字节流，重复编码会直接导致数据损坏。

2. 废弃SQL替换实体的方案
   replace(..., '’', '&#8217')属于将数据与HTML显示逻辑耦合的临时hack，后续如果有非浏览器客户端（如桌面应用）请求数据，会拿到多余的HTML实体，引发兼容性问题。

3. 确保SQLite数据存储合规
   SQLite默认以UTF-8编码存储数据，直接查询获取原始文本即可，无需额外处理——当WebSocket配置为UTF-8后，Tcl会自动完成文本到UTF-8字节流的转换，浏览器能正确解析弯引号这类Unicode字符。

第一条消息失败的排查方向 #

若调整配置后仍有问题，检查以下几点：

• 浏览器端WebSocket是否以文本模式创建（未指定binaryType为arraybuffer）；
• 第一条消息内容是否包含非法字符，或握手阶段是否有残留的未处理数据；
• 确认chan configure命令是在WebSocket握手响应发送完成后执行的。

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