UTF 8 以 XML 格式编码的日语字符串

没记错的话，这是真的，前 32 个 unicode 代码点不允许作为 XML 文档中的字符，即使用 &# 转义。不确定它们是否被允许在HTML中，但可以肯定的是，服务器认为它们在您的请求中是不允许的，并且它获得了唯一有意义的投票。

我注意到您的文档声称是用iso-2022-jp编码的，而不是utf-8。事实上，文档中出现的字符序列ESC $ B是有效的 iso-2022-jp。它表示数据正在切换编码（从 ASCII 转换为称为 JIS X 0208-1983 的 2 字节日语编码）。

但是在构造请求的过程中，有人看到该0x1B字节并将其解释为字符 U+001B，而没有意识到它旨在作为已经在文档编码中编码的数据中的一个字节。因此，它已将其作为"最大努力"进行了XML转义，即使这不是有效的XML。

可能，序列化XML文档的任何内容都不知道编码应该是iso-2022-jp的。我想它认为它应该将文档序列化为 ASCII、ISO-Latin-1 或 UTF-8，而 <meta> 元素对它没有任何意义（无论如何，这是一种指定编码的 HTML 方式，它在 XML 中没有特别的意义）。但是我不知道MS-DOM，所以我不知道如何纠正它。

如果您只是从 iso-2022-jp 数据中删除ESC字符，那么您隐藏了数据已切换编码的事实，因此解码器将继续将所有7nMK内容解释为 ASCII，而它应该被解释为 JIS X 0208-1983。因此，垃圾。

其他奇怪的事情 - 切换回 ASCII 的iso-2022-jp代码是ESC ( B，但我在您的数据中看到|(B</font>，当我期望第二个 ESC 字符发生与第一个字符相同的事情时：&#0x1B(B</font> 。同样，$B#M#S(B和$BL@D+(B都是从 ASCII 切换到 JIS X 0208-1983 并返回的尝试，同样，ESC字符只是消失而不是被转义。

我没有解释为什么有些ESC字符消失了，一个角色逃脱了，但你生成的东西看起来几乎但不完全像有效的iso-2022-jp，这绝非巧合。我认为 iso-2022-jp 是 7 位编码，因此部分问题可能是您获取了 iso-2022-jp 数据，并通过将 ISO-Latin-1（或其他一些下半部分与 ASCII 匹配的 8 位编码，例如任何 Windows 代码页）转换为 UTF-8 的函数运行它。如果是这样，则此函数保持 7 位数据不变，不会将其转换为 UTF-8。然后，当解释为 UTF-8 时，数据中包含 ESC 字符。

如果要将数据作为 UTF-8 发送，那么首先需要实际将其从 iso-2022-jp 转换出来（转换为宽字符或 UTF-8，无论您的 SOAP 或 XML 库期望什么）。其次，您需要将其标记为 UTF-8，而不是 iso-2022-jp。最后，您需要将整个文档序列化为 UTF-8，尽管正如我所说，您可能已经在这样做了。

正如史蒂夫·杰索普（Steve Jessop）所指出的，看起来您已将文本编码为iso-2022-jp，而不是UTF-8。 因此，首先要做的是检查并确保您拥有正确的 UTF-8。

如果问题仍然存在，请考虑对文本进行编码。

最简单的选项是"十六进制编码"，您只需将每个字节的十六进制值写为 ASCII 数字。 例如，0x1B字节变为"1B"，即0x31,0x42。

如果你想花哨，你可以使用MIME甚至UUENCODE。