Почему Java допускает экранированные символы Юникода в исходном коде?

Question

I недавно узнал , что Юникод разрешен в исходном коде Java не только как символы Юникода (например, double π = Math.PI;), но также как экранированные последовательности (например, double \u03C0 = Math.PI;).

Первый вариант имеет смысл для меня - он позволяет программистам называть переменные и методы на международном языке по своему выбору.Однако я не вижу практического применения второго подхода.

Вот несколько фрагментов кода, иллюстрирующих использование, протестированных с Java SE 6 и NetBeans 6.9.1:

Этокод напечатает 3.141592653589793

public static void main(String[] args) {
    double π = Math.PI;
    System.out.println(\u03C0);
}

Объяснение: π и \ u03C0 - это один и тот же символ Unicode

Этот код ничего не печатает

public static void main(String[] args) {
    double π = Math.PI; /\u002A
    System.out.println(π);

    /* a comment */
}

Объяснение:приведенный выше код фактически кодирует:

public static void main(String[] args) {
    double π = Math.PI; /*
    System.out.println(π);

    /* a comment */
}

Который комментирует текст печати. ​​

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

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

Во-вторых, кажется, что у IDE нет поддержки.Ни NetBeans, ни Eclipse не предоставили правильную подсветку кода для примеров.Фактически, NetBeans даже отмечал синтаксическую ошибку (хотя компиляция не была проблемой).

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

Мой вопрос таков:

Почему Java разрешает экранировать последовательности Unicode дляиспользоваться в синтаксисе?Какие «плюсы» этой функции позволили ей остаться частью Java, несмотря на многие «минусы»?

Answer 1

Экранирующие последовательности Unicode позволяют хранить и передавать исходный код в чистом ASCII и по-прежнему использовать весь диапазон символов Unicode.Это имеет два преимущества:

• Нет риска того, что символы, не входящие в ASCII, будут сломаны инструментами, которые не могут их обработать.Это было настоящей проблемой еще в начале 1990-х годов, когда была разработана Java.Отправка электронного письма, содержащего не-ASCII символы, и его поступление без изменений было скорее исключением, чем нормой.

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

Первый вариант имеет смысл для меня - он позволяет программистам называть переменные и методы на международном языке по своему выбору.Однако я не вижу практического применения второго подхода.

Оба приведут к абсолютно одинаковому байт-коду и будут иметь ту же мощность, что и языковая функция.Единственное отличие состоит в исходном коде.

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

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

Во-вторых, кажется, что не хватаетподдержки среди IDE.

Это вряд ли вина функции или ее конструкторов.Но тогда, я не думаю, что это когда-либо было предназначено, чтобы использоваться "вручную".В идеале в среде IDE должна быть возможность, чтобы вы вводили символы в обычном режиме и отображали их как обычно, но автоматически сохраняли их как escape-последовательности Unicode.Возможно, уже есть плагины или параметры конфигурации, которые заставляют IDE вести себя таким образом.

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

Answer 2

Хорошая вещь в кодировке \u03C0 заключается в том, что она гораздо менее вероятна, если ее зашифрует текстовый редактор с неправильными настройками кодировки. Например, ошибка в моем программном обеспечении была вызвана случайным преобразованием из UTF-8 é в MacRoman é неправильно настроенного текстового редактора. Указав код Unicode, вы совершенно недвусмысленно понимаете, что вы имеете в виду.

Answer 3

Синтаксис \ uXXXX позволяет однозначно представлять символы Unicode в файле с кодировкой, не способной выражать их напрямую, или если вы хотите, чтобы представление гарантированно использовалось даже в самом нижнем общем знаменателе, а именно в 7-битном ASCII кодирование.

Вы могли бы представлять всех своих символов с помощью \ uXXXX, даже пробелы и буквы, но это редко требуется.

Answer 4

Во-первых, спасибо за вопрос. Я думаю, что это очень интересно. Во-вторых, причина в том, что исходный файл Java представляет собой текст, который может использовать различные кодировки. Например, кодировка по умолчанию в Eclipse - Cp1255. Это окончание не поддерживает символы, такие как π. Я думаю, что они думали о программистах, которые должны работать на системах, которые не поддерживают Unicode, и хотели позволить этим программистам создавать программы с поддержкой Unicode. Это было причиной для поддержки нотации.