# Bestes Text file encoding..?



## sirbender (9. Jun 2009)

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 (9. Jun 2009)

Den Workspace in den Preferences auf UTF-8 stellen


----------



## sirbender (9. Jun 2009)

Wildcard hat gesagt.:


> 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 (9. Jun 2009)

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 (9. Jun 2009)

Wildcard hat gesagt.:


> 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 (9. Jun 2009)

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 (9. Jun 2009)

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 (9. Jun 2009)

Ok danke...hab ich jetzt gemacht 

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


----------



## Wildcard (9. Jun 2009)

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 (10. Jun 2009)

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 (10. Jun 2009)

Wildcard hat gesagt.:


> 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 (10. Jun 2009)

deathbyaclown hat gesagt.:


> 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 (10. Jun 2009)

Wildcard hat gesagt.:


> 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 (10. Jun 2009)

Ark hat gesagt.:


> 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 (11. Jun 2009)

sirbender hat gesagt.:


> 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 (11. Jun 2009)

Wildcard hat gesagt.:


> 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 (11. Jun 2009)

CJK texte?


----------



## Ark (11. Jun 2009)

Steht sogar in der Wikipedia: CJK ? Wikipedia 

Ark


----------



## Wildcard (11. Jun 2009)

Ark hat gesagt.:


> 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 (11. Jun 2009)

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


----------



## Wildcard (11. Jun 2009)

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 (11. Jun 2009)

Wildcard hat gesagt.:


> 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 (11. Jun 2009)

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 (11. Jun 2009)

sirbender hat gesagt.:


> 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 (11. Jun 2009)

maki hat gesagt.:


> 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 (11. Jun 2009)

Guybrush Threepwood hat gesagt.:


> 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 (11. Jun 2009)

Wildcard hat gesagt.:


> 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 (11. Jun 2009)

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 (11. Jun 2009)

sliwalker hat gesagt.:


> 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 (11. Jun 2009)

???: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 (11. Jun 2009)

Guybrush Threepwood hat gesagt.:


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


Ist ein Property. file.encoding


----------



## Guybrush Threepwood (11. Jun 2009)

Wildcard hat gesagt.:


> 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 (11. Jun 2009)

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 (11. Jun 2009)

> 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 (11. Jun 2009)

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


----------



## Guybrush Threepwood (12. Jun 2009)

Spacerat hat gesagt.:


> Ä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 (12. Jun 2009)

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


----------

