encoding - (Tcl) 我应该使用什么字符编码集？

Question

所以我尝试使用 Tcl 打开并解析一些旧的 Visual Studio 编译日志文件；我唯一的问题是文件的编码很奇怪。用 Notepad++ 检查它们后，它们似乎采用“UCS-2 Little Endian”编码。两个问题:

• Tcl 中有没有命令可以让我查看文件的字符编码？我知道有编码系统它告诉我系统编码。

• 使用编码名称 Tcl 告诉我可用的编码名称如下:

  cp860 cp861 cp862 cp863 tis-620 cp864 cp865 cp866 gb12345 gb2312-raw cp949 cp950 cp869 dingbats ksc5601 macCentEuro cp874 macUkraine jis0201 gb2312 euc-cn euc-jp mac泰国 iso8859-10 jis0208 iso2022-jp mac冰岛 iso2022 iso8859-13 jis0212 iso8859-14 iso8859-15 cp737 iso8859-16 big5 euc-kr mac罗马尼亚 mac土耳其语 gb1988 iso2022-kr mac希腊 ascii cp437 mac罗马 iso8859-1 iso8859-2 iso8859-3 mac克罗地亚 koi8-r iso8859-4 ebcdic iso885 9-5 cp1250 macCyrillic iso8859-6 cp1251 macDingbats koi8- u iso8859-7 cp1252 iso8859-8 cp1253 iso8859-9 cp1254 cp1255 cp850 cp1256 cp932 身份 cp1257 cp852 macJapan cp1258 shiftjis utf-8 cp855 cp936 符号 cp775 unicode cp857

  鉴于此，在 fconfigure -encoding 命令中使用什么名称来读取这些 UCS-2 Little Endian 编码文件并将其转换为 >UTF-8 使用吗？如果我正确理解fconfigure命令，我需要指定源文件的编码类型，而不是我想要的；我只是不知道上面列表中的哪个选项对应于UCS-2 Little Endian。阅读了一些内容后，我发现 UCS-2 是 UTF-16 字符编码的前身，但该选项也不在这里。

谢谢!

Answer 1

恐怕，目前还没有办法仅通过使用 fconfigure -encoding ?something? 来做到这一点:unicode 编码具有相当大的意义，并且有一个feature request创建对 UTF-16 变体的显式支持。

你能对此做些什么？

由于在 Windows 上运行的 Tcl 中的 unicode 应该表示具有 native 字节序 ¹ 的 UTF-16(Wintel 上的小字节序)，如果您解决方案应该是一个快速而肮脏的解决方案，只需尝试使用 -encoding unicode 看看是否有帮助。

如果您的目标是一些更防弹或面向 future 的跨平台解决方案，我会将 channel 切换为二进制更多，一次读取两个字节 block 的内容，然后使用

binary scan $twoBytes s n

至scan the sequence of two bytes将 $twoBytes 作为 16 位整数放入名为“n”的变量中，后跟类似

set c [format %c $n]

至produce a unicode character out of the number保存在 $n 中，并将其分配给一个变量。

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

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

<小时/>

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

<小时/>

¹ 真实情况是，Tcl 对其处理的文本字符串(即通过操作文本而不是通过二进制格式获得的字符串)唯一保证 或 encoding conversionto 或以二进制模式读取流)的原因是它们是 Unicode(或者更确切地说，它的“BMP”部分)。 但从技术上讲，解释器可能会在默认使用的 UTF-8 编码和一些固定长度编码(即所谓的“unicode”)之间切换任何字符串的内部表示形式。 “问题”是 Tcl 文档中没有任何部分指定内部固定长度编码，因为您需要将您输出或读取的任何文本显式转换为某些特定编码或从某些特定编码读取 - 通过配置流或使用编码convertfrom和编码convertto或使用二进制格式和二进制扫描，解释器将执行正确的事情无论它当前对源字符串值使用哪种精确编码 - 它都是透明的。此外，“标准”Tcl 解释器的下一个版本可能会决定完全放弃此内部功能，或者说，使用 32 位或 64 位整数进行内部固定长度编码。无论“非标准”解释器做什么(如 Jacl 等)也取决于他们。换句话说，此功能是内部功能，不是有关口译员行为的书面契约(Contract)的一部分。顺便说一句，Tcl 字符串的“标准”编码 (UTF-8) 也没有这样指定 — 它只是一个实现细节。