Ho un piccolo progetto Java in cui ho impostato le proprietà dei file di classe su UTF-8 (utilizzo un sacco di caratteri stranieri non trovati sul CP1252 predefinito) .Creazione di file UTF-8 in Java da un Jar eseguibile
L'obiettivo è creare un file di testo (in Windows) contenente un elenco di elementi. Quando si esegue il file di classe da Eclipse stesso (premendo Ctrl + F11) crea il file in modo impeccabile e aprendolo in un altro editor (sto usando Notepad ++) Posso vedere i personaggi come volevo.
┌──────────────────────────────────────────────────┐
│ Universidade2010 (18/18)│
│ hidden: 0│
├──────────────────────────────────────────────────┤
Ma, quando ho esportare il progetto (con Eclipse) come Jar eseguibile ed eseguirlo usando 'javaw -jar project.jar' il nuovo file creato è un pasticcio di punti interrogativi
????????????????????????????????????????????????????
? Universidade2010 (19/19)?
? hidden: 0?
????????????????????????????????????????????????????
ho seguito alcuni suggerimenti su come utilizzare UTF-8 (che sembra essere rotto di default su Java) per cercare di correggere questo modo ora sto usando
Writer w = new OutputStreamWriter(fos, "UTF-8");
e scrivendo l'intestazione della distinta base alla file come in questo question already answered ma ancora senza fortuna durante l'esportazione in Jar
Mi mancano alcuni comandi di proprietà o riga di comando, quindi Java sa che voglio creare file UTF-8 per impostazione predefinita?
il problema non è sulla creazione del file stesso, perché mentre in via di sviluppo il file viene emesso correttamente (con i caratteri Unicode)
La classe che crea il file è ora (e seguendo il suggerimento di utilizzando la classe Charset) come questo:
public class Printer {
File f;
FileOutputStream fos;
Writer w;
final byte[] utf8_bom = { (byte) 0xEF, (byte) 0xBB, (byte) 0xBF };
public Printer(String filename){
f = new File(filename);
try {
fos = new FileOutputStream(f);
w = new OutputStreamWriter(fos, Charset.forName("UTF-8"));
fos.write(utf8_bom);
} catch (FileNotFoundException e) {
} catch (IOException e) {
e.printStackTrace();
}
}
public void print(String s) {
if(fos != null){
try {
fos.write(s.getBytes());
fos.flush();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
E tutti i caratteri in uso sono definiti come tali:
private final char pipe = '\u2502'; /* │ */
private final char line = '\u2500'; /* ─ */
private final char pipeleft = '\u251c'; /* ├ */
private final char piperight = '\u2524'; /* ┤ */
private final char cupleft = '\u250c'; /* ┌ */
private final char cupright = '\u2510'; /* ┐ */
private final char cdownleft = '\u2514'; /* └ */
private final char cdownright = '\u2518'; /* ┘ */
Il problema rimane, quando si esegue l'output su un file semplicemente eseguendo il progetto su Eclipse, il file risulta perfetto, ma dopo aver distribuito il progetto in un Jar e averlo eseguito il file emesso ha la formattazione distrutta (ho scoperto che sono sostituiti dal carattere "?")
Sono arrivato a pensare che questo non sia un problema con il codice, è un problema se lo si distribuisce in un file Jar, penso che Eclipse stia compilando i file sorgente per CP1252 o qualcosa del genere, ma anche sostituendo tutti i caratteri unicode per le loro costanti di codice non ha aiutato
Cosa stai usando per vedere i punti interrogativi? Un'utilità che uso molto sotto Linux è 'od -c nome-file' che scarica il file byte per byte. Dovresti essere in grado di vedere se il file generato all'interno di eclipse e dalla riga di comando è lo stesso. Sospetto che siano tutti uguali e il tuo editore stia ostacolando. – Gray
Sto usando il Notepad ++ per aprire i 2 file di testo generati (quello dal pacchetto jar e quello dal progetto in eclissi), quando apro i file notepad ++ indica che è un "UNIX UTF-8" file per entrambi, ma i file sembrano diversi, anche se è lo stesso codice in esecuzione, solo impacchettato come un Jar eseguibile – RuntimeError
Analizzando i due file su un editor esadecimale il file creato dal Jar sembra aver sostituito tutti i non ANSI caratteri con 0x3F (punto interrogativo), ma il codice BOM viene scritto con successo all'inizio. – RuntimeError