Bestes Text file encoding..?

[sirbender]

Hi,

ich entwickle unter Windows und Linux und stelle den Code in ein CVS. Manchmal verhaut es einige Zeichen weil scheinbar Eclipse unter verschiedenen OS ein anderes Text encoding nutzt.

Welches Text encoding sollte ich den einstellen in Eclipse fuer beide OS? Muss ich irgendwas mit dem CVS beachten?

 

[Wildcard]

Den Workspace in den Preferences auf UTF-8 stellen

 

[sirbender]

Den Workspace in den Preferences auf UTF-8 stellen

Ich glaube UTF-8 deckt nicht alle Zeichen ab die ich darstellen will. Bsp.:

*.·*·.

Deswegen frage ich ja. Unter Linux nutze ich naemlich UTF-8 und da habe ich dann immer einige Zeichen die als Boxen angezeigt werden (verwendeter Font kennt das Zeichen nicht?)

 

[Wildcard]

UTF-8 deckt so ziemlich alles ab. Dein Problem ist, dass du die Zeichen im falschen Encoding (cp1252 deutsches Windows Encoding) committed hast. Korrigiere alles in UTF-8, check es ein, danach passt es dann.

 

[sirbender]

UTF-8 deckt so ziemlich alles ab. Dein Problem ist, dass du die Zeichen im falschen Encoding (cp1252 deutsches Windows Encoding) committed hast. Korrigiere alles in UTF-8, check es ein, danach passt es dann.

Aber wenn ich in Windows umstelle werden wie gesagt die Zeichen zerhackt. Und Linux hat UTF-8 und zeigt beim auschecken die Zeichen als Boxen an. Wie verhindere ich beim Umstellen auf UTF-8 dass die Zeichen 'verlorengehen'?

 

[Wildcard]

Geht nicht. Konvertieren müsstest du vorher. Linux bietet dazu tools an. Wenn es nicht allzu viele Zeichen sind, würde ich sie aber lieber händisch korrigieren.

 

[Der Müde Joe]

Ich entweickle in Ubuntu, 2 meiner Mitarbeiter in Xp und Vista. Alle haben UTF-8 eingestellt. Null problemo..(frei nach Alf)

EDIT:
Früher war alle Win und in CP-1256 (?), wurde mal alles auf UTF-8 konvertiert und aufs CVS gehauen.

 

[sirbender]

Ok danke...hab ich jetzt gemacht

Seltsam dass UTF-8 nicht per Default eingestellt ist fuer alle OS.

 

[Wildcard]

Sehe ich genauso. UTF-8 sollte in jedem Fall default sein, leider sieht das Platform Team das anderes und verwendet das Default Encoding des OS.

 

[Guybrush Threepwood]

Aufpassen sollte man nur beim Starten des Programms aus Eclipse heraus. Da verwendet nämlich Ganymed die Workspace-Einstellung und nicht die Betriebssystem-Einstellung. Das sollte man dann unter Run configurations ändern. Ansonsten kann es beim Einlesen von z. B Textdateien unter Windows mit dem FileReader zu Porblemen kommen. Ein weiteres Problem: Wenn man mit NSIS über das NSIS-Eclipse-Plugin entwickelt, dann sollten die NSIS-Source-Codes selektiv auf CP1252 umgestellt werden, da sonst die Texte in den Installer komische Zeichen enthalten.

Ansonsten habe aber auch ich und alle Mitarbeiter auf UTF-8 umgestellt und es funktioniert top.

 

[bygones]

Sehe ich genauso. UTF-8 sollte in jedem Fall default sein, leider sieht das Platform Team das anderes und verwendet das Default Encoding des OS.

da habt ihr ja n paar leutchen angeheuert

 

[Wildcard]

da habt ihr ja n paar leutchen angeheuert

Wer ist wir?

Aufpassen sollte man nur beim Starten des Programms aus Eclipse heraus. Da verwendet nämlich Ganymed die Workspace-Einstellung und nicht die Betriebssystem-Einstellung

Du meinst: Eclipse verwendet beim einlesen das Betriebssystem Setting und eben nicht das Workspace Setting?
Das macht ja auch Sinn, beim einlesen soll sich der Quellcode ums Encoding kümmern und nicht die IDE. Das soll später ja auch laufen...

 

[Ark]

Wer ist wir?

Da hat wohl jemand gedacht, du wärst einer der Übeltäter. Aber ich muss zugeben, dass ich deinen Beitrag auch erst so gelesen, als wärst du "einer von ihnen", und mich deshalb voll gewundert hatte, bis ich merkte, dass dein Beitrag diesen Schluss nicht zulässt.

