Мы создаем веб-проект (Java) с Eclipse. По умолчанию Eclipse использует кодировку Cp1252
на компьютерах с Windows (которые мы используем).
Поскольку у нас также есть разработчики в Китае (помимо Европы), я начал задаваться вопросом, действительно ли это кодировка для использования .
Моей первоначальной мыслью было преобразовать в UTF-8
, потому что «поддерживает все наборы символов» . Однако действительно ли это мудро? Может, лучше выбрать другую кодировку? Я вижу пару проблем:
1) Как веб-браузер интерпретирует файлы по умолчанию? Зависит ли это от используемой языковой версии? Я хочу, чтобы мы подробно объявляли используемые схемы кодирования:
Xml version = '1.0' encoding = 'UTF-8'?>
объявлений. @CHARSET "UTF-8";
.
или
Я определенно рекомендую UTF-8 всем другим схемам кодирования.
Убедитесь, что ваша СУБД полностью совместима с UTF-8, если вы храните многоязычные данные в базе данных.
Также убедитесь, что все файлы, включая css, javascript, файлы шаблонов приложений сами закодированы в UTF-8 с Спецификация В противном случае директивы charset
могут быть неправильно интерпретированы браузером.
У нас есть более 30 языков в большой CMS с поддержкой базы данных, и она работает как часы. У клиента есть редакторы-люди для всех языков, которые вводят данные.
Вы можете столкнуться с проблемами сопоставления с некоторыми языками (на ум приходит пример страшного турецкого без точек i
- ı - в базах данных без учета регистра). На это всегда есть ответ, но он будет очень специфичен для базы данных.
Я не знаком со спецификой пакетов ресурсов Java. Мы используем некоторые библиотеки Java, такие как markdownj
, которые без проблем обрабатывают текст в кодировке UTF-8 в базе данных и из нее.
Отредактировано, чтобы ответить на комментарии ОП:
Я думаю, что основная причина внедрения UTF-8 заключается в том, что вы никогда не знаете, в каком направлении будут развиваться ваши системы. Вы можете предположить, что сегодня будете работать только с одним языком, но это неверно даже в идеально одноязычных средах, поскольку вам может потребоваться хранить имена или ссылки, содержащие значения октетов, отличных от US-ASCII.
Кроме того, поток символов в кодировке UTF-8 не изменяет значения октетов US-ASCII, что обеспечивает полную совместимость с файловыми системами, не поддерживающими UTF-8, или другим программным обеспечением.
Все современные браузеры будут правильно интерпретировать UTF-8 при условии, что приложение/текстовый файл был закодирован с помощью UTF-8, и вы включаете на любую обслуживаемую страницу. в браузер.
Обязательно проверьте, поддерживает ли ваше промежуточное ПО (php, jsp и т. д.) UTF-8 в любом месте, и сделайте это в сочетании с вашей базой данных.
Я не понимаю, в чем проблема с разработчиками, которые потенциально имеют дело с данными, которые они не понимают. Разве это не так, когда мы имеем дело с данными на наших родных языках? По крайней мере, с системой, полностью поддерживающей Юникод, они смогут распознавать, соответствуют ли глифы, которые они видят в браузере или в базе данных, языку, с которым они должны иметь дело, вместо того, чтобы получать потоки ???? ?????? ??? ????
Я считаю, что использование UTF-8 в качестве кодировки символов для всего — беспроигрышный вариант. Это должно работать практически в любой ситуации, и вы готовы к тому дню, когда ваш босс придет и будет настаивать на том, чтобы вы стали многоязычным.