Сообщение из 200 символов было написано в 8-битной кодировке Windows 1251

Обновлено: 04.07.2024

seb=> показать client_encoding ;
client_encoding
-----------------
UTF8

seb=> показать server_encoding;
server_encoding
-----------------
UTF8

seb=> select
convert(convert('абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ', 'utf-8', 'iso-8859-5'), 'iso-8859-5', 'windows-1251');< br />ОШИБКА: символ 0xf1 кодировки "ISO_8859_5" не имеет эквивалента
в "MULE_INTERNAL"

я записываю вывод convert(. 'utf-8', 'iso-8859-5') в файл и читаю его
с помощью: iconv -f iso-8859-5 -- все символы читаются нормально . (смотри проги во вложении)

convert(. 'iso-8859-5', 'utf-8') выглядит хорошо, я проверяю это следующим образом:
seb=> set standard_conforming_strings TO on; --- не экранируйте bytea
SET
seb=> select
convert('\320\321\322\323\324\325\361\326\327\330\331\ 332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\260\261\262\ 263\264\265\241\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\ 313\314\315\316\317', 'iso-8859-5', 'utf-8');

seb=> отключить стандартные_конформные_строки; --- теперь мы должны экранировать bytea
для отображения текста
SET
seb=> select
E'\320\260\320\261\320\262\320\263 \320\264\320\265\321\221\320\266\320\267\320\270\320\271\320\272\320\273\320\274\320\275\320\276\320 \277\321\200\321\201\321\202\321\203\321\204\321\205\321\206\321\207\321\210\321\211\321\212\321\213 \321\214\321\215\321\216\321\217\320\220\320\221\320\222\320\223\320\224\320\225\320\201\320\226\320 \227\320\230\320\231\320\232\320\233\320\234\320\235\320\236\320\237\320\240\320\241\320\242\320\243 \320\244\320\245\320\246\320\247\320\250\320\251\320\252\320\253\320\254\320\255\320\256\320\257';
?столбец?
------------------------------------------------------ -----------------------------
абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ
(1 запись)

параметр текстовой строки представляет собой русский алфавит от первой до последней буквы
нижний регистр и от первой до последней буквы ЗАГЛАВНЫЙ регистр

Я слышал противоречивые мнения от людей - согласно странице Википедии UTF-8.

Это одно и то же, не так ли? Кто-нибудь может пояснить?

То, что эта WIKI пишет о юникоде и UTF, на мой взгляд, нормально. Некоторые комментарии к нему странные: «В UTF-8 (или любой другой многобайтовой кодировке) можно разделить или обрезать строку в середине символа, что может привести к недопустимой строке». Таким образом, строка, которая получает кодировку UTF-8, больше не является строкой, а является массивом байтов или потоком байтов. Символы, составляющие строку, кодируются. Конечно, это тоже можно расшифровать. Теперь, конечно, вы можете вырезать последовательность utf-8 после стартового байта или после следующего байта, но зачем кому-то это делать?

@brighty Если этот поток байтов передается по сети, которая пакетирует его, тогда строка может быть разделена на два пакета, т. е. в месте, отличном от границы UTF-8 (т. е. там, где следующий байт не является байтом со старшими битами 0 , 110 , 1110 , 11110 или 10 ).

@SlySven Вы говорите о потоке байтов или строке? Конечно, поток байтов можно разделить на два пакета, но задачей TCP является воссоздание головоломки в пункте назначения, например. грамм. каждый пакет имеет свой порядковый номер, и получатель подтверждает каждый полученный пакет. Конечно, если сеанс TCP/IP отключается неуместно, только части потока байтов, скажем, в кодировке utf-8, достигают места назначения.

Оба! Я пишу в основном для клиентского приложения MUD, и в отсутствие дополнительной (так называемой "Go-Ahead" или "End-of-record") сигнализации пакеты могут разделяться и действительно разделяются по мере прохождения через Интернет - если клиент не ожидает достаточно долго дальнейших пакетов.

18 ответов 18

Чтобы расширить ответы других пользователей:

У нас есть множество языков с множеством символов, которые в идеале должны отображаться на компьютерах. Unicode присваивает каждому символу уникальный номер или кодовую точку.

Но этого недостаточно, если вы хотите представить символы более чем одного языка, поэтому втиснуть все доступные символы в один байт просто не получится.