Fast zum Thema: Ich denke, es sollte nur noch zwei sinnvoll einzusetzende Zeichensätze geben: UTF-8 (vorrangig europäischer Raum) und UTF-16 BE (asiatischer Raum).

Ark

 

[Wildcard]

Fast zum Thema: Ich denke, es sollte nur noch zwei sinnvoll einzusetzende Zeichensätze geben: UTF-8 (vorrangig europäischer Raum) und UTF-16 BE (asiatischer Raum).

Lässt sich doch auch alles in UTF-8 abbilden. Variable Länge, bis zu 4 Bit (also UTF-32)

 

[sliwalker]

Ok danke...hab ich jetzt gemacht

Seltsam dass UTF-8 nicht per Default eingestellt ist fuer alle OS.

Ne seltsam ist das nicht, wenn man das hier kennt:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) - Joel on Software

 

[Ark]

Lässt sich doch auch alles in UTF-8 abbilden. Variable Länge, bis zu 4 Bit (also UTF-32)

Du meinst bestimmt 4 Bytes, oder? Natürlich könnte auch alles mit UTF-8 gemacht werden, aber dann bräuchte man für (übliche) CJK-Texte immerhin mindestens 3 statt 2 Bytes pro Zeichen. (Ja, okay, das ist jetzt nicht der Hammer ...)

Ark

 

[sirbender]

CJK texte?

 

[Ark]

Steht sogar in der Wikipedia: CJK ? Wikipedia

Ark

 

[Wildcard]

Du meinst bestimmt 4 Bytes, oder? Natürlich könnte auch alles mit UTF-8 gemacht werden, aber dann bräuchte man für (übliche) CJK-Texte immerhin mindestens 3 statt 2 Bytes pro Zeichen. (Ja, okay, das ist jetzt nicht der Hammer ...)

4 byte, natürlich... typo
Klar, UTF-8 braucht manchmal ein byte mehr als ein spezialisierter Charset, aber muss man heute wirklich immer noch um jedes byte kämpfen?

 

[sirbender]

hat das irgendeinen Effekt auf das compilierte Classfile welches Encoding ich nutze? Nein, oder?

 

[Wildcard]

Nein, nur auf das Java File und der Java Compiler muss wissen in welchem Encoding die Java Datei ist (passiert bei Eclipse automatischt).

 

[Guybrush Threepwood]

Wer ist wir?

Du meinst: Eclipse verwendet beim einlesen das Betriebssystem Setting und eben nicht das Workspace Setting?
Das macht ja auch Sinn, beim einlesen soll sich der Quellcode ums Encoding kümmern und nicht die IDE. Das soll später ja auch laufen...

Naja, das widerspricht aber der Java API vom FileReader:

Convenience class for reading character files. The constructors of this class assume that the default character encoding and the default byte-buffer size are appropriate.

Das verstehe ich so, dass das Programm das Encoding des Betriebssystems verwenden soll, und nicht die Workspace-Einstellung. Auf Windows bedeutet das eben, dass beim Einlesen von Text-Dateien automatisch CP1252 angenommen wird. Ist auch praktisch in jedem Javabuch so beschrieben. Ich finde, Eclipse hält sich da seit Ganymed (davor war es anders) nicht an den vorgesehenen Standard. Es hat mich viel Zeit gekostet, nach der Umstellung auf Ganymed herauszufinden, woher diverse Probleme kommen, wo doch die Programme mit Europa problemlos funktionierten.

 

[sliwalker]

Hmm,

ich weiß nicht ob ihr gerade von zwei verschiedenen Dingen sprecht.
Wildcard bezieht sich glaube ich auf das Encoding der Java-Quelldatei und Du sprichst vom FileReader.
Stimmt das so?

Der FileReader nimmt das default OS-Encoding, ganz gleich was in der IDE eingestellt ist, weil die IDE das Encoding nur für die Source-Files an sich verwendet. Aber natürlich kannst Du dem reader auch sagen, dass er ein anderes Encoding nehmen soll.

greetz
SLi

 

[maki]

hat das irgendeinen Effekt auf das compilierte Classfile welches Encoding ich nutze? Nein, oder?

Klar, Sonderzeichen etc.

Am besten hat man gar keine Sonderzeichen in Java Quelldateien.

 

[Wildcard]

Klar, Sonderzeichen etc.

Am besten hat man gar keine Sonderzeichen in Java Quelldateien.

???:L
Im class File spielt es keine Rolle, darum kümmert sich der Compiler. Wichtig ist nur, das der Compiler gesagt bekommt in welchem Encoding die sourcen sind.

 

[Wildcard]

Naja, das widerspricht aber der Java API vom FileReader:

