Когда мы начали внедрять Mulesoft в качестве пилота в нашей компании, мы заметили, что mulesoft будет наследовать системную кодовую страницу (windows-1252) в кажущиеся случайными моменты. Несмотря на установку предпочтения Anypoint studio (7.2.0), а время выполнения (4.2.1 EE) по умолчанию - UTF-8. Поэтому исходящие соединители (и соединители по умолчанию http) будут отправлять свои запросы http в этой кодировке. Затем любой API, который мы пишем, выдает следующую ошибку:
Message : HTTP PUT on resource 'https://mocksvc-proxy.anypoint.mulesoft.com:443/exchange/*********/1.0.2/subscription' failed: media type application/json; charset=windows-1252 not supported (415).
Мы обнаружили, что решение этой проблемы состояло в том, чтобы установить кодировку для преобразования сообщения непосредственно перед соединителем, чтобы принудительно преобразовать его в UTF-8 следующим образом:
<ee:transform doc:name="Transform Message" doc:id="-redacted-">
<ee:message>
<ee:set-payload><![CDATA[%dw 2.0
output application/json encoding="UTF-8"
---
{
"applicatie": "-redacted-",
"clientid": vars."-redacted-" as Number
}]]></ee:set-payload>
</ee:message>
</ee:transform>
Однако, поскольку в anypoint studio 7.2.1 это исправление больше не работает.
Я не могу найти ничего, что мы изменили, и все настройки по-прежнему установлены в UTF-8.
Для настройки проекта установлено изображение UTF-8
Кто-нибудь знает способ, которым мы можем попытаться форсировать кодировку, или заставить API, которые мы строим, принять windows-1252? (что было бы приемлемо, но не желательно, если это вообще возможно)
Или вы думаете, что это ошибка, которую мы должны сообщить mulesoft?
Эта проблема возникает на Mule Standalone EE Версия: 4.1.2 Сборка: 41de9970 на
Windows server 2016 Datacenter.
Anypoint studio встроил Mule 4.1.2
в Windows 7.