По сути, существует два разных типа кодирования: один расширяет диапазон значений, добавляя больше битов. Примерами этих кодировок могут быть UCS2 (2 байта = 16 бит) и UCS4 (4 байта = 32 бита). Они страдают от той же проблемы, что и стандарты ASCII и ISO-8859, поскольку их диапазон значений по-прежнему ограничен, даже если предел значительно выше.

Другой тип кодировки использует переменное количество байтов на символ, и наиболее распространенными кодировками для этого являются кодировки UTF.Все кодировки UTF работают примерно одинаково: вы выбираете размер блока, который для UTF-8 равен 8 битам, для UTF-16 — 16 битам, а для UTF-32 — 32 битам. Затем стандарт определяет некоторые из этих битов как флаги: если они установлены, то следующая единица в последовательности единиц считается частью того же символа. Если они не установлены, эта единица полностью представляет один символ. Таким образом, наиболее распространенные (английские) символы занимают только один байт в UTF-8 (два в UTF-16, 4 в UTF-32), но символы других языков могут занимать шесть байтов и более.

Многобайтовые кодировки (после вышеприведенного объяснения я должен сказать многоэлементные) имеют то преимущество, что они относительно эффективны по пространству, но недостатком является то, что такие операции, как поиск подстрок, сравнения и т. д., должны декодировать символы. в кодовые точки юникода, прежде чем такие операции могут быть выполнены (хотя есть несколько сокращений).

Как стандарты UCS, так и стандарты UTF кодируют кодовые точки, как определено в Unicode. Теоретически эти кодировки можно использовать для кодирования любого числа (в пределах диапазона, поддерживаемого кодировкой), но, конечно, эти кодировки были сделаны для кодирования кодовых точек Unicode. И это ваши отношения между ними.

Стандарт Unicode определяет меньше кодовых точек, чем может быть представлено в 32 битах. Таким образом, для всех практических целей UTF-32 и UCS4 стали одной и той же кодировкой, поскольку вам вряд ли придется иметь дело с многозначными символами в UTF-32.

Термин символ используется здесь в общем смысле то, что читатель воспринимает как отдельный элемент отображения. Распространенными примерами являются буква «а», символ «@» и эмодзи «🐂». Иногда то, что выглядит как один символ, на самом деле состоит из нескольких независимых элементов отображения, как объясняется в разделе о кластерах графем.

Типы строк и символов

Экземпляр класса string представляет некоторый текст. Строка логически представляет собой последовательность 16-битных значений, каждое из которых является экземпляром структуры char. Свойство string.Length возвращает количество экземпляров char в экземпляре строки.

Следующий пример функции выводит значения в шестнадцатеричном формате всех экземпляров char в строке:

Передайте этой функции строку "Hello", и вы получите следующий вывод:

Каждый символ представлен одним значением char. Эта закономерность справедлива для большинства языков мира. Например, вот вывод для двух китайских иероглифов, которые звучат как nǐ hǎo и означают Привет:

Однако для некоторых языков и некоторых символов и эмодзи требуется два экземпляра char для представления одного символа. Например, сравните символы и экземпляры char в слове, означающем осейдж на языке осейджей:

В предыдущем примере каждый символ, кроме пробела, представлен двумя экземплярами char.

Один эмодзи Unicode также представлен двумя символами char, как показано в следующем примере, показывающем эмодзи быка:

Эти примеры показывают, что значение string.Length , указывающее количество экземпляров char, не обязательно указывает количество отображаемых символов. Один экземпляр char сам по себе не обязательно представляет символ.

Пары символов, которые соответствуют одному символу, называются суррогатными парами. Чтобы понять, как они работают, вам нужно понимать кодировку Unicode и UTF-16.

Кодовые точки Юникода

Юникод — это международный стандарт кодирования, используемый на различных платформах, с различными языками и алфавитами.

Стандарт Unicode определяет более 1,1 миллиона кодовых точек. Кодовая точка — это целое число, которое может находиться в диапазоне от 0 до U+10FFFF (десятичное число 1 114 111). Некоторые кодовые точки назначаются буквам, символам или эмодзи. Другие назначаются действиям, управляющим отображением текста или символов, например переходу на новую строку. Многие кодовые точки еще не назначены.

Вот несколько примеров присвоения кодовых точек со ссылками на таблицы Unicode, в которых они появляются:

