Кодировка исходного файла Java и неудачный тест - PullRequest
1 голос
/ 30 ноября 2011

Во-первых, я хотел бы сказать, что я потратил много времени в поисках объяснения / решения. Я нашел подсказки о проблеме, но не смог решить мою конкретную проблему. Отсюда и пост на тему, которая, кажется, была избита до смерти хотя бы в некоторых случаях.

У меня есть тестовый класс Java, который проверяет правильное кодирование / декодирование утилитой Mime. Строки, используемые для тестирования, объявлены в исходном файле, и мы используем assertEquals () для проверки равенства после обработки входной строки. Вот пример:

String test = "S2, =?iso-8859-1?Q?F=E4ltstr=F6m?= =?iso-8859-1?Q?,_Patrik?= S3";
String expected = "S2, Fältström, PatrikS3";

В моем редакторе (и других внешних редакторах, таких как Notepad ++ и UltraEdit) входные строки отображаются правильно, если я решу прочитать их как кодировку windows-1252 или ISO-8859-1; UTF-8 отображает ожидаемую строку как «F ltstr m».

При компиляции и запуске на компьютере с Windows 7 я получаю следующий вывод:

Ожидаемый: S2, F ltstr m, PatrikS3

Фактически: S2, Fältström, PatrikS3

Я получаю это поведение в командной оболочке, а также в моем редакторе кода. Как ни странно, он работает на компьютере с Windows XP. Тем не менее, я проверил кодовую страницу, используя chcp в командной оболочке, и в обоих случаях получаю одинаковый вывод. Единственный способ заставить это работать - это скомпилировать класс с помощью "-encoding windows-1252", что я не хочу делать по разным причинам.

Итак, вопросы: 1) что отличает XP и Windows 7 от этого? Изменилась ли кодировка платформы по умолчанию? 2) как я могу это исправить, чтобы он работал как на машине с Windows 7, так и на машине с Linux?

Большое спасибо за понимание!

Ответы [ 4 ]

2 голосов
/ 30 ноября 2011

Похоже, кодировка по умолчанию, используемая на вашем компьютере с Windows 7, - UTF-8, а в Windows XP - Windows-1252. Итак: всегда будьте явными в кодировке, которую ваши файлы используют при компиляции, не зависите от платформы по умолчанию.

Кстати: насколько я знаю, Java на моем компьютере с Windows 7 по-прежнему использует Windows-1252 по умолчанию.

0 голосов
/ 01 декабря 2011

Достаточно предыдущих ответов.

Как вы упомянули.К вашему сведению, в наших проектах мы установили (java) исходную кодировку UTF-8, чтобы оставаться международным и без необходимости возвращаться к \ uXXXX Escape.Читатели и Авторы явно упоминают кодировку.Ведь и в наших национальных проектах мы придерживаемся UTF-8. Я думаю, что UTF-8 может быть новым соглашением.

BufferedReader in = new BufferedReader(
      new InputStreamReader(new FileInputStream(is), "UTF-8"));

Экранирование MIME-строк не требуется в API Java-почты, который может обрабатывать UTF-8 в темах и контенте.*

0 голосов
/ 30 ноября 2011

Я не эксперт в этом вопросе, но чтобы увидеть, действительно ли они разные, зайдите на: Язык и региональные стандарты -> Панель управления -> Вкладка дополнительных параметров В общем, вы не можете ожидать, что все ваши пользователи будут использовать латинскую кодировку Windows по умолчанию и зачем вам это? Кроме того, подумайте о других операционных системах, которые используют другие кодировки по умолчанию (* nix, MAC и т. Д.).Это оставляет вам возможность угадать, потому что, скажем, если у вас есть латинский символ A, вы не сможете различить, находится ли он в ASCII, UTF-8 или ISO-8859-1, потому что эти кодировки отображают этот символ на одну и ту же запись в таблице символов.(в нашем случае запись таблицы 41 в шестнадцатеричном формате)!Если вы действительно хотите как-то решить эту проблему, то нет идеального решения, но вы можете использовать CharsetEncoder ( Java SE 7 - CharsetEncoder ) и CharsetDecoder ( Java SE 7 - Charset Decoder )может быть в состоянии обрабатывать символы в определенном формате и кодировать / декодировать их как байты.Однако в этом подходе все еще есть некоторые недостатки, такие как:1) Вы не можете ожидать, что все сопоставления символов будут обнаружены успешно.2) Это убийственная производительность при выполнении нескольких / тяжелых операций ввода-вывода.Лучшая ставка, на мой взгляд, одна: КОНВЕНЦИЯ Используйте собственное кодирование-декодирование (например, UTF-8) с помощью концевых строк в стиле Unix (/ n) и обрабатывайте все файлы как таковые.Если вы планируете читать файлы, созданные другими, и ожидаете прочитать символы, которые не могут быть отображены в вашей кодировке, попробуйте использовать «большую» кодировку (UTF-16) или прочитать «недопустимый» символ в байтах и ​​записать его с помощьюсобственная кодировка в байтах (однако она будет записана в нечитаемом / непредставимом формате!)Мои 0,02 цента.Повеселись :) РЕДАКТИРОВАТЬ : Проверьте также этот пост: Преобразование кодировки Java

0 голосов
/ 30 ноября 2011

Что касается того, как это исправить, я бы посоветовал вам сохранить ваши тестовые данные в файле или файлах. Убедитесь, что файлы сохранены с необходимой кодировкой. Загрузите свои тестовые данные во время выполнения, используя необходимую кодировку. Это отделяет ваши тесты от кодировки компилятора.

...