Почему разрешено выполнение кода Java в комментариях с определенными символами Unicode?

Так как это еще не адресовано, вот объяснение, почему перевод экранов Unicode происходит до любой другой обработки исходного кода:

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

Итак, исходный код Java может быть написан в любой кодировке и позволяет использовать широкий диапазон символов в идентификаторах, символах и String литералах и комментариях. Затем, чтобы передать его без потерь, все символы, не поддерживаемые целевой кодировкой, заменяются их экранами Unicode.

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

Это причина другой странной функции, о которой даже не упоминалось: синтаксис \uuuuuuxxxx:

Когда инструмент перевода ускользает от символов и встречает последовательность, которая уже является экранированной последовательностью, она должна вставить дополнительный u в последовательность, преобразуя \ucafe в \uucafe. Значение не изменяется, но при преобразовании в другое направление инструмент должен просто удалить один u и заменить только последовательности, содержащие один u своими символами Юникода. Таким образом, даже Unicode-экраны сохраняются в исходной форме при конвертации взад и вперед. Думаю, никто никогда не использовал эту функцию...

Я собираюсь полностью неэффективно добавить точку, просто потому, что я не могу помочь себе, и я еще не видел ее, что вопрос недействителен, поскольку в нем содержится скрытая предпосылка, которая неверна, а именно, что код находится в комментарии!

В исходном коде Java\u000d во всех отношениях эквивалентен символу ASCII CR. Это конец строки, простой и простой, где бы он ни возникал. Форматирование в вопросе вводит в заблуждение, что соответствует синтаксически соответствующей последовательности символов:

public static void main(String... args) {
   // The comment below is no typo. 
   // 
 System.out.println("Hello World!");
}

ИМХО самый правильный ответ: код выполняется потому, что он не находится в комментарии; это на следующей строке. "Выполнение кода в комментариях" не разрешено на Java, как и следовало ожидать.

Большая часть путаницы проистекает из того факта, что синтаксические маркеры и IDE не достаточно сложны, чтобы учитывать эту ситуацию. Они либо вообще не обрабатывают экраны unicode, либо делают это после разбора кода вместо предыдущего, например javac.

Побег \u000d завершает комментарий, потому что \u экраны равномерно преобразуются в соответствующие символы Юникода до того, как программа будет маркирована. Вы можете использовать \u0057\u0057 вместо //, чтобы начать комментарий.

Это ошибка в вашей среде IDE, которая должна синтаксически выделять строку, чтобы было ясно, что \u000d завершает комментарий.

Это также ошибка дизайна на языке. Теперь это не может быть исправлено, потому что это может сломать программы, зависящие от него. \u escape файлы должны либо быть преобразованы в соответствующий символ Юникода компилятором только в тех контекстах, где это "имеет смысл" (строковые литералы и идентификаторы и, возможно, нигде больше), или им было запрещено создавать символы в U + 0000 -007F или оба. Любая из этих семантик предотвратила бы завершение комментария путем \u000d escape, без вмешательства в случаи, когда \u escapes являются полезными - обратите внимание, что это включает использование \u экранов внутри комментариев как способ кодирования комментариев в нелатинском script, потому что текстовый редактор может принимать более широкое представление о том, где \u экраны значительны, чем компилятор. (Я не знаю ни одного редактора или IDE, которые будут отображать экраны \u как соответствующие символы в любом контексте.)

Аналогичная ошибка конструкции в семействе C, ¹ где обратная косая черта-новая строка обрабатывается до определения границ комментария, например,

// this is a comment \
   this is still in the comment!

Я привожу это, чтобы проиллюстрировать, что бывает легко сделать эту конкретную ошибку дизайна, и не осознавать, что это ошибка, пока не будет слишком поздно ее исправлять, если вы привыкли думать о токенизации и анализировать путь программисты компилятора думают о токенизации и разборе. В принципе, если вы уже определили свою формальную грамматику, а затем кто-то придумает синтаксический специальный случай — триграфы, backslash-newline, кодирование произвольных символов Unicode в исходных файлах, ограниченных ASCII, независимо от того, что нужно вклинивать, проще добавить проход преобразования перед токенизатором, чем переопределять токенизатор, чтобы обратить внимание на то, где имеет смысл использовать этот специальный случай.

¹ Для педантов: я знаю, что этот аспект C был на 100% преднамеренным, с обоснованием; Я этого не делаю; что это позволит вам механически форсировать код с произвольно длинными строками на перфокарты. Это было неправильное дизайнерское решение.

Это был преднамеренный выбор дизайна, который полностью возвращается к оригинальному дизайну Java.

Для тех, кто спрашивает "кто хочет, чтобы Unicode удалялся в комментариях?", я полагаю, что они - люди, родной язык которых использует набор символов латинского алфавита. Другими словами, он присущ оригинальному дизайну Java, что люди могут использовать произвольные символы Unicode везде, где это законно в Java-программе, чаще всего в комментариях и строках.

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

Я согласен с @zwol, что это ошибка дизайна; но я даже более критично отношусь к нему.

\u escape полезен в строках и char литералах; и что единственное место, в котором оно должно существовать. Его следует обрабатывать так же, как и другие escape-последовательности, такие как \n; и "\u000A" должно означать точно "\n".

Нет абсолютно никакого смысла иметь \uxxxx в комментариях - никто не может это прочитать.

Точно так же нет смысла использовать \uxxxx в другой части программы. Единственное исключение, вероятно, в общедоступных API, которые принудительно содержат некоторые символы не-ascii - что в последний раз мы видели?

У дизайнеров были свои причины в 1995 году, но через 20 лет это кажется неправильным выбором.

(вопрос читателям - почему этот вопрос продолжает получать новые голоса? этот вопрос связан с чем-то популярным?)

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

Вероятная причина этого заключается в том, что было желание разрешить весь BMP как возможные символы исходного кода Java. Это создает проблему, хотя:

• Вы хотите иметь возможность использовать любой символ BMP.
• Вы хотите иметь возможность вводить любой BMP charater достаточно легко. Способ сделать это - с экранами Unicode.
• Вы хотите, чтобы лексическая спецификация была легкой для людей, чтобы читать и писать, а также разумно легко реализовать.

Это невероятно сложно, когда Unicode выйдет из игры: он создает целый набор новых правил лексера.

Легкий выход состоит в том, чтобы выполнить лексирование в два этапа: сначала найдите и замените все символы Unicode символом, который он представляет, а затем проанализируйте результирующий документ так, как будто escape-коды Unicode не существуют.

Поверхность этого заключается в том, что ее легко указать, поэтому упрощает ее спецификацию и ее легко реализовать.

Недостатком является, ну, ваш пример.

Компилятор не только переводит escape-последовательности Unicode в символы, которые они представляют, прежде чем он анализирует программу в токенах, но делает это до удаления комментариев и пробелов.

Эта программа содержит единственный Unicode escape (\ u000d), расположенный в единственном комментарии. Как говорится в комментарии, этот escape представляет символ перевода строки, а компилятор переводит его перед , отбрасывая комментарий.

Это зависит от платформы. В некоторых формах плат, таких как UNIX, он будет работать на других, таких как Windows, это не будет. Хотя результат может выглядеть невооруженным глазом, он может легко вызвать проблемы, если он был сохранен в файле или передан в другую программу для последующей обработки.