Вопрос по java, javadoc, unicode – Юникод в javadoc и комментарии?

13

Некоторые компиляторы не работают с не-ASCII символами в JavaDoc и комментариях к исходному коду. Каковы текущие (Java 7) и будущие (Java 8 и более поздние) практики в отношении Unicode в исходных файлах Java? Есть ли различия между IcedTea, OpenJDK и другими средами Java, и что диктуется спецификацией языка? Следует ли экранировать все символы, не входящие в ASCII, в JavaDoc с помощью HTML&escape;-подобные коды? Но какой будет Java// comment эквивалент?

Update: комментарии указывают, что можно использовать любой набор символов и что при компиляции необходимо указать, какой набор символов используется в исходном файле. Я посмотрю на это и буду искать подробности о том, как настроить это через Ant, Eclipse и Maven.

На самом деле, вы можете использовать любую кодировку в ваших исходных файлах, вам просто нужно указать, какую кодировку вы выбрали для компилятора Java и командной строки javadoc. Guillaume Polet
ОК, это та информация, которую я ищу! Во-первых, это очень круто, и не знал об этом. Итак, теперь мне просто нужно выяснить, как заставить компилятор узнать, какой набор символов использовать ... например, CDK скомпилирован с использованием Ant, Maven и Eclipse ... Egon Willighagen
Посмотри наthis (Я уверен, что это определено JLS). Alexander Pavlov

Ваш Ответ

2   ответа
4

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

Eclipse

Eclipse (проверено 3.7) не требует специальной настройки, и вы можете с радостью использовать исходный код Java, например:

double π = Math.PI;

Ant

<javac encoding="UTF-8" ... >
</javac>

Java

javac -encoding UTF-8 src/main/Foo.java
13

Some compilers failed on non-ASCII characters in JavaDoc and source code comments.

Вероятно, это связано с тем, что компилятор предполагает, что вводом является UTF-8, а в исходном файле есть недопустимые последовательности UTF-8. То, что они появляются в комментариях в редакторе исходного кода, не имеет значения, потому что лексер (который отличает комментарии от других токенов) никогда не запускается. Ошибка возникает, когда инструмент пытается преобразовать байты в символы до запуска лексера.


man страница дляjavac а такжеjavadoc сказать

-encoding name
          Specifies  the  source  file  encoding   name,   such   as
          EUCJIS/SJIS.   If  this option is not specified, the plat-
          form default converter is used.

так работаетjavadoc с флагом кодирования

javadoc -encoding <encoding-name> ...

после замены<encoding-name> кодировка, которую вы используете для своих исходных файлов, должна заставить его использовать правильную кодировку.

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


What is the current (Java 7) and future (Java 8 and beyond) practices with respect to Unicode in Java source files?

Алгоритм работы с исходным файлом в Java

  1. Collect bytes
  2. Convert bytes to chars (UTF-16 code units) using some encoding.
  3. Replace all sequences of '\\' 'u' followed by four hex digits with the code-unit corresponding to those hex-digits. Error out if there is a "\u" not followed by four hex digits.
  4. Lex the chars into tokens.
  5. Parse the tokens into classes.

Текущая и прежняя практика заключается в том, что шаг 2, преобразование байтов в кодовые единицы UTF-16, зависит от инструмента, который загружает модуль компиляции (исходный файл), но де-факто стандартом для интерфейсов командной строки является использование-encoding флаг.

После того, как это преобразование произойдет, язык обязывает\uABCD последовательности стилей преобразуются в кодовые единицы UTF-16 (шаг 3) перед лексированием и анализом.

Например:

int a;
\u0061 = 42;

является допустимой парой операторов Java. Любой инструмент с исходным кодом Java должен, после преобразования байтов в символы, но перед синтаксическим анализом, найти последовательности \ uABCD и преобразовать их, чтобы этот код был преобразован в

int a;
a = 42;

до разбора. Это происходит независимо от того, где находится последовательность \ uABCD.

Этот процесс выглядит примерно так

  1. Get bytes: [105, 110, 116, 32, 97, 59, 10, 92, 117, 48, 48, 54, 49, 32, 61, 32, 52, 50, 59]
  2. Convert bytes to chars: ['i', 'n', 't', ' ', 'a', ';', '\n', '\\', 'u', '0', '0', '6', '1', ' ', '=', ' ', '4', '2', ';']
  3. Replace unicode escapes: ['i', 'n', 't', ' ', 'a', ';', '\n', a, ' ', '=', ' ', '4', '2', ';']
  4. Lex: ["int", "a", ";", "a", "=", "42", ";"]
  5. Parse: (Block (Variable (Type int) (Identifier "a")) (Assign (Reference "a") (Int 42)))

Should all non-ASCII characters be escaped in JavaDoc with HTML &escape;-like codes?

Нет необходимости, кроме специальных символов HTML, таких как'<' что вы хотите буквально появиться в документации. Ты можешь использовать\uABCD последовательности внутри комментариев Javadoc. Java-процесс\u.... перед синтаксическим анализом исходного файла, чтобы они могли появляться внутри строк, комментариев, где угодно. Вот почему

System.out.println("Hello, world!\u0022);

является допустимым оператором Java.

/** @return \u03b8 in radians */

эквивалентно

/** @return θ in radians */

насколько это касается Javadoc.


But what would be the Java // comment equivalent?

Ты можешь использовать// комментарии в Java, но Javadoc только смотрит внутрь/**...*/ комментарии к документации.// комментарии не несут метаданных.

Одно из последствий обработки Java в\uABCD Последовательности в том, что хотя

// Comment text.\u000A System.out.println("Not really comment text");

выглядит как однострочный комментарий, и многие IDE выделят его как таковой, это не так.

Разочаровывает, спасибо.
Будут ли java-инструменты уважать метаданные emacs / vim о кодировке?
@ Марчин, если вы имеете в виду комментарий, как// -*- coding: UTF-8 -*- в начале файла инструмент может выбрать это, но инструменты Sun не AFAIK.
@ Марчин, да. Кодировка исходного кода - это PITA. Многие новые языки требуют или настоятельно рекомендуют UTF-8 в качестве формата кодирования для своих исходных файлов.JSON а такжеPython default "quot; кодировкой по умолчанию является UTF-8", "по умолчанию UTF-8".Go а такжеRust являются более строгими: «Исходный код - это текст Unicode, закодированный в UTF-8», «ввод интерпретируется как последовательность кодовых точек Unicode, закодированных в UTF-8». Ява должна для-source 1.7.

Похожие вопросы