This would be in addition to previous, if someone meets a problem with scandic letters that isn’t solved with the solution above.
If the java source files contain scandic letters they need to be interpreted correctly by the Java used for compiling. (e.g. scandic letters used in constants)
Even that the files are stored in UTF-8 and the Maven is configured to use UTF-8, the System Java used by the Maven will still use the system default (eg. in Windows: cp1252).
This will be visible only running the tests via maven (possibly printing the values of these constants in tests. The printed scandic letters would show as ‘< ?>’)
If not tested properly, this would corrupt the class files as compile result and be left unnoticed.
To prevent this, you have to set the Java used for compiling to use UTF-8 encoding.
It is not enough to have the encoding settings in the maven pom.xml, you need to set the environment variable:
JAVA_TOOL_OPTIONS = -Dfile.encoding=UTF8
Also, if using Eclipse in Windows, you may need to set the encoding used in addition to this (if you run individual test via eclipse).
Как пофиксить?
Gradle для Minecraft 1.7.10
-
Вопрос задан
-
1642 просмотра
У тебя где-то идет преобразование из Unicode символов в символы кодировки cp1251 (только латиница и кириллица) и если попадается символ который ни то и не другое — то кодировщик не может его преобразовать. Решение — найти в конфигурации где у тебя идет использование cp1251 и заменить его на utf-8 или utf-16.
Пригласить эксперта
Была такая же проблема с gradle, он использовал кодировку 1251
Указал ему использовать UTF-8 и все заработало
добавил в build.gradle строки:
allprojects {
tasks.withType(JavaCompile) {
options.encoding = ‘UTF-8’
}
}
Войдите, чтобы написать ответ
-
Показать ещё
Загружается…
Минуточку внимания
Распределенное обучение с TensorFlow и Python
AI_Generated 05.05.2025
В машинном обучении размер имеет значение. С ростом сложности моделей и объема данных одиночный процессор или даже мощная видеокарта уже не справляются с задачей обучения за разумное время. Когда. . .
CRUD API на C# и GraphQL
stackOverflow 05.05.2025
В бэкенд-разработке постоянно возникают новые технологии, призванные решить актуальные проблемы и упростить жизнь программистам. Одной из таких технологий стал GraphQL — язык запросов для API,. . .
Распознавание голоса и речи на C#
UnmanagedCoder 05.05.2025
Интеграция голосового управления в приложения на C# стала намного доступнее благодаря развитию специализированных библиотек и API. При этом многие разработчики до сих пор считают голосовое управление. . .
Реализация своих итераторов в C++
NullReferenced 05.05.2025
Итераторы в C++ — это абстракция, которая связывает весь экосистему Стандартной Библиотеки Шаблонов (STL) в единое целое, позволяя алгоритмам работать с разнородными структурами данных без знания их. . .
Разработка собственного фреймворка для тестирования в C#
UnmanagedCoder 04.05.2025
C# довольно богат готовыми решениями – NUnit, xUnit, MSTest уже давно стали своеобразными динозаврами индустрии. Однако, как и любой динозавр, они не всегда могут протиснуться в узкие коридоры. . .
Распределенная трассировка в Java с помощью OpenTelemetry
Javaican 04.05.2025
Микросервисная архитектура стала краеугольным камнем современной разработки, но вместе с ней пришла и головная боль, знакомая многим — отслеживание прохождения запросов через лабиринт взаимосвязанных. . .
Шаблоны обнаружения сервисов в Kubernetes
Mr. Docker 04.05.2025
Современные Kubernetes-инфраструктуры сталкиваются с серьёзными вызовами. Развертывание в нескольких регионах и облаках одновременно, необходимость обеспечения низкой задержки для глобально. . .
Создаем SPA на C# и Blazor
stackOverflow 04.05.2025
Мир веб-разработки за последние десять лет претерпел коллосальные изменения. Переход от традиционных многостраничных сайтов к одностраничным приложениям (Single Page Applications, SPA) — это. . .
Реализация шаблонов проектирования GoF на C++
NullReferenced 04.05.2025
«Банда четырёх» (Gang of Four или GoF) — Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес — в 1994 году сформировали канон шаблонов, который выдержал проверку временем. И хотя C++ претерпел. . .
C# и сети: Сокеты, gRPC и SignalR
UnmanagedCoder 04.05.2025
Сетевые технологии не стоят на месте, а вместе с ними эволюционируют и инструменты разработки. В . NET появилось множество решений — от низкоуровневых сокетов, позволяющих управлять каждым байтом. . .
Проблема:
В проекте используется jaxws-maven-plugin версии 2.1, генерирующий классы по WSDL. В WSDL и импортируемой в неё схеме есть русские буквы в аннотациях. При сборке проекта при компиляции возникают ошибки «unmappable character for encoding UTF-8» при попытке скомпилировать сгенерированные классы. ОС — Windows, кодировка исходников проекта — UTF-8.
Проект использует кодировку исходников UTF-8. wsimport генерирует исходники в cp1251 (в системной кодировке), причем они содержат русские символы в комментариях, пришедшие туда из аннотаций к XSD-схеме.
В отличие от wsimport`а версии 2.2, опции «encoding», позволяющей задать кодировку целевых файлов, нет. Нет такой опции и у используемого им xjc (эту опцию можно было бы передать ему через опцию -B<xjcoption> wsimport`а).
Как ни странно, помогла установка параметра xnocompile в false:
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.1</version>
<!— … —>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws-wsimport</sourceDestDir>
<xnocompile>false</xnocompile>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${basedir}/src/jax-ws-catalog.xml</catalog>
</configuration>
</plugin>
Также xnocompile можно установить в false не в конфигурации всего плагина, а внутри конфигурации execution`а, эффект тот же:
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<xnocompile>false</xnocompile>
<!— … —>
</configuration>
<!— … —>
</execution>
</executions>
<!— … —>
</plugin>
Генерируемые исходники все также в cp1251, но компиляция проходит. Есть идея, что это происходит потому, что сгенерированные файлы компилируются сразу wsimport`ом, и в этом случае компилятор не обращает внимание на кодировку файлов проекта (посколько о ней не знает), а читает исходники в системной кодировке, в какой они и действительно закодированы.
Обновлено: 2024-11-26
Посещений: 680
Бывает так, что в при компиляции Java через cmd появляется сообщение — error: unmappable character for encoding windows-1252 и на этом этапе компиляция аварийно завершается. Как правило, подобного рода проблема случается в Windows и успешно решается.
На всякий случай уточняю, аббревиатура cmd есть «интерпретатор командной строки» или еще варианты: «командная строка», «консоль», «терминал».
Исходные данные
В представленном скриншоте, можно видеть, что данный исходный код с кодированием utf-8 находится в среде Windows 7, где кодировка cmd по умолчанию — cp866.
Среда Windows может быть любой, не обязательно седьмой версии. В данном случае имеет значение кодировка консоли по умолчанию.
Решение проблемы с компиляцией
Все просто, в командную строку необходимо ввести следующий текст — javac -encoding utf8 Solution.java (1). Тем самым сообщаем JDK (инструментарий для Java), что кодировка компилируемого исходного кода — utf-8. Теперь процедура компиляции Java через cmd завершается успешно и в папке solution появляется новый файл — Solution.class . Запускаем его на выполнение с помощью — java Solution и видим, что файл выполняется корректно и в командной строке отображают символы кириллицы.
В качестве эксперимента, меняем кодировку в командной строке на 1251, набрав — chcp 1251 (2), снова запускаем файл Solution.class. Опять все корректно выполняется и отображается. Для наглядности, все вышеперечисленные действия представлены в представленных скриншотах.
В сущности, ошибки не было, а была необходимость сообщить JDK про установленную кодировку в исходном коде. На такое решение натолкнула мысль, что компиляция одного и того же текста в Linux, в отличие от Windows, выполняется корректно.
Демонстрация в GNU/Linux Ubuntu
Из представленного далее скриншота следует, что терминал настроен на utf-8, а компиляция осуществляется этого же самого кода, что и в предыдущем случае, только в данном примере выполняется успешно с первого раза.
⚬ ⚬ ⚬
Ничего сложного, таким образом решается проблема с кириллизацией в процессе компиляции Java через cmd.
Может возникнуть вопрос, зачем нужна эта возня с консолью? Гораздо проще выполнить то же самое с помощью комфортных программных средств (Ant, Maven, …). Дело в том, что встречаются ситуации, когда cmd помогает лучше понять процесс запуска приложения на этапе создания, особенно на начальном.
Также умение использования командной строки всегда полезно и обязательно пригодится в трудной ситуации, когда графический интерфейс в Windows будет бессилен. А в семействе UXIX подобных ОС это необходимый рабочий инструмент. Где рекомендуется научиться работать. Выбор широк: FreeBCD, OpenBSD, NetBSD и Linux со множеством дистрибутивов.