Java: проблема с кодировкой многоплатформенной строки

Question

У меня странная ситуация, когда я не понял, как обращаться. У нас есть разработчики, работающие на нескольких платформах, основная платформа - Linux, но у нас также есть люди, работающие над OS X и Windows.

У нас есть набор тестов, которые все строят и работают отлично на Linux. Но когда мы пытаемся запустить их на OS X, они терпят неудачу. Неудачное утверждение - это проверка того, что две строки равны, но есть один символ, который не похож на тот же символ в среде Mac. Я вполне уверен, что это просто потому, что файл закодирован определенным образом, а ожидаемое строковое значение, которое является жестко закодированным, кодируется по-разному. Я смог исправить некоторые другие проблемы с кодировкой, установив JVM file.encoding через MAVEN-OPTS, но до этого момента я был в тупике от этой проблемы.

Структура выглядит примерно так: some.xml -> XSLT -> объект assertEquals ("ожидаемое значение", object.valueToTest());

Любая информация о том, как исправить это несоответствие? Или даже почему это происходит в первую очередь?

Заголовок в файле xml говорит, что он закодирован в UTF-8, но возможно, что файл может быть закодирован по-разному в файловой системе. Есть ли способ проверить, что такое фактическая кодировка?

Answer 1

В основном, what Pete Kirkham said.

я был в состоянии исправить некоторые другие вопросы кодирования путем установки виртуальной машины Java file.encoding через Maven-OPTS

Не делайте этого; it is not supported and may have unintended side-effects.

Правильный способ specify source file encoding находится в файлах pom.xml.

<project> 
    ... 
    <properties> 
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
    </properties> 
    ... 
</project> 

Это гарантирует, что компилятор будет декодировать исходные файлы последовательно на всех platfroms и эквивалентно использованию javac -encoding X ...

Подробнее о кодировании в исходных файлах here.

Answer 2

Обычная причина: если кто-то использует одну старую строку < -> байты, которые не принимают параметр для указания кодировки.

Не исключено, что это проблема кодирования в исходном файле, хотя я только переехал между Windows и Linux, поэтому я никогда не видел его, но вы должны использовать escape-код Unicode для любой точки кода выше U00007f.

Answer 3

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

Как персонаж представлен в файле? Вы можете попробовать избежать любого unicode в строковых константах, используя \uXXXX notation.

This page также дает другое представление о том, почему это может не работать. Кодировка по умолчанию на Mac - «MacRoman», которая не является подмножеством UTF-8. Поэтому, как вы подозревали, персонаж, вероятно, интерпретируется по-разному.

Answer 4

Если файл XML начинается с <?xml ... encoding="UTF-8"?>, вы можете быть достаточно уверены, что он закодирован как UTF-8 в файловой системе. В противном случае откройте его в редакторе, который позволит вам увидеть, что представляют собой необработанные байты. emacs M-xfind-file-literally.

В качестве альтернативы, ваш исходный код java может иметь забавный байт в строковом литерале, который по-разному представлен в разных кодировках. Я думаю, что компилятор читает исходный код, используя кодировку платформы по умолчанию. Чтобы обойти эту проблему переносимости, вы можете закодировать любой символ без ascii с помощью обозначения \ uxxxx. Это нормально для пользователей английского языка, но может быть немного утомительным для всех остальных!

EDIT: Не в тему, но это напомнило мне любопытный файл, который я нашел на работе в тестовом корпусе. Это был файл XML, который был закодирован как ascii/utf-8, но тег кодирования сказал «UTF-16». Это выглядело бы нормально в простых редакторах, таких как блокнот, которые не учитывали директиву кодирования XML, но выглядели бы странно в умных редакторах, которые читали файл как UTF-16