Как в джава при чтении файла указать кодировку
Обновлено: 05.07.2024
Как получить кодировку символов текстового файла в Java [версия UTF-8, улучшенная версия]
1. Распознать кодировку символов:
1. Кодировка String в Java по умолчанию - UTF-8, которую можно получить с помощью следующего оператора: Charset.defaultCharset();
2. По умолчанию в Windows используется кодировка текстовых файлов ANSI, для китайских операционных систем - GBK. Например, если мы используем программу «Блокнот» для создания нового текстового документа, кодировка символов по умолчанию - ANSI.
3. Для текстовых текстовых документов предусмотрены четыре варианта кодирования: ANSI, Unicode (включая Unicode Big Endian и Unicode Little Endian), UTF-8, UTF-16.
4. Поэтому, когда мы читаем txt-файл, мы иногда можем не знать его формат кодирования, поэтому нам нужно использовать программу для динамического определения кодировки txt-файла.
- ANSI: нет определения формата, GBK или GB2312 для китайских операционных систем
- UTF-8: первые три байта: 0xE59B9E (UTF-8), 0xEFBBBF (UTF-8 с спецификацией)
- UTF-16: первые два байта: 0xFEFF
- Unicode: первые два байта: 0xFFFE
Например, если документ Unicode начинается с 0xFFFE, используйте программу, чтобы вынуть первые несколько байтов и оценить.
5. Соответствие между кодировкой Java и кодировкой текста:
UTF-8 содержит две спецификации:
Нужно судить о первых трех байтах:
Первые три байта: 0xE59B9E
Первые три байта: 0xEFBBBF
Юникод содержит две спецификации:
1、UCS2 Little Endian
2、UCS2 Big Endian
Java читает текстовый файл. Если формат кодирования не совпадает, появятся искаженные символы. Поэтому вам необходимо установить правильную кодировку символов при чтении текстовых файлов. Формат кодирования текстового документа записывается в заголовке файла. Формат кодирования файла необходимо проанализировать в программе. После получения формата кодирования файл не будет искажен при чтении файла в этом формате.
Эта статья посвящена нескольким наиболее часто используемым методам чтения файла на Java.
- Файлы.строки , возвращают поток ( Java 8)
- Files.ReadString , возвращает Строка (Java 11), максимальный размер файла 2G.
- Files.ReadAllBytes , возвращает байт[] (Java 7), максимальный размер файла 2G.
- Files.ReadAllLines , возвращает Список<Строка> ( Java 8)
- BufferedReader , классический старый друг (Java 1.1 -> навсегда)
- Сканер (Java 1.5)
Новая Java 8 Files.lines хорошо работает при чтении небольших или больших текстовых файлов, возвращает Поток (гибкий тип и поддержка параллельных), автоматически закрывает ресурсы и содержит одну строку чистого кода.
В современной Java 8+ мы должны использовать Files.lines для чтения текстового файла.
Примечание В двух словах, нет большой разницы в чтении небольших файлов, просто вкус возвращаемого типа. Для чтения в большом файле выберите Java 8 Files.lines для потоковых и параллельных функций или классический БуферизоВанный читатель .
Текстовый Файл
Вот простой текстовый файл, содержащий всего пять строк. Остальные примеры Java будут читать этот файл.
1. Файлы.строки ( Java 8)
1.1 В этом примере используется Java 8 Files.lines для чтения вышеупомянутого файла в Поток и печати его строка за строкой. Кроме того, Files.lines поможет автоматически закрыть открытый ресурс (файл); нам не нужно заключать код в try-with-resources .
1.2 Для чтения в небольшом текстовом файле мы можем использовать собрать легко преобразовать поток в Список<Строка> .
1.3 Для чтения в большом текстовом файле, и если порядок строк не имеет значения, мы можем включить параллельный поток функция для дальнейшего повышения скорости чтения.
1.4 Распространенной ошибкой является прямое преобразование большого Потока в Список , и это приведет к java.lang. Ошибка из памяти: Пространство кучи Java если размер потока больше, чем размер кучи запущенной JVM.
1.5 Последний, lines.foreach , не сохраняет порядок строк, попробуйте lines.forEachOrdered если мы хотим сохранить порядок.
2. Файлы.Строка чтения (Java 11)
2.1 Это Files.ReadString() считывает файл в строку, и если размер файла для чтения превышает 2G, он выдает java.lang. Ошибка из памяти: Требуемый размер массива слишком велик .
2.2 Просмотрите исходный код, новую Java 11 ReadString , внутренне используйте существующую Java 7 ReadAllBytes для чтения файла в байт[] и JLA.новая строка Без ответа для преобразования байта[] обратно в строку.
3. Файлы.ReadAllBytes (Java 7)
3.1 В этом примере используется Files.ReadAllBytes для чтения файла в массив байтов байт [] , если размер файла для чтения превышает 2G, он будет выбрасывать java.lang. Ошибка из памяти: Требуемый размер массива слишком велик .
4. Файлы.Строки для чтения (Java 8)
4.1 В этом примере используется Files.ReadAllLines чтобы прочитать файл в Список<Строка> , если размер файла больше, чем размер кучи запущенной JVM, он выбросит java.lang. Ошибка из памяти: Пространство кучи Java .
5. БуферизоВанный читатель (Java 1.1)
5.1 Классический и старый друг, BufferedReader пример, хорошо работает при чтении небольших и больших файлов, а размер буфера по умолчанию (8 кб) достаточно велик для большинства целей.
5.2 Мы можем указать размер буфера.
5.3 В Java 8 мы можем использовать новый Files.newBufferedReader для создания BufferedReader .
Просмотрите исходный код, ничего особенного.
Прочтите это – Java Как читать файл с помощью BufferedReader
5.4 Для справки, классическая попытка поймать, наконец, закрыть открытый файл вручную.
6. Сканер (Java 1.5)
6.1 В классе Сканер функция разделитель по-прежнему полезна для чтения и фильтрации небольшого файла. Java 9 и Java 10 добавили новые методы, такие как найдите все и конструкторы для улучшения класса Сканер . Однако для чтения в большом файле этот класс Scanner работает медленно по сравнению с BufferedReader .
С кодировками в java плохо. Т.е., наоборот, все идеально хорошо: внутреннее представление строк – Utf16-BE (и поддержка Unicode была с самых первых дней). Все возможные функции умеют преобразовывать строку из маленького регистра в большой, проверять является ли данный символ буквой или цифрой, выполнять поиск в строке (в том числе с регулярными выражениями) и прочее и прочее. Для этих операций не нужно использовать какие-то посторонние библиотеки вроде привычных для php mbstring или iconv. Как говорится, поддержка многоязычных тестов “есть в коробке”. Так откуда берутся проблемы? Проблемы возникают, как только строки текста пытаются “выбраться” из jvm (операции вывода текста различным потребителям) или наоборот пытаются в эту самую jvm “залезть” (операция чтения данных от некоторого поставщика).
Сказка про капиталистов
Надо сказать, что unicode это не статическое образование, не принятый еще при царе горохе стандарт, который с тех пор безуспешно пытаются реализовать производители различных продуктов. Это динамический, постоянно развивающийся стандарт, с множество версий и соответствующих спецификаций. Полагаю, с тем, что для хранения текста написанного на различных языках (а для азиатов хватит и одного их родного языка) размера символа в один байт совершенно не достаточно, согласны все. Нет, чтобы взять и прикинуть, сколько там всего языков на всей планете, сколько в их алфавитах символов, сколько разных значков (нотных, графических) может потребоваться на ближайшие 100 лет. Взяли, прикинули: 1 байт – смешно, 2 уже лучше, но все равно маловато, 3 байта (примерно 16 миллионов символов уже хорошо), а если взять для представления символа все 4 байта (4 миллиарда с гаком) – то просто замечательно. Приняли бы такое решение, потом бы издали указ: мол, так и так с первого числа сего месяца начинается новые и улучшенные компьютерные времена, переделали бы все заводы по производству компьютеров, вызывали Била Гейтса на партсобрание, дали бы ценное указание и жизнь стала бы гораздо лучше. Увы, в этом жестком капиталистическом мире, на всей планете найдется всего несколько человек, которые согласятся ради возможности решить раз и навсегда все проблемы на то, чтобы объем их винчестеров и оперативной памяти уменьшится сразу в четыре раза (во сколько раз уменьшится производительность вычислений сказать тяжело – но все равно очень неслабо). Да, еще достижение всеобщего блага привело бы к полной потере всего ранее написанного софта, документов и т.д. Увы капитализм не захотел устроить всемирный субботник, а нам наследникам красного октября приходится это расхлебывать. Конечно, это шутка. Но во всякой шутке, как известно, есть доля шутки. Первая версия Unicode представляла собой кодировку, в которой каждый символ кодировался 2 байтами, для некоторых символов (наиболее часто используемых, а не всех возможных) были выделены определенные области (интервалы). Потом, с течением времени решили, что все же 64 тысяч символов будет маловато и необходим механизм хранения их большего числа. Кроме того, разработчики стандарта поняли, что в разных странах разное понятие о “букве” и все стало еще сложнее. В принципе все это написано на wikipedia, так что прекращаю рассказывать сказки, и перехожу к java, точнее к проблемам связанным с кодировками в java.
Типовые проблемы с которыми сталкиваются java-разработчики
Т.к. java приложения взаимодействуют с различными подсистемами, то и возникающие проблемы бывают разными. Хотя все, в общем случае, сводится к одной из двух проблем:
Проблема 1. Данные были успешно прочитаны, но на стадии отображения не нашлись нужные шрифты. В этом случае отсутствующие картинки шрифта заменяются на квадратики. Лечится проблема путем установки нужных шрифтов (например, при установке windows вас обычно спрашивают, хотите ли вы добавить поддержку шрифтов для азиатских языков). Есть два вида шрифтов: физические и логические. Физические шрифты – это те шрифты, файлы которых установлены либо в папку там_где_ваша_jre/lib/fonts, либо те шрифты которые установлены в стандартное место для вашей операционной системы (все версии jre обязаны поддерживать шрифты TrueType, остальные же форматы - необязательно). Логические шрифты (например, Serif, Sans-Serif, Monospaced, Dialog и DialogInput) – это правила отображения некоторых имен на реальные физические шрифты. Например, для windows логический шрифт serif это ссылка на физический times new roman. Задаются эти правила в файлах fontconfig.properties.src, fontconfig.98.properties.src, fontconfig.Me.properties.src. Для swing приложений, мы можем не только работать с идущими в самой операционной системе шрифтами, но и носить файл шрифта вместе со своим приложением, так чтобы полностью не зависеть от того, где оно будет запущено. В составе класса java.awt.GraphicsEnvironment есть несколько методов позволяющих получить информацию о том, какие шрифты доступны на вашем компьютере.
public Font [] getAllFonts ()public abstract String [] getAvailableFontFamilyNames ()
Надо сказать, что в качестве параметра второму методу можно передать в качестве параметра объект Locale (сведения о географическом местоположении страницы, ее языке, денежных единицах …). В этом случае будут возвращены шрифты, локализованные для именно этого языка. Если же никакого параметра при вызове не указать, то вы получите список шрифтов привязанных к текущей (по-умолчанию) локали.
Для того, чтобы создать шрифт на основании некоторого файла ttf, необходимо вызвать статический метод createFont из класса Font. В качестве параметров для него следует указать файл, который содержит определение шрифта, а также указать тип этого файла (Font.TRUETYPE_FONT или Font.TYPE1_FONT). Созданный объект шрифта можно “настроить” указав для него размер или стиль (plain, italic, bold). Используйте для этого метод deriveFont.
JPanel pa = new JPanel ( new GridLayout ( 0 , 1 )) ;
pa.add ( lab_1 ) ;
pa.add ( lab_2 ) ;
pa.add ( lab_3 ) ;
pa.add ( lab_4 ) ;
jf.setContentPane ( pa ) ;
jf.pack () ;
Теперь вернемся к русским буквам и java.
Вторая наиболее часто встречающаяся проблема - это неправильное преобразование кодировки. Например, вы хотите прочитать текстовый файл в кодировке windows-1251. Но при создании объекта InputStreamReader вы указали неверную кодировку (или положились на значение по-умолчанию).
В результате при чтении файла символы будут рассматриваться как принадлежащие определенной кодовой странице. Но вовсе не факт что некоторый код символа корректный для кодировки A будет также корректен для кодировки B. В случае корректности кодов, мы увидим то, что некоторые из символов были заменены на какие-то другие символы. А вот, если код является некорректным (например, зарезервирован на будущее), то такой символ будет заменен на знак “?”.
Для получения списка всех доступных кодировок вы можете использовать следующий код (вызов статического метода Charset.availableCharsets):
SortedMap<String, Charset> charsetsMap = Charset.availableCharsets () ;final JList list = new JList ( charsetsMap.keySet () .toArray ()) ;
final JScrollPane pane = new JScrollPane ( list ) ;
jf.getContentPane () .add ( pane ) ;
jf.pack () ;
Здесь “utf-8” правильная кодировка, а “windows-1251” – неправильная.
Но предупреждаю сразу – это плохой, очень плохой способ “починить примус”. Помните, что в ходе преобразований возможна потеря символов (из-за несовместимых кодировок). Так что если вы прочитали данные из файла в неверной кодировке, то отсутствующие символы были заменены на значки вопросов. Следовательно попытка восстановить оригинальный массив байтов будет безуспешной.
Java и web.
Web – это то самое место где сталкиваются множество людей работающих под разными версиями операционных систем использующие разные браузеры и написанный нами сайт должен работать всегда и везде.
Самая идеальная ситуация - когда отправка идет с помощью метода POST. В этом случае браузер кодирует данные в такой же кодировке, как и в той, что была сформирована веб-страница. За кодировку возвращаемых данных отвечают либо указанная вверху jsp-файла директива:
Первая из этих опций (contentType) указывает на кодировку выходного документа, а вторая (pageEncoding) на кодировку собственно файла в котором находится код jsp-страницы.
Либо, если вы создаете сервлет, то первым шагом нужно указать выходную кодировку документа:
Классно, значит, если мы сформировали страницу в кодировке utf-8, то данные из формы придут к нам в формате “utf-8”. Классно, то классно, но кто сказал, что ваш веб-сервер правильно эти данные сможет раскодировать? Теоретически, когда браузер делает запрос к серверу, то отправляется не только сведения о том какой документ хочет видеть клиент, не только данные из формы, но и сведения об браузере, об поддерживаемых кодировках, об предпочитаемых языках документа, и прочее и прочее и прочее. Может там найдется сведения о кодировке? Давайте проверим. При создании тега form вы должны указать значение не только метода отправки (GET или POST), но и значение атрибута enctype. Его возможные значения: "multipart/form-data" или "application/x-www-form-urlencoded". В первом случае форма будет способна отправлять не только текстовые данные, но и, например, файлы (кто бы мне сказал, почему sun-овцы не могли реализовать парсинг подобного запроса самостоятельно или внести в стандарт для любого servlet-контейнера, а отдали на откуп посторонним?). Рассмотрим как кодируются данные в случае "multipart/form-data"? Ниже пример подобного запроса:
Как видите, запрос разбит на секции с помощью некоторой уникальной комбинации символов. Итак, где в этом запросе есть указание на то, в какой кодировке пришли данные от браузера? Нигде, нет их. Может быть, кодировка указывается при запросе "application/x-www-form-urlencoded"? Ладно, вот пример еще одного запроса:
Способ кодирования информации отличен: прежде всего, заметьте, как были переданы русские буквы. В первом случае они передаются как есть, т.е. в той кодировке в которой была сформирована и сама страница. Во втором случае буквы превратились во множество значков процента, цифр и букв. Кодировка "application/x-www-form-urlencoded" применяется также и в случае отправки данных методом GET (передается в адресной строке).
То, в зависимости от используемой кодировки, данные будут отправлены либо так:
%FF%F9%E8%EA%E8_%F1_%EF%E8%E2%EE%EC - так выглядит слово “ящики с пивом” в кодировке windows-1251
%D1%8F%D1%89%D0%B8%D0%BA%D0%B8_%D1%81_%D0%BF%D0%B8%D0%B2%D0%BE%D0%BC – а так выглядит это слово в кодировке utf-8.
Возвращаясь к анализу двух примеров запроса данных, мы нигде не видим указания на то какая кодировка используется для отправки данных. Может, у меня не правильный браузер, и какие то другие, правильные, браузеры указывают кодировку отправляемых данных? Увы, ни internet explorer 6,7 ни firefox 2,3 ни opera 9.5 не указывают сведений о кодировке.
Автоматически определить кодировку tomcat не может, а раз не может, то будет выполнять преобразование поступивших данных из кодировки (по-умолчанию) ISO8859-1. Несколько раз мне встречались в сети рекомендации делать что-то вроде:
Когда вызывается ваш сервлет (или jsp, что суть одно и то же). То вы можете узнать в какой кодировке к вам пришли данные, например, так:
Если значение кодировки null (а оно равно этой величине почти всегда), тогда tomcat решает, что входные данные были в формате ISO8859-1 и пытается именно так выполнить парсинг строки. Существует народное поверье, что если создать специальный сервлет-фильтр, который будет вызываться до того, как будет выполнено первое обращение к списку передаваемых параметров и установит значение правильной кодировки, то все заработает без проблем, например:
Теперь при первом же обращении к какому-либо из входных параметров:
Равно как и для jstl:
Будет выполнено раскодирование входных данных с учетом указанной вами кодировки.
Наверное, форсировать установку значения для кодировки не всегда правильно. С другой стороны, если ваше веб-приложение содержит страницы, формируемые в разных кодировках (непонятно, правда, зачем вам это понадобилось), то можно тонко настроить шаблон для тех адресов jsp-страниц, которые будут обслуживаться этим фильтром:
Можно обойтись и меньшей кровью, выполнив эту команду внутри вашего сервлета самой первой строкой кода (нужно только быть уверенным в том, что никакой другой код не пытался получить значения переменных до вас):
Или, если вы создаете jsp-файл с использованием jstl-тегов, то такую команду:
Однако для того, чтобы указанное значение кодировки было применено к параметрам переданным методом GET (применительно к tomcat) нужно выполнить правку конфигурационного файла server.xml и добавить для элемента Connector атpибут useBodyEncodingForURI равный значению “true”. В этом случае разбор параметров будет выполнен с такой кодировкой, которую вы установили с помощью вызова request.setCharacterEncoding("utf-8").
| URIEncoding | This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used. |
| useBodyEncodingForURI | This specifies if the encoding specified in contentType should be used for URI query parameters, instead of using the URIEncoding. This setting is present for compatibility with Tomcat 4.1.x, where the encoding specified in the contentType, or explicitely set using Request.setCharacterEncoding method was also used for the parameters from the URL. The default value is false. |
Проще говоря, либо вы указывате явно значение кодировки для всех входных запросов с помощью параметра URIEncoding (а-га, вот как будто бы всегда и для всех приложений на этом хостинге только такая кодировка является допустимой). Либо устанавливаете вторую перменную |useBodyEncodingForURI равной значению true (по-умолчанию ее значение false).
Единственная проблема в том, что мы выполнять правку файла server.xml мы можем лишь, в случае если имеем прямой доступ к каталогу, где установлен tomcat. Согласитесь, что в случае типового виртуального хостинга мы можем управлять приложением только с помощью файлов web.xml и еще META-INF/context.xml – а это не то. Также, если ваше приложение запущено под другим веб-сервером, то вам нужно будет разбираться с его специфическим настройками.
Некоторое время назад я пытался разобраться с настройками для resin. В FAQ написано, что на разбор данных оказывают влияние следующие значения:
Тег character-encoding, может быть дочерним по отношению к следующим уровням настройки: resin, server, host-default, host, web-app-default, web-app (на уровне приложения, а значит мы можем настроить свое приложение даже на самом обычном виртуальном хостинге).
Обратите внимание на схему, которая регламентирует содержимое web.xml в следующем примере (традиционная )
То такой пример не будет работать: т.к. тег character-encoding является специфическим именно для resin.
Если же значение кодировки явно не указано, то для чтения данных используется кодировка по-умолчанию для jvm (file.encoding). К сожалению, мои попытки запустить resin с указанием входной кодировки ничем хорошим не закончились (после установки значения кодировки в web.xml переданные рускоязычные символы превращались в черт его знает что). Так что пришлось обходиться привычным request.setCharacterEncoding ('utf-8'); Тогда у меня было мало времени разбираться в особенностях поведения resin, также я не исключаю что это был хитрый баг, так что если у кого-то есть заметки по этому поводу, то прошу поделиться с общественностью.
Как вывод: если данные передаются методом POST, то проблем нет. Если методом GET то проблемы есть; и особенно большие проблемы в случае, если кодировки для метода GET и POST отличаются друг от друга, или некоторые GET запросы приходят в одной кодировке, а некоторые – в другой. Думаете, такого не может быть? Может. Ситуация была такова: есть сайт в кодировке utf-8 на его страницах находится множество ссылок ссылающихся на разделы этого же сайта, и, внимание, в тексте ссылок содержались русскоязычные названии (как некое подобие wikipedia). Если человек жмет на такую ссылку то адресная строка перед кодированием ее с помощью x-www-form-urlencoded, подвергалась кодированию в utf-8 (кодировку страницы). Однако если такую ссылку вводили в адресную строку браузера руками, то кодировка была windows-1251 (это для русскоязычной windows). Для linux машины, на которой стояла fedora, кодировка была utf-8. как решили проблему? Как обычно: матюгами и напильником.
1- FileReader
FileReader - это подкласс InputStreamReader, который используется для чтения текстовых файлов.
- BufferedReader
- CharArrayReader
- FilterReader
- InputStreamReader
- LineNumberReader
- PipedReader
- PushbackReader
- Reader
- StringReader
FileReader имеет только методы, унаследованные от InputStreamReader. На самом деле вы можете использовать InputStreamReader для чтения символов из любого источника, однако FileReader специально разработан для чтения символов из файловой системы.
Примечание: Конструкторы с параметром Charset были добавлены в FileReader, начиная с версией Java 11. Поэтому, если вы используете более раннюю версию Java и хотите прочитать файл с указанной кодировкой, вместо этого используйте класс InputStreamReader.
2- Examples
При чтении текстового файла лучше использовать комбинацию BufferedReader и FileReader для достижения лучшей производительности:
3- Проблемы UTF-8 BOM!
До того, как UTF-8 стал популярным, генераторы файлов UTF-8 всегда добавляли первые 3 bytes, чтобы отметить, что этот файл был закодирован UTF-8, они часто называются BOM (Byte Order Mark). В то время как файлы UTF-8, созданные Java, не включают BOM.
FileReader не удаляет автоматически BOM при чтении файлов UTF-8. Команда разработчиков Java понимает это, однако никаких обновлений не будет, так как это нарушит предыдущие сторонние библиотеки на базе Java, такие как XML Parser и т.д.
Например, ниже приведен файл UTF-8 (BOM), созданный старым инструментом, вы можете скачать его для проверки обсуждаемой проблемы:
Используйте FileReader для чтения вышеуказанного файла:
В результате появляется символ с кодом 65279, который является нежелательным символом.
Некоторые из следующих классов поддерживают исключение BOM, которое вы можете использовать:
BOMInputStream - это класс в библиотеке Apache Commons IO, который поддерживает удаление BOM.
Читайте также: