Когда я бегу maven install
свой мультимодульный проект maven, я всегда получаю следующий вывод:
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
Итак, я немного погуглил, но все, что я могу найти, это то, что я должен добавить:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
... на мой pom.xml. Но это уже есть (в родителе pom.xml
).
Настройка <encoding>
для maven-resources-plugin или maven-compiler-plugin также не исправляет это.
Так в чем проблема?
Ответы:
ОК, я нашел проблему.
Я использую некоторые плагины отчетности. В документации по отказоустойчивому подключаемому модулю ( http://maven.apache.org/plugins/maven-failsafe-plugin/integration-test-mojo.html ) я обнаружил, что
<encoding>
конфигурация - конечно - использует${project.reporting.outputEncoding}
по умолчанию , Поэтому я добавил свойство как дочерний элементproject
элемента, и теперь все в порядке:Смотрите также http://maven.apache.org/general.html#encoding-warning
источник
Это было бы в дополнение к предыдущему, если кто-то встречает проблему со скандинавскими буквами, которая не решается с помощью решения выше.
Если исходные файлы java содержат буквы scandic, они должны быть правильно интерпретированы Java, используемой для компиляции . (например, скандические буквы, используемые в константах)
Даже если файлы хранятся в UTF-8 и Maven настроен на использование UTF-8, системная Java, используемая Maven, все равно будет использовать системную настройку по умолчанию (например, в Windows: cp1252).
Это будет видно только при запуске тестов через maven (возможно, при печати значений этих констант в тестах. Напечатанные буквы скандинада будут отображаться как «<?>»). Если не протестировать должным образом, это приведет к повреждению файлов классов в результате компиляции и будет осталось незамеченным.
Чтобы предотвратить это, вы должны настроить Java, используемую для компиляции, на использование кодировки UTF-8. Недостаточно иметь параметры кодировки в файле maven pom.xml, вам нужно установить переменную среды: JAVA_TOOL_OPTIONS = -Dfile.encoding = UTF8
Кроме того, если вы используете Eclipse в Windows, вам может потребоваться установить кодировку, используемую в дополнение к этому (если вы запускаете отдельный тест через eclipse).
источник
-Dfile.encoding
если вы используете I / O в Java без явного указания кодировки (что не рекомендуется). Я не вижу, как это связано со скандальными буквами в исходных файлах Java. Non-ASCII в исходных файлах Java работает с Maven, еслиproject.build.sourceEncoding
он установлен правильно, как описано в ответе Итана Леруа.javac
, он передает кодировку, установленнуюproject.build.sourceEncoding
(вы можете проверить, используяmvn -X
), поэтому я не вижу, как то, что вы описываете, необходимо. Если вы по-прежнему сталкиваетесь с проблемами кодирования в своем проекте, подумайте над тем, чтобы задать это как отдельный вопрос - похоже, вы столкнулись с другой проблемой. В идеале, опубликовать воспроизводимый контрольный пример.Если вы объедините ответы выше, наконец, pom.xml, настроенный для UTF-8, должен выглядеть так.
pom.xml
источник
Кажется, что люди смешивают кодировку контента со встроенной кодировкой файлов / ресурсов. Иметь только мавенские свойства недостаточно. Имея
-Dfile.encoding=UTF8
не эффективный. Чтобы избежать проблем с кодировкой, вы должны следовать следующим простым правиламВсегда устанавливайте кодировку явно, когда работаете с файлами, строками, вводом-выводом в вашем коде. Если вы не будете следовать этому правилу, ваше приложение будет зависеть от среды.
-Dfile.encoding=UTF8
Точно отвечает за настройки среды времени выполнения, но мы не должны зависеть от него. Если у вас тысячи клиентов, потребуется больше усилий для настройки систем и поиска проблем из-за этого. У вас просто есть дополнительная зависимость, которую вы можете избежать, установив ее явно. Из-за этого большинство методов в Java, использующих кодировку по умолчанию, помечены как устаревшие.Убедитесь, что контент, с которым вы работаете, также находится в той же кодировке, что и вы. Если это не так, предыдущие шаги не имеют значения! Например, файл не будет обработан правильно, если его кодировка не UTF8, но вы ожидаете этого. Чтобы проверить кодировку файлов в Linux:
Надеюсь, это будет кому-то полезно.
источник
Попробуй это:
источник
В моем случае я использовал
maven-dependency-plugin
так, чтобы решить проблему, я должен был добавить следующее свойство:Смотрите Apache Maven Resources Plugin / Определение схемы кодирования символов
источник