2016-08-09 79 views
4

Ich habe ein Problem beim Lesen einer codierten Datei, die zuvor auf meinem eigenen Code geschrieben wurde.Java - Die zuvor erstellte codierte Datei kann nicht korrekt gelesen werden

Der ursprüngliche String korrekt angezeigt wird (einschließlich Akzentzeichen)

Mein Code den String in einer codierten Datei ist folgendes zu speichern:

OutputStreamWriter writer = new OutputStreamWriter(new FileOutputStream(fileName), 
     "ISO-8859-1"); 
writer.write(text); 

Dann las ich, wie dies die Datei, :

InputStream is = getClass.getResourceAsStream(fileName); 

try {   
    BufferedReader br = new BufferedReader(new InputStreamReader(is, "ISO-8859-1")); 
    String line; 
    StringBuilder sb = new StringBuilder(); 

    while((line = br.readLine()) != null) { 
     sb.append(line); 
    } 

    String result = sb.toString(); 
} catch (UnsupportedEncodingException e3) { 
} catch (IOException e) { } 

Der String Ergebnis wird nicht richtig angezeigt. Zum Beispiel fehlen die Akzentzeichen.

Ich habe auch andere Möglichkeiten versucht, wie die Zeichenfolge in Bytes zu kodieren und dann in die Datei diese Bytes zu schreiben. Ich bekomme immer die gleichen Ergebnisse, auch mit anderen ISO-Kodierungen. Irgendeine Idee?

+0

Die API funktioniert einwandfrei, es muss ein anderer Fehler bei der Codierung der Einstellungen Ihres Terminals vorliegen. – Kennet

+0

Sie schreiben eine Datei in das Dateisystem, aber das Lesen geschieht von einer Ressource, auf dem Klassenpfad, möglicherweise in einem Glas oder Krieg gepackt. Das könnte bedeuten, dass Sie über zwei verschiedene Dateien sprechen, vielleicht eine in Ihrem Quellverzeichnis, eine im Build-Verzeichnis oder jar. Und das Lesen könnte sogar auf einer zwischengespeicherten Version sein, vor der geschriebenen. Ändern Sie den Inhalt, um das zu überprüfen. (Und dann 'append (" \ r \ n ")' fehlt, wie die nahen Anrufe sind.) –

+0

Kann nicht reproduzieren. Wenn Sie eine Datei mit der gleichen Codierung lesen, die zum Schreiben verwendet wird, erhalten Sie die gleichen Zeichen - aber ich musste ein explizites 'writer.close()' hinzufügen, um tatsächlich zu schreiben. Was passieren kann: die von Joop vorgeschlagene Datei nicht lesen, eine der Dateien auf einem falsch konfigurierten Terminal anzeigen usw. Aber es ist ** nicht ** ein Java-Konvertierungsproblem. –

Antwort

0

Das Problem ist, dass Ihr String einen anderen Zeichensatz hat, wahrscheinlich UTF-16. Ausgabe der Text, wie Ihr erforderlich charset

Diese Antwort zeigt die syntax

+0

Könnten Sie näher erläutern, was bedeutet, dass Ihr String einen anderen Zeichensatz hat, wahrscheinlich UTF-16 *? Natürlich hat es! Die Java-Spezifikation besagt, dass Strings intern UTF16-codiert sind. Aber das ist völlig unabhängig von der Frage. –

+0

Ist Ihre Frage nicht, warum der Stringbuilder die Zeichen falsch ausgibt? Der Grund dafür ist, dass der stringbuilder.toString UTF-16 ausgibt. – farrellmr

+0

Die direkte Ausgabe von UTF-16 kommt fast nur in GUI-Programmen vor, da Befehlszeilenschnittstellen auf gängigen Systemen (Linux, Windows, Mac) 8-Bit-Zeichen verwenden. Wenn Sie 'System.out.println' verwenden, wird die Zeichenfolge automatisch in der Standardcodierung des Systems codiert. Aber es könnte tatsächlich ein Problem der Codierung in einem Terminalfenster sein. Ihre Antwort ist nicht so schlecht und zeigt, wo das Problem liegen könnte, aber der Grund, den Sie geben, ist nicht der richtige. –

0

Problem gelöst!

Es wurde nicht mit einem Fehler im Code verbunden. Ich arbeite derzeit an einem Team, und das Projekt wurde mit Maven gemacht.

Im Moment baute ich das Projekt, Maven kopiert alle Ressourcen in einen anderen Ordner, die Codierung in UTF-8. Wenn die Ressource im Code abgerufen wurde, war die gelesene Datei nicht die Originaldatei, sondern die UTF-8-codierte Datei, die von Maven generiert wurde.

Entschuldigen Sie, dass ich dieses Detail nicht veröffentlicht habe, ich bin neu mit Maven und ich wusste nicht, dass es diese Art von Problemen verursachen kann.

Vielen Dank für Ihre Antworten!