Почему Java выполняет код, написанный в комментариях с помощью Unicode-символов?

Почему это происходит?

Всё дело в том, как компилятор Java обрабатывает Unicode-escape последовательности. Согласно спецификации Java (JLS §3.3), Unicode-escape последовательности обрабатываются на самом раннем этапе компиляции, ещё до того, как компилятор начинает разбирать синтаксис. Это означает, что преобразование \uXXXX в реальные символы происходит до того, как компилятор определяет, что является комментарием, а что — кодом.

В вашем примере последовательность \u000d соответствует символу возврата каретки (CR, U+000D). Когда компилятор видит эту последовательность, он заменяет её на реальный символ перевода строки. В результате строка:

// \u000d System.out.println("Это выполняется!");

превращается в две строки:

// 
 System.out.println("Это выполняется!");

Первая строка — это пустой комментарий //, а вторая строка уже является полноценным кодом, который выполняется!

Как это работает пошагово?

1. Этап 1 (Unicode-экранирование): Компилятор сканирует исходный код и заменяет все \uXXXX на соответствующие символы. Ваш \u000d становится символом CR.
2. Этап 2 (Лексический анализ): Теперь компилятор разбивает код на токены. Он видит // как начало однострочного комментария, затем CR (который интерпретируется как конец строки), и затем System.out.println(...) как новый оператор.
3. Этап 3 (Синтаксический анализ и компиляция): "Случайный" код обрабатывается как обычный код Java.

Другие опасные Unicode-символы

Наиболее критичные символы — это управляющие символы Unicode, которые могут влиять на структуру строк:

• \u000a (LF, перевод строки) — делает то же самое, что и \u000d.
• \u000d (CR, возврат каретки) — как в вашем примере.
• \u000c (FF, перевод страницы) — может влиять на лексический анализ.
• \u001a (SUB, символ замены) — в некоторых старых системах может обозначать конец файла.

Как защититься от таких ошибок?

На практике это редко приводит к проблемам, если вы пишете код в современных IDE (IntelliJ IDEA, Eclipse), которые визуально показывают нестандартные символы. Но вот несколько правил:

• Не используйте Unicode-escape в комментариях. Если нужно написать не-ASCII символы (например, кириллицу), просто вставляйте их напрямую. Современные IDE поддерживают UTF-8.
• Используйте статический анализатор кода. Инструменты вроде Checkstyle или SpotBugs могут предупредить о подозрительных Unicode-последовательностях.
• Проверяйте код на наличие скрытых символов. Включите отображение непечатных символов в вашей IDE.
• Будьте осторожны с копированием кода. При копировании из веб-страниц или PDF могут попасть невидимые Unicode-символы.

Пример "безопасного" комментария

public class SafeExample {
    public static void main(String[] args) {
        // Правильно: используем UTF-8 напрямую
        // System.out.println("Привет, мир!"); 
        
        // Опасно: \u000a System.out.println("Хак!");
        
        System.out.println("Безопасный вывод");
    }
}

В первом комментарии нет Unicode-escape, поэтому он остаётся комментарием. Во втором — \u000a разорвёт комментарий и выполнит код.

Заключение

Эта особенность Java — не баг, а следствие ранней обработки Unicode. Она редко встречается в реальной разработке, но знание о ней помогает избежать трудноуловимых ошибок. Помните: Unicode-escape обрабатываются до всего остального, поэтому их нельзя "спрятать" в комментариях или строках.

cat -A YourFile.java