其他 - （Tcl）我应该使用什么字符编码集？

恐怕，目前无法仅通过使用来做到这一点fconfigure -encoding ?something?：unicode编码具有相当的含义，并且存在一项功能请求，以创建对UTF-16变体的显式支持。

您能对此做什么？

由于unicode在Windows上运行的Tcl中应表示本机字节序为^1的 UTF-16 （在Wintel上为小字节序），因此，如果您的解决方案被认为是一种快速又肮脏的解决方案-encoding unicode，请尝试使用它，看看是否有帮助。

如果您的目标是跨平台解决方案的防弹或将来防弹，我可以将通道更多地切换为二进制，一次读取两个字节的内容，然后使用

binary scan $twoBytes s n

到扫描的两个字节序列中$twoBytes作为16位整数到名为“n”的变量，随后像

set c [format %c $n]

以产生一个Unicode字符出一批在$ N，并将其分配给一个变量。

这种方式据说需要更多的技巧才能正确获得：

• 您可以检查从流中获得的第一个字符，以查看它是否是字节顺序标记，如果是，则将其删除。
• 如果需要以行方式处理流，则必须实现一个小状态机，该状态机可以正确处理CR＆plus; LF序列。
• 在执行时read $channelId 2，要获取下一个字符，应检查它是否不仅返回0或2，而且还返回1（以防文件碰巧损坏了），并进行处理。

UCS-2编码与UTF-16的不同之处在于UTF-16可能包含所谓的代理对，因此它不是固定长度的编码。 因此，正确处理UTF-16流意味着还检测到这些代理对。另一方面，我几乎不相信MSVS生成的编译日志可能包含它们，因此我只假定它是用UCS-2LE编码的。

¹真实的故事是，Tcl保证对其处理的文本字符串（即，通过处理文本而不是通过二进制模式通过binary format或不encoding convertto读取流的文本字符串而获得的字符串）唯一保证的是它们是Unicode（或者说， BMP”部分）。但是从技术上讲，解释器可以在默认情况下使用的UTF-8编码和某些固定长度的编码之间切换任何字符串的内部表示，该编码称为“ unicode”。“问题”是Tcl文档中没有任何部分指定内部固定长度编码，因为encoding convertfromencoding convertto或使用binary formatand binary scan，无论源字符串值当前使用哪种精确编码，解释器都将做正确的事情—都是透明的。而且，“标准” Tcl解释器的下一个发行版可能决定完全放弃此内部功能，或者对于该内部固定长度编码使用32位或64位整数。“非标准”口译员所做的任何事情（如此类Jacl）也取决于他们。换句话说，此功能是内部功能，而不是有关口译员行为的书面合同的一部分。顺便说一句，Tcl字符串（UTF-8）的“标准”编码也没有这样指定-只是实现细节。