Почему экосистема Java использует различные кодировки символов всюду по их программному стеку?
Например, файлы класса используют CESU-8 (иногда также названный MUTF-8), но внутренне Java сначала использовал UCS-2, и теперь он использует UTF-16. Спецификация о допустимых исходных файлах Java говорит, что минимальный компилятор Java приспосабливания только должен принять символы ASCII.
Какова причина этого выбора? Разве не имело бы большего смысла использовать то же кодирование всюду по экосистеме Java?
3 ответа
ASCII для исходных файлов - это потому, что в то время не считалось разумным ожидать от людей текстовых редакторов с полной поддержкой Unicode. С тех пор ситуация улучшилась, но она все еще не совершенна. Вся эта \uXXXX штука в Jave - это, по сути, эквивалент триграфов языка Си в Java. (Когда был создан C, некоторые клавиатуры не имели фигурных скобок, поэтому приходилось использовать триграфы!)
Во время создания Java формат файлов классов использовал UTF-8, а среда выполнения - UCS-2. В Unicode было менее 64 тысяч кодовых точек, поэтому 16 бит было достаточно. Позже, когда в Юникод были добавлены дополнительные "плоскости", UCS-2 был заменен на (практически) совместимый UTF-16, а UTF-8 был заменен на CESU-8 (отсюда "Compatibility Encoding Scheme...").
В формате файлов классов они хотели использовать UTF-8 для экономии места. Дизайн формата файлов классов (включая набор инструкций JVM) был в значительной степени ориентирован на компактность.
Во времени выполнения они хотели использовать UCS-2, поскольку считалось, что экономия места менее важна, чем возможность избежать необходимости работать с символами переменной ширины. К сожалению, теперь, когда это UTF-16, это в какой-то степени отменилось, потому что кодовая точка теперь может принимать несколько "символов", и, что еще хуже, тип данных "char" теперь назван неправильно (он больше не соответствует символу в целом, а вместо этого соответствует единице кода UTF-16).
MUTF-8 для эффективности, UCS2 для истерического изюма. :)
В 1993 году UCS2 был Unicode; все считали, что 65536 символов должно хватить на всех.
Позже, когда стало ясно, что действительно существует огромное количество языков в мире, было слишком поздно, не говоря уже об ужасной идее, переопределить char как 32 бита, так что вместо этого -без обратной совместимости был сделан выбор.
В некотором смысле аналогично взаимосвязи между ASCII и UTF-8, строки Java, которые не выходят за пределы исторических границ UCS2, идентичны по битам их представлению в UTF16. Только когда вы раскрашиваете за пределами этих линий, вы можете начать беспокоиться о суррогатах и т. Д.
Похоже, это обычная проблема разработки программного обеспечения. Ранний код - это один стандарт, обычно самый простой для реализации на момент его создания, затем в более поздних версиях добавляется поддержка более новых/лучших/менее распространенных/более сложных стандартов.
Минимальный компилятор, вероятно, должен принимать только ASCII, потому что именно его используют многие распространенные редакторы. Эти редакторы могут быть не идеальны для работы с Java и не приближаются к полноценной IDE, но часто их вполне достаточно, чтобы подправить один исходный файл.
Java, кажется, попыталась установить планку выше и работать с наборами символов UTF, но они также оставили "запасной вариант" ASCII. Я уверен, что есть заметки с какого-нибудь заседания комитета, которые объясняют почему.