Das verstehe ich so, dass das Programm das Encoding des Betriebssystems verwenden soll, und nicht die Workspace-Einstellung. Auf Windows bedeutet das eben, dass beim Einlesen von Text-Dateien automatisch CP1252 angenommen wird. Ist auch praktisch in jedem Javabuch so beschrieben. Ich finde, Eclipse hält sich da seit Ganymed (davor war es anders) nicht an den vorgesehenen Standard. Es hat mich viel Zeit gekostet, nach der Umstellung auf Ganymed herauszufinden, woher diverse Probleme kommen, wo doch die Programme mit Europa problemlos funktionierten.

Ich habe es gerade mal selbst getestet, weil mir die Aussage spanisch vorkommt, und du liegst daneben. Nichts dergleichen passiert.

 

[Guybrush Threepwood]

Ich habe es gerade mal selbst getestet, weil mir die Aussage spanisch vorkommt, und du liegst daneben. Nichts dergleichen passiert.

Ok, noch einmal konkret (und ich bin mir sicher, dass es stimmt): Wenn in der Workspace ein Projekt auf UTF-8 steht, dann werden seit Ganymed automatisch bei per FileReader unter Windows eingelesenen Textdateien auch UTF-8-Kodierung zugrunde gelegt. Erst wenn man unter Run Configurations -> Common -> Console Encoding auf Cp1252 gestellt wird, dann wird das Standard Windows Encoding verwendet.

Beispiel: Projekt auf UTF-8, Console Encoding "Default - inherited (UTF-8)"

Das ist ein Text mit den Umlauten � � � � � � �.

Gleiches Programm, nun mit Console Ecoding auf Cp1252 :

Das ist ein Text mit den Umlauten ä ü ö Ä Ü Ö ß.

Und hier das Progrämmchen:

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;

public class ReaderTest {

	public static void main(String[] args) {
		new ReaderTest();

	}

	public ReaderTest() {
		String content = null;

		FileReader reader = null;

		try {
			File file = new File("c:/temp/test.txt");
			reader = new FileReader(file);

			long fileLength = file.length();

			char[] arr = new char[(new Long(fileLength)).intValue()];
			int readedElements = reader.read(arr);
			if (-1 != readedElements) {
				content = new String(arr);
			}

		} catch (FileNotFoundException fnfex) {
			System.out.println(fnfex.getMessage());
		} catch (IOException ioex) {
			System.out.println(ioex.getMessage());
		} finally {
			if (null != reader) {
				try {
					reader.close();
				} catch (IOException ioex) {
					System.out.println(ioex.getMessage());
				}
			}
		}

		System.out.println(content);
	}
}

P.S.: Das ist nicht nur bei der Ausgabe in der Console so, sondern auch bei aus Textdateien eingelesenen Labels in GUIs und der Debugger zeigt es auch. Bei Europa war das nicht so.

 

[sliwalker]

Hoi,

ich muss Dir widersprechen.
Nimm mal diesen Code:

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
 
public class ReaderTest {
 
    public static void main(String[] args) {
        new ReaderTest();
 
    }
 
    public ReaderTest() {
        String content = null;
 
        FileReader reader = null;
 
        try {
            File file = new File("c:/test/test.txt");
            reader = new FileReader(file);
            
            System.out.println(reader.getEncoding());
            
            long fileLength = file.length();
 
            char[] arr = new char[(new Long(fileLength)).intValue()];
            int readedElements = reader.read(arr);
            if (-1 != readedElements) {
                content = new String(arr);
            }
 
        } catch (FileNotFoundException fnfex) {
            System.out.println(fnfex.getMessage());
        } catch (IOException ioex) {
            System.out.println(ioex.getMessage());
        } finally {
            if (null != reader) {
                try {
                    reader.close();
                } catch (IOException ioex) {
                    System.out.println(ioex.getMessage());
                }
            }
        }
 
        System.out.println(content);
    }
}

Du erhälst beides mal Cp1252.
Der reader verändert sich nicht, jedoch die Konsole. Und wenn Du ein Cp1252 Encoding einliest und es als UTF-8 interpretierst, kommt Murke raus.
Meinen Link von oben gelesen?

greetz
SLi

 

[Wildcard]

Du erhälst beides mal Cp1252.
Der reader verändert sich nicht, jedoch die Konsole.

Eben. Die Konsole ist etwas Eclipse spezifisches und das sich die per Default an den Workspace anpasst ist sowohl legitim, als auch sinnvoll.

 

[Guybrush Threepwood]

???:L

Ich habe Deinen Code genommen und die Codezeile "System.out.println(reader.getEncoding());" eingefügt. Wenn ich unter Run Configurations das Default Ecoding (UTF-8) eingestellt habe:

UTF8
Das ist ein Text mit den Umlauten � � � � � � �.

