Проблема с кодировкой между новым установленным сервером Ubuntu 16.04 LTS и обновленным сервером - PullRequest
0 голосов
/ 06 июня 2019

В рамках проекта нам нужно было перейти с Ubuntu 14.04 на Ubuntu 16.04. Тем не менее, поскольку обновление было завершено, полная функциональность не работает правильно. Кодировка символов перемешивается при сохранении в базе данных. Одна и та же версия программного обеспечения Debian дает разные результаты, что подразумевает проблему ISO с другой библиотекой или некоторые различия в поведении Java.

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

Было добавлено ведение журнала для печати полученных байтов, и Java все еще читает это, как и следовало ожидать. Однако, когда он сохраняет их в базе данных, они совершенно разные. Это делается через настройку соединения JPA ранее. Это уже использует поле 'useUnicode = true & characterEncoding = UTF-8'. Когда Java снова читает эти данные, она все еще думает, что использует правильные байты, когда это не так. Аналогично, если вы добавляете что-то непосредственно в БД, в журналах отладки Java не отображаются правильные байты, однако информация по-прежнему отображается правильно при отображении через интерфейс, который мог пройти только здесь. Это подразумевает, что проблема заключается в хранении данных, а не в их обработке, но одна и та же версия установки Debian влияет на обе версии. Рабочая версия правильно читает байты, когда выводит их из базы данных.

شلاؤ, например, на арабском языке, как предполагается, кодируется как (с помощью шестнадцатеричной функции в mysql / mariadb), в правильной версии выходит как «D8B4D984D8A7D8A4» НО в неправильной версии, отображается как «C398C2B4C399C284C398C2A7C39. Это может предоставить больше информации о том, почему кодировка не работает правильно. С Java, читающим неправильные байты, как будто они правильные, это, скорее всего, проблема с Java, но путаница остается из-за несоответствия между системами.

Ответы [ 2 ]

0 голосов
/ 11 июня 2019

Для тех, кто может испытывать нечто подобное, получилось так, что Java работала без дефолта до utf8. OpenEJB / JPA был настроен правильно, как и база данных, но один из аспектов сервера по умолчанию использовал другую кодировку, поэтому аргументы запуска для затронутой области решили проблему!

0 голосов
/ 06 июня 2019

D8B4D984D8A7D8A4 - это правильная кодировка utf8 (или utf8mb4) для شلاؤ.C398C2B4C399C284C398C2A7C398C2A4 - это версия с двойным кодированием.Это подразумевает, что что-то все еще указывает "latin1" как набор символов.Возможно, вы сбросили и перезагрузили данные, и вот где это произошло?

Подробнее об этом см. Проблема с символами UTF-8;то, что я вижу, это не то, что я хранил и, возможно, http://mysql.rjweb.org/doc.php/charcoll

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...