Progress28.ru

IT Новости


09ae9cb0
5 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Java dfile encoding utf 8

Установка кодировки символов Java по умолчанию?

Как правильно установить кодировку символов по умолчанию, используемую JVM (1.5.х) программно?

Я читал, что -Dfile.encoding=whatever раньше был способ пойти для старых JVMs. У меня нет такой роскоши по причинам, в которые я не хочу вдаваться.

и свойство устанавливается, но это, похоже, не вызывает окончательный вызов getBytes ниже, чтобы использовать UTF8:

15 ответов

к сожалению, file.encoding свойство должно быть указано при запуске JVM; к моменту ввода основного метода кодировка символов, используемая String.getBytes() и конструкторы по умолчанию InputStreamReader и OutputStreamWriter постоянно кэшируется.

As Эдвард грех указывает, в частном случае, как это, переменная окружения JAVA_TOOL_OPTIONS can используется для указания этого свойства, но обычно это делается так это:

Charset.defaultCharset() будет отражать изменения file.encoding свойство, но большинство кода в основных библиотеках Java, которые должны определить кодировку символов по умолчанию, не используют этот механизм.

когда вы кодируете или декодируете, вы можете запросить file.encoding собственность или Charset.defaultCharset() чтобы найти текущую кодировку по умолчанию и использовать соответствующий метод или перегрузку конструктора, чтобы указать ее.

поскольку командная строка не всегда может быть доступна или изменена, например, во встроенных VMs или просто VMs, запущенных глубоко в сценариях, a JAVA_TOOL_OPTIONS переменная предоставляется так, что агенты могут быть запущены в этих случаях.

установив переменную среды (Windows) JAVA_TOOL_OPTIONS до -Dfile.encoding=UTF8 , (Java) System свойство будет устанавливаться автоматически при каждом запуске JVM. Вы будет знать, что параметр был выбран, потому что следующее сообщение будет опубликовано на System.err :

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

У меня есть хакерский способ, который определенно работает!!

таким образом, вы собираетесь обмануть JVM, который будет думать, что charset не установлен и сделать это, чтобы установить его снова в UTF-8, во время выполнения!

Я думаю, что лучший подход, чем установка набора символов платформы по умолчанию, тем более, что у вас, похоже, есть ограничения на влияние на развертывание приложения, не говоря уже о платформе, — это вызвать гораздо более безопасный String.getBytes(«charsetName») . Таким образом, ваше приложение не зависит от вещей, находящихся вне его контроля.

Я лично считаю, что String.getBytes() должно быть устаревшим, так как это вызвало серьезные проблемы в ряде случаев, которые я видел, когда разработчик не учитывал значение по умолчанию кодировка, возможно, меняется.

Я не могу ответить на ваш первоначальный вопрос, но я хотел бы предложить вам несколько советов-не зависите от кодировки JVM по умолчанию. Всегда лучше явно указать желаемую кодировку (например,» UTF-8″) в вашем коде. Таким образом, вы знаете, что он будет работать даже в разных системах и конфигурациях JVM.

Откуда в Java всплывают проблемы с кодировками и возможная причина падения марсианского зонда

Планета Марс уже не первый год населена роботами. То тут, то там появляются беспилотные электрокары и летающие дроны, а в программах, написанных на Java, с завидной регулярностью всплывают проблемы с кодировками.

Хочу поделиться своими мыслями о том, почему это происходит.

Предположим, у нас есть файл, в котором хранится нужный нам текст. Чтобы поработать с этим текстом в Java нам нужно загнать данные в String. Как это сделать?

Обратите внимание, что для чтения файла недостаточно просто знать его имя. Нужно еще знать, в какой кодировке в нем находятся данные. Двоичное представление символов в памяти Java-машины и в файле на жестком диске практически никогда не совпадает, поэтому нельзя просто взять и скопировать данные из файла в строку. Сначала нужно получить последовательность байт, а уже потом произвести преобразование в последовательность символов. В приведенном примере это делает класс InputStreamReader.

