uppercase und lowercase

[mschnell]

Ja, klar.
Mhh, nur so nebenbei, was war eigentlich genau dein Problem? Vielleicht gehen wir besser mal von was konkretem aus..

Siehe Überschrift und Anfang des Threads: Uppercase und Lowercase funktionieren bei keinem String Typ korrekt mit deutschen Umlauten. In Turbo-Delphi dagegen geht es .

-Michael

[theo]

Uppercase und Lowercase funktionieren bei keinem String Typ korrekt mit deutschen Umlauten. In Turbo-Delphi dagegen geht es .

Wie gesagt bei mir (GTK2) geht das: http://www.lazarusforum.de/viewtopic.php?p=24016#p24016" onclick="window.open(this.href);return false;
Ich glaube immer noch, dass du was falsches einspeist.

[mschnell]

Wie gesagt bei mir (GTK2) geht das: http://www.lazarusforum.de/viewtopic.php?p=24016#p24016" onclick="window.open(this.href);return false;

Wie im Thread beschrieben habe ich bisher nur Windows getestet (damit ich es mit Turbo-Delphi vergleichen kann). Linux kommt dran, wenn hier nichts mehr zu klären ist.

Ich glaube immer noch, dass du was falsches einspeist.

Hast Du den angegeben Code 'mal untere Windows probiert ? Bekommst Du 'was anderes 'raus ?
Wie bereits mehrfch gesagt: Lazarus sollte sich defaultmäßig möglichst wie Delphi verhalten. Ich habe keine Einstellungen verändert.
-Michael

[theo]

Wie bereits mehrfch gesagt: Lazarus sollte sich defaultmäßig möglichst wie Delphi verhalten. Ich habe keine Einstellungen verändert.

Wieso? Wieso sollte sich ein System das Unicode kann verhalten wie ein System das das nicht kann?
Delphi 2009 verhält sich auch nicht wie Delphi 6

[theo]

Hast Du den angegeben Code 'mal untere Windows probiert ? Bekommst Du 'was anderes 'raus ?

Nein, weil der Code imho falsch ist.
Aber ich habe für dich mal Windows gestartet und es ist alles wie erwartet.

Mach mal ein Neues Projekt -> Button drauf -> Click

Dann schreibst du

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var astr:String;
begin
astr:='hähä';
ShcwMessage(inttostr(length(astr)));
Caption:=UTF8UpperCase(astr);
end;

Alles Prima oder? 6 Char lang UTF8, -> Caption wird HÄHÄ

[mschnell]

Wieso sollte sich ein System das Unicode kann verhalten wie ein System das das nicht kann?

Turbo-Delphi und Lazarus können beide Unicode. Schau Dir das Beispiel an: da werden die entsprechenden Unicode-Funktionen aufgerufen. Widestrings sind auch in beiden Systemen vorhanden und die sind immer Unicode (egal ob man es UCS2 oder utf16 nennt).

Delphi 2009 verhält sich auch nicht wie Delphi 6

Was hat denn Delphi 2009 damit zu tun ? So weit in ich noch nicht /und Lazarus auch nicht).

-Michael

[theo]

Turbo-Delphi und Lazarus können beide Unicode. Schau Dir das Beispiel an: da werden die entsprechenden Unicode-Funktionen aufgerufen. Widestrings sind auch in beiden Systemen vorhanden und die sind immer Unicode (egal ob man es UCS2 oder utf16 nennt).

Die VCL konnte es nicht bis zur Version 2009 und der Code Editor wahrsch. auch nicht.

Aber hast du mein Beispiel oben mal ausprobiert?

[mschnell]

Aber ich habe für dich mal Windows gestartet und es ist alles wie erwartet.