Десятичный	Шестнадцатеричный	Пример	Описание
10	U+000A	Н/Д< /td>	ПЕРЕД СТРОКИ
97	U+0061	a	СТРОЧНАЯ ЛАТИНСКАЯ БУКВА A
562	U+0232	Ȳ	ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА Y С МАКРОНОМ
68 675	U+10C43	𐱃	СТАРО-ТЮРСКАЯ БУКВА ОРХОН АТ
127,801	U+1F339	🌹	эмодзи РОЗА

Кодовые точки обычно обозначаются с помощью синтаксиса U+xxxx , где xxxx – целочисленное значение в шестнадцатеричном формате.

Во всем диапазоне кодовых точек есть два поддиапазона:

Базовая многоязычная плоскость (BMP) в диапазоне от U+0000 до U+FFFF . Этот 16-битный диапазон обеспечивает 65 536 кодовых точек, что достаточно для охвата большинства систем письма в мире.
Дополнительные кодовые точки в диапазоне U+10000..U+10FFFF . Этот 21-битный диапазон содержит более миллиона дополнительных кодовых точек, которые можно использовать для менее известных языков и других целей, таких как эмодзи.

На следующей диаграмме показана взаимосвязь между BMP и дополнительными кодовыми точками.

Единицы кода UTF-16

Один 16-битный код может представлять любую кодовую точку в 16-битном диапазоне базовой многоязычной плоскости. Но для кодовой точки в дополнительном диапазоне необходимы два экземпляра char.

Суррогатные пары

Преобразование двух 16-битных значений в одно 21-битное облегчается специальным диапазоном, называемым суррогатными кодовыми точками, от U+D800 до U+DFFF (десятичные числа от 55 296 до 57 343). ) включительно.

На следующей диаграмме показана взаимосвязь между BMP и суррогатными кодовыми точками.

Когда за старшим заместителем кодовой точкой ( U+D800..U+DBFF ) сразу следует младшая суррогатная кодовая точка ( U+DC00..U+ DFFF ), пара интерпретируется как дополнительная кодовая точка по следующей формуле:

Вот та же формула в десятичной системе счисления:

старшая суррогатная кодовая точка не имеет большего числового значения, чем младшая суррогатная кодовая точка. Старшая суррогатная кодовая точка называется «старшей», потому что она используется для вычисления старших 10 бит диапазона 20-битной кодовой точки. Младшая суррогатная кодовая точка используется для вычисления младших 10 бит.

Например, фактическая кодовая точка, соответствующая суррогатной паре 0xD83C и 0xDF39, вычисляется следующим образом:

Вот тот же расчет с использованием десятичной системы счисления:

В предыдущем примере показано, что "\ud83c\udf39" – это кодировка UTF-16 упомянутой ранее кодовой точки U+1F339 ROSE ('🌹').

Скалярные значения Unicode

Термин скалярное значение Unicode относится ко всем кодовым точкам, кроме суррогатных кодовых точек. Другими словами, скалярное значение — это любая кодовая точка, которой назначен символ или может быть присвоен символ в будущем. Под «символом» здесь понимается все, что может быть назначено кодовой точке, включая такие вещи, как действия, управляющие отображением текста или символов.

На следующей диаграмме показаны кодовые точки скалярного значения.

Тип Rune как скалярное значение

Конструкторы Rune проверяют, является ли результирующий экземпляр допустимым скалярным значением Unicode, в противном случае они выдают исключение. В следующем примере показан код, который успешно создает экземпляры Rune, поскольку входные данные представляют допустимые скалярные значения:

В следующем примере возникает исключение, поскольку кодовая точка находится в суррогатном диапазоне и не является частью суррогатной пары:

В следующем примере возникает исключение, поскольку кодовая точка выходит за пределы дополнительного диапазона:

Пример использования рун: изменение регистра букв

API, который принимает char и предполагает, что он работает с кодовой точкой, являющейся скалярным значением, не работает правильно, если char получен из суррогатной пары. Например, рассмотрим следующий метод, который вызывает Char.ToUpperInvariant для каждого символа в строке:

