0

我正在尝试使用日语字符串创建一个 SOAP 调用。我面临的问题是，当我将此字符串编码为 UTF8 编码字符串时，其中包含许多控制字符（例如 0x1B (Esc)）。如果我删除所有此类控制字符以使其成为有效的 SOAP 调用，则日语内容在服务器端显示为垃圾。如何为日文字符创建有效的 SOAP 请求？任何建议都受到高度赞赏。我正在使用带有 MS-DOM 的 C++。

最诚挚的问候。

4

2 回答 2

3

如果我没记错的话是真的，前 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，所以我不知道如何纠正。

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

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

我无法解释为什么某些ESC字符消失了，而一个字符被转义了，但是您生成的内容看起来几乎但不完全像 valid ，这绝非巧合iso-2022-jp。我认为 iso-2022-jp 是 7 位编码，所以部分问题可能是您获取了 iso-2022-jp 数据，并通过转换 ISO-Latin-1（或其他一些 8下半部分匹配 ASCII 的位编码，例如任何 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，尽管正如我所说的，您可能已经在这样做了。

于 2012-06-08T11:03:27.113 回答
0

正如 Steve Jessop 所指出的，您似乎已将文本编码为 iso-2022-jp，而不是 UTF-8。所以首先要做的是检查并确保你有正确的 UTF-8。

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

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

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

于 2012-06-08T15:55:37.097 回答