CreateDirUTF8 funktioniert nicht mit "ä"...[gelöst]

[corpsman]

Guten morgen allerseits,

Ich habe also durchgeboxt, dass wir im Geschäft Lazarus einsetzen.

Und nun ist auch tatsächlich das erste Programm fertig geworden, welches wir unseren Kunden antun wollen.

Das Problem ist nun, dass wir einen Testkunden haben der als Benutzernamen unter Windows folgenden hat : "Ing Büro xyz"

Also einen Benutzernamen mit Leerzeichen und ü.

Mittels

Code: Alles auswählen

s := IncludeTrailingPathDelimiter(systoutf8(GetAppConfigDir(false)));

hohle ich mir das Verzeichniss, in welchem ich Meine UserDaten abspeichern will. Wie der Titel schon andeutet klappt das speichern natürlich nicht (das Verzeichniss wird korrekt ermittelt).

Erst dachte ich, dass ich das ü oder die Leerzeichen falsch konvertiere, aber wie mein Sample (Anhang) zeigt, liegt es daran nicht. Wenn ich Verzeichnisse mit Leerzeichen oder umlauten in das Edit1 eingebe kann ich diese sehr wohl speichern, so lange der Pfad nicht in das Home Verzeichnis des Users zeigt.

Um das ganze besser nachstellen zu können, habe ich mir auf meinem Windows XP SP3 Pc ebenfalls so einen User angelegt (sogar als Admin). Und wollte von da aus den Fehler nachstellen. Doch leider kann ich unter diesem Nutzer nicht mal Lazarus starten, es hängt sich quasi komplett auf.

Nun wäre es schön, wenn ich alle unsere Kunden zwingen könnte sich vernünftige Benutzernamen aus zu denken, ..

Egal, eine andere Lösung für das Problem muss her. Hat einer von euch eine Idee, wie ich auf das Verzeichniss zugreifen kann ?

Gruß

Corpsman

[hde]

Ich verstehe nicht genau, was du creieren willst. Mit Umlauten und Leerschritten funktioniert deine Grundfunktion sowhol unter WIN XP SP3 als auch unter Win7-64bit.
Kann es sein, dass du ein mehrstufiges Dir erzeugen willst? Es geht immer nur stufenweise.
hde

[Heinrich Wolf]

Kann es sein, dass du ein mehrstufiges Dir erzeugen willst? Es geht immer nur stufenweise.
hde

Mehrstufig geht mit ForceDirectories(). Leider steht in der Hilfe nicht, ob UTF8 oder ANSI übergeben werden muss.

[Ally]

IncludeTrailingPathDelimiter kann kein UTF8.
Ich habe mir folgendes gebastelt.

Code: Alles auswählen

function IncludeTrailingPathDelimiterUTF8(Pfad: string): string;
begin
  if UTF8Copy(Pfad, UTF8Length(Pfad), 1) <> DirectorySeparator then
    Result := Pfad + DirectorySeparator
  else
    Result := Pfad;
end;

[hde]

Mag sein, müsste ich ausprobieren, aber mit "CreateDirUTF8" wie es corpsman versucht gehts nur stufenweise, egal ob Umlaute oder nicht.
hde

[hde]

sry. Ally war schneller, aber nochmals:so wie es corpsman programmiert hat funktioniert es bei mir auch bei einem User (hab dafür "Bürger" angelegt) mit Umlauten. jedoch nur stufenweise.
hde

[corpsman]

Das ist ja der Wahnsinn, das IncludeTrailingPathDelimiter nicht utf8 fähig ist, gut zu wissen, thx.

Ich probiere das morgen gleich mal aus.

Ebenso mit ForceDirectories, das kannte ich so noch nicht *g* würde meinen Code ein wenig kürzen.

Wie gesagt, so lange mein User Name nicht "Ing Büro xyz" int und das Zielverzeichniss nicht in dessen Home liegt, funktioniert mein Sample ja auch wunderbar. Damit ich den Fehler auf meinem System überhaupt bekomme muss ich den Benutzer wechseln, ärgerlich nur, dass Lazarus auf diesem Nutzer nicht startet..

Kann den 2. Teil jemand bestätigen ?, dann würde ich nen Bug Report dazu erstellen ( also nen User mit ä und leerzeichen im namen erstellen und lazarus starten )

Gruß

Corpsman

[hde]

nein, kannich nicht bestätigen, Dein Prog läuft auch unter User mit Ü und Lazarus offenbar auch

[Socke]

IncludeTrailingPathDelimiter kann kein UTF8.

Das ist ja der Wahnsinn, das IncludeTrailingPathDelimiter nicht utf8 fähig ist, gut zu wissen, thx.

Die gängigsten Pfadtrenner sind der Schrägstrich / und der umgekehrte Schrägstrich \ mit den ASCII Werten 47 beziehungsweise 92. Nun möge mir der/die geneigte Schreiber[in] bitte erklären, wie dies nicht im UTF-8-Wertebereich, der mit ASCII identisch ist, liegen kann...

[mschnell]

Das ist ja der Wahnsinn, das IncludeTrailingPathDelimiter nicht utf8 fähig ist, gut zu wissen, thx.

Ich sag dazu jetzt nix und warte lieber weiter auf die Lazarus-Version, die defaultmäßig (wie Delphi und mse) mit 16 Bit Strings arbeitet.

-Michael

[theo]

IncludeTrailingPathDelimiter kann kein UTF8.

Quatsch.

[theo]

Ich sag dazu jetzt nix und warte lieber weiter auf die Lazarus-Version, die defaultmäßig (wie Delphi und mse) mit 16 Bit Strings arbeitet.

Du sagst eben doch was, und beweist einmal mehr, dass du keine Ahnung davon hast.

[corpsman]

So ich konnte das Problem nun endlich finden und "Lösen".

Es sieht so aus, als würde der String Falsch interpretiert, nachdem ich ihn aber "Byte" weise wegkopiert und dann wieder zurückkopieren lies hat es funktioniert.

Code: Alles auswählen

 
  WorkPath := systoutf8(IncludeTrailingPathDelimiter(GetAppConfigDir(false))); 
  setlength(s, length(WorkPath));
  For i := 1 To length(WorkPath) Do Begin
    s[i] := WorkPath[i];
  End;
  WorkPath := '';
  WorkPath := s;
 

@theo
Auch wenn es OT ist, ist da wirklich was dran dass Lazarus 16 Bit Strings ( UTF16 ) kriegen soll ? Ich lese das in letzter Zeit immer öfter.
Muss zugeben finde das UTF8 sehr gut ( vor allem, weil mein Linux das auch hat ), die Umgewöhnung nach dem Umstieg von Windoof war auch nicht ohne. Würde das ganze ungern noch mal machen müssen.

[Socke]

Auch wenn es OT ist, ist da wirklich was dran dass Lazarus 16 Bit Strings ( UTF16 ) kriegen soll ? Ich lese das in letzter Zeit immer öfter.
Muss zugeben finde das UTF8 sehr gut ( vor allem, weil mein Linux das auch hat ), die Umgewöhnung nach dem Umstieg von Windoof war auch nicht ohne. Würde das ganze ungern noch mal machen müssen.

Was soll ein 16 Bit String denn genau sein? Zur Auswahl stehen UTF-16 Litle Endian, UTF-16 Big Endian, UTF-16 Native Endian und UCS-2. Alleine UCS-2 bringt nicht die Probleme der Mehrteiligen Zeichen mit sich, da hier nur die Basic Multilingual Plane verwendet wird. bei allen UTF-16 Varianten hat man die gleichen Probleme wie bei UTF-8: einige Zeichen müssen aus mehreren Kodierungseinheiten (bei UTF-8 Bytes, bei UTF-16 Words) zusammengesetzt werden. Der Unterschied ist: die BMP umfasst die meisten oder sogar fast alle gebräuchlichen Zeichen. Somit treten die Probleme nur in geringerem Umfang auf (also nur bei Programmen, die ein bestimmtes Publikum haben). Mit sauberer Programmierarbeit hat das meiner Meinung nach wenig zu tun.

Da sich die LCL durchgehend für UTF-8 entschieden hat (Ausnahme: das veraltete GTK wählt seinen eigenen Zeichensatz), wäre es doppelte Arbeit, das ganze jetzt auf eine andere Kodierung umzusetzen. Falls der Compiler jedoch sauberes Duch-die-Gegend-kodieren in UTF unterstützt, hätte sich das ganz schnell unperformant erledigt (wobei man hier in der Regel auf die Geschwindigkeit verzichten kann).

Sollte sich die RTL ebenfalls für einen Zeichensatz festlegen und alle Betriebssysteme dahingehend abstrahieren (ausgenommen wären die direkten ABI/API-Aufrufe), wäre zumindest die Unterstützung für alle Unicode-unfähigen Betriebssysteme (unter anderem: Win95, Win98, WinME; mit Einschränkungen WinCE sowie WinNT bis vor Win2000; ab Win2000 wird auch UTF-16 verwendet) verloren. Andernfalls gibt es immer wieder Probleme mit dem Mapping von Unicode-Zeichen auf ISO-8859-Zeichen.

[theo]

So ich konnte das Problem nun endlich finden und "Lösen".

Es sieht so aus, als würde der String Falsch interpretiert, nachdem ich ihn aber "Byte" weise wegkopiert und dann wieder zurückkopieren lies hat es funktioniert.

Macht mMn extrem wenig Sinn, dein Code. Was soll das bewirken? Wie ist WorkPath deklariert?

Zur anderen Frage: Siehe Socke's Antwort. Das Problem liegt erstmal in der Unicode-untauglichen RTL, nicht in der LCL.