Есть сообщение xml сообщения в формате UTF-8 т.е. там из само сообщение и его заголовок с указанием версии
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
нужно сконвертировать XML в Utf-16 вместе с заголовком.

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

Напр через JAXP через парсер считать XML (без DOM просто Simple API ), и перевести в другую кодировку.
В документации JAXP и поиском хорошего варианта я не нашел.

Задача относится к известной проблеме - как сохранить Utf-8 в колонку MS SQL с типом XML . MS SQL хранит все в UTF-16, а сообщение приходит в UTF-8

Я сначала думал что SQLXML может сам преобразовать, но ошибался .



Выдаст "XML parsing: line 1, character 38, unable to switch the encoding"

Самое удивительное если сообщение передать в UTF-8 но заголовок поправить на encoding="UTF-16" передача в SQl пройдет нормально. Возможно из за того что Java хранит строки внутри в Utf-16 по некоторым источникам.
В общем хотелось бы услышать Best practice , не хочется писать костыли

Ну это странно, что сама задача костыль вроде перекодировка в более широкую кодировку не является криминалом.
Мне потом для Win-1251 тоже отдельный костыль писать?

да
Сообщения приходят из шины RabbitMQ, кодировка сообщения известна. Я их сохраняю в свой буфер, буфер на MSSQL он XML хранит в UTF16.
При маштабировании могут появляться новые кодировки

Petro - к сожалению вы не прочитали ту ссылку которую привели (я понимаю много букв) . Покажу пальцем.
https://docs.microsoft.com/ru-ru/sql/relational-databases/native-client/features/using-xml-data-types?view=sql-server-ver15
здесь описываются правила того как SQL сервер проводит конвертации в свой внутренний тип.
Возьмите напр раздел ODBC

"
When converting from C to SQL data types, SQL_C_WCHAR, SQL_C_BINARY, and SQL_C_CHAR can all be converted to SQL_SS_XML, with the following stipulations:

SQL_C_WCHAR: A BOM is always be added to data sent to the server. If the data already started with a BOM, this results in two BOMs at the start of the buffer. The server uses the first BOM to recognize the encoding as UTF-16 and then discard it. The second BOM is interpreted as a zero-width nonbreaking space character.

SQL_C_BINARY: No conversion is performed, and the data is passed to the server "as is." UTF-16 data must start with a BOM; if it does not, the encoding may not be correctly recognized by the server.

SQL_C_CHAR: The data is converted to UTF-16 on the client and sent to the server just as SQL_C_WCHAR (including the addition of a BOM). If the XML is not encoded in the client code page this can cause data corruption.
"

Про OleDB аналогично. Я думаю это достаточно для понимания что проблема существует и SQL сервер хранит XML тип в UTF-16.
Если спросите гугл "ms sql xml utf-8 utf-16 " там будет куча подобных проблем.

Больше я бы не хотел обсуждать постановку задачи, поскольку для меня проблема очевидна

P S Версия SQL у меня 2008r2 , в более старших там не лучше , кому интересно см тут https://techcommunity.microsoft.com/t5/sql-server/introducing-utf-8-support-for-sql-server/ba-p/734928 они расширили поддержку для строковых типов но для XML колонок нет
Кстати SQL вообще на внутренних типах сидит на UTF-16 на всех типах и только с 2019 го там начали UTF-8 внедрять
Более того Db2 тоже этим страдает https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/java/src/tpc/imjcc_c0021816.html

А зачем в SQL XML колонки как специальный тип? Подумали? .....
а ну конечно чтобы XMLQuery использовать XPath и вообще много чего интересного. Нельзя узко мыслить в современном мире, иначе XML будет восприниматься как обычный текст с тегами, без валидации по схеме и без применения стека XML технологий.

Perto прошу не участвовать в обсуждении, я не собираюсь рассказывать всю свою архитектуру для этого есть другой раздел форума
https://www.sql.ru/forum/systems-architecture . Как говорится не знаете ответа пройдите мимо

работает.
Хотя непонятно тогда почему на том же сообщении в UTF-8 НЕ работает


Судя по стандарту https://www.w3.org/TR/xml/#sec-guessing должно было работать, но видимо SQLXML от setString ждет чтото другого.

Проверю еще на разных кодировках, спасибо за наводку

mad_nazgul, у вас там какая то своя боль по поводу хранения в форматах XML Json и вы куда то повели далеко от темы
Как я ранее написал " Я их сохраняю в свой буфер, буфер на MSSQL" это именно буфер. Шина не может долго хранить очередь, а вот исходники сообщений нужно гдето хранить для последущей загрузки в структуры реляционной базы данных. В XML колонках это удобно, допустим загрузили из буфера данные в таблицы СУБД, а по истечении времени понадобилось вытащить из сообщений еще один реквизит - просто сканируем буфер еще раз и добавляем его + в регулярный код. При наличии буфера всегда можно предъявить исходник сообщения, по которому создали документ или операцию в таблицах СУБД. Плюсов много не буду все перечислять,.Естественно использовать XML колонки для аналитических отчетов это противопоказано - просто технологически нет достаточных средств для этого.

Это именно буфер истории сообщений, сообщение как правило читается максиму 2 -3 раза при импорте в субд. За год может набежать 5 терабайт. Если хотите предложить лучшее решение нужно видеть полную картину и уже от нее думать, но я не дал достаточно информации чтобы думать ;)

[quot lleming#22147983]

Ну тогда это то что нужно, исходники интересно для Jdbc можно смотреть?

мне тут смайликов недостаточно что выразить эмоции