Erstellen von UTF-8 Dateien in Java von einem runnable Jar
Habe ich ein kleines Java-Projekt, wo ich die Eigenschaften der class-Dateien auf UTF-8 (ich benutze eine Menge von ausländischen Zeichen, die nicht auf der Standard-CP1252).
Das Ziel ist, erstellen Sie eine text-Datei (in Windows) mit einer Liste von Elementen.
Beim ausführen der class-Dateien aus Eclipse (Strg+F11) erstellt er die Datei einwandfrei und öffnen Sie es in einem anderen editor (ich verwende Notepad++) sehe ich die Zeichen, wie ich wollte.
┌──────────────────────────────────────────────────┐
│ Universidade2010 (18/18)│
│ hidden: 0│
├──────────────────────────────────────────────────┤
Aber, wenn ich das Projekt exportieren (in Eclipse) als runnable Jar und führen Sie es mit 'javaw -jar project.jar' die neue Datei erstellt, ein Chaos von Fragezeichen
????????????????????????????????????????????????????
? Universidade2010 (19/19)?
? hidden: 0?
????????????????????????????????????????????????????
Ich habe befolgt einige Tipps, wie man UTF-8 verwenden (die scheint kaputt zu sein, die standardmäßig auf Java) zu versuchen, dies zu korrigieren, so jetzt bin ich mit
Writer w = new OutputStreamWriter(fos, "UTF-8");
und das schreiben der BOM-header in die Datei wie in diesem Frage schon beantwortet aber noch ohne Glück, beim exportieren in ein Jar -
Bin ich etwas fehlt Eigenschaft oder command-line-Befehl ein, damit Java weiß, ich will UTF-8-Dateien standardmäßig ?
das problem ist nicht auf das erstellen der Datei selbst , weil bei der Bearbeitung der Datei ausgegeben wird korrekt (mit dem unicode-Zeichen)
Die Klasse, die die Datei erstellt ist (und nach dem Vorschlag der Verwendung des Charset-Klasse) wie folgt aus:
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();
}
}
}
}
Und alle Zeichen verwendet werden, sind so definiert:
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'; /* ┘ */
Bleibt das problem bestehen, wenn die Ausgabe in eine Datei einfach, indem Sie das Projekt auf Basis von Eclipse, die Datei kommt heraus, perfekt, aber nach der Implementierung des Projektes in eine Jar-und es läuft der ausgegebenen Datei ist die Formatierung zerstört (ich habe herausgefunden, dass Sie ersetzt werden durch '?' char)
Ich bin gekommen, zu denken, dies ist nicht ein problem mit dem code ein problem aus der Bereitstellung von es in eine Jar-Datei, ich denke, Eclipse kompilieren der Quelldateien zu CP1252 oder so etwas, sondern sogar ersetzen alle unicode-Zeichen durch Ihren code-Konstanten nicht helfen
- Was verwenden Sie, um zu sehen, die Fragezeichen? Ein Dienstprogramm, das verwende ich sehr viel unter Linux ist
od -c file-name
die dumps die Datei byte-by-byte. Sie sollten in der Lage sein zu sehen, ob die erzeugte Datei in eclipse, und von der Befehl-Linie ist die gleiche. Ich vermute, Sie sind die gleichen, und in Ihrem editor ist immer in den Weg. - Ich bin mit dem Notepad++ öffnen 2 erzeugten text-files (die aus dem jar-Paket und das aus dem Projekt in eclipse), wenn ich die Dateien öffnen mit notepad++ die status bar zeigt, dass er ein "UNIX UTF-8" Datei für beide, aber die Dateien sehen anders aus, obwohl es der gleiche code ausgeführt wird, nur verpackt als runnable Jar
- Die Analyse der beiden Dateien mit einem hex-editor die Datei erstellt durch das Glas scheint, ersetzt alle nicht-ANSI-Zeichen mit 0x3F (Fragezeichen), aber die Stückliste code ist erfolgreich geschrieben wird, am Anfang.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Historische Gründe, Java-Codierung standardmäßig auf der system-Codierung (etwas, das mehr Sinn wieder auf Windows 95). Dieses Verhalten ist nicht wahrscheinlich, sich zu ändern. Meines Wissens, gibt es nicht irgendetwas gebrochen über Java encoder-Implementierung.
Der obige code sendet den folgenden text vorangestellt, mit einem byte order mark:
┌──┐
├──┤
Windows-apps wie Notepad ableiten kann, die Codierung aus der Stückliste und entschlüsseln Sie die Datei korrekt.
Ohne code ist es nicht möglich, zu erkennen Fehler.
Nein - es gibt keine solche Einstellung. Einige vermuten Einstellung
file.encoding
auf der Kommandozeile, aber das ist ein schlechte Idee.Schrieb ich einen umfassenden blog-post zu dem Thema hier.
Dies ist eine überarbeitung von dein code:
Meisten von Ihnen gewünschte Funktionalität bereits in
PrintWriter
. Beachten Sie, dass sollten Sie bieten einen Mechanismus, um zu überprüfen, für die zugrunde liegenden Fehler, und schließen Sie den stream (oder riskieren Sie undicht file-handles).\u250c
etc) für das schreiben von down diese Sonderzeichen im Java-Quellcode-Datei. Dies beseitigt eine mögliche Quelle von Problemen: Verschiedene text-Editoren möglicherweise speichern Sie die Java-Quelldatei in verschiedenen Codierungen.