Я получаю ошибку компиляции по следующему методу.
public static boolean isValidPasswd(String passwd) {
String reg = "^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[~#;:?/@&!\"'%*=¬.,-])(?=[^\\s]+$).{8,24}$";
return Pattern.matches(reg, passwd);
}
at Utility.java:[76,74] unmappable character for enoding UTF-8. 74th character is' " '
Как я могу это исправить? Спасибо.
У вас есть проблема с кодировкой с исходным кодом. Возможно, это ISO-8859-1, но компилятор был настроен на использование UTF-8. Это приведет к ошибкам при использовании символов, которые не будут иметь одинаковое представление байтов в UTF-8 и ISO-8859-1. Это произойдет со всеми символами, которые не являются частью ASCII, например ¬ НЕ ЗНАК.
Вы можете имитировать это со следующей программой. Он просто использует вашу строку исходного кода и генерирует массив байтов ISO-8859-1 и декодирует это "неправильно" с кодировкой UTF-8. Вы можете видеть, в какой позиции линия повреждена. Я добавил 2 пробела в исходный код, чтобы поместить позицию 74, чтобы соответствовать этому значению ¬ NOT SIGN, который является единственным символом, который будет генерировать разные байты в ISO- 8859-1 и кодирование UTF-8. Я думаю, это будет соответствовать отступу с реальным исходным файлом.
String reg = " String reg = \"^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[~#;:?/@&!\"'%*=¬.,-])(?=[^\\s]+$).{8,24}$\";";
String corrupt=new String(reg.getBytes("ISO-8859-1"),"UTF-8");
System.out.println(corrupt+": "+corrupt.charAt(74));
System.out.println(reg+": "+reg.charAt(74));
что приводит к следующему результату (испорченному из-за разметки):
String reg = "^ (? =. [0-9]) (? =. [az]) (? =. [AZ]) (? =. [~ #;:?/@&!" '% * =., -]) (? = [^\S] + $). {8,24} $";:
String reg = "^ (? =. [0-9]) (? =. [az]) (? =. [AZ]) (? =. [~ #;:?/@&!" '% * = ¬., -]) (? = [^\S] + $). {8,24} $";: ¬
Смотрите "live" в https://ideone.com/ShZnB
Чтобы исправить это, сохраните исходные файлы с кодировкой UTF-8.
Я собираюсь создать сервер сборки CI в ящике Linux для устаревшей системы, запущенной в 2000 году. Существует раздел, который создает PDF файл, который содержит символы, отличные от UTF8. Мы находимся в заключительных шагах релиза, поэтому я не могу заменить героев, дающих мне горя, но по причинам Dilbertesque я не могу ждать неделю, чтобы решить эту проблему после выпуска. К счастью, команда "javac" в Ant имеет параметр "encoding".
<javac destdir="${classes.dir}" classpathref="production-classpath" debug="on"
includeantruntime="false" source="${java.level}" target="${java.level}"
encoding="iso-8859-1">
<src path="${production.dir}" />
</javac>
Компилятор Java предполагает, что ваш ввод кодируется в кодировке UTF-8 либо потому, что вы указали его, либо потому, что его кодировка по умолчанию для вашей платформы.
Однако данные в ваших файлах .java на самом деле не закодированы в UTF-8. Вероятно, проблема - это символ ¬. Убедитесь, что ваш редактор (или IDE) выбора фактически защищает свой файл в кодировке UTF-8.
В eclipse попытайтесь перейти к свойствам файла (Alt + Enter) и смените ресурс → 'Кодировка текстового файла' → на Other to UTF-8. Повторно запустите файл и проверьте, будет ли символ нежелательной почты в строке/файле. Убери это. Сохраните файл.
Измените ресурс кодирования → "Кодировка текстового файла" на значение по умолчанию.
Скомпилируйте и разворачивайте код.
Компилятор использует кодировку символов UTF-8 для чтения исходного файла. Но файл должен был быть написан редактором с использованием другой кодировки. Откройте файл в редакторе, установленном в кодировку UTF-8, исправьте метку кавычки и сохраните ее снова.
В качестве альтернативы вы можете найти точку Unicode для символа и использовать escape-код Unicode в исходном коде. Например, символ A можно заменить на Unicode escape \u0041.
Кстати, при использовании метода matches() вам не нужно использовать привязки begin и end-line ^ и $. Вся последовательность должна соответствовать регулярному выражению при использовании метода matches(). Анкеры полезны только с помощью метода find().
Для пользователей IntelliJ это довольно легко, как только вы узнаете, что такое оригинальная кодировка. Вы можете выбрать кодировку в правом нижнем углу окна, вам будет предложено диалоговое окно с сообщением:
Выбранная вами кодировка ('[тип кодирования]') может изменить содержимое '[Ваш файл]'. Вы хотите перезагрузить файл с диска или конвертировать текст и сохранить в новой кодировке?
Итак, если у вас есть несколько символов, сохраненных в некоей нечетной кодировке, то вам следует сначала выбрать "Reload", чтобы загрузить файл в кодировку плохих символов. Для меня это оказалось? символов в их правильное значение.
IntelliJ может сказать, что вы, скорее всего, не выбрали правильную кодировку и будете предупреждать вас. Вернитесь назад и повторите попытку.
Как только вы увидите, что плохие символы исчезнут, измените поле выбора кодировки в нижнем правом углу обратно в формат, который вы изначально планировали (если вы отправляете это сообщение об ошибке, это скорее всего будет UTF-8). На этот раз в диалоговом окне выберите кнопку "Конвертировать".
Для меня мне нужно было перезагрузить "windows-1252", а затем перевести обратно в "UTF-8". Оскорбительными символами были одинарные кавычки ('и), которые, вероятно, были вставлены из документа Word (или электронной почты) с неправильной кодировкой, и вышеуказанные действия преобразуют их в UTF-8.
Следующие компиляции для меня:
class E{
String s = "^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[~#;:?/@&!\"'%*=¼.,-])(?=[^\\s]+$).{8,24}$";
}
Смотрите:
"error: unmappable character for encoding UTF-8" означает, что java обнаружил символ, который не отображается в UTF-8. Следовательно, откройте файл в редакторе и установите кодировку символов в UTF-8. Вы должны быть в состоянии найти символ, который не представлен в UTF-8. Снять этот символ и перекомпилировать.
Спасибо Michael Konietzka (fooobar.com/questions/96992/...) за ваш ответ.
Я сделал это в Eclipse/STS:
Preferences > General > Content Types > Selected "Text"
(which contains all types such as CSS, Java Source Files, ...)
Added "UTF-8" to the default encoding box down the bottom and hit 'Add'
Бинго, ошибка ушла!
Я наблюдал эту проблему при использовании Eclipse. Мне нужно было добавить кодировку в файл pom.xml, и она была решена. http://ctrlaltsolve.blogspot.in/2015/11/encoding-properties-in-maven.html