Проблема кодировки Charset в веб-сервисах, вызываемых из Biztalk - PullRequest
2 голосов
/ 20 декабря 2010

У меня возникает проблема, когда Biztalk вызывает веб-службы SOAP.Кажется, что веб-сервисы одной конкретной системы не всегда включают атрибут «charset» в заголовок ответа Content-Type.В случаях, когда это отсутствует, кодировка интерпретируется как кодировка Windows-1252 вместо UTF-8.

Ответ от веб-службы на самом деле кодируется в кодировке UTF-8, даже если атрибут "charset" отсутствует.Поэтому мой вопрос: возможно ли как-то сказать Biztalk, что UTF-8 следует использовать в качестве набора символов по умолчанию, если в заголовках ответа HTTP от службы не указан набор символов.

Просто для дальнейшего указания: Если следующий заголовоквозвращается из веб-службы, Biztalk правильно интерпретирует кодировку:

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

Однако, когда часть кодировки отсутствует, Biztalk возвращается к кодировке Windows-1252 и некоторые международные символы искажаются:

Content-Type: text/xml

Я знаю, что самым простым решением было бы исправить веб-службу так, чтобы она всегда возвращала атрибут кодировки UTF-8, но, к сожалению, у нас нет контроля над службами, и поставщик не выпустит исправление для этого в ближайшее время.

Другое исправление, которое мы попытались, - использовать переписывание в IIS для перезаписи заголовка ответа.Это прекрасно работает, если только сервисы не возвращают большой объем данных.В этом случае IIS будет использовать чанкованное кодирование, и механизм перезаписи, по-видимому, удваивает чанк-кодирование выходных данных веб-службы, в результате чего результирующий вывод прерывается.Веб-сервер Apache в качестве прокси-сервера и переписать заголовок с Apache.Это работает, но, поскольку оно создает дополнительные накладные расходы и является довольно хакерским, мы бы предпочли исправить проблему в существующей конечной точке.На данный момент Biztalk является единственным, к которому у нас есть доступ, чтобы вносить изменения.

Я надеюсь, что любой может помочь мне в этом.

1 Ответ

0 голосов
/ 20 декабря 2010

Простым решением было бы использование компонента пользовательского конвейера кодирования транскодера в приемном конвейере.Это, ИМХО, лучше, чем размещение отдельного прокси на стороннем сервере.Но вы правы, решение проблемы в корне было бы лучше, если бы вы могли приложить руку к внешнему веб-сервису.

Такой композит можно найти там: http://maximelabelle.wordpress.com/category/pipeline-components/

...