# Eclipse-Prblem mit Zeichenkodierung Windows-Linux



## tommyboy66 (13. Mrz 2008)

Hallo Leute,

ich arbeite zur Zeit an einem Projekt über CVS. Als IDE wird Eclipse verwendet. Mein Problem ist nun das einige der Mitarbeiter unter Windows arbeiten und das gesamte Projekt mit cp1252 kodiert ist. Unter Windows ist das alles kein Problem, doch ich arbeite mit Linux (Ubuntu 7.10). HIer gibt es diese Kodierung unter Eclipse natürlich nicht. Meine Frage ist nun, ob ich Eclipse irgendwie beibringen kann das Windows cp1252-Format von Windows zu lesen ohne dies vorher umkodieren zu müssen. Nach dem Umkodieren und verändern des Codes muss das Projekt wieder in das Repository eingecheckt werden was den Nachteil hat, dass die Windows-User wieder unlesbare Zeichen in ihrem Code haben.

Bin für jede Hilfe oder jeden Ansatz dankbar.

MfG
tommyboy


----------



## Wildcard (13. Mrz 2008)

Solange du im ASCII Bereich bleibst hast du kein Problem.
Externalisierte Strings in .properties müssen ja sowieso ISO codiert sein.
Aber ich kenne das Problem... sehr ärgerlich. Eine vernünftige Lösung habe ich noch nicht gefunden, ausser den Windowsern beizubringen ihre Projekte als UTF-8 anzulegen.


----------



## tommyboy66 (13. Mrz 2008)

Hallo Wildcard und danke für deine Antwort,

das hatte ich durch meine Recherchen im Internet schon befürchtet das das nicht funktioniert. Leider geht es nicht um reines ASCII sondern größtenteils um Ausgaben auf der GUI (mit Swing) und die Generierung der Javadoc, da diese auf Deutsch geschrieben ist. Windowsusern beibringen auf UTF-8 umzustellen würde ich gut finden    bin aber leider extrem in der Minderheit   Meiner Meinung nach müsste Eclipse diese Codierung gleich als Standard unter beiden Plattformen anbieten dann gäbe es diese Probleme nicht. 
Naja, so weit so gut falls du irgendwann eine Lösung finden solltest immer her damit.

Schöne Nacht noch,
tommyboy


----------



## Wildcard (13. Mrz 2008)

tommyboy66 hat gesagt.:
			
		

> Meiner Meinung nach müsste Eclipse diese Codierung gleich als Standard unter beiden Plattformen anbieten dann gäbe es diese Probleme nicht.


Würde ich auch bevorzugen, aber es wird nunmal das Plattform Encoding verwendet (auch das macht irgendwo sinn).
Tut mir leid das ich nicht mehr helfen kann, aber falls du an anderer Stelle eine zufriedenstellende Lösung findest, mach sie doch bitte auch hier bekannt.
Ansonsten bin ich übrigens absolut gegen deutsche Java-Docs, Umlaute im Quelltext,.. ich meine eine diesbezügliche Diskussion vor kurzem mit byto geführt zu haben  :lol:


----------



## tommyboy66 (13. Mrz 2008)

Wildcard hat gesagt.:
			
		

> Ansonsten bin ich übrigens absolut gegen deutsche Java-Docs, Umlaute im Quelltext,.. ich meine eine diesbezügliche Diskussion vor kurzem mit byto geführt zu haben  :lol:



Bin ich eigentlich auch, aber leider ist das Vorgabe das die Javadoc auf Deutsch sein muss. Wie löst du das Problem mit den Umlauten auf der GUI-Seite? Machst du das alles über diese externalisierten Strings? Macht dieser extra Aufwand  nicht nur Sinn bei Mehrsprachenanwendungen? Ich glaube der Aufwand ist zu groß das jetzt noch umzustellen. So, ich werd jetzt erstmal Windows starten  :?


----------



## Wildcard (14. Mrz 2008)

Strings sollten schon externalisiert sein.
Zum einen hast du damit die Möglichkeit irgendeinen Übersetzer die Properties Datei in die Hand zu drücken um ein Mehrsprachiges Programm zu erhalten, zum anderen gehören Beschriftungen IMO nicht die Programmlogik.
Mit Source -> Externalize Strings ist das doch auch wirklich keine Arbeit mehr, also gibt es eigentlich nichts, was gegen externalisierte Strings spricht.


----------

