Компиляция (javac) кодированного UTF8 исходного кода Java с помощью спецификации

Привет, спасибо за чтение моего сообщения.

Моя проблема заключается в следующем: я хочу скомпилировать исходный файл Java с "javac" с этим файлом, который кодируется UTF-8 с помощью спецификации (ОС - WinXP).

Ниже я что делаю:

1) Создайте файл с "Блокнотом" и выберите кодировку UTF-8

dos> notepad Test.java
"File -> Save as..."
File name   : Test.java
Save as type: All Files
Encoding    : UTF-8
Save

2) Создайте Java-класс в этом файле и сохраните файл, как в 1)

public class Test
{
    public static void main(String [] args)
    {
        System.out.println("This is a test.");
    }
}

3) Визуализируйте шестнадцатеричную версию файла (первая строка)

dos> xxd Test.java | head -1
0000000: efbb bf70 7562 6c69 6320 636c 6173 7320  ...public class

Примечание: ef bb bf - это кодированная UTF-8 спецификация (кодированная спецификация UTF-16 BOM FE FF).

4) Попробуйте скомпилировать этот код с помощью "javac" 

dos> javac -encoding utf8 Test.java
Test.java:1: illegal character: \65279
?public class Test
^
1 error

Примечание. 65279 - это десятичная версия спецификации.

Мой вопрос следующий: как я могу сделать эту компиляцию с помощью:

  • сохранение кодировки UTF-8
  • и сохранение спецификации?

Спасибо за помощь и наилучшие пожелания.

Леа

Ответы

Ответ 1

Обрежьте спецификацию, а затем используйте javac -encoding utf8 x.java

Ответ 2

Это не проблема с вашим текстовым редактором, это проблема с javac! Спецификация Unicode говорит, что спецификация в UTF-8 полезна, она не говорит, что это запрещено! Если спецификация может быть там, то javac HAS для ее обработки, но это не так. Фактически, использование спецификации в файлах UTF-8 полезно для того, чтобы отличать ANSI-кодированный файл от кодированного в Юникоде файла.

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

Этот отчет об ошибке указывает, что эта "проблема" никогда не будет исправлена: http://bugs.java.com/view_bug.do?bug_id=4508058

Поскольку этот поток находится в двух лучших результатах Google для поиска "javac BOM", я оставляю это здесь для будущих читателей.