Zeichensatzcodierungsproblem in Webdiensten, die von Biztalk aufgerufen werden

Question

Ich habe ein Problem, wenn Biztalk SOAP-Webdienste aufruft. Die Web-Services von einem bestimmten System scheinen nicht immer ein "charset" -Attribut im Content-Type-Antwortheader zu enthalten. In den Fällen, in denen dies fehlt, wird der Zeichensatz anstelle von UTF-8 als Windows-1252-Codierung interpretiert.

Die Antwort vom Webservice ist tatsächlich UTF-8 codiert, auch wenn das Attribut "charset" fehlt. Meine Frage ist also, ob es irgendwie möglich ist, BizTalk mitzuteilen, dass UTF-8 als Standard-Zeichensatz verwendet werden soll, wenn in den HTTP-Antwortheadern des Dienstes kein Zeichensatz angegeben ist.

Nur angeben weiter: Wenn die folgenden Header aus dem Webdienst zurückgegeben wird, interpretiert Biztalk die charset richtig:

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

jedoch, wenn der charset Teil fehlt, Biztalk fällt zurück auf Windows-1252-Codierung und einige internationale Zeichen sind verstümmelt:

Content-Type: text/xml 

ich weiß, dass die einfachste Lösung wäre es, die Web-Service zu beheben, um das UTF-8-Zeichensatz-Attribut immer wieder zurückkehren, aber leider haben wir keine Kontrolle über die ser Laster und der Anbieter wird in naher Zukunft keine Lösung dafür veröffentlichen.

Ein anderer Fix, den wir versucht haben, besteht darin, das Umschreiben in IIS zu verwenden, um den Antwortheader neu zu schreiben. Dies funktioniert einwandfrei, es sei denn, die Dienste geben eine große Datenmenge zurück. In diesem Fall verwendet IIS chunked encoding, und die Rewrite-Engine scheint die Ausgabe des Webdienstes doppelt zu codieren, wodurch die resultierende Ausgabe kaputt gemacht wird.

Die einzige Lösung, die ich bisher hatte, ist die Verwendung eines Apache-Webservers als Proxy und das Neuschreiben der Kopfzeile mit Apache. Das funktioniert, aber da es zusätzlichen Aufwand verursacht und ziemlich hakisch ist, würden wir es vorziehen, das Problem an einem bestehenden Endpunkt zu beheben. Gegenwärtig ist das Biztalk-Ende das einzige, zu dem wir Änderungen vornehmen können.

Ich hoffe, dass mir hier jemand helfen kann.

Answer 1

Eine einfache Lösung wäre die Verwendung einer benutzerdefinierten Encoding Transcoder-Pipeline-Komponente in der Empfangspipeline. Dies ist IMHO besser als das Hosten eines separaten Proxys in einem Drittanbieterserver. Aber Sie haben Recht, das Problem an der Wurzel zu lösen, wäre besser, wenn Sie den externen Webservice in die Hand nehmen können.

Eine solche composent sind dort zu finden: http://maximelabelle.wordpress.com/category/pipeline-components/