Проблема возврата строк с - в MySQL из Java

Я использую базу данных MySQL с приложением Spring.

База данных должна иметь зашифрованные личные данные. Это сделано с помощью AES_ENCRYPT. Данные получены с помощью AES_DECRYPT для их отображения.

Проблема заключается в том, что при возврате строк, которые должны содержать ñ, тильды или специальные символы, они не отображаются как таковые и изменяются (ñ как ñ).

Кто-нибудь знает, как вернуть правильные символы из базы данных?

Я понимаю, что вы храните их уже модифицированные (ñ вместо ñ) в поле VARBINARY.

ИЗМЕНЕНО

utf8 - utf_spansih_ci используется для таблицы. Проблема заключается в том, что в полях, которые не VARBINARY, он хранится правильно.

2
задан 13.10.2016, 14:58
4 ответа

Да, ты должен показывать ему, что это специальный символ utf8_spanish.

SELECT nombre 
  FROM empleados 
 WHERE nombre
  LIKE '%ñ%' COLLATE utf8_spanish_ci 
1
ответ дан 24.11.2019, 13:07
  • 1
    В ajecutars консультация: – user1748166 13.10.2016, 15:12
  • 2
    Выполнив консультацию SELECT AES_DECRYPT(campo,clave) COLLATE utf8_spanish_ci FROM table дай ошибку COLLATION not valid for CHARACTER SET 'binary' – user1748166 13.10.2016, 15:13
  • 3
    Гениальный, funcin и # 243;! – user1748166 13.10.2016, 15:20

cotejamiento базы данных - в utf8? Если он не так, измени ее с

ALTER TABLE <table name> COLLATE utf8_general_ci;
2
ответ дан 24.11.2019, 13:07
  • 1
    Я соглашаюсь из-за двух v и # 237; схвати. Из-за workbench или из-за aplicaci и # 243; n Java Спринг MVC. База данных est и # 225; уже в utf-8, поля, хранившиеся в поле VARCHAR, если, что хранятся правильной формы. Проблема - с VARBINARY despu и # 233; s делания одного AES_ENCRYPT и и #192; ES_DECRYPT' – user1748166 13.10.2016, 14:56

Если заявление таблицы кодов таблицы сделано на основании utf8 и все же он не возвращает "специальные" символы, вероятно, что соглашаются на Сервер Данных с приложением, которое конфигурировалось под другой таблицей кодов. Попытайся выполнять предварительную консультацию, чтобы просить данные в utf8: SET NAMES utf8. Эта консультация спровоцирует, что сервер возвращает результаты, кодировавшие в utf8. Также помещается возможность, что данные были разложены с Вашего хранения, это, что были посланы кодировавшие в не подожданной таблице кода. ЗАМЕТЬ: Для использования символов испанского языка, рекомендуемо использовать заявление utf8_spanish_ci.

2
ответ дан 24.11.2019, 13:07
  • 1
    Таблица уже est и # 225; в utf8_spanish_ci. Я ввожу с workbench, и во всех случаях он возвращает мне ñ, измененный – user1748166 13.10.2016, 14:58

Проблема была решена делая

CAST(AES_DECRYPT(campo, clave) AS CHAR) COLLATE utf8_spanish_ci

Со Спринг singue, не функционируя: знает кто-то, как вынуждать COLLATION в одном ComboPooledDataSource? Только несмотря на то, что он включает COLLATE в querys не функционирует

Было нужно менять charset server в utf8, с latin1, потому что а он входит в конфликт.

1
ответ дан 24.11.2019, 13:07