Если я правильно помню, это верно, первые 32 кодовых обозначения Unicode не разрешены в качестве символов в документах XML, даже с экранами &#. Не уверен, разрешены ли они в HTML или нет, но, конечно, сервер считает, что они не разрешены в ваших запросах, и он получает единственно значимое голосование.
Я заметил, что ваш документ утверждает, что он закодирован в iso-2022-jp, а не utf-8. И действительно, последовательность символов ESC $ B, которая появляется в вашем документе, действительна iso-2022-jp. Он указывает, что данные переключают кодировки (от ASCII до 2-байтовой японской кодировки JIS X 0208-1983).
Но где-то в процессе построения вашего запроса что-то увидело этот байт 0x1B и интерпретировал его как символ U + 001B, не понимая, что он предназначен как один байт в данных, которые уже закодированы в кодировке документа. Таким образом, он имеет XML-экранирование как «лучшее усилие», хотя это недействительный XML.
Возможно, что бы ни сериализовало ваш XML-документ, он не знает, что кодировка должна быть iso-2022-jp. Я полагаю, он считает, что предполагается, что он будет сериализовать документ как ASCII, ISO-Latin-1 или UTF-8, а элемент <meta> ничего не значит для него (это HTML-способ указания кодировки в любом случае, он не имеет особого значения в XML). Но я не знаю MS-DOM, поэтому я не знаю, как это исправить.
Если вы просто удалите ESC символы из данных изо-2022-JP, то вы скрыть тот факт, что данные коммутируемые кодировки, и поэтому декодер будет продолжать интерпретировать все, что 7nMK вещей, как ASCII, когда он должен интерпретироваться как JIS X 0208-1983. Следовательно, мусор.
Что-то еще Чужие - iso-2022-jp код для переключения обратно в ASCII является ESC (B, но я вижу |(B</font> в ваших данных, когда я ожидал бы то же самое произойдет со вторым ESC персонажа, как случилось с первым: �x1B(B</font> , Аналогично, $B#M#S(B и [email protected]+(B являются искаженными попытками переключения с ASCII на JIS X 0208-1983 и обратно, и снова символы ESC только что исчезли, а не были экранированы.
У меня нет объяснений, почему некоторые ESC персонажей исчезли, и один из них сбежал, но не может быть совпадением, что то, что вы создаете, выглядит почти, но не совсем, как и действительный iso-2022-jp. Я думаю, iso-2022-jp - это 7-битная кодировка, поэтому частью проблемы может быть то, что вы взяли данные iso-2022-jp и запускаете ее через функцию, которая преобразует ISO-Latin-1 (или некоторые другие 8 битная кодировка, для которой нижняя половина соответствует ASCII, например, любой кодовой странице Windows) для UTF-8. Если это так, то эта функция оставляет 7-битные данные без изменений, они не преобразуют ее в UTF-8. Затем, когда интерпретируется как UTF-8, данные содержат в нем символы ESC.
Если вы хотите отправить данные как UTF-8, то в первую очередь вам нужно будет преобразовать его из iso-2022-jp (в широкие символы или в UTF-8, в зависимости от того, что ожидает ваша SOAP или XML-библиотека).Во-вторых, вам нужно обозначить его как UTF-8, а не как iso-2022-jp. Наконец, вам нужно сериализовать весь документ как UTF-8, хотя, как я уже сказал, вы уже можете это сделать.
Почему вы говорите, что запрос SOAP с кодировкой UTF-8 недействителен? Сервер не принимает XML с 'encoding =" utf-8 "? –
Эти «контрольные» символы являются частью кодировки японских символов и не должны быть удалены. Что происходит, когда вы их не удаляете? Служит ли вызов SOAP в любом случае? –
Символы utf-8 обязательно должны оставаться внутри сообщения. Возможно, проблема заключается не в самом сообщении, а в создании сообщения. Вы выводили свои данные в виде двоичных файлов, поэтому никакого другого преобразования не произошло? – Thorsten