Wenn ich Run Configuration auf Cp1252 stelle, oder das Encoding der Quelltextdatei auf CP1252 stelle und bei Run Configuration auf Default klicke:

Cp1252
Das ist ein Text mit den Umlauten ä ü ö Ä Ü Ö ß.

Habe ich jetzt einen Knoten im Hirn oder stimmt was mit meinem Rechner nicht? Der Reader verändert aufgrund der Run Configuration sein Encoding.
???:L

 

[Wildcard]

Der Reader verändert aufgrund der Run Configuration sein Encoding.
???:L

Ist ein Property. file.encoding

 

[Guybrush Threepwood]

Ist ein Property. file.encoding

... dann überschreibt Eclipse also beim Start eines Programms das System property, indem es die VM mit "-Dfile.encoding=..." startet?

 

[sliwalker]

Also bei mir nicht.
Wenn ich das Beispiel mit zwei verschiedenen Console Encodings starte, kommt bei mir immer die gleiche Ausgabe.
Der Reader hat immer das Encoding des OS(bei mir). Keine Ahnung warum das bei Dir anders ist.
Aber lange Rede kurzer Sinn, mit folgendem Code kannst Du schließlich überprüfen, was in den Properties steht.

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
 
public class ReaderTest {
 
    public static void main(String[] args) {
        new ReaderTest();
 
    }
 
    public ReaderTest() {
        String content = null;
 
        FileReader reader = null;
 
        try {
            File file = new File("c:/test/test.txt");
            reader = new FileReader(file);
            
            System.out.println("ReaderEcoding: " + reader.getEncoding());
            System.out.println("Property: " + System.getProperty("file.encoding"));
            
            long fileLength = file.length();
 
            char[] arr = new char[(new Long(fileLength)).intValue()];
            int readedElements = reader.read(arr);
            if (-1 != readedElements) {
                content = new String(arr);
            }
 
        } catch (FileNotFoundException fnfex) {
            System.out.println(fnfex.getMessage());
        } catch (IOException ioex) {
            System.out.println(ioex.getMessage());
        } finally {
            if (null != reader) {
                try {
                    reader.close();
                } catch (IOException ioex) {
                    System.out.println(ioex.getMessage());
                }
            }
        }
 
        System.out.println(content);
    }
}

 

[Spacerat]

Habe ich jetzt einen Knoten im Hirn oder stimmt was mit meinem Rechner nicht? Der Reader verändert aufgrund der Run Configuration sein Encoding.

Ähh... "Knoten im Hirn", um es mal mit deinen Worten zu sagen (Wohl zu viel "Grog" gehabt, wenn du verstehst was isch meine ). Eclipse verwendet die Einstellungen nur zum Lesen der Quelltexte und für die Ausgabe in die Konsole. Für das Lesen innerhalb von FileReader ist die System-Property "file.encoding" zuständig. Und die ändert sich durch die Einstellungen in Eclipse nicht.
@Edit: Vieeel zu lagsaaam...

 

[sliwalker]

Genau.
Dann ist ja alles klar.
Prost...

 

[Guybrush Threepwood]

Ähh... "Knoten im Hirn", um es mal mit deinen Worten zu sagen (Wohl zu viel "Grog" gehabt, wenn du verstehst was isch meine ). Eclipse verwendet die Einstellungen nur zum Lesen der Quelltexte und für die Ausgabe in die Konsole. Für das Lesen innerhalb von FileReader ist die System-Property "file.encoding" zuständig. Und die ändert sich durch die Einstellungen in Eclipse nicht.

Da soll mich doch ein Piranhapudel ...

Bei mir unter Eclipse Ganymed ändert sich

System.out.println(System.getProperty("file.encoding").toString());

immer gemäß der Kodierung der Workspace. Bei Eclipse Europa war das nicht so. Das Verhalten ist neu ab Version 3.4.0. Die Einstellung betrifft also *nicht* nur das Encoding der Quelltext-Dateien und die Ausgabe auf der Console, sondern das "file.encoding" und möglicherweise auch andere Properties ändern sich dadurch. Korrigieren lässt es sich - wie gesagt - wenn man unter Run Configurations -> Common -> Console Encoding das Enncoding umstellt.

Das tritt bei mir auf Windows unter XP und Vista auf. Auf anderen Systemen habe ich es nicht probiert.

Fazit: Beim Einlesen von Dateien immer Encoding fest angeben, anstatt sich auf Voreinstellungen zu verlassen.

 

[sliwalker]

Aha,

gut zu wissen.
Kann ich nicht nachprüfen, nehme es aber mal so hin.
Habe Ganymede 3.3.x auf WinXPSP3.

Das ist ja ein starkes Stück...
Sowas darf aber nicht sein!

greetz
SLi