Если входная строка содержит строчную букву Дезерет er ( 𐑉 ), этот код не преобразует ее в прописную ( 𐐡 ). Код вызывает char.ToUpperInvariant отдельно для каждой суррогатной кодовой точки, U+D801 и U+DC49 . Но U+D801 сам по себе не имеет достаточно информации, чтобы идентифицировать его как строчную букву, поэтому char.ToUpperInvariant оставляет его в покое. Точно так же он обрабатывает U+DC49. В результате строчная буква «𐑉» во входной строке не преобразуется в прописную «𐐡».

Вот два варианта правильного преобразования строки в верхний регистр:

Вызовите String.ToUpperInvariant для входной строки, а не итерируйте посимвольно. Метод string.ToUpperInvariant имеет доступ к обеим частям каждой суррогатной пары, поэтому он может правильно обрабатывать все кодовые точки Unicode.

Повторяйте скалярные значения Unicode как экземпляры Rune, а не экземпляры char, как показано в следующем примере. Поскольку экземпляр Rune является допустимым скалярным значением Unicode, его можно передать API-интерфейсам, которые должны работать со скалярным значением. Например, вызов Rune.ToUpperInvariant, как показано в следующем примере, дает правильные результаты:

Другие API рун

Тип Rune предоставляет аналоги многих API-интерфейсов char. Например, следующие методы отражают статические API для типа char:

Чтобы получить необработанное скалярное значение из экземпляра Rune, используйте свойство Rune.Value.

Чтобы преобразовать экземпляр Rune обратно в последовательность char, используйте метод Rune.ToString или Rune.EncodeToUtf16.

Поскольку любое скалярное значение Unicode может быть представлено одним символом или суррогатной парой, любой экземпляр Rune может быть представлен не более чем двумя экземплярами символов. Используйте Rune.Utf16SequenceLength, чтобы узнать, сколько экземпляров char требуется для представления экземпляра Rune.

Кластеры графем

Рассмотрите экземпляры строки "a", "á", "á" и " 👩🏽‍🚒". Если ваша операционная система обрабатывает их в соответствии со стандартом Unicode, каждый из этих строковых экземпляров отображается как отдельный текстовый элемент или кластер графем. Но последние два представлены более чем одной кодовой точкой скалярного значения.

Строка "a" представлена одним скалярным значением и содержит один экземпляр char.

Строка "á" представлена одним скалярным значением и содержит один экземпляр char.

Строка "á" выглядит так же, как "á", но представлена двумя скалярными значениями и содержит два экземпляра char.

U+0061 СТРОЧНАЯ ЛАТИНСКАЯ БУКВА A
U+0301 ОБЪЕДИНЕНИЕ ОСТРОГО АКЦЕНТА

Наконец, строка " 👩🏽‍🚒 " представлена четырьмя скалярными значениями и содержит семь экземпляров char.

U+1F469 ЖЕНЩИНА (дополнительный диапазон, требуется суррогатная пара)
U+1F3FD EMOJI MODIFIER FITZPATRICK TYPE-4 (дополнительный диапазон, требуется суррогатная пара)
U+200D СОЕДИНИТЕЛЬ НУЛЕВОЙ ШИРИНЫ
U+1F692 ПОЖАРНАЯ МАШИНА (дополнительный диапазон, требуется суррогатная пара)

В некоторых из предыдущих примеров, таких как комбинированный модификатор акцента или модификатор тона кожи, кодовая точка не отображается на экране как отдельный элемент. Скорее, он служит для изменения внешнего вида текстового элемента, который был перед ним. Эти примеры показывают, что может потребоваться несколько скалярных значений, чтобы составить то, что мы считаем одним «символом» или «кластером графем».

Пример: количество символов, рун и текстовых элементов

Пример: разделение экземпляров строки

При разделении строковых экземпляров избегайте разделения суррогатных пар и кластеров графем. Рассмотрим следующий пример неправильного кода, который намеревается вставлять разрывы строк через каждые 10 символов в строке:

Поскольку этот код перечисляет экземпляры char, суррогатная пара, которая пересекает границу из 10 символов, будет разделена, и между ними будет введена новая строка. Эта вставка приводит к повреждению данных, поскольку суррогатные кодовые точки имеют смысл только как пары.

Возможность повреждения данных не устраняется, если вы перечисляете экземпляры Rune (скалярные значения) вместо экземпляров char. Набор экземпляров Rune может составлять кластер графем, который охватывает границу в 10 символов. Если набор кластеров графем разделен, он не может быть правильно интерпретирован.

Лучше разбить строку, подсчитав кластеры графем или текстовые элементы, как в следующем примере:

