Charset encoding problem in webservices called from Biztalk

I have a problem occurring when Biztalk calls SOAP web services. The web services from one specific system seems to not always include a "charset" attribute in the Content-Type response header. In the cases where this is missing, the charset is interpreted as Windows-1252 encoding instead of UTF-8.

The response from the web servcie 开发者_StackOverflow社区is actually UTF-8 encoded even when the "charset" attribute is missing. So my question is if it's somehow possible to tell Biztalk that UTF-8 should be used as default charset when no charset is specified in the HTTP response headers from the service.

Just to specify further: If the following header is returned from the web service, Biztalk interprets the charset correctly:

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

However when the charset part is missing, Biztalk falls back on Windows-1252 encoding and some international characters are garbled:

Content-Type: text/xml

I know that the simplest solution would be to fix the web service to always return the UTF-8 charset attribute, but sadly we have no control over the services and the vendor will not release a fix for this anytime soon.

Another fix we have attempted is to use rewriting in IIS to rewrite the response header. This works fine unless when the services returns a large amount of data. In that case IIS will used chunked encoding, and the rewrite engine seems to double chunk-encode the output from the web service, rendering the resulting output broken.

The only solution I had working so far is to use an Apache web server as a proxy, and rewrite the header with Apache. This works, but since it introduces extra overhead and is quite hackish we would rather prefer to fix the problem at an existing end-point. Currently the Biztalk end is the only one we have access to make changes on.

I hope anyone can help me on this.

An easy solution would be to use an Encoding Transcoder Custom Pipeline Component in the receive pipeline. This is, IMHO, better than hosting a separate proxy in a third-party server. But you are right, solving the problem at its root would be better if you can have a hand on the external web service.

Such a composent can be found there: http://maximelabelle.wordpress.com/category/pipeline-components/