Код получается достаточно громоздким при том, что необходимость в преобразовании из байтов в символы и обратно возникает очень часто. В связи с этим логичным было бы предоставить разработчику вспомомогательные функции и классы, облегчающие работу по перекодировке. Что для этого сделали разработчики Java? Они завели функции, которые не требуют указания кодировки. Например, класс InputStreamReader имеет конструктор с одним параметром типа InputStream.

Стало чуть попроще. Но здесь разработчики Java закопали серьезные грабли. В качестве кодировки для преобразования данных они использовали так называемый «default character encoding».

Default charset устанавливается Java-машиной один раз при старте на основании данных взятых из операционной системы и сохраняется для информационных целей в системном свойстве file.encoding. В связи с этим возникают следующие проблемы.

  1. Кодировка по умолчанию — это глобальный параметр. Нельзя установить для одних классов или функций одну кодировку, а для других — другую.
  2. Кодировку по умолчанию нельзя изменить во время выполнения программы.
  3. Кодировка по умолчанию зависит от окружения, поэтому нельзя заранее знать, какая она будет.
  4. Поведение методов, зависящих от кодировки по умолчанию, нельзя надежно покрыть тестами, потому что кодировок достаточно много, и множество их значений может расширяться. Может выйти какая-нибудь новая ОС с кодировкой типа UTF-48, и все тесты на ней окажутся бесполезными.
  5. При возникновении ошибок приходится анализировать больше кода, чтобы узнать, какую именно кодировку использовала та или иная функция.
  6. Поведение JVM в случае изменения окружения после старта становится непредсказуемо.

Но главное — это то, что от разработчика скрывается важный аспект работы программы, и он может просто не заметить, что использовал функцию, которая в разном окружении будет работать по-разному. Класс FileReader вообще не содержит функций, которые позволяют указать кодировку, хотя сам класс логичен и удобен, поэтому он стимулирует пользователя на создание платформозависимого кода.

Из-за этого происходят удивительные вещи. Например, программа может неправильно открыть файл, который ранее сама же создала.

Или, скажем, есть у нас XML-файл, у которого в заголовке написано encoding=«UTF-8», но в Java-программе этот файл открывается при помощи класса FileReader, и привет. Где-то откроется нормально, а где-то нет.

Особенно ярко проблема file.encoding проявляется в Windows. В ней Java в качестве кодировки по умолчанию использует ANSI-кодировку, которая для России равна Cp1251. В самой Windows говорится, что «этот параметр задает язык для отображения текста в программах, не поддерживающих Юникод». При чем здесь Java, которая изначально задумывалась для полной поддержки Юникода, непонятно, ведь для Windows родная кодировка — UTF-16LE, начиная где-то с Windows 95, за 3 года до выхода 1-й Java.

Читать еще:  При включении камеры пишет ошибка галереи

Так что если вы сохранили при помощи Java-программы файл у себя на компьютере и отправили его вашему коллеге в Европу, то получатель при помощи той же программы может и не суметь открыть его, даже если версия операционной системы у него такая же как и у вас. А когда вы переедете с Windows на Mac или Linux, то вы уже и сами свои файлы можете не прочитать.

А ведь еще есть Windows консоль, которая работает в OEM-кодировке. Все мы наблюдали, как вплоть до Java 1.7 любой вывод русского текста в черном окне при помощи System.out выдавал крокозябры. Это тоже результат использования функций, основанных на default character encoding.

Я у себя проблему кодировок в Java решаю следующим образом:

  1. Всегда запускаю Java с параметром -Dfile.encoding=UTF-8. Это позволяет убрать зависимость от окружения, делает поведение программ детерминированным и совместимым с большинством операционных систем.
  2. При тестировании своих программ обязательно делаю тесты с нестандартной (несовместимой с ASCII) кодировкой по умолчанию. Это позволяет отловить библиотеки, которые пользуются классами типа FileReader. При обнаружении таких библиотек стараюсь их не использовать, потому что, во-первых, с кодировками обязательно будут проблемы, а во-вторых, качество кода в таких библиотеках вызывает серьезные сомнения. Обычно я запускаю java с параметром -Dfile.encoding=UTF-32BE, чтобы уж наверняка.