UTF-8 и UTF-32

Как и UTF-16, UTF-8 требует наличия нескольких единиц кода для представления некоторых скалярных значений Unicode. UTF-32 может представлять любое скалярное значение в одной 32-битной кодовой единице.

Вот несколько примеров, показывающих, как одна и та же кодовая точка Unicode представлена в каждой из этих трех систем кодирования Unicode:

Как отмечалось ранее, одна кодовая единица UTF-16 из суррогатной пары сама по себе не имеет смысла. Точно так же одна кодовая единица UTF-8 сама по себе не имеет смысла, если она находится в последовательности из двух, трех или четырех, используемых для вычисления скалярного значения.

Окончание байтов

В архитектуре с прямым порядком байтов строка, состоящая из кодовых точек UTF-16 [ D801 DCCC ], будет размещаться в памяти как байты [ 0x01, 0xD8, 0xCC, 0xDC ] . В архитектуре с обратным порядком байтов эта же строка будет размещаться в памяти как байты [ 0xD8, 0x01, 0xDC, 0xCC ] .

Компьютерные системы, взаимодействующие друг с другом, должны согласовать представление данных, передаваемых по сети. Большинство сетевых протоколов используют UTF-8 в качестве стандарта при передаче текста, отчасти для того, чтобы избежать проблем, которые могут возникнуть при взаимодействии машины с прямым порядком байтов с машиной с прямым порядком байтов. Строка, состоящая из кодовых точек UTF-8 [ F0 90 93 8C ], всегда будет представлена как байты [ 0xF0, 0x90, 0x93, 0x8C ] независимо от порядка следования байтов.

В предыдущем примере метод Encoding.UTF8.GetBytes декодирует строку UTF-16 обратно в серию скалярных значений Unicode, затем повторно кодирует эти скалярные значения в UTF-8 и помещает полученную последовательность в байт. множество. Метод Encoding.UTF8.GetString выполняет обратное преобразование, преобразуя массив байтов UTF-8 в строку UTF-16 .

Поскольку кодировка UTF-8 широко распространена в Интернете, может возникнуть соблазн считывать необработанные байты из сети и обрабатывать данные так, как если бы это была кодировка UTF-8. Тем не менее, вы должны подтвердить, что он действительно правильно сформирован. Вредоносный клиент может отправить в вашу службу неверный формат UTF-8. Если вы работаете с этими данными, как если бы они были правильно сформированы, это может привести к ошибкам или дырам в безопасности вашего приложения. Для проверки данных UTF-8 вы можете использовать такой метод, как Encoding.UTF8.GetString , который будет выполнять проверку при преобразовании входящих данных в строку .

Правильная кодировка

Правильно сформированная кодировка Unicode представляет собой строку единиц кода, которую можно однозначно и без ошибок декодировать в последовательность скалярных значений Unicode. Правильно сформированные данные можно свободно перекодировать между UTF-8, UTF-16 и UTF-32.

Вопрос о том, правильно ли сформирована последовательность кодирования, не связан с последовательностью байтов архитектуры машины. Неверно сформированная последовательность UTF-8 одинаково неправильно сформирована как на машинах с обратным порядком байтов, так и на машинах с прямым порядком байтов.

Вот несколько примеров неправильного кодирования:

В кодировке UTF-8 последовательность [ 6C C2 61 ] имеет неправильный формат, поскольку за C2 не может следовать 61 .

В UTF-32 последовательность [ 0011ABCD ] имеет неверный формат, поскольку 0011ABCD находится за пределами диапазона скалярных значений Unicode.

Неправильный литерал:

Подстрока, разделяющая суррогатную пару:

API, такие как Encoding.UTF8.GetString, никогда не возвращают неправильно сформированные экземпляры строк. Методы Encoding.GetString и Encoding.GetBytes обнаруживают неправильно сформированные последовательности во входных данных и выполняют замену символов при создании выходных данных. Например, если Encoding.ASCII.GetString(byte[]) видит во входных данных байт, отличный от ASCII (за пределами диапазона U+0000..U+007F), он вставляет '?' в возвращаемый экземпляр строки. Encoding.UTF8.GetString(byte[]) заменяет неправильно сформированные последовательности UTF-8 на U+FFFD REPLACEMENT CHARACTER ('�') в возвращаемом экземпляре строки. Дополнительные сведения см. в стандарте Unicode, разделы 5.22 и 3.9.

