2016-08-09 6 views
4

У меня проблема с чтением закодированного файла, ранее налагаемого на мой собственный код.Java - Невозможно правильно прочитать ранее созданный закодированный файл

Исходная строка отображается правильно (в том числе ударения)

Мой код, чтобы сохранить строку в закодированный файл состоит в следующем:

OutputStreamWriter writer = new OutputStreamWriter(new FileOutputStream(fileName), 
     "ISO-8859-1"); 
writer.write(text); 

Затем я прочитал файл, как это : не корректно отображается результат

InputStream is = getClass.getResourceAsStream(fileName); 

try {   
    BufferedReader br = new BufferedReader(new InputStreamReader(is, "ISO-8859-1")); 
    String line; 
    StringBuilder sb = new StringBuilder(); 

    while((line = br.readLine()) != null) { 
     sb.append(line); 
    } 

    String result = sb.toString(); 
} catch (UnsupportedEncodingException e3) { 
} catch (IOException e) { } 

Строка. Например, метки акцента отсутствуют.

Я также пробовал другие способы, такие как кодирование строки в байтах, а затем записывать в файл эти байты. Я всегда получаю те же результаты, что и другие кодировки ISO. Есть идеи?

+0

API работает хорошо, должна быть некоторая другая ошибка в настройках кодирования вашего терминала. – Kennet

+0

Вы пишете файл в файловой системе, но чтение происходит из ресурса, на пути к классу, возможно, упакованного в банку или в войну. Это может означать, что вы говорите о двух разных файлах, возможно, в вашем исходном каталоге, в каталоге сборки или в банке. И чтение может быть даже в кешированной версии, до письменной. Измените содержимое, чтобы проверить это. (И тогда 'append (" \ r \ n ")' отсутствует, равно как и закрытые вызовы.) –

+0

Невозможно воспроизвести. Если вы читаете файл с той же кодировкой, что и для его записи, вы получаете одинаковые символы, но мне пришлось добавить явный 'writer.close()', чтобы на самом деле писать. Что может случиться: не читать ожидаемый файл, как предлагается Joop, отображая один из файлов на неправильно сконфигурированном терминале и т. Д. Но это ** не ** проблема преобразования Java. –

ответ

0

Проблема в том, что ваша строка имеет другой набор символов, возможно UTF-16. Вывод текста в качестве необходимого набора символов

Этот ответ показывает syntax

+0

Не могли бы вы рассказать о том, что означает * ваша строка имеет другой набор символов, возможно UTF-16 *? Конечно, есть! Спецификация Java говорит, что строки кодируются внутри UTF16. Но это совершенно не связано с вопросом. –

+0

Ваш вопрос не в том, почему stringbuilder выводит символы неправильно? Причина в том, что stringbuilder.toString выводит UTF-16 – farrellmr

+0

Прямой вывод UTF-16 почти встречается только в графических программах, потому что интерфейсы командной строки используют 8 бит символов в общих системах (Linux, Windows, Mac). Когда вы используете 'System.out.println', строка автоматически кодируется в кодировке sytem по умолчанию. Но это действительно может быть проблема кодирования в окне терминала. Ваш ответ не так уж плох и показывает, где проблема может лежать, но причина, которую вы даете, неверна. –

0

Проблема решаемая!

Это не было связано с какой-либо ошибкой в ​​коде. В настоящее время я работаю над командой, и проект был составлен с Maven.

На данный момент я построил проект, Maven скопировал все ресурсы в другую папку, закодировав их в UTF-8. В коде при получении ресурса файл, который он читал, не был исходным файлом, а кодированный файл UTF-8, созданный Maven.

Извините, что не публикуем эту деталь, я новичок с Maven, и я не знал, что это может вызвать такие проблемы.

Благодарим всех вас за ответы!

Смежные вопросы