Это не дает стопроцентной гарантии от проблем, потому что есть же еще и лаунчеры, которые запускают Java в отдельном процессе с теми параметрами, которые считают нужными. Например, так делали многие плагины к анту. Сам ант работал с file.encoding=UTF-8, но какой-нибудь генератор кода, вызываемый плагином, работал с кодировкой по умолчанию, и получалась обычная каша из разных кодировок.

По идее, со временем код должен становиться более качественным, программы более надежными, форматы более стандартизованными. Однако этого не происходит. Вместо этого наблюдается всплеск ошибок с кодировками в Java-программах. Видимо, это связано с тем, что в мир Java иммигрировали люди, не привыкшие решать проблему кодировок. Скажем, в C# по умолчанию применяется кодировка UTF-8, поэтому разработчик, переехавший с C#, вполне разумно считает, что InputStreamReader по умолчанию использует эту же кодировку, и не вдается в детали его реализации.

Недавно наткнулся на подобную ошибку в maven-scr-plugin.

Но настоящее удивление пришлось испытать при переезде на восьмерку. Тесты показали, что проблема с кодировкой затесалась в JDK.

На девятке не воспроизводится, видимо, там уже починили.

Поискав по базе ошибок, я нашел еще одну недавно закрытую ошибку, связанную с теми же самыми функциями. И что характерно, их даже исправляют не совсем правильно. Коллеги забывают, что для стандартных кодировок, начиная с Java 7, следует использовать константы из класса StandardCharsets. Так что впереди, к сожалению, нас ждет еще масса сюрпризов.

Запустив grep по исходникам JDK, я нашел десятки мест, где используются платформозависимые функции. Все они будут работать некорректно в окружении, где родная кодировка, несовместима с ASCII. Например, класс Currency, хотя казалось бы, уж этот-то класс должен учитывать все аспекты локализации.

Когда некоторые функции начинают создавать проблемы, и для них существует адекватная альтернатива, давно известно, что нужно делать. Нужно отметить эти функции как устаревшие и указать, на что их следует заменить. Это хорошо зарекомендовавший себя механизм deprecation, который даже планируют развивать.

Я считаю, что функции, зависящие от кодировки по умолчанию, надо обозначить устаревшими, тем более, что их не так уж и много:

ФункцияНа что заменить
Charset.defaultCharset()удалить
FileReader.FileReader(String)FileReader.FileReader(String, Charset)
FileReader.FileReader(File)FileReader.FileReader(File, Charset)
FileReader.FileReader(FileDescriptor)FileReader.FileReader(FileDescriptor, Charset)
InputStreamReader.InputStreamReader (InputStream)InputStreamReader.InputStreamReader (InputStream, Charset)
FileWriter.FileWriter(String)FileWriter.FileWriter(String, Charset)
FileWriter.FileWriter(String, boolean)FileWriter.FileWriter(String, boolean, Charset)
FileWriter.FileWriter(File)FileWriter.FileWriter(File, Charset)
FileWriter.FileWriter(File, boolean)FileWriter.FileWriter(File, boolean, Charset)
FileWriter.FileWriter(FileDescriptor)FileWriter.FileWriter(FileDescriptor, Charset)
OutputStreamWriter.OutputStreamWriter (OutputStream)OutputStreamWriter.OutputStreamWriter (OutputStream, Charset)
String.String(byte[])String.String(byte[], Charset)
String.String(byte[], int, int)String.String(byte[], int, int, Charset)
String.getBytes()String.getBytes(Charset)

Да, а что там с космическим аппаратом на Марсе?

