Я сталкиваюсь с проблемами при составлении отчетов при отображении имен. Мое приложение использует разные технологии PHP, Perl и BI Pentaho.
Мы используем MYSQL в качестве базы данных, и моя таблица CHARSET=utf8
,
Моя таблица хранится со значениями в строках, как показано ниже, что неправильно
Row1 = Ãx—350
Row2 = Ñz–401
PHP и Perl используют разные встроенные функции для преобразования указанных выше значений, которые хранятся в БД и отображаются в пользовательском интерфейсе, как показано ниже, что является правильным
Expected Row1 = Áx—350
Expected Row2 = Ñz–401
Приходя к отчетам, использующим Pentaho, я использую ETL для преобразования данных, прежде чем показывать данные в отчетах. Чтобы преобразовать вышеупомянутые сохраненные значения БД, я пытаюсь преобразовать данные через шаг Java как ниже
new java.lang.String(new java.lang.String(CODE).getBytes("Windows-1252"), "UTF-8")
Но это не преобразование значений должным образом, только среди 2 вышеупомянутых неправильных значений Стр2 значение было преобразовано правильно, но первое Row1 неправильно конвертировать, как показано ниже
Converted Row1 = �?x—350
Converted Row2 = Ñz–401
Подскажите, пожалуйста, каким образом я могу правильно преобразовать значения, чтобы, например, Row1 значение должно быть правильно преобразовано в АХ-350.
Я написал небольшую программу на Java, как показано ниже AXA €»350 строка в АХ-350
String input = "Ãx—350";
byte[] b1 = input.getBytes("Windows-1252");
System.out.println("Input Get Bytes = "+b1.toString());
String szUT8 = new String(b1, "UTF-8");
System.out.println("Input Encoded = " + szUT8);
Выход из приведенного выше кода, как показано ниже
Input Get Bytes = [B@157ee3e5
Input Encoded = �?x—350-350—É1
Если мы видим вывод, строка неверна там, где фактический ожидаемый результат равен АХ-350.
Подтвердить на кодирование / декодирование схемы, которые я попробовал проверить строку онлайн и проверено со строкой AXA €»350 и выход, как и ожидалось АХ-350 что правильно.
Поэтому из этого следует указать, почему java-код не может преобразовываться должным образом, хотя я использую правильные схемы кодирования / декодирования, что-либо еще, что пропущено или мой подход неверен.
CHARSET
если в вашей базе данных установлено значение utf-8, это не обязательно означает, что данные там должным образом кодируются в utf-8 (или даже вообще в utf-8), как мы можем видеть. Похоже, вы имеете дело с кракозябры — символы, которые были одновременно декодированы с использованием неправильной схемы кодирования, а затем, в свою очередь, закодированы неправильно. Исправление — это обычно утомительный процесс определения прошлых ошибок декодирования / кодирования и последующего их устранения.
Короче говоря: если у вас есть моджибаке, вы не сможете выполнять автоматические преобразования, если не знаете (или не можете выяснить), какие преобразования были сделаны в прошлом.
Преобразование — это вопрос сначала декодирования, а затем кодирования. Чтобы конвертировать в Perl:
my $string = "some windows-1252 string";
use Encode;
my $raw = decode('windows-1252',$string);
my $encoded = encode('utf-8',$raw);
Других решений пока нет …