我正在尝试使用日语字符串创建SOAP调用。我遇到的问题是，当我将此字符串编码为UTF8编码的字符串时，它中有许多控制字符（例如0x1B（Esc））。如果我删除所有这些控制字符以使其成为有效的SOAP调用，则日语内容在服务器端显示为垃圾。 如何为日文字符创建有效的SOAP请求？任何建议都非常感谢。 我正在使用C ++和MS-DOM。
最诚挚的问候。
答案 0 :(得分：3)
如果我没记错的话，那么前32个unicode代码点不允许作为XML文档中的字符，甚至可以使用&#进行转义。不确定它们是否被允许使用HTML，但当然服务器认为它们不允许在您的请求中使用，并且它获得了唯一有意义的投票。
我注意到您的文档声称是以iso-2022-jp编码，而不是utf-8。事实上，文档中出现的字符序列ESC $ B是有效的iso-2022-jp。它表示数据正在切换编码（从ASCII到2字节日语编码，称为JIS X 0208-1983）。
但在构建请求的过程中某些地方已经看到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角色发生在第一个：�x1B(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（或其他一些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，尽管我已经说过您可能已经这样做了。
答案 1 :(得分：0)
正如Steve Jessop所指出的，看起来你已经将文本编码为iso-2022-jp，而不是UTF-8。所以要做的第一件事就是检查并确保你有正确的UTF-8。
如果问题仍然存在，请考虑对文本进行编码。
最简单的选项是“十六进制编码”，您只需将每个字节的十六进制值写为ASCII数字。例如0x1B字节变为“1B”，即0x31,0x42。
如果您想要使用MIME，甚至可以使用UUENCODE。