Часть программного обеспечения для марсианского зонда Скиапарелли написали на Java, на актуальной в то время версии 1.7. Запустили изделие весной, и путь к месту назначения составил полгода. Пока он летел, в Европейском космическом агентстве обновили JDK.

Ну а что? Разработка софта для нынешней миссии завершена, надо делать ПО уже для следующей, а мы все еще на семерке сидим. НАСА и Роскосмос уже давно на восьмерку перешли, а там лямбды, стримы, интерфейсные методы по умолчанию, новый сборщик мусора, и вообще.

Обновились и перед посадкой отправили на космический аппарат управляющую команду не в той кодировке, в которой он ожидал.

Pro Java

Страницы

23 мар. 2015 г.

Лексическая структура Java. Часть 1 – Unicode и другие кодировки

В предыдущей части были представлены видео на которых было показано создание классической программы HelloWorld на Java в различных средах разработки. Но там есть один ньюансик. Обычно среды разработки могут определить кодировку текста в которой была написана программа и правильно ее откомпилировать, чтобы текст, отличный от латинского алфавита правильно отображался в консоли и вообще в программах.

Сразу скажу, что программы на Java лучше создавать в кодировке Unicode (UTF-8) , так как если вы будете писать их в других кодировках, то могут быть проблемы с отображением символов национальных алфавитов, отличных от латинского. Хотя они могут быть даже если вы их пишете в Unicode и сейчас мы в этом убедимся.

Теперь в бой! Посмотрим все на примерах. Возьмем классическую программу Hello World и допишем в нее строчку выводящую сообщение “Привет Мир!” на русском языке. Текст программы запишем как и полагается в кодировке UTF-8.

И теперь откомпилируем ее с параметрами по умолчанию. То есть просто дадим команду

javac HelloWorld.java

И выполним нашу программу командой

java HelloWorld

И смотрим результат

Текст на русском языке “Привет Мир!” отобразился кракозябрами. Что же случилось? Почему такая не справедливость? Ведь мы же записали текст программы в Unicode! Сделали все как положено!

Но дело в том, что компилятор javac, по умолчанию, компилирует программу в кодовой странице операционной системы.

Читать еще:  Stringbuilder append java

Теперь откомпилируем эту же программу, но уже укажем в какой кодировке у нас исходный код программы c помощью следующей команды

javac -encoding utf8 HelloWorld.java

И запустим программу на выполнение

Ну вот теперь русский текст “Привет Мир!” отображается правильно.

Как правило, среды разработки многие параметры компилятора, заботливо, подставляют за разработчика, но все же хорошо бы разбираться в том, что происходит.

В данном примере я намеренно не использовал ни какие среды разработки, а воспользовался простым текстовым редактором.

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

Сейчас рассмотрим еще несколько примеров исходников в различных кодировках для лучшего понимания темы и на этом закончим с использованием текстового редактора, хотя часто он бывает нужен, чтобы просто заглянуть в текст программы не запуская “тяжелую” IDE.

И так я создал такую же простую программу как “Hello World”, но в разных кодировках (866, 1251 и UTF-8).

Код абсолютно одинаковый только создан в разных кодировках.

Теперь скомпилируем их с параметрами по умолчанию и запустим.

Но сперва отметим такую команду консоли Windows как chcp. Про нее мало кто знает. Она отображает текущую кодовую страницу консоли, а так же может ее устанавливать.

Посмотрим текущую кодовую страницу консоли, откомпилируем программу Example866.java и запустим ее.

Как видим вывод русского текста не правильный, одни кракозабры, зато слово Java и восклицательный знак (!) вывелись правильно. Это происходит потому что Unicod код латинских символов (первых 128) совпадает с ASCII и Latin-1. Поэтому если в вашей программе вы используете только латинский алфавит для отображения строк и т.п., то можно не беспокоится. Все всегда будет отображаться корректно, но с символами других алфавитов это не так.