Встроенные классы Encoding также можно настроить таким образом, чтобы они выдавали исключение, а не выполняли подстановку символов при обнаружении неправильно сформированных последовательностей. Этот подход часто используется в приложениях, чувствительных к безопасности, где замена символов может быть неприемлемой.

В качестве промежуточного программного обеспечения SAP PI/PO интегрирует системы SAP/не SAP, которые используют разные форматы (текстовый (XML, CSV…), двоичный) для представления данных. Иногда они даже кодируют текст в разных форматах ИЛИ используют разные кодовые страницы. Этот документ помогает понять и справиться с такими ситуациями.

Кодовая страница представляет собой таблицу, в которой каждому символу присвоен номер. Например, «А» — 65, «а» — 97, «б» — 98 и т. д.

Нажмите на изображение, чтобы развернуть его. HTML-форма скриншотов ниже прилагается (пожалуйста, переименуйте .txt в .html). ASCII, ISO 8859-1, CP-1252 и Юникод.

«A» равно 65. 65 = 10 0001 (64*1 32*0 16*0 8*0 4*0 2*0 1*1). Представление номера кодовой страницы в 0 и 1 является кодировкой.

10 0001 равно 65. Найдите 65 в кодовой странице, это «A». Поиск номера кодовой страницы является декодированием.

Некоторые кодировки имеют фиксированную длину. Пример ASCII, ISO 8859-1, cp1252, UTF-32 и ISO 8859-1 и cp1252 должны использовать 1 байт для представления номера кодовой страницы. ASCII должен использовать 1 байт (на самом деле он использует только 7 байтов, 1-й бит игнорируется). UTF-32 должен использовать 4 байта.

Некоторые кодировки имеют переменную длину. Пример UTF-8 и UTF-16. UTF-8 будет начинаться с 1 байта, если номер кодовой страницы слишком велик для представления в 1 байте, он может использовать 2, 3 или 4 байта. UTF-16 будет начинаться с 2 байтов, при необходимости будет использоваться 4 байта (т. е. 2 байта или 4 байта).

UTF-8: – UTF-8 является предпочтительной кодировкой в Интернете. HTML, XML, JSON… по умолчанию кодируются в UTF-8.

Знак порядка байтов (BOM): — это уведомление целевой системы о кодировании. Некоторым приложениям Microsoft Windows требуется спецификация для правильного декодирования текста UTF. Вот как работает спецификация. Если мы отправляем текст в кодировке UTF-8, то мы добавляем к этому текстовому потоку префикс двоичной формы EF BB BF (шестнадцатеричный). Затем целевая система считывает эти символы и понимает: «Этот текстовый поток начинается с EF BB BF, тогда этот текст должен быть в формате UTF-8, и я должен использовать логику декодирования UTF-8». Он не будет отображать EF BB BF. Если мы отправляем UTF-16 с обратным порядком байтов, то мы добавим к этому текстовому потоку префикс FE FF (шестнадцатеричный). Затем целевая система считывает эти символы и понимает: «Этот текстовый поток начинается с FE FF, тогда этот текст должен быть UTF-16 BE».

Нажмите на изображение, чтобы развернуть его.

Чтобы проверить, используют ли исходная, PI/PO и целевая системы правильную кодировку. Вы можете запросить исходную систему для отправки знака евро € в одном из элементов данных. Если целевая система не декодирует € должным образом, проблема заключается в кодовой странице/кодировке.

Почему знак евро € отображается как €?

€ -> U+20AC (шестнадцатеричный) -> 0010 0000 1010 1100 -> 11100010 10000010 10101100 -> E2 82 AC -> â‚¬

Вот несколько замечаний из приведенного выше документа.

При чтении XML SAP рекомендует использовать для параметра «Тип файла» значение «Двоичный». Поскольку пролог XML имеет детали кодирования. SAP-нота 821267.

Для изменения кодировки можно использовать следующие модули адаптеров.

MessageTransformationBean: Transfer.ContentType = text/xml;charset="cp1252"

XMLAnonymizerBean: anonymizer.encoding = «utf-8»

К вашему сведению. cp1252 расширен до ASCII и ISO 8859-1. UTF-8 является надмножеством cp1252, но количество используемых байтов может отличаться.

Читайте также: