Quelltext- und Systemcodierung

[Socke]

Hallo,
Das Thema Unicode, UTF8 und so weiter wurde ja schon an anderer Stelle sehr ausführlich diskutiert. Mich würde aber mal interessieren, wir ihr den möglichen Unterschied zwischen Systemcodierung und Quelltextcodierung handhabt.
Die Systemcodierung muss man ja vor allem bei der RTL beachten, da die hier systemabhängig ist.
Die LCL benutzt durchgehen Unicode in UTF8.
Quelltexte können mit Lazarus in den verschiedensten Codierungen abgespeichert werden.
Wie handhabt ihr das, wenn ihr bspw. eine Datei in einem externen Programm öffnen wollt. Sieht das dann so aus, weil Quelltext und LCL mit UTF8 arbeiten?

Code: Alles auswählen

ExecuteProcess(ExeSearch(UTF8ToSys('notepad.exe'),GetEnvironmentVariable(UTF8ToSys('PATH'))),[UTF8ToSys(Edit1.Text)]);
// alles in UTF8 wäre etwas kürzer:
ExecuteProcess(ExeSearch('notepad.exe',GetEnvironmentVariable('PATH')),[Edit1.Text]);

Oder ignoriert ihr das, weil euer Primärziel sowieso wie alles andere auf UTF8 läuft? Oder hofft ihr einfach, dass alles gut läuft?

[theo]

Das kommt halt drauf an, was das Zielprogramm kann.
Wenn es mit UTF-8 umgehen kann, braucht man den Inhalt nicht konvertieren. Vllt. noch eine BOM anhängen, damit es eindeutig ist.
Geht auch mit TCharEncStream. http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;

[Socke]

Es ging mir weniger um das Verarbeiten von Dateien.
Vielmehr war die Frage, wie ihr es handhabt, dass LCL immer mit UTF8 arbeitet, während die RTL die Strings direkt an das OS weiter reicht und somit ggf. einen UTF8-String an ein Windows (welches zumindest bis XP nicht mit UTF8 arbeitet) weiter gibt.

[theo]

Es ging mir weniger um das Verarbeiten von Dateien.
Vielmehr war die Frage, wie ihr es handhabt, dass LCL immer mit UTF8 arbeitet, während die RTL die Strings direkt an das OS weiter reicht und somit ggf. einen UTF8-String an ein Windows (welches zumindest bis XP nicht mit UTF8 arbeitet) weiter gibt.

Naja, bei Filenamen z.B. alles nach und von "Sys" konvertieren.
Im Moment gibt es afaik keine vernünftige Lösung, unter Windows intl. Zeichen in Dateinamen zu adressieren (Kein Unicode in der RTL)

[Socke]

Naja, bei Filenamen z.B. alles nach und von "Sys" konvertieren.
Im Moment gibt es afaik keine vernünftige Lösung, unter Windows intl. Zeichen in Dateinamen zu adressieren (Kein Unicode in der RTL)

Hieße also, Windows als nicht brauchbares OS abstempeln und nur für UTF8-Systeme entwickeln bis es eine brauchbare Lösung gibt? Da Windows XP wahrscheinlich nie UTF8-Unterstützung erhält, werden alle Dateinamen nur in 1-Byte-System-Codierung zur Verfügung stehen. Ich wäre ja dafür, jede API-Funkion (aller Systeme) mit einem UTF8-Wrapper auszustatten

[theo]

Naja, bei Filenamen z.B. alles nach und von "Sys" konvertieren.
Im Moment gibt es afaik keine vernünftige Lösung, unter Windows intl. Zeichen in Dateinamen zu adressieren (Kein Unicode in der RTL)

Hieße also, Windows als nicht brauchbares OS abstempeln und nur für UTF8-Systeme entwickeln bis es eine brauchbare Lösung gibt? Da Windows XP wahrscheinlich nie UTF8-Unterstützung erhält, werden alle Dateinamen nur in 1-Byte-System-Codierung zur Verfügung stehen. Ich wäre ja dafür, jede API-Funkion (aller Systeme) mit einem UTF8-Wrapper auszustatten

UTF8 ist eigentlich nicht der Punkt. Es liesse sich auch mit UTF16 (WideString) bedienen. Der Haken ist nur, dass die RTL für Windows momentan noch nicht die Wide- sondern die Ansi-Funktionen verwendet.
Wenn man also auf deutschem Windows eine Datei mit russischem Namen hat, ist man geliefert. Man kann da als Ausweg nur direkt Win-API-Wide Funktionen verwenden.
Das Problem ist hinlänglich bekannt: z.B: http://bugs.freepascal.org/view.php?id=15642" onclick="window.open(this.href);return false;

[Socke]

Dass das "Problem" bekannt ist und auf absehbare Zeit nicht behoben wird, ist mir schon klar. Meine Frage zielte daher eher auf einen praktikablen Weg ab, wie man dieses Problem umgehen kann bis eine brauchbare Lösung vorhanden ist.

[theo]

Dass das "Problem" bekannt ist und auf absehbare Zeit nicht behoben wird, ist mir schon klar. Meine Frage zielte daher eher auf einen praktikablen Weg ab, wie man dieses Problem umgehen kann bis eine brauchbare Lösung vorhanden ist.

Hier gibt es keine allgemeine Lösung. Du kannst momentan nur versuchen, die Funktionen die du benötigst mit den entsprechenden Winapi-Wide-Funktionen zu ersetzen. Auf Linux gibt es das Problem ja nicht.

Edit: Was teilweise auch geht: Mit kurzen Namen arbeiten: http://www.lazarusforum.de/viewtopic.php?p=37027#p37027" onclick="window.open(this.href);return false;

[Socke]

Hier gibt es keine allgemeine Lösung. Du kannst momentan nur versuchen, die Funktionen die du benötigst mit den entsprechenden Winapi-Wide-Funktionen zu ersetzen. Auf Linux gibt es das Problem ja nicht.

Ich wollte eigentlich möglichst platformunabhängig programmieren...
Damit wären wir dann bei "Write once, compile everywhere, run nowhere" um sarkastisch zu werden

[theo]

Hier gibt es keine allgemeine Lösung. Du kannst momentan nur versuchen, die Funktionen die du benötigst mit den entsprechenden Winapi-Wide-Funktionen zu ersetzen. Auf Linux gibt es das Problem ja nicht.

Ich wollte eigentlich möglichst platformunabhängig programmieren...
Damit wären wir dann bei "Write once, compile everywhere, run nowhere" um sarkastisch zu werden

Habe oben noch ein Edit eingehängt. http://www.lazarusforum.de/viewtopic.php?p=37027#p37027" onclick="window.open(this.href);return false;

[Socke]

Naja, kurze Namen sind auch nicht unbedingt die plattformunabhängig.

[theo]

Naja, kurze Namen sind auch nicht unbedingt die plattformunabhängig.

Wie gesagt, im Moment geht's nur mit Flickwerk.