Was genau ist wie erwartet ? Kommt bei Dir ein anderes Ergebnis im Memo als ich es oben angegeben habe ? (Ich "erwarte", dass dasselbe 'rauskommt wie bei Turbo-Delphi und das ist bei mir nicht so.)

Dann schreibst du Caption:=UTF8UpperCase(astr);

Ich will nicht mit utf-8 arbeiten, weil utf8-strings nicht sinnvoll funktionieren (Ich sage nicht "falsch", sie funktionieren so wie es definiert ist).
s[3] gibt beim utf-8string s:='ü23' ein '2' (sowohl entsprechend der Definition als auch in meinem Test). Das finde ich völlig blödsinning, ich würde natürlich (wie bei ShortString, ANSIString und WideString) '3' erwarten. (übrigens s[2] ergibt (logischerwise) gar keines der drei im String vorhandenen sichtbaren Zeichen.)

Mit geht es hier hauptsächlich um Widestrings (da tritt dieser Blödsinn nur bei extrem exotischen Zeichen auf. Damitz kann ich leben.) Die restlichen Zeilen im Testprogramm sind habe ich zur weiteren Vertiefung eingebaut. Und wie gesagt, in Meinen Tests klappt WideUppercase für Widestrings in Turbo-Delphi aber nicht in Lazarus. Was ergibt denn Dein Programm in diesem Fall ? Und wenn dasselbe herauskommt wie bei mir (ASCII-Zeichen werden groß, äöü nicht) hältst Du das für richtig ? Wenn ja warum ?

-Michael

[theo]

Du weigerst dich einfach schon den ganzen Tag zu akzeptieren, dass deine Strings im Editor UTF-8 codiert sind.
Du kannst etwas anderes erwarten, du kannst es hassen oder lieben: Es ist einfach so!!!
Wenn man die als solche behandelt, funktioniert alles, auch WideUpperCase.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var us:UTF8String;
ws:WideString;
begin
us:='öäü';
ws:=UTF8Decode(us);
ws:=WideUpperCase(ws);
caption:=UTF8Encode(ws);
end;

[mschnell]

OK, du hast das Problem exakt eingekreist.

Ich habe aus Deinem Code folgenden Test-Code gemacht:

Code: Alles auswählen

procedure TForm1.Button2Click(Sender: TObject);
var
  us1, us2:UTF8String;
  ws1, ws2:WideString;
begin
  us1:='öäü';
  ws1:=UTF8Decode(us1);
  ws2:=WideUpperCase(ws1);
  us2:=UTF8Encode(ws2);
 
  Memo1.Lines.Add('ws1 (' + inttostr(length(ws1)) + '):');
  Memo1.Lines.Add(ws1);
  dump(@ws1[1], 2*length(ws1));
 
  Memo1.Lines.Add('ws2 (' + inttostr(length(ws2)) + '):');
  Memo1.Lines.Add(ws2);
  dump(@ws2[1], 2*length(ws2));
 
  Memo1.Lines.Add(us2);
 
  Memo1.Lines.Add('--------');
 
 
  ws1:='öäü';
  ws2:=WideUpperCase(ws1);
  us2:=UTF8Encode(ws2);
 
  Memo1.Lines.Add('ws1 (' + inttostr(length(ws1)) + '):');
  Memo1.Lines.Add(ws1);
  dump(@ws1[1], 2*length(ws1));
 
  Memo1.Lines.Add('ws2 (' + inttostr(length(ws2)) + '):');
  Memo1.Lines.Add(ws2);
  dump(@ws2[1], 2*length(ws2));
 
  Memo1.Lines.Add(us2);
end;

Ausgabe Lazarus:

Code: Alles auswählen

ws1 (3):
= #246 #0 #228 #0 #252 #0 
= F6 00 E4 00 FC 00 
 
ws2 (3):
= #214 #0 #196 #0 #220 #0 
= D6 00 C4 00 DC 00 
 
ÖÄÜ
--------
ws1 (6):
öäü
= #195 #0 #182 #0 #195 #0 #164 #0 #195 #0 #188 #0 
= C3 00 B6 00 C3 00 A4 00 C3 00 BC 00 
 
ws2 (6):
öäü
= #195 #0 #182 #0 #195 #0 #164 #0 #195 #0 #188 #0 
= C3 00 B6 00 C3 00 A4 00 C3 00 BC 00 
 
öäü

Ausgabe Turbo Delphi

Code: Alles auswählen

ws1 (0):
 
= 
= 
 
ws2 (0):
 
= 
= 
 
 
--------
ws1 (3):
öäü
= #246 #0 #228 #0 #252 #0 
= F6 00 E4 00 FC 00 
 
ws2 (3):
ÖÄÜ
= #214 #0 #196 #0 #220 #0 
= D6 00 C4 00 DC 00 
 
ÖÄÜ

Deine Idee, die String-Konstante mit UTF8Decode zu behandeln scheint also der Schlüssel des Problems zu sein.

Was hat Dich auf die Idee gebracht ? Die Sourcecode-Datei ist jedenfalls nicht als utf-8, sondern als UCS2 abgespeichert (BOM= FFFE). Ich bin deswegen da nicht d'rauf gekommen (und, weil ich eigentlich mit utf8 nichts zu tun haben will, wenn Lazarus intern oder in der OS-API utf8 benutzt, soll es mich gefälligst davon verschonen ! Die ekligen Windows-Handles versteckt es ja netterweise auch vor mir. )

Außerdem braucht TMemo.Lines.Add offensichtlich einen UTF8-String und interpretiert einen Widestring falsch.

Das ist insofern beruhigend, dass offensichtlich in Lazarus also doch mehr funktioniert, als ich befürchtet habe.

Allerdings sehe ich die Notwendigkeit, eine String-Konstante erst durch eine Funktion zu schicken, bevor sie einer Variablen zugeordnet wird als heftiges Manko. Wie Delphi das macht (die String-Konstante automatisch in den richtigen Widestring-Wert zu wandeln) kommt mir da sehr viel logischer/besser/benutzerfreundlicher vor.

Das TMemo.Lines.Add einen Widestring falsch interpretiert halte ich für einen Bug. Wenn die Umwwandlung nicht automatisch richtig passiert sollte es doch eine Variante für Widestring geben.

Warum verlässt Lazarus da den Kompatibilitäts-Pfad ? Wie der Test zeigt ist die Zuweisung Stringonstante->Widestring völlig inkompatibel. Die Variante mit utf8decode läuft nur in Lazarus, die Variante ohne utf8decode läuft nur in Turbo-Delphi.

-Michael

[theo]

Was hat Dich auf die Idee gebracht ? Die Sourcecode-Datei ist jedenfalls nicht als utf-8, sondern als UCS2 abgespeichert (BOM= FFFE).

Weil die LCL nun mal mit UTF-8 funktioniert. Synedit (Der IDE-Editor) ist auch Teil der LCL, ergo ist das was da "drinsteht" UTF-8.

Allerdings sehe ich die Notwendigkeit, eine String-Konstante erst durch eine Funktion zu schicken, bevor sie einer Variablen zugeordnet wird als hefitges Mankio.

Das muss man nicht. Behandle sie einfach als UTF-8 und gut ist. Dazu kannst du auch die Klasse verwenden, die ich im anderen Thread gepostet habe.

Wie Delphi das macht (die String-Konstante automatisch in den richtigen Widestring-Wert zu wandeln) kommt mir da sehr viel logischer/besser/benutzerfreundlicher vor.

Altes Delphi läuft mit Ansi. Die Controls TEdit etc. sind nicht Unicode tauglich. Das kann man nicht vergleichen.

Warum verlässt Lazarus da den Kompatibilitäts-Pfad ?

Zum zig-ten mal: Weil es Unicode kann.
Das neue Delphi 2009 kann das auch und verlässt den Kompatibilitäts-Pfad auch.

[mschnell]

Allerdings sehe ich die Notwendigkeit, eine String-Konstante erst durch eine Funktion zu schicken, bevor sie einer Variablen zugeordnet wird als heftiges Manko.

Das muss man nicht. Behandle sie einfach als UTF-8 und gut ist. Dazu kannst du auch die Klasse verwenden, die ich im anderen Thread gepostet habe.

Warum willst Du mir verbieten, die Stringverarbeitung mit Widestrings zu machen ? Die bietet Lazarus doch ebenso wie Turbo-Delphi und MSEIDE an, sie sind Unicode und sind wesentlich praktischer zu benutzen als der utf8 Kram ?

Wie Delphi das macht (die String-Konstante automatisch in den richtigen Widestring-Wert zu wandeln) kommt mir da sehr viel logischer/besser/benutzerfreundlicher vor.

Altes Delphi läuft mit Ansi. Die Controls TEdit etc. sind nicht Unicode tauglich. Das kann man nicht vergleichen.

Delphi kann Unicode in Widestrings und macht die Konvertierung zu ANSIStrings automatisch (z.B. wenn die VCL-Funktionen ANSI-Strings erzeugen oder verarbeiten).
Lazarus kann ebenfalls Unicode in Widestrings es sollte doch möglich sein Konvertierung zu UTF8Strings automatisch zu machen (z.B. wenn die LCL-Funktionen UTF8Strings erzeugen oder verarbeiten).

Warum verlässt Lazarus da den Kompatibilitäts-Pfad ?

Zum zig-ten mal: Weil es Unicode kann.

Turbo-Delphi kann Unicode in Widestrings. Was die VCL bzw. LCL verwendet sollte in einem ordentlichen System wurscht sein, wenn der Programmierer komplett mit Unicode in Widestrings arbeitet (sofern alle verwendetemn Zeichen in der verwendeten Codepage und in Unicode < $FFFF sind).

Das neue Delphi 2009 kann das auch und verlässt den Kompatibilitäts-Pfad auch.

Kann ich leider nicht testen. Es sollte mich aber sehr wundern, wenn "alter" Delphi-Code, der Widestrings verwendet in D2009 nicht mehr funktioniert.

Mich würde natürlich auch interessieren, wie sich diese Problematik in MSEIDE zeigt, habe ich aber nicht installiert

-Michael

[theo]

Warum willst Du mir verbieten, die Stringverarbeitung mit Widestrings zu machen ?

Wie kommst du denn darauf, dass ich dir was verbieten will? Ich hab doch nur geschrieben, dass man es nicht muss!
Lass bitte deinen Unmut nicht an mir aus.

Delphi kann Unicode in Widestrings und macht die Konvertierung zu ANSIStrings automatisch (z.B. wenn die VCL-Funktionen ANSI-Strings erzeugen oder verarbeiten).

Wenn du Verbesserungsvorschläge hast, dann wende dich bitte an die Entwickler oder bleib bei Delphi.
Mir wird das langsam zu blöd.

[mse]

Aber ich habe für dich mal Windows gestartet und es ist alles wie erwartet.

Was genau ist wie erwartet ? Kommt bei Dir ein anderes Ergebnis im Memo als ich es oben angegeben habe ? (Ich "erwarte", dass dasselbe 'rauskommt wie bei Turbo-Delphi und das ist bei mir nicht so.)

Ich zitiere nochmal von meinem früheren Beitrag:

Code: Alles auswählen

 
var
  s1, s2, s3: string; //in {$mode objfpc}{$h+} sind dies ansistrings
  c1: char;
  i1: Integer;
  su1, su2: UTF8String;
  sw1, sw2: Widestring;
  ss1, ss2: ShortString;
  sa1, sa2: AnsiString;
  wstr1,wstr2,wstr3,wstr4: widestring;
 
begin
  s1  := 'abcdefhäöü';
   //im quelltext steht hier  'abcdefh'#195#164#195#182#195#188
  s2  := UpperCase(s1); 
   //dies ist ASCII uppercase,
   //resultat:                'ABCDEFH'#195#164#195#182#195#188
  sa1 := 'abcdefhäöü';
   //im quelltext steht hier  'abcdefh'#195#164#195#182#195#188
  sa2 := AnsiUpperCase(sa1);
   //hier wird die Windows Funktion CharUpperBuf() aufgerufen,
   //sie erwartet cp1252 codierung und gibt cp1252 zurück.
   //sa1 in cp1252 interpretiert bedeutet
   //                         'abcdefhäöü'
   //resultat:                'ABCDEFHäöü'
  c1  := s1[1];
  su1 := AnsiToUtf8(s1);
(*
 
function AnsiToUtf8(const s : ansistring): UTF8String;{$ifdef SYSTEMINLINE}inline;{$endif}
  begin
    Result:=Utf8Encode(s);
  end;
 
function UTF8Encode(const s : WideString) : UTF8String;
  var
    i : SizeInt;
    hs : UTF8String;
  begin
    result:='';
    if s='' then
      exit;
    SetLength(hs,length(s)*3);
    i:=UnicodeToUtf8(pchar(hs),length(hs)+1,PWideChar(s),length(s));
    if i>0 then
      begin
        SetLength(hs,i-1);
        result:=hs;
      end;
  end;
  
procedure Win32Ansi2WideMove(source:pchar;var dest:widestring;len:SizeInt);
  var
    destlen: SizeInt;
  begin
    // retrieve length including trailing #0
    // not anymore, because this must also be usable for single characters
    destlen:=MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, source, len, nil, 0);
    // this will null-terminate
    setlength(dest, destlen);
    MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, source, len, @dest[1], destlen);
  end;
 
*)
    // 'abcdefhäöü' wird in von cp-1252 in Unicode gewandelt,
    // ergibt:
    // 'abcdefh'#195#164#195#182#195#188', in utf-8 codiert:
    // 'abcdefh'#195#131#194#164#195#131#194#182#195#131#194#188
 
  su2 := su1; // UTF8LowerCase(su1);
  sw1 := s1;
    // 'abcdefhäöü' wird in von cp-1252 in Unicode gewandelt,
    // ergibt:
    // 'abcdefh'#195#164#195#182#195#188' = 'abcdefhäöü'
 
  sw2 := WideUpperCase(sw1);
    // 'abcdefhäöü' -> 'ABCDEFHäöü' (Unicode)
  s3  := sw2;
    // Unicode 'ABCDEFHäöü' wird auf cp1252 gewandelt, ergibt:
    //  'ABCDEFH'#195#164#195#182#195#188 oder 'ABCDEFHäöü'
  ss1 := s1;
    //ss1 = 'abcdefh'#195#164#195#182#195#188
  ss2 := Uppercase(ss1);
    //ASCII uppercase = 'ABCDEFH'#195#164#195#182#195#188
  wstr1:= utf8decode(su1);
  wstr2:= utf8decode(su2);
  wstr3:= utf8decode(ansistring(sw1));
  wstr4:= utf8decode(ansistring(sw2));
{
 //Lazarus interpretiert die übergebenen ansistrings als utf-8
 
  Memo1.Lines.Add(s1); 
  //'abcdefh'#195#164#195#182#195#188 -> 'abcdefhäöü'  
  Memo1.Lines.Add(s2);
  //'ABCDEFH'#195#164#195#182#195#188 -> 'ABCDFHäöü'
  Memo1.Lines.Add(s3);
  //'ABCDEFH'#195#164#195#182#195#188 -> 'ABCDFHäöü'
  Memo1.Lines.Add(su1);
  //'abcdefh'#195#131#194#164#195#131#194#182#195#131#194#188 ->
  //'abcdefhäöü'
  Memo1.Lines.Add(su2);
  //'abcdefh'#195#131#194#164#195#131#194#182#195#131#194#188 ->
  //'abcdefhäöü'
  Memo1.Lines.Add(sw1);
  //sw1 wird von Unicode in cp1252 gewandelt und als utf8 interpretiert:
  //'abcdefh'#195#164#195#182#195#188 -> 'abcdefhäöü'
  Memo1.Lines.Add(sw2);
  //sw2 wird von Unicode in cp1252 gewandelt und als utf8 interpretiert:
  //'ABCDEFH'#195#164#195#182#195#188 -> 'ABCDEFHäöü'
  //Und so weiter...
  Memo1.Lines.Add(ss1);
  Memo1.Lines.Add(ss2);
  Memo1.Lines.Add(sa1);
  Memo1.Lines.Add(sa2);
  i1 := sizeof(c1);
  Memo1.Lines.Add('-' + ' ' + inttostr(i1));
}
end.
 

Warum mache ich mir denn solche Mühe, die Hintergründe aufzuzeigen, wenn du es doch nicht liest?

Martin

[mse]

Mich würde natürlich auch interessieren, wie sich diese Problematik in MSEIDE zeigt, habe ich aber nicht installiert

MSEide arbeitet intern komplett mit widestrings (in MSEgui msestring genannt) und benützt utf-8 lediglich zum Speichern von Textdateien.
Zur Plattform-unabhängigen Behandlung von Stringkonstanten empehle ich, den Quelltext in utf-8 zu speichern und beim Kompilieren -Fcutf8 anzugeben. FPC übersetzt dann zur Kompilierzeit die Stringkonstanten im Programm in widestrings, siehe den mehrmals erwähnten Beitrag von Jonas Maebe.

Martin