Unicodezeichen mit mehr als einem wideChar?

[Mavarik]

Hallo Zusammen!

Ich habe in der Vergangenheit kaum mit Unicode arbeiten müssen.

Viele Unicode Zeichen - non-Ascii - lassen sich immer noch mit einem "WordChar" darstellen.
Es gibt jedoch auch Zeichen die aus 2 und 3 "WordChars" bestehen.

z.B. "LATIN CAPITAL LETTER C WITH COMBINING OGONEK AND COMBINING BREVE"

$0043 $0328 $0306...

Wenn ich also einen String habe: "ABCDEFG" + CHR($43)+chr($328)+chr($306);
wird dieser in einem TEdit als "ABCDEFGC" <- Das C hat dann die schnörkel, dargestellt.

Soweit so gut... Length(Edit.Text) = 10
Wenn meine Datenbank, mein Feld im Record oder was auch immer nur (in diesem Beispiel) eine Länge von 9 Chars hat...
Ein Copy würde aber das Zeichen ändern. // Adresse.Str := Copy(Edit.Text,1,9);

Auch die üblichen Routine wie:

Delphi-Quellcode:

for i:=1 to length(S) do
  begin
    if S[i] = cMyCoolesC then 
     Foo(S[i]);
  end;

Kann nie funktionieren, da ich eigentlich immer 3 Chars vergleichen müsste...

Delphi-Quellcode:

S := cMyCoolesC + 'A';
Pos('A',S) = 4;

Mit solchen Zeichen funktioniert die "normalen" Routine die man i.d.R zu Haufe im Source hat nicht.

Wie geht Ihr damit um, wenn Ihr solche Zeichen verarbeiten müsst?
Übersehe ich etwas?

Grüsse
Mavarik

[himitsu]

Egal ob so oder so,
wenn bei Eintragung in die DB ein Text einfach so ohne Meldung abgeschnitten wird, dann hat man eh ein Problem.
-> direkt bei eingabe begrenzen (MaxLength) und/oder beim Speichern die Länge prüfen.


Es gibt viele Funktionen, welche CombiningChars/Composites beachten, prüfen, vergleichen oder konverieren (trennen/zusammenfassen).

CharNext/CharNextEx/CharPrev/CharPrevEx, CompareString/CompareStringEx, MultiByteToWideChar/WideCharToMultiByte, ...
Aber teilweise muß man das erst aktivieren, z.B. mit WC_COMPOSITECHECK/MB_COMPOSITE/MB_PRECOMPOSED


Neuerdings zählen auch Smilies dazu, seidem man dort anfängt zu gendern. (das gleiche Smilie weiblich/männlich und in verschiedenen Hautfarben)

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

[Rollo62]

Zitat:

MultiByteToWideChar

Ich vermute mal solche Funktionen machen aus dem 3-Byte Zeichen oder Emofijs womöglich 4-Byte+x-Byte lange Zeichenketten,
womit Dir nicht geholfen wäre, richtig ?

Geht es nur um ein paar, fest-definierte spezielle Zeichen, oder kann da generell das ganze UTF-32 Spektrum auftreten ?

Bei nur ein paar, fest definierten Zeichen könnte es sinnvoll sein ein eigenes "Mapping" von lesbaren Zeichen dafür anzulegen,
was dann aber natürlich das orginale Zeichen zerstören wird.

[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.

[freimatz]

Zitat von Mavarik:

Mit solchen Zeichen funktioniert die "normalen" Routine die man i.d.R zu Haufe im Source hat nicht.

Wie geht Ihr damit um, wenn Ihr solche Zeichen verarbeiten müsst?
Übersehe ich etwas?

Ja, dass Deine Ansicht von "normal" falsch ist.
Es sind analoge Probleme wie damals bei der Umstellung in Delphi von Ansistring zu Unicodestrings.
Zwei Optionen:
1. forget it
2. Beiss in den sauren Apfel und stelle alles um. (Der Apfel ist sehr sauer)

Ich habe es damlas nur in dem Bereich umgestellt wo es nötig war.
Leider bietet Delphi da nur wenig Unterstützung. Wenn schon in den Standardtyp Char ein Zeichen nicht reinpasst ist das suboptimal.

[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.