В данном случае, как видим, не смотря на то, что даже кодовая страница консоли у нас 866 и файл с исходником тоже в этой же кодировке, вывод все равно отображается не правильно.

Это происходит потому, что компилятор javac конвертирует все символы в Unicode. Давайте попробуем установить кодовую страницу консоли в Unicode и посмотрим может, тогда все отобразится правильно.

Опять все отобразилось не правильно, за исключением слова Java и восклицательного знака. Но кракозябры уже другие, что безусловно не может не радовать…

И так в чем же проблема? А проблема в том, что как уже я говорил, по умолчанию компилятор использует кодовую страницу операционной системы, в нашем случае это CP1251, так как Windows у нас настроен на использование кириллической кодировки CP1251.

Произошло следующее, компилятор, перевел символы кодировки 866 в UTF-8, полагая что это кодировка CP1251. Поэтому в данном случае, как бы мы не меняли кодовую страницу мы уже не получим правильного отображения русского текста. Давайте зададим для консоли кодировку cp1251 и посмотрим что будет.

Кракозябры у нас опять другие, но слово Java и восклицательный знак по прежнему выводятся правильно.

Чтобы исправить эту ситуацию надо откомпилировать программу Exemple866.java с использованием кодовой страницы 866. И чтобы проверить это вернем консоли кодировку по умолчанию 866, дабы все было по честно по правилам.

Теперь у нас все правильно выводится.

Далее откомпилируем программу Example1251.java и запустим ее. Ее можно компилировать с параметрами по умолчанию, так как javac будет использовать для нее кодировку 1251, что нам и нужно.

Все тоже отображается правильно. Ну и тоже самое с программой ExampleUTF8.java

Как видим, нам тоже пришлось указывать ключ при компиляции, чтобы javac правильно воспринял кодировку исходника программы. Русский текст тоже выводится правильно.

Теперь небольшой ликбез об UTF8. Данная кодировка использует ДВА БАЙТА для хранения кода символа, что позволяет представить 65535 символов – это покрывает почти все символы всех языков Земли. Кодировка ASCII может представить только 256 символов.

Теперь посмотрим нашу самую русскую букву Ё в кодировке 1251 (ASCII) и в кодировке UTF8.

В кодировке 1251 ASCII буква Ё представлена одним байтом (A8).

В кодировке UTF-8 буква Ё представлена двумя байтами (D0 81).

И теперь посмотрим бинарные файлы классов Example866.class и Example1251.class

Как видим наш текст на русском “Это Java программа!” в обоих бинарниках отображается одинаково, хотя один из них сделан из исходника в кодировке 866, а другой в кодировке 1251. Это произошло потому, что компилятор javac, перевел символы из этих кодировок в кодировку UTF-8.

Так же я подчеркнул байты CA FE BA BE – это так называемое магическое число java. По нему виртуальная машина определяет что перед ней именно класс Java, а не что-то еще. Эта комбинация присутствует в начале всех откомпилированных файлов классов Java с расширением .class.

Ну и чтобы все было более наглядней приведу еще одни скрин сравнения этих файлов

Так вот! К чему я это все?

Граждане, храните деньги в сберегательной кассе!

Пишите исходники в UTF-8. Надежно, выгодно, удобно.

Как получить UTF-8 работает в Java webapps?

мне нужно, чтобы UTF-8 работал в моем Java webapp (сервлеты + JSP, не используется фреймворк) для поддержки äöå etc. для обычного финского текста и кириллических алфавитов, таких как ЦжФ для особых случаев.

Мои настройки следующие:

  • среда разработки: Windows XP
  • производственная среда: Debian

используемая база данных: MySQL 5.x

пользователи в основном используют Firefox2, но и Opera 9.x, FF3, IE7 и Google Chrome являются используется для доступа к сайту.

как этого добиться?

13 ответов:

отвечая себе, как FAQ этого сайта поощряет его. Это работает для меня:

