xsl 1.0 转换后的错误字符编码答案

【问题标题】：bad character encoding after xsl 1.0 transformxsl 1.0 转换后的错误字符编码
【发布时间】：2013-12-11 16:53:55
【问题描述】：

我才刚刚开始学习编码问题，而且我学到的知识已经足够知道它比我想象的要复杂得多（至少在 Windows 上），而且我还有很多东西要学。

我有一个我认为是用 UTF-8 编码的 xml 文档。我正在使用 VB.net 应用程序将带有（XslCompiledTransform 和 XmlTextWriter）的 xml 转换为特定于列的文本文件。 xml 中的某些字符在输出文本文件中出现错误。示例：一个破折号 (—) 被转换为三个字符“â€”。发生这种情况时，文件中的列将被丢弃。

据我了解，破折号甚至不是“Unicode 字符”。我不希望它有问题。但是，我可以通过更改 VB.net 应用程序中指定的编码来解决问题。

如果我使用它，则会保留 em-dash：

Using writer = New XmlTextWriter(strOutputPath, New UTF8Encoding(True))

如果我使用它，破折号会损坏为“-”：

Using writer = New XmlTextWriter(strOutputPath, New UTF8Encoding(False))

True/False 只是告诉 VB 是否在文件开头写入 BOM。据我了解，对于 UTF-8，BOM 既不需要也不推荐。所以，我的偏好是 False - 但后来我得到了奇怪的字符。

我有几个问题：

如何确定 xml 文件是 UTF-8？有 Windows 工具可以告诉我吗？
如何确定转换后的文件实际上是坏的？难道真正的问题是我用来查看它的编辑器？ EmEditor 和 UltraEdit 都显示相同的内容。
我尝试使用 XVI32 十六进制编辑器查看文件。我想知道实际写入磁盘的内容，而不是某些 GUI 程序向我显示的内容。但是，即使是在 EmEditor 中看起来不错的文件，XVI32 也会向我显示坏字符。难道 XVI32 就是不理解非 ASCII 字符？为此，您会推荐什么 Windows 十六进制编辑器？

XML 文件为 650 MB，最终文本文件为 380 MB - 这在一定程度上限制了有用工具的列表。

【问题讨论】：

您希望 XslCompiledTransform 作为转换结果创建的文本文件采用哪种编码？您如何看待文本文件，您使用哪个应用程序？听起来它可以识别 UTF-8 BOM 并读取将其解码为 UTF-8 的文件，但是当您没有 BOM 时，它会使用不同的，可能是 8 位编码，如 Windows-1252。因此，您要么必须确保输出 BOM，要么必须将读取文本文件的代码或应用程序更改为默认为 UTF-8。
@MartinHonnen 如果可能的话，我希望将文本文件编码为 UTF-8。我同时使用 EmEditor 和 UltraEdit 来查看文件。那么，您认为该文件实际上是 UTF-8 吗？我将调查 EmEditor 或 UltraEdit 是否有办法在打开文件时强制编码。谢谢。
我认为你得到了一个 UTF-8 编码的文本文件，是的，但是你的编辑器使用 8 位编码，如 Windows 代码页或 ISO-8859-x 来解码文件。如果没有 BOM，编辑器就无法知道文件是 UTF-8 编码的，您必须告诉编辑器您想读取为 UTF-8。

标签： vb.net xslt encoding xslt-1.0

【解决方案1】：

您说“据我所知，em-dash 甚至不是“Unicode 字符”。你是什么意思？ Unicode 字符集肯定包含 em dash: 2014 hex 的代码。在 UTF-8 编码中，它将是 3 个字节：E2、80、94。

我怀疑 Martin Honnen 是对的，您的编辑器根本没有正确显示文件。几个建议：

我不熟悉你提到的编辑器，但是处理不同编码的编辑器通常会默默地选择一种编码来解释文件（如果有的话，基于 BOM，有时基于他们的字符代码看）。他们通常还有一些方法可以显示他们将文件解释为什么编码，以及告诉他们将文件加载（或重新加载）为特定编码的方法。如果您的编辑器没有这些功能，我建议您购买具有这些功能的编辑器，例如 EditPlus 或 NotePad++。

至于十六进制编辑器，我不熟悉你提到的那个，但十六进制编辑器的全部意义在于查看原始字节。这样的编辑器通常也提供文本视图（通常与十六进制视图并排），如果他们这样做，我不会依赖他们对编码的处理。只需使用它们查看十六进制字节，并查看两个文件中 em dash 的字节是否相同。

