sonderzeichenproblem beim übergang von linux zu windows

[ramin]

Hallo!

ich prgrammiere mein Programm unter Linux und komiliere es dann unter windows. jetzt tritt dabei ein sonderzeichenproblem auf: Ich baue im Quelltext ein SVG, das ich dann dem SVGWidget zuweise. sind sonderzeichen im svg, wird es unter windows nicht geladen - angeblich sei die kodierung fehlerhaft. ich bin nicht sicher woan das liegt nd was ich dagegen tun soll.

danke!

r

[Kratzy974]

Windows Sachen werden meist in Codetable 1252 codiert, unter linux sicherlich utf8. Nun musst du unter Windows auch UTF-8 verwenden. Das musst du entweder irgendwo im System machen (bitte hilf mir einer damit, nicht probiert) Da die QTextCodec::codecForLocale() Informationen verwendet werden, um den aktuellen Codec raus zu bekommen.
Man kann auch im Programm dies entsprechend setzen QTextCodec::setCodecForLocale(), allerdings kann man dann Probleme mit anderer Software bekommen, namentlich lupdate, linguist.

[ramin]

das ist mir jetzt nicht so ganz klar:
mal angenommen, ich schreibe unter Linux im QtCreator ein programm was nichts anderes tut als:

Code: Alles auswählen

 
QFile file("out.txt");
     if (!file.open(QIODevice::WriteOnly | QIODevice::Text))
         return;

     QTextStream out(&file);
     out << "ÄÄÜÜÖÖ " << endl;
file.close();

sobald ich einen knopf drücke. diesen quellcode kopere ich jetzt ins windows, öffne dort mit dem qtcreator den code, kompiliere und schaue mir anschließend die datei an - dann hat die eine kaputte kodierung?
schreibe ich das programm gleich in windows, dann gehts??
??

[Kratzy974]

Ich muss dazu sagen, dass ich mit dem qtcreator noch nicht gearbeitet habe, also nicht weiss, in welche Codierung er die Sourcetexte speichert.
Auf dem Mac ist es tatsächlich so, dass, wenn ich dort in den Sourcecode Umlaute hineinschreibe (entsprechend deinem Beispiel), und dann kompiliere, werden mir die Texte in zB Dialogen falsch angezeigt. Trage ich die unter Windows (halt Codetable 1252) in den Sourcecode ein, so funktioniert der Text auf Win und Mac (Allerdings ist dies auf dem Mac im Sourcecode cryptisch.

Es gibt sicherlich Wege um das zu verhindern, nur soll das zeigen, dass die Codierung der Sourcedateien, und der Interpretation im fertigen Programm von System zu System unterschiedlich sind. Aus dem Grunde musst du deine Systeme aufeinander abstimmen. Oder beobachten, welche Arbeitsreihenfolge zu den wenigsten Problemen führt.

[ramin]

dann bleibt mit ja nur noch die frage zu stellen, die mich als kompletten volldeppen qualifieziert: was tue ich dagegen? unter linux jede einzelne datei mit kate zu öffnen und dann als iso..15 zu speichern hat nicht gebracht - ebenso wie unterwindows für jede datei die kodierung auf utf8 zu setzen...
da muss es doch eine möglichkeit geben?

[Christian81]

Gar nichts - im Quellcode benutzt man normalerweise nur ASCII und fertig. Die Diskussion hatten wir erst letzte Woche ode so...

[ramin]

das war auch das problem.
hauptsächlicht geht aber darum, dass ein bytearray, das einen string zugewiesen bekommt, den in iso1 erhält. in qstring gibt es eine klasse mit beispiel, wie hieraus utf8 gemacht wird.

[Kratzy974]

Christian : Natürlich wird der Code nicht nur in ASCII Gespeichert. Sonst wären einige Sachen nicht möglich. ASCII ist immerhin nur für 127 Zeichen eindeutig definiert, die zweite Tabelle ist recht frei. Und es ist in Sourcecode mehr möglich. Mach mal in VS eine cpp auf, und dann schau mal oben im Datei Menu nach File - Advanced Save Options.

Bei mir brachte unter Windows die Codetabelle 1252 wählen bisher das meiste (Windows / Mac / Linux). Allerdings wäre Utf-8 schlauer, aber ich habe mir noch nicht die Mühe gemacht, alles entsprechend einzustellen (weil ich auch noch nicht genau weiss wie). Allerdings musste ich die Umlaute dann immer unter Windows eingeben.

Grüße,

[Christian81]

Es ist auf alle Fälle wesentlich einfacherer nur ASCII zu benutzen - das es nicht geht habe ich nie behauptet - nur muss man sich dann eben mit den Konsequenzen rumärgern und darf sich nicht wundern wenn es dann doch mal nicht geht weil ein Compiler eben die Kodierung anders sieht.

[Kratzy974]

Christian : ok.

Natürlich ist der kleinste gemeinsame Nenner nutzbar. Ich nutze jedoch den Kommentar in tr() für deutsche Kommentare um den Übersetzern zu helfen. Da sind Umlaute angenehm.
Bei einem anderen Projekt wurde entschieden, dass die Grundsätze (Also in tr()) in Deutsch zu sein haben.
Es gibt also immer Bedingungen, welche dazu führen, dass der kleinste gemeinsame Nenner verlassen wird. So sollte man auch verstehen, warum etwas nicht funktioniert, wenn man vom Minimalweg mal weg ist.

Zu Visual Studio : Der Compiler selbst ist aufgrund der Installation und Eingestellten Region / Sprache auf eine Codetabelle festgesetzt. Der Sourcecode lässt sich jedoch in Unicode 65001 (with signature) speichern und nutzen, wenn man das Project auf Unicode stellt. Jedoch werden keine Zeichen ausserhalb der Compiler Codetabelle nutzbar sein, für Text in den Sourcen (Es gibt entsprechende Warnungen). Später eingeladene Texte haben das Problem natürlich nicht. Es geht alleine um die Sourcecode Interpretation des Compilers.

[Strahlex]

Probiers mit

Code: Alles auswählen

CODECFORTR = UTF-8

in der pro-file. Funktioniert bei mir perfekt, natürlich müssen dann die Quelltextdateien UTF-8 codiert sein.