Comportamento diverso tra javac 1.6 e javac 1.7 quando si gestiscono caratteri speciali

Question

prima di tutto vorrei ringraziarvi e dire esplicitamente che sto sbattendo la testa su questo problema per diversi giorni e alla ricerca di una soluzione in altri simili discussioni senza successo.

La nostra applicazione è responsabile della generazione di classi java e alcuni di essi possono contenere caratteri speciali nel nome classe (quindi nome file) come ZoneRéservée435.java che impone la codifica a UTF-8.

Fino Java 1.6 il compito formica:

<javac source="1.5" target="1.5" srcdir="${src.dir}" destdir="${classes.dir}" deprecation="on" debug="on" classpathref="classpath" fork="false" memoryMaximumSize="512m" encoding="UTF-8"> 

ha funzionato bene.

Quando si trasferisce a Java 1.7 il nome del file non è stato sempre salvato utilizzando la codifica UTF-8 con conseguente un nome di file simile a:? ZoneRe servire e435.java

Guardandomi intorno ho capito che avevo bisogno di? imposta la variabile env LC_CTYPE su UTF-8. Che ha risolto il problema nomeFile ma ho ancora ottenere un errore di compilazione

error: class ZoneRéservée435 is public, should be declared in a file named ZoneRéservée435.java 

Anche se hanno lo stesso nome, sembrano essere codificati in due modi diversi. La parte interessante è che questa differenza di codifica stava accadendo con java 1.6 ma che stava compilando bene.

Qualcuno ha qualche suggerimento o idee?

Per quello che ho capito il problema di codifica è legato al fatto che la classe è generato con il seguente:

Writer out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(file), Charset.forName("UTF-8"))); 

• Il codice all'interno del file sta usando U + 00E9 per definire la speciale char;
• Il nome file utilizza eU + 0301;

Qualche suggerimento su come affrontare questo?

Answer 1

Sembra che il file system utilizza la forma decomposta della lettera é (che è la sequenza dei caratteri e e ´ o \u0065 e \u0301), mentre il generatore di codice utilizza la forma composta da é (che è \u00e9). Questo è un problema tipico del file system HFS + di Apple, che utilizza sempre la forma scomposta.

Cosa si può fare per risolvere questo problema è modificare l'applicazione per decomporre il nome della classe che appare nel file sorgente generato con java.text.Normalizer:

Normalizer.normalize(classname, Normalizer.Form.NFD)

Vedi anche: http://en.wikipedia.org/wiki/Unicode_equivalence