в основном символы äåö не являются проблемой, поскольку набор символов по умолчанию, используемый браузерами и tomcat / java для webapps, является latin1 ie. ISO-8859-1, который «понимает» эти символы.

чтобы заставить UTF-8 работать под Java + Tomcat + Linux/Windows+Mysql требуется следующее:

настройка сервера Tomcat.xml

это нужно сконфигурируйте, что соединитель использует UTF-8 для кодирования параметров url (GET request):

ключевой частью является URIEncoding= «UTF-8» в приведенном выше примере. Это гарантирует, что Tomcat обрабатывает все входящие параметры GET в кодировке UTF-8. В результате, когда пользователь записывает в адресную строку браузера следующее:

Читать еще:  Chrome отладка javascript

символ ж обрабатывается как UTF-8 и кодируется (обычно браузером, прежде чем даже попасть на сервер) как %D0%B6.

POST запрос не зависит от этого.

CharsetFilter

тогда пришло время заставить java webapp обрабатывать все запросы и ответы в кодировке UTF-8. Это требует, чтобы мы определили фильтр набора символов следующим образом:

этот фильтр гарантирует, что если браузер не установил кодировку, используемую в запросе, то он установлен в UTF-8.

другой дело сделано с помощью этого фильтра, чтобы установить кодировку ответа по умолчанию ie. кодировка, в которой возвращается html/что угодно. Альтернативой является установка кодировки ответа и т. д. в каждом контроллере приложения.

этот фильтр должен быть добавлен к web.xml или дескриптор развертывания веб-приложения:

кодировка страницы JSP

в своем web.xml добавить следующее:

кроме того, все JSP-страницы веб-приложения должны иметь в верхней части следующее:

если используется какой-то макет с разными JSP-фрагментами, то это необходимо в все из них.

в HTML-meta теги

кодировка страницы JSP говорит JVM обрабатывать символы на странице JSP в правильной кодировке. Тогда пришло время сообщить браузеру, в какой кодировке находится html-страница:

это делается со следующим в верхней части каждой страницы xhtml, созданной веб-приложением:

JDBC-соединение

при использовании БД, необходимо определить, что соединение использует кодировку UTF-8. Это делается в контексте.xml или где соединение JDBC определяется следующим образом:

база данных и таблицы MySQL

используемая база данных должна использовать кодировку UTF-8. Это достигается путем создания базы данных со следующими параметрами:

тогда все таблицы также должны быть в UTF-8:

ключевой частью является CHARSET=utf-8.

конфигурация сервера MySQL

MySQL serveri также должен быть настроен. Обычно это делается в Windows путем изменения мой.ini -файл и в Linux по настройке мой.cnf -файл. В этих файлах должно быть определено, что все клиенты, подключенные к серверу, используют utf8 в качестве набора символов по умолчанию и что кодировка по умолчанию, используемая сервером, также является utf8.

процедуры и функции Mysql

они также должны иметь определенный набор символов. Например:

вам запросы: latin1 и UTF-8

если и когда он определен на сервере tomcat.xml, которые получают параметры запроса кодируются в UTF-8, следующие запросы GET обрабатываются правильно:

поскольку ASCII-символы кодируются одинаково как с latin1, так и с UTF-8, строка «Petteri» обрабатывается правильно.

кириллический символ ж вообще не понимается на латинском языке1. Потому что Tomcat проинструктирован обрабатывать параметры запроса как UTF-8 it кодирует этот символ правильно как %D0%B6.

если и когда браузеры проинструктированы читать страницы в кодировке UTF-8 (с заголовками запросов и метатегом html), по крайней мере Firefox 2/3 и другие браузеры с этого периода все кодируют символ как %D0%B6.

конечным результатом является то, что все пользователи с именем «Petteri» найдены, а также все пользователи с именем «ж» найдены.

а как же ААА?

HTTP-спецификация определяет, что по умолчанию URL-адреса кодируются как latin1. Это приводит к в firefox2, firefox3 etc. кодирование следующего

