2011-02-14 34 views
57

Recibo un error de compilación en el siguiente método."Caracteres no asignables para la codificación de UTF-8" error

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' " ' 

¿Cómo puedo solucionar este problema? Gracias.

+0

Compila muy bien con mi Eclipse, pero que '¬' en el medio parece un poco raro, ¿estás seguro de que el problema es con '"' y no '¬'? Has intentado guardar el archivo con otro editor y asegurándome de que la codificación sea UTF-8? – esaj

+0

lo que hice fue abrir el archivo en cuestión (con suerte se puede deducir de qué archivo se queja). Luego acabo de guardar el archivo nuevamente (después de escribir algunos caracteres aleatorios para registrar un cambio) , luego los borré). Luego, después de volver a guardar, pude compilar.Supongo que volver a guardar guarda el archivo en el modo nativo de su sistema operativo. – user798719

Respuesta

1

Los siguientes compilaciones para mí:

class E{ 
    String s = "^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[~#;:?/@&!\"'%*=¼.,-])(?=[^\\s]+$).{8,24}$"; 
} 

Ver:

enter image description here

+1

Has reemplazado el '¬' con un' ¼'. –

+0

@Luke mhh eso es extraño, eso es lo que el copy/paste hace por mí ... He agregado una captura de pantalla de mi ventana de gvim. De todos modos, realmente no estoy respondiendo la pregunta, así que haré este CW. – OscarRyz

6

El compilador de Java asume que su entrada es codificación UTF-8, ya sea porque ha especificado que sea o porque es la codificación predeterminada de tu plataforma.

Sin embargo, los datos en sus archivos .java en realidad no están codificados en UTF-8. El problema es probablemente el carácter ¬. Asegúrese de que su editor (o IDE) de elección realmente guarda su archivo en codificación UTF-8.

2

El compilador usa la codificación de caracteres UTF-8 para leer su archivo de origen. Pero el archivo debe haber sido escrito por un editor usando una codificación diferente. Abra su archivo en un editor establecido en la codificación UTF-8, corrija la comilla y guárdela de nuevo.

Como alternativa, puede encontrar el punto Unicode para el carácter y usar un escape Unicode en el código fuente. Por ejemplo, el carácter A se puede reemplazar con el escape Unicode \u0041.

Por cierto, no es necesario utilizar el COMIENZO y línea final anclajes ^ y $ cuando se utiliza el método de matches(). La secuencia completa debe coincidir con la expresión regular cuando se usa el método matches(). Los anclajes solo son útiles con el método find().

38

Tiene un problema de codificación con su archivo de código fuente. Es tal vez codificado en ISO-8859-1, pero el compilador estaba configurado para usar UTF-8. Esto dará como resultado errores al usar caracteres, que no tendrán la misma representación de bytes en UTF-8 e ISO-8859-1. Esto sucederá con todos los caracteres que no sean parte de ASCII, por ejemplo ¬NOT SIGN.

Puede simular esto con el siguiente programa. Simplemente utiliza su línea de código fuente y genera una matriz de bytes ISO-8859-1 y decodifica este "error" con la codificación UTF-8. Puedes ver en qué posición se corrompe la línea. Agregué 2 espacios en su código fuente para ajustar la posición 74 para ajustar esto a ¬NOT SIGN, que es el único carácter, que generará diferentes bytes en la codificación ISO-8859-1 y la codificación UTF-8. Supongo que esto coincidirá con la sangría con el archivo fuente real.

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));  

que se traduce en la siguiente salida (en mal estado a causa de marcado):

String reg = "^(?=.[0-9])(?=.[a-z])(?=.[A-Z])(?=.[~#;:?/@&!"'%*=�.,-])(?=[^\s]+$).{8,24}$";: �

String reg = "^(?=.[0-9])(?=.[a-z])(?=.[A-Z])(?=.[~#;:?/@&!"'%*=¬.,-])(?=[^\s]+$).{8,24}$";: ¬

Ver "en vivo" en https://ideone.com/ShZnB

Para solucionar este problema, guardar los archivos de origen con UTF-8 codificación

+2

Gracias Michael! Tuve un problema similar en un proyecto de java verificado en un antiguo servidor cvs. Entonces, para solucionarlo, lo hice - [Determinar y cambiar la codificación de caracteres del archivo] (http://mindspill.net/computing/linux-notes/determine-and-change-file-character-encoding/): find -name '* .java '-exec recode Latin-1..UTF-8 {} \; – Gilberto

+3

La respuesta sería útil con un ejemplo de CÓMO guardar el archivo de origen con codificación UTF-8. ¡Gracias! – kellyfj

+0

@kellyfj Esto depende, por supuesto, del editor que el usuario utilice. Supongo que cada editor tiene un menú para este tipo de opción. –

1

"error: carácter no identificable para la codificación UTF-8" significa que Java ha encontrado un carácter que no está representando en UTF-8. Por lo tanto, abra el archivo en un editor y establezca la codificación de caracteres en UTF-8. Debería poder encontrar un personaje que no esté representado en UTF-8. Quitar este carácter y volver a compilar.

9

Estoy en el proceso de configurar un servidor de compilación CI en una caja Linux para un sistema heredado iniciado en 2000. Hay una sección que genera un PDF que contiene caracteres que no son UTF8. Estamos en los últimos pasos de un lanzamiento, por lo que no puedo reemplazar a los personajes que me causan dolor, pero por razones Dilbertesque, no puedo esperar una semana para resolver este problema después del lanzamiento. Afortunadamente, el comando "javac" en Ant tiene un parámetro de "codificación".

<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> 
3

en Eclipse tratar de ir a presentar propiedades (Alt + Enter) y cambiar los recursos -> 'Codificación de texto Archivo' -> A otro a UTF-8. Vuelva a abrir el archivo y verifique que haya un carácter no deseado en algún lugar de la cadena/archivo. Eliminarlo Guarda el archivo.

Cambie el recurso de codificación -> 'Codificación de archivo de texto' a Predeterminado.

Compila e implementa el código.

2

Gracias Michael Konietzka (https://stackoverflow.com/a/4996583/1019307) por su respuesta.

hice esto en 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' 

Bingo, ha ido de error!

3

Para los usuarios de IntelliJ, esto es bastante fácil una vez que descubres cuál era la codificación original. Puede seleccionar la codificación de la esquina inferior derecha de la ventana, se le pedirá un cuadro de diálogo que dice:

The encoding you've chosen ('[encoding type]') may change the contents of '[Your file]'. Do you want to reload the file from disk or convert the text and save in the new encoding?

Así que si le sucede que tiene un par de caracteres que se almacenan en alguna codificación extraña, lo que debe hacer primero seleccione 'Recargar' para cargar todo el archivo en la codificación de los caracteres incorrectos. Para mí esto cambió el? personajes en su propio valor.

IntelliJ puede decir si es muy probable que no haya elegido la codificación correcta y le avisará. Revertir e intentar nuevamente.

Una vez que vea desaparecer los caracteres incorrectos, cambie la casilla de selección de codificación en la esquina inferior derecha al formato que originalmente tenía previsto (si está buscando en Google este mensaje de error, probablemente sea UTF-8). Esta vez, seleccione el botón 'Convertir' en el cuadro de diálogo.

Para mí, necesitaba volver a cargar como 'windows-1252', luego convertir de nuevo a 'UTF-8'. Los caracteres ofensivos eran comillas simples ('y') probablemente pegadas desde un documento de Word (o correo electrónico) con la codificación incorrecta, y las acciones anteriores las convertirán a UTF-8.

Cuestiones relacionadas