Encoding 从Biztalk调用的Web服务中的字符集编码问题

Biztalk调用SOAP web服务时出现问题。来自一个特定系统的web服务似乎并不总是在内容类型响应头中包含“charset”属性。在缺少此项的情况下，字符集被解释为Windows-1252编码，而不是UTF-8

来自web服务的响应实际上是UTF-8编码的，即使缺少“charset”属性也是如此。所以我的问题是，当服务的HTTP响应头中没有指定字符集时，是否可以告诉Biztalk UTF-8应该用作默认字符集

仅进一步说明： 如果从web服务返回以下标头，Biztalk将正确解释该字符集：

Content-Type: text/xml; charset=UTF-8

但是，当缺少字符集部分时，Biztalk会采用Windows-1252编码，并且某些国际字符会被乱码：

Content-Type: text/xml

我知道最简单的解决方案是修复web服务，使其始终返回UTF-8字符集属性，但遗憾的是，我们无法控制这些服务，供应商也不会很快发布解决方案

我们尝试的另一个修复方法是在IIS中使用重写来重写响应头。除非服务返回大量数据，否则这种方法可以正常工作。在这种情况下，IIS将使用分块编码，而重写引擎似乎对来自web服务的输出进行双分块编码，从而导致结果输出中断

到目前为止，我唯一的解决方案是使用ApacheWeb服务器作为代理，并用Apache重写头部。这是可行的，但由于它引入了额外的开销，而且相当粗糙，我们更愿意在现有的端点上解决这个问题。目前，Biztalk端是我们唯一有权对其进行更改的端

---

我希望任何人都能在这方面帮助我。

一个简单的解决方案是在接收管道中使用编码转码器自定义管道组件。IMHO，这比在第三方服务器中托管单独的代理要好。但是您是对的，如果您能够帮助外部web服务，那么从根本上解决问题会更好

可以在那里找到这样一个组合：

---

一个简单的解决方案是在接收管道中使用编码转码器自定义管道组件。IMHO，这比在第三方服务器中托管单独的代理要好。但是您是对的，如果您能够帮助外部web服务，那么从根本上解决问题会更好

可以在那里找到这样一个组合：

---

我真的希望有一个可以指定默认编码的设置。问题不在于源数据的编码；它不需要任何转码，因为它已经是UTF-8了。我们只需要告诉Biztalk，如果web服务的HTTP响应头中没有指定编码，它应该假定XML是UTF-8编码的。据我所知，Biztalk确实假定UTF-8编码，而没有otherwize明确提及。如果您确实观察了windows-1252输入，这意味着web服务已经明确指定了它，尽管它的指定不正确。在这种情况下，您需要一个类似于m'y suggestion的解决方案……我已经使用SoapUI测试了web服务，还使用Wireshark完成了数据包捕获，在这两种情况下，web服务的输出都是UTF-8。唯一的区别似乎是内容类型标头中缺少字符集属性。Biztalk的输出看起来像UTF-8，解析为Win-1252（我已经多次看到这一结果）。这意味着像æ、ø和å这样的普通挪威字符被输出为两个字符（映射到Win-1252代码页的两个UTF-8字节）。您能检查这是在适配器中还是在管道处理过程中发生的吗？也许，暂时将管道设置为PassThruReceive以进行确认。我认为这里的反汇编程序没有错。在响应头中缺少字符集的情况下，适配器可能做了错误的事情。在这种情况下，解决方案比较棘手，可能涉及注入自定义行为或配置自定义WCF绑定。您正在使用WCF，对吗？我真的希望有一个可以指定默认编码的设置。问题不在于源数据的编码；它不需要任何转码，因为它已经是UTF-8了。我们只需要告诉Biztalk，如果web服务的HTTP响应头中没有指定编码，它应该假定XML是UTF-8编码的。据我所知，Biztalk确实假定UTF-8编码，而没有otherwize明确提及。如果您确实观察了windows-1252输入，这意味着web服务已经明确指定了它，尽管它的指定不正确。在这种情况下，您需要一个类似于m'y suggestion的解决方案……我已经使用SoapUI测试了web服务，还使用Wireshark完成了数据包捕获，在这两种情况下，web服务的输出都是UTF-8。唯一的区别似乎是内容类型标头中缺少字符集属性。Biztalk的输出看起来像UTF-8，解析为Win-1252（我已经多次看到这一结果）。这意味着像æ、ø和å这样的普通挪威字符被输出为两个字符（映射到Win-1252代码页的两个UTF-8字节）。您能检查这是在适配器中还是在管道处理过程中发生的吗？也许，暂时将管道设置为PassThruReceive以进行确认。我认为这里的反汇编程序没有错。在响应头中缺少字符集的情况下，适配器可能做了错误的事情。在这种情况下，解决方案比较棘手，可能涉及注入自定义行为或配置自定义WCF绑定。您使用的是WCF，对吗？正如其他人评论的那样，我很惊讶BTS将其视为1252，因为它通常默认为UTF-8。你能详细说明你是如何看待这个问题的吗？通常，可以引导BTS使用/assu编码