в кодированной версии

в latin1 символ ä кодируется как %E4. даже если страница / запрос / все определено для использования UTF-8. Кодированная UTF-8 версия ä является %C3%A4

результат из этого следует, что веб-приложение совершенно не может корректно обрабатывать параметры запроса из запросов GET, поскольку некоторые символы кодируются в latin1, а другие в UTF-8. обратите внимание: запросы POST работают как браузеры кодируют все параметры запроса из форм полностью в UTF-8, Если страница определена как UTF-8

почитать

очень большое спасибо за авторов следующего для дачи ответов для моего проблема:

  • http://tagunov.tripod.com/i18n/i18n.html
  • http://wiki.apache.org/tomcat/Tomcat/UTF-8
  • http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/
  • http://dev.mysql.com/doc/refman/5.0/en/charset-syntax.html
  • http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-tomcat-jsp-etc.html
  • http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-for-mysql-tomcat.html
  • http://jeppesn.dk/utf-8.html
  • http://www.nabble.com/request-parameters-mishandle-utf-8-encoding-td18720039.html
  • http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html
  • http://www.utf8-chartable.de/

Важное Замечание

mysql поддерживает базовый Многоязычный Самолет использование 3-байтовых символов UTF-8. Если вам нужно выйти за пределы этого (некоторые алфавиты требуют более 3-байт UTF-8), то вам либо нужно использовать аромат VARBINARY тип столбца или использовать utf8mb4 набор символов (что требует MySQL 5.5.3 или более поздней версии). Просто имейте в виду, что с помощью utf8 набор символов в MySQL не будет работать 100% времени.

Tomcat с Apache

еще одна вещь, если вы используете Apache + Tomcat + mod_JK разъем, то вам также нужно сделать следующие изменения:

  1. добавить URIEncoding= «UTF-8» в сервер tomcat.xml-файл для соединителя 8009, он используется соединителем mod_JK.
  2. перейти к вашей папке apache т. е. /etc/httpd/conf и добавить AddDefaultCharset utf-8 на httpd.conf file . Примечание: сначала проверить, что он существует или нет. Если существует, вы можете обновить его с помощью этой строки. Вы также можете добавить эту строку внизу.

Я думаю, что вы довольно хорошо подытожили это в своем собственном ответе.

в процессе UTF-8-ing(?) из конца в конец вы также можете убедиться, что сама java использует UTF-8. Использовать Единственный Способ Иметь Установленный.encoding=utf-8 в качестве параметра для JVM (может быть настроен в catalina.летучая мышь.)

добавить kosoant это, если вы используете Spring, а не пишете свой собственный фильтр сервлетов, вы можете использовать класс org.springframework.web.filter.CharacterEncodingFilter они предоставляют, настраивая его следующим образом в вашем интернете.XML-код:

Это для греческого кодирования в таблицах MySql, когда мы хотим получить к ним доступ с помощью Java:

используйте следующую настройку соединения в пуле соединений JBoss (mysql-ds.xml)

Если вы не хотите помещать это в пул соединений JNDI, вы можете настроить его как JDBC-url, как показано в следующей строке:

для меня и Ника, так что мы никогда не забудем его и тратить время больше.

хороший подробный ответ. просто хотел добавить еще одну вещь, которая определенно поможет другим увидеть кодировку UTF-8 на URL-адресах в действии .

выполните следующие действия, чтобы включить кодировку UTF-8 на URL-адресах в firefox.

введите «about: config» в адресной строке.

используйте тип входного фильтра для поиска » сеть.стандартный URL-адрес.свойство encode-query-utf8.

  • выше свойство будет иметь значение false по умолчанию, поверните это к истине.
  • перезапустить браузер.
  • кодировка UTF-8 на URL работает по умолчанию в IE6 / 7 / 8 и chrome.

    хочу также добавить от здесь эта часть решила мою проблему utf:

    Ссылка на основную публикацию