Unicodezeichen mit mehr als einem wideChar?

[TigerLilly]

Der Code wird in Delphi mit Unicode-Unterstützung funktionieren, wie erwartet. Auch die Datenbank hat in der Regel ein Kodierschema, ist das Feld dort auch Unicode, hast du kein Problem. Wenn du versuchst, UniCode-Strings in non-Unicode-Felder zu schrieben, wird bei Sonderzeichen eher was unerwartetes passieren.

[Ydobon]

Ab Version 2000 verwendet Windows intern UTF-16 und nicht mehr UCS-2. Programme die darauf laufen sollten eigentlich bei normalen Zugriffen keine Probleme haben, egal ob ein Zeichen mit 2 oder mit 4 Byte kodiert ist.

[himitsu]

Hier geht es nicht um UCS2/UTF-16, bzw. nich um die Codierung der "Chars" im Unicode, aber ja die Surrogates bestehen ebenfalls aus 2 Chars. (die lassen sich aber auch supereinfach prüfen/finden)

Die CombiningChars/Composites gab es auch früher schon und das auch in jeder anderen Codierung ala ANSI, UTF-8 usw., also wo, unabhängig von der Kodierung, mehrere Char virtuell ein "Zeichen" darstellen.
z.B. A¨ = Ä oder E´ = É (wobei man letzteres auch selbst eingeben kann, aber da andersrum, also zuerst ´ und dann E)

Wobei es diese Combining-Chars doppelt gibt. Einmal Einzeln und einmal als Combinierend.
Und bei den Smilies erfandman das nun auch, um gendern und rassieren zu können, für weiblich/männlich und viele Hautfarben.

https://en.wikipedia.org/wiki/Precomposed_character
https://de.wikipedia.org/wiki/Kombinierendes_Zeichen

´ Acute Accent #$B4
◌́ Combining Acute Accent #$0301 (p.s siehe Zitat, denn es ist ein ◌ + ´)

[Der schöne Günther]

Es doch eigentlich genau was himitsu sagt - Es geht nicht um Bytes. Es geht um Zeichen. Und wie diese Zeichen auf dem Bildschirm (für einen Menschen) dargestellt werden ist nicht das gleiche.

Dieser nicht ganz erst gemeinte Comic zeigt das auch nochmal gut:
https://xkcd.com/1813/

Ich sehe das große Problem noch nicht ganz. Wenn jemand als Vorname "Jupp 😎" eingibt und aus diesem Eingabefeld maximal die ersten sechs Zeichen gespeichert werden muss er doch damit leben können wenn ein Programm dann später "Jupp �" anzeigt. Alternativ filtert man das halt einfach raus, sollte man mit Benutzereingaben eh immer machen:

Delphi-Quellcode:

uses System.Character;

var
   newText: String;
   finalText: String;
   character: Char;
begin
   newText := String.Empty;
   for character in 'Hallo 😎'.Substring(0, 7) do
      if(character.IsLetterOrDigit()) then
         newText := newText + character;

   Edit1.Text := newText;
end;

[Mavarik]

Nicht so ganz...

Anbei mal ein kleines TestProg.

Beispiel: Memo Zeile 687 & 688
Wenn ich einen String vergleich mache und suche das Zeichen aus Zeile 687, finde ich auch das Zeichen aus 688 das aber eigentlich ein anderes Zeichen ist,
ich müsste also bei diesem Char nach der Suche immer das nächste Zeichen prüfen und dann vergleichen, ob diese Kombination ein neues Zeichen ergibt.

Das gleich bei einer Abgeschnittenen Ausgabe...

oder Memo Zeile 292...
Ich finde in einem String ein "r" bei 290 und 291 muss ich das nächste Zeichen kontrollieren bei 292 die nächsten 2.

Die Tabelle ist eine Unicode Teilmenge der Latin 1.2 Erweiterung. (Nur die Zeichen, die in ein Ascii Zeichen umgewandelt werden können)
Wenn ich also einen beliebigen Unicode String der in eine TEdit per Clipboard kopiert wird auf Validität überprüfen will, ist das nicht so ganz einfach.

Ich hoffe immer noch, dass ich etwas übersehe...

Mavarik

[Der schöne Günther]

Das konkrete Problem habe ich noch nicht verstanden. Angenommen du hast den String "Dånsk". Also "D" + (char)0x61 + (char)0x30A + "nsk" Dann liefert "Dånsk".StartsWith("Da") auch false , obwohl die ersten beiden Character ja übereinstimmen.

Ist doch alles gut so? Wenn du von Hand nun Strings in der Mitte durchsäbelst speicherst du in deiner Anwendung im schlimmsten Fall nur "Da" statt "Då".
Das gilt, solange wir über "Combining Marks" und nicht über die ganz crazy Sachen wie 👸🏿 sprechen.

[Mavarik]

Zitat von Der schöne Günther:

Das konkrete Problem habe ich noch nicht verstanden. Angenommen du hast den String "Dånsk". Also "D" + (char)0x61 + (char)0x30A + "nsk" Dann liefert "Dånsk".StartsWith("Da") auch false , obwohl die ersten beiden Character ja übereinstimmen.

OK, StartWith kann das also, gut zu wissen - oder auch nicht. Kommt darauf an, welche Funktionalität man erwartet.

Eine Routine die Feststellen muss, ob es sich um Kosit, Latin 1.1 oder Latin 1.2 handelt sieht dann so aus...

Delphi-Quellcode:

For i:=1 to length(S) do
  begin
    if Dic3Char.TryGetValue(S[i],Target) then
      begin
        if length(S) > I+2 then
          begin
            if (s[i+1] = Target.Char2) and (S[i+2] = Target.Char3) then
              Exit(IsLatin1_2);
          end;
      end else begin
    if Dic2Char.TryGetValue(S[i],Target) then
      begin
        if length(S) > I+1 then
          begin
            if (s[i+1] = Target.Char2) then
              begin
                if IsLatin1_1(S[i],s[i+1] 
                  then Exit(IsLatin1_1)
                  else Exit(IsLatin1_2);
              end;
          end;
      end else begin
        if not Dic1Char.TryGetValue[S[i],Target) then
        Exit(NonKoSIT);
      end;
    end;
  end;