Какую схему кодирования следует использовать в веб-проекте? - PullRequest
8 голосов
/ 31 августа 2010

Мы создаем (Java) веб-проект с Eclipse. По умолчанию Eclipse использует кодировку Cp1252 на машинах Windows (которые мы используем).

Поскольку у нас также есть разработчики в Китае (в дополнение к Европе), я начал задаваться вопросом, действительно ли это кодировка для использования.

Моей первоначальной мыслью было преобразование в UTF-8, потому что "поддерживает все наборы символов" . Однако действительно ли это мудро? Должны ли мы выбрать другую кодировку вместо этого? Я вижу пару вопросов:

1) Как веб-браузер интерпретирует файлы по умолчанию? Зависит ли это от того, какую языковую версию вы используете? После этого я должен многословно объявить используемые схемы кодирования:

  • Файлы XHTML могут задавать кодировку многословно с помощью объявлений <?xml version='1.0' encoding='UTF-8' ?>.
  • CSS-файлы могут установить это @CHARSET "UTF-8";.
  • Файлы JavaScript не имеют встроенных объявлений, но можно глобально определить <meta http-equiv="Content-Script-Type" content="text/javascript; charset=utf-8"> или <script type="text/javascript" charset="utf-8"> для конкретных сценариев.

Что если мы оставим файл CSS без объявления @CHARSET "UTF-8";? Как браузер определяет, как он закодирован?

2) Разумно ли использовать UTF-8, потому что настолько гибок . Блокируя наш код в Cp1252 (или, может быть, ISO-8859-1), я могу гарантировать, что иностранные разработчики не будут вводить специальные символы в файлы. Это эффективно препятствует тому, чтобы они вставили китайские комментарии, например (мы должны использовать 100% английский). Кроме того, использование UTF-8 иногда позволяет разработчикам случайно вводить некоторые странные символы, которые трудно / невозможно воспринимать человеческим глазом. Это происходит, когда люди, например, копируют-вставляют текст или случайно нажимают какую-то странную комбинацию клавиш.

Казалось бы, включение UTF-8 в проект просто приносит проблемы ...

3) Для интернационализации я изначально считал UTF-8 хорошей вещью («как вы можете добавить переводы, если кодировка файла не поддерживает необходимые символы?»). Однако, как оказалось, пакеты ресурсов Java (файлы .properties) должны быть должны быть закодированы с помощью ISO-8859-1, поскольку в противном случае они могут сломаться. Вместо этого международные символы преобразуются в нотацию \uXXXX, например, \u0009, а файлы кодируются с помощью ISO-8859-1. Итак ... мы даже не можем использовать UTF-8 для этого.

Для двоичных файлов ... ну, схема кодирования на самом деле не имеет значения (я думаю, можно сказать, что она даже не существует).

Как мы должны подойти к этим вопросам?

Ответы [ 2 ]

6 голосов
/ 31 августа 2010

Я бы определенно рекомендовал UTF-8 для всех других схем кодирования.

Убедитесь, что ваша СУБД полностью соответствует UTF-8, если вы храните многоязычные данные в базе данных

Также убедитесь, что все файлы, включая css, javascript, файлы шаблонов приложений, сами закодированы в UTF-8 с BOM.В противном случае директивы charset могут неправильно интерпретироваться браузером.

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

Вы можете столкнуться с проблемами сопоставления с некоторыми языками (пример страшного турецкого без точек i - ı - в базах данных без учета регистра происходит вразум).На это всегда есть ответ, но он будет очень специфичным для базы данных.

Я не знаком со спецификой Java Resource Bundles.Мы используем некоторые библиотеки Java, такие как markdownj, которые обрабатывают текст в кодировке UTF-8 в базу данных и из нее без проблем.


Отредактировано для ответа на комментарии ОП:

Я думаю, что основная причина внедрения UTF-8 заключается в том, что вы никогда не знаете, в каком направлении будут развиваться ваши системы.Вы можете предположить, что сегодня вы будете работать только с одним языком, но это неверно даже в совершенно одноязычных средах, поскольку вам, возможно, придется хранить имена или ссылки, содержащие значения не-US-ASCII октетов.

Кроме того, поток символов в кодировке UTF-8 не будет изменять значения октетов US-ASCII, что обеспечивает полную совместимость с файловыми системами, не поддерживающими UTF-8, или другим программным обеспечением.

Современные современные браузеры будут все правильно интерпретировать UTF-8, если приложение / текстовый файл был закодирован с помощью UTF-8, и вы включите <meta charset="utf-8"> на любой странице, которая передается в браузер.

Проверьте, поддерживает ли ваше промежуточное ПО (php, jsp и т. Д.) UTF-8 где-либо, и сделайте это вместе с вашей базой данных.

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

Я верю, что использование UTF-8 в качестве кодировки вашего персонажа - это безопасная ставка.Это должно работать практически во всех ситуациях, и вы готовы к тому дню, когда ваш начальник приходит и настаивает на том, что вы должны говорить на нескольких языках.

5 голосов
/ 31 августа 2010

Моей первоначальной мыслью было преобразование в UTF-8, потому что «он поддерживает все наборы символов».Однако действительно ли это мудро?

Перейти на это.Вы хотите мирового господства.

1) Как веб-браузер интерпретирует файлы по умолчанию?Зависит ли это от того, какую языковую версию вы используете?

Для этого используется заголовок ответа Content-Type (примечание: real заголовок ответа, а не метатег HTML).Я вижу / знаю, что вы - разработчик Java, поэтому вот ответы, нацеленные на JSP / Servlet: установка <%@page pageEncoding="UTF-8" %> в верхней части страницы JSP неявно сделает это правильно, а установка response.setCharacterEncoding("UTF-8") в Servlet / Filter сделает то же самое.Если этот заголовок отсутствует, браузер должен решить / определить кодировку полностью.MSIE будет использовать кодировку платформы по умолчанию.Firefox немного умнее и будет угадывать кодировку на основе содержимого страницы.

2) Разумно ли использовать UTF-8, потому что он очень гибкий.Блокируя наш код в Cp1252 (или, может быть, ISO-8859-1), я могу гарантировать, что иностранные разработчики не будут вводить специальные символы в файлы.

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

3) Для интернационализации я изначально считал UTF-8 хорошей вещью («как вы можетедобавить переводы, если кодировка файла не поддерживает необходимые символы? ").Однако, как оказалось, пакеты ресурсов Java (файлы .properties) должны быть закодированы с помощью ISO-8859-1, поскольку в противном случае они могут сломаться.

Это решается, поскольку Java 1.6 сновый Properties#load() метод, принимающий Reader и новый класс ResourceBundle.Control, в котором вы можете контролировать загрузку файла комплекта.В терминах JSP / Servlet обычно используется ResourceBundle.Просто установите в качестве имени пакета сообщений полное имя класса пользовательской реализации ResourceBundle, и оно будет использовано.

Для двоичных файлов ... ну, схема кодирования недействительно важно (я полагаю, можно сказать, что его даже не существует).

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

См. Также:

...