查看文件的另一种方式可能会出错：即使您的编辑器将文件解释为 UTF-8，并非所有字体都包含所有 unicode 字符，并且对于那些不在字体中的字符，它们可能会显示一个小方块或者什么都没有。尝试几种不同的字体，或者找到一种声称支持 unicode 的字体（尽管没有字体支持所有 Unicode，并且 Unicode 规范有几个修订版添加了更多字符）。我认为，Lucida Sans Unicode 是大多数 Windows 系统上的一种。

另一个技巧：我强烈推荐实用程序 BabelMap。您可以在那里查找任何 unicode 字符并查看 unicode 值是什么，您可以从那里复制字符并将其粘贴到文本编辑器中的文件中，然后查看它是如何显示的。

【讨论】：

我的意思是 em-dash 不是 Unicode 字符是你不需要使用 Unicode 来使用 em-dash。它是不是在扩展的 ASCII 范围内，或者是 ANSI，或者......我不知道，正如我所说的，我只是在摸索这些东西的表面。我不能使用 Notepad++，因为文件太大——它给了我一条错误信息。我相信 EmEditor 和 UltraEdit 都具有强制使用特定编码打开文件的能力。我会研究那个角度的。物料清单呢？我已经读到 UTF-8 没有必要也不建议这样做。
在 UltraEdit 中使用 Hex 视图会显示 E2 80 94 em-dash 所在的位置。如果我正确理解您写的内容，则可以确认该文件确实是 UTF-8 编写的，但我看得很糟糕。文件的 GUI 视图显示“-”。
em-dash 绝对不是 ASCII，但它是在 Windows-1252 中，有些人松散地称之为 ANSI，有时会与 ASCII 混淆。只有 00-7F 是正确的 ASCII 并且与 UTF-8 兼容。
就 BOM 而言，据我了解，它是可选的，因此您不需要它。但这对于理解它的编辑来说绝对是方便的。如果您尝试使用不理解的内容打开或处理文件，这可能会明显不方便，我认为建议不要使用它可能是基于这种可能性。不过，我认为这在过去更令人担忧。
即使 Notepad++ 出现“此文件太大”错误，它仍然显示它认为的编码是：“ANSI as UTF-8”。

【解决方案2】：

UltraEdit 提供了几个用于处理 UTF-8 编码文件的配置设置。 自动检测 UTF-8 文件在 文件处理 - Unicode/UTF-8 检测 配置对话框中默认启用。

启用此设置后，UltraEdit 将搜索 UTF-8 BOM。如果不存在，它会在前几 KB 中搜索通常出现在 HTML/XHTML 文件的头部或 XML 文件的第一行中的 UTF-8 声明。如果文件顶部没有 BOM 和标准化编码信息，UltraEdit 会在前 64 KB 内搜索看起来像 UTF-8 编码字符的字节序列。如果可以找到这样的字节序列，UltraEdit 会将文件解释为 UTF-8 编码文件。例如，仅包含 3 个字节 E2 80 94 的文件被解释为 UTF-8 编码文件。

UltraEdit 在主窗口底部的状态栏中指示检测到哪个编码并且对活动文件处于活动状态（保存时）。在状态栏中显示 UTF-8 或 U8-，具体取决于使用的状态栏（高级或基本）以及作为旧版本使用的 UltraEdit 版本版本只有基本状态栏。

只有以 UTF-8 编码且没有 BOM、没有 UTF-8 字符集或编码声明以及前 64 KB 内没有 UTF-8 编码字符的文件会被错误地作为 ANSI 文件打开。在这种情况下，用户可以使用 UltraEdit 增强的 File - Open 命令，并在使用 Open 按钮打开文件之前明确选择 UTF-8 编码。

为了完整性，还有一个可以手动添加到 uedit32.ini 的配置设置，这会导致将所有未被检测为 UTF-16 文件的文件作为 UTF-8 编码文件打开。对于那些只想处理 UTF-8 编码文件的人来说，这是一个有用的设置，即使文件中经常没有代码值大于 127 的字符。

有关使用 UTF-8 编码文件的更多信息，请访问 UltraEdit 论坛。有几个主题包含大量关于在 UltraEdit 中编辑 UTF-8 编码文件的信息。

【讨论】：

非常感谢您提供如此详细的信息。