Файл.listFiles () искажает имена Юникода с помощью JDK 6 (проблемы нормализации Юникода)

решение извлечено из вопроса:

спасибо Стивену П за то, что поставил меня на правильный путь.

сначала исправить, для нетерпеливых. Если вы компилируете с Java 6 Вы можете использовать java.текст.Нормализатор класс для нормализации строк в единую форму по вашему выбору, например,

// Normalize to "Normalization Form Canonical Decomposition" (NFD)
protected String normalizeUnicode(String str) {
    Normalizer.Form form = Normalizer.Form.NFD;
    if (!Normalizer.isNormalized(str, form)) {
        return Normalizer.normalize(str, form);
    }
    return str;
}

С java.text.Normalizer доступен только в Java 6 и более поздних версиях, если вам нужно скомпилировать с Java 5, вам, возможно, придется прибегнуть к sun.text.Normalizer реализация и что-то вроде этого отражение на основе hack см. также как это нормализует работу функции?

этого достаточно, чтобы я решил, что не буду поддерживать компиляцию моего проекта с Java 5:/

вот другие интересные вещи, которые я узнал в этом грязном приключении.

• путаница вызвана тем, что имена файлов находятся в одной из двух форм нормализации, которые не могут быть непосредственно сравнивается: нормализация формы канонического разложения (NFD) или нормализация формы канонического состава (NFC). Первый имеет тенденцию иметь буквы ASCII, за которыми следуют "модификаторы" для добавления акцентов и т. д., В то время как последний имеет только расширенные символы без ведущего символа ACSCII. Прочитайте ссылки на страницу wiki Stephen P для лучшего объяснения.

• строковые литералы Unicode, такие как содержащийся в примере кода (и полученные через HTTP в моем реальном приложении), находятся в форма NFD, в то время как имена файлов, возвращаемые File.listFiles() метод NFC. Следующий мини-пример демонстрирует различия:

  String name = "Trîcky Nåme";
  System.out.println("Original name: " + URLEncoder.encode(name, "UTF-8"));
  System.out.println("NFC Normalized name: " + URLEncoder.encode(
      Normalizer.normalize(name, Normalizer.Form.NFC), "UTF-8"));
  System.out.println("NFD Normalized name: " + URLEncoder.encode(
      Normalizer.normalize(name, Normalizer.Form.NFD), "UTF-8"));
  

  выход:

  Original name: Tri%CC%82cky+Na%CC%8Ame
  NFC Normalized name: Tr%C3%AEcky+N%C3%A5me
  NFD Normalized name: Tri%CC%82cky+Na%CC%8Ame
  

• если вы строите File объект со строковым именем,File.getName() метод вернет имя в какой бы форме вы ни дали его изначально. Однако, если вы позвоните File методы, которые обнаруживают имена самостоятельно, они, похоже, возвращают имена в форме NFC. Это потенциально противный попался. Это, конечно, gotchme.

• согласно цитате ниже от документация Apple имена файлов хранятся в разложенной форме (NFD) в файловой системе HFS Plus:

  при работе в Mac OS вы обнаружите, что используете смесь предварительно составленного и разложенного Unicode. Например, HFS Plus преобразует все имена файлов в разложенный Unicode, в то время как клавиатуры Macintosh обычно создают предварительно составленные Юникод.

  так File.listFiles() способ услужливо (?) преобразует имена файлов в (предварительно)составленную (NFC) форму.

Я видел что-то подобное раньше. Люди, которые uploadde файлы с Mac на веб-приложение, использовать имена файлов с é.

a) в ОС, что char является нормальным e + "знак для применяется к предыдущему char"

b) в Windows это специальный символ: é

оба являются Unicode. Так... Я понимаю, что вы передаете опцию (b) в файл create и в какой-то момент Mac OS преобразует ее в опцию (a). Возможно, если вы найдете проблему двойного представительства через интернет, вы можете получить способ успешно справиться с обеими ситуациями.

надеюсь, что это помогает!

в файловой системе Unix имя файла действительно является байтом с нулевым завершением[]. Таким образом, среда выполнения java должна выполнять преобразование из java.ленг.Строка в байт[] во время операции createNewFile (). Преобразование char-to-byte регулируется языковым стандартом. Я тестировал настройки LC_ALL to en_US.UTF-8 и en_US.ISO-8859-1 и получил внятные результаты. Это с Солнцем (...Oracle) java 1.6.0_20. Однако Для LC_ALL=en_US.POSIX результат:

File name:   Tr%C3%AEcky+N%C3%A5me
Listed name: Tr%3Fcky+N%3Fme

3F вопросительный знак. Это говорит мне, что преобразование не было успешным для не-ASCII символы. Опять же, все так, как и ожидалось.

но причина, по которой ваши две строки отличаются, заключается в эквивалентности между символом \u00EE (или C3 AE в UTF-8) и последовательность i+\u0302 (69 CC 82 в UTF-8). \u0302-комбинирующий диакритический знак (комбинирующий окружной акцент). Во время создания файла произошла некоторая нормализация. Я не уверен, сделано ли это во время выполнения Java или в ОС.

Примечание: мне потребовалось некоторое время, чтобы понять это, так как фрагмент кода, который вы опубликовали, не имеет комбинированной диакритической метки, но эквивалентный символ î (например,\u00ee). Вы должны были встроить escape-последовательность Unicode в строковый литерал (но это легко сказать позже...).

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

вы можете использовать аргумент VM -encoding для этого.

javac -encoding UTF-8 com/example/Foo.java

таким образом .class файл будет содержать правильные символы, и вы сможете создать и перечислить правильное имя файла, а также.

альтернативным решением является использование новой java.НИО.Путь api вместо java.Ио.Файл api, который работает отлично.