Виртуальная машина Java становится медленнее в зависимости от ее кодировки?

Question

Предположим, что испанский товарищ по команде пишет класс с TipoNotificación.Обратите внимание на специальные символы, такие как ú, ó и т. Д.

Помимо нормализации проекта кодирования, с какими проблемами я могу столкнуться?

Answer 1

Помимо нормализации проекта кодирования

Это должно быть достаточной причиной для исключения не-ascii символов в идентификаторах:

1. некоторые символы визуально не различимы (U + 0041 / U + 0391), в крайнем случае это может привести к путанице
2. не у всех есть клавиатура, которая позволяет легко набирать [a] симпатичных символов;это может разочаровать разработчиков.

Что касается вашего первоначального вопроса, я не думаю, что есть какие-либо существенные накладные расходы.Как уже говорилось, строки хранятся внутри UTF-16.Однако имена файлов (включая имена классов) в файлах JAR кодируются в UTF-8, что означает, что JVM считывает один дополнительный байт для каждого не ascii символа во время загрузки .Поскольку в испанском языке не более одного диакритического знака на слово, вы можете рассчитывать в среднем на один или два дополнительных байта на класс.Там нет никакого способа, чтобы вы могли заметить это даже в самых ограниченных аппаратных средах.

Answer 2

Единственное, что должно (должно) быть затронуто, это время, которое требуется для загрузки и обработки текстовых файлов. Файлы классов (двоичные файлы) не должны быть затронуты. Убедитесь, что ваша Java IDE и система сборки настроены правильно. Если вы используете Maven, вам будет предложено установить кодировку набора символов в нескольких местах.

JVM хранит данные как UCS-2 или UTF-16. Это означает, что каждый символ хранится внутри с двумя байтами данных. Иногда это может быть неприятным сюрпризом для людей, пришедших из C-фона, где каждый символ обычно является байтом ASCII (старший бит не определен). Вы можете потратить недели на изучение и пытки над кодировками.

Вероятно, единственный полезный совет, который я могу дать, это установить ВСЕ в UTF-8. Просто стандартизируйте это везде. В ваших IDE, текстовых редакторах, сборках, страницах JSP и особенно в вашей базе данных. Напишите модульные тесты и интеграционные тесты, чтобы убедиться, что все установлено на UTF-8. Вы действительно не хотите иметь дело с миграцией / очисткой данных, пытаясь выяснить, какое случайное кодирование привело к определенной строке странных символов.

Вот слайд-колода на I18N, которую я написал недавно, надеюсь, это поможет.

http://www.slideshare.net/williverson/software-internationalization-crash-course

Да, и вы должны предполагать, что любые имена файлов, которые когда-либо будут передаваться по сети (например, общий доступ к файлам, электронная почта), будут испорчены и обработаны как ASCII или кодировка локальной ОС. Например, на компьютерах Mac, которые будут MacRoman, и в системах английского языка США CP1251. Таким образом, если вы связываете свои классы в JAR, это, вероятно, нормально, но у неразорвавшихся классов (или исходных файлов!) Будет проблема. Не JVM, а вещь уровня ОС.

Answer 3

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

OTOH, у вас могут возникнуть обычные проблемы с именами файловой системы, кодировкой символов текстового редактора и, возможно, даже именами файлов jar / zip.

Answer 4

Java кодирует строки, используя UTF16, и легко обрабатывает символы с акцентом без увеличения потребности в памяти. Поэтому ответ на ваш вопрос - нет.

Answer 5

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