Problem mit Multibyte-Zeichen

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

Ich muss einmal mehr richtigstellen.
Hier - und vermutlich auch in allen anderen entprechenden Posts im Deutschen Lazarusforum zu diesem Thema -
geht es um:

Code: Alles auswählen

 
var
  c: Char;
  s: String;
begin
  s := 'ä';
  c := s[1];
  ShowMessage(c); // Gibt leere Meldung aus
end;
 
var
  s1, s2: String;
begin
  s1 := 'ä';
  s2 := s1[1] + s1[2];
  ShowMessage(s2); // Gibt ä aus
end;
 
 

Das verwendete Zeichen 'ä' liegt wie alle üblicherweise verwendeten Zeichen lebender Sprachen im Unicodebereich kleiner $D800 und findet im 16Bit UnicodeChar Typ Platz. Dieser Bereich wird Basic Multilingual Plane (BMP) genannt.
Zeichen im Unicodebereich über $d7ff werden auf zwei 16Bit UnicodeChar aufgeteilt (=Surrogate Pair), das erste 16 Bit Element (=Codeunit) im Bereich $d800..$dbff, das zweite im Bereich $dc00..dfff. Für alle 16Bit Zeichen (=Codepoint) im Bereich < $d800 gibt es also keine Überlappung mit aufgeteilten Zeichen im Unicodebereich > $ffff.
Im Bereich $10000 bis $10ffff liegen hauptsächlich Codepoints toter Sprachen und selten gebrauchte Spezialzeichen.
Wenn ihr also nach Schriftzeichen lebender Sprachen sucht, könnt ihr bedenkenlos UnicodeString und UnicodeChar einsetzen, auch wenn im zu durchsuchenden Text beliebige aufgeteilte Codepoints vorkommen. Ein Surrogate Pair wird lediglich zu zwei für euch unbekannte Zeichen über die ihr im Suchen hinweggeht.
Das Einzige was ihr nicht tun solltet, ist das Aufteilen eines UnicodeString zwischen einem aufgeteilten Codepoint (Surrogate Pair), da dann das letzte Zeichen des Start-strings das erste Zeichen des End-strings ungültig werden. Ich glaube aber, dass dies in allen im Deutschen Lazarus Forum geschilderten Umlautproblemen nicht passieren kann.
Wenn ihr nach Zeichen in toten Sprachen sucht, wird es schwieriger. Dies ist aber sowieso Spezialistenarbeit denn da gibt es sehr viel zu berücksichtigen wie z.B. aus mehreren Codepoints zusammengesetzen Zeichen und die Schreibrichtung.

mischi
Beiträge: 206
Registriert: Di 10. Nov 2009, 18:49
OS, Lazarus, FPC: macOS, 10.13, lazarus 1.8.x, fpc 3.0.x
CPU-Target: 32Bit/64bit

Re: Problem mit Multibyte-Zeichen

Beitrag von mischi »

My 2 cents:

In dem Zusammenhang sollte man die Unicode Normalization erwähnen, weil es selbst schon für die Umlaute mindestens zwei prinzipielle Repräsentations-Möglichkeiten gibt: 1. ä als einzelnes Zeichen, 2. als a mit Doppelpunkten drüber. Ein einfacher Vergleich von Strings aus verschiedenen Quellen kann da schon mal schief gehen. Leider gibt es auch für die Normalization noch 2 Varianten. Linux macht Normalization nach NFC, aber Mac OS X nach NFD. Ich bin mir nicht sicher, aber ich würde da bereits Ärger erwarten, wenn man Dateinamen von Netzlaufwerken ohne weitere Normalisierung vergleicht.

MiSchi.
MiSchi macht die fink-Pakete

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Re: Problem mit Multibyte-Zeichen

Beitrag von theo »

Ich glaube ich habe ein

Déjà-vu

Mathias
Beiträge: 6194
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Problem mit Multibyte-Zeichen

Beitrag von Mathias »

Waren das unter DOS noch schöne Zeiten 256 Zeichen und fertig.

Als ich noch mit Turbo-Pascal programmierte hatte ich nie Probleme mit Umlauten etc.
Aber heute ist alles kaotisch, überall was anderes. :cry:
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Problem mit Multibyte-Zeichen

Beitrag von Michl »

Sehr passend (leider auf Englisch) http://www.joelonsoftware.com/articles/Unicode.html

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

BeniBela
Beiträge: 309
Registriert: Sa 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4)
CPU-Target: 64 Bit

Re: Problem mit Multibyte-Zeichen

Beitrag von BeniBela »

mse hat geschrieben:Im Bereich $10000 bis $10ffff liegen hauptsächlich Codepoints toter Sprachen und selten gebrauchte Spezialzeichen.



Wenn man vollständige mathematische oder asiatische Text mit Unicode schreiben will, braucht man diese Zeichen ständig.

Und die Zeichen, die ich oben gepostet habe, will ich auch alle verwenden können. (mittlere Zeile, 2tes Zeichen ist zum Beispiel zufälligerweise mein Webseitenlogo. )

Mathias hat geschrieben:Waren das unter DOS noch schöne Zeiten 256 Zeichen und fertig.

Als ich noch mit Turbo-Pascal programmierte hatte ich nie Probleme mit Umlauten etc.
Aber heute ist alles kaotisch, überall was anderes. :cry:


Wenn man konsequent UTF-8 verwendet hat, kriegt man heute auch keine Probleme

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

BeniBela hat geschrieben:Und die Zeichen, die ich oben gepostet habe, will ich auch alle verwenden können. (mittlere Zeile, 2tes Zeichen ist zum Beispiel zufälligerweise mein Webseitenlogo. )

Die kannst du verwenden, lediglich nicht z.B. als character case labels, bitte lies nochmals Obenstehendes. Ist denn das so schwer zu verstehen?

BeniBela
Beiträge: 309
Registriert: Sa 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4)
CPU-Target: 64 Bit

Re: Problem mit Multibyte-Zeichen

Beitrag von BeniBela »

mse hat geschrieben:
Die kannst du verwenden, lediglich nicht z.B. als character case labels, bitte lies nochmals Obenstehendes. Ist denn das so schwer zu verstehen?


Aber so wie oben beschrieben, kann man nicht danach suchen!

Und wenn es sich verwenden könnte, hätte ich es nicht auf pastebin posten müssen

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

BeniBela hat geschrieben:Aber so wie oben beschrieben, kann man nicht danach suchen!

Richtig, wenn man nach Zeichen >$d7ff sucht muss man UnicodeString statt UnicodeChar verwenden. Das ist genau gleich wie bei deinem gewohnten utf-8. Nur dass dort die Grenze bei $7f liegt und somit bereits deutsche Umlaute nicht mehr funktionieren.
Dein Text wird im Konqueror wie unten angezeigt, ganz so problemlos ist die Sache scheinbar nicht. ;-)
Dateianhänge
characters.png

Patito
Beiträge: 203
Registriert: Di 22. Sep 2009, 13:08
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: xxBit

Re: Problem mit Multibyte-Zeichen

Beitrag von Patito »

mse hat geschrieben:Im Bereich $10000 bis $10ffff liegen hauptsächlich Codepoints toter Sprachen und selten gebrauchte Spezialzeichen.


Es gibt dort Symbole, die für z.B. Button-Captions interessant sind. Eines der Beispiele in letzter Zeit war doch so eine Art Play-Button.
Wenn man sich die Arbeit Button-Glyphs zusammenzusuchen durch ein paar Unicode-Chars als Caption ersparen kann,
sind diese Spezialzeichen ganz schnell nicht mehr selten.

Ausserdem gibt es dort eine User-Defined-Area, in dem z.B. Produktlogos von Firmen liegen können.
Vielleicht sollte jemand mal alle größeren Firmen anrufen, und verlangen, dass sie den Bereich in ihren Spezialfonts nie und nimmer verwenden sollen...

Die Idee von halbgarer Unicode-Unterstützung gefällt mir nicht. Version 8.0 des Unicode-Standard ist jetzt auf Juni 2015 angekündigt.
Will man wirklich jedes Jahr die Daumen drücken müssen, dass in der neuen Version keine populären Character dabei sind?
Die Smileys aus Unicode 6.0 sieht man doch inzwischen überall.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

mischi hat geschrieben:Linux macht Normalization nach NFC, aber Mac OS X nach NFD.

Soviel ich weiss interpretiert Linux Dateinamen als array of byte ohne Bedeutung ausser den Zeichen #0 und '/'. Man kann also nicht einmal sicher damit rechnen, dass Linux Filenamen utf-8 codiert sind.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

@Patito:
Darum geht es ja gar nicht. Es geht um die Suche nach *bekannten* Zeichen. Ein Problem bestünde erst dann, wenn das Unicode Consortium das Zeichen 'ä' z.B. vom jetzigen $e5 auf $12345 verlegen würde. Ich versuche diesen Umstand schon mehrere Jahre "rüber zu bringen", scheinbar ist mir das immer noch nicht gelungen. :-)
Zuletzt geändert von mse am Do 18. Sep 2014, 10:12, insgesamt 1-mal geändert.

BeniBela
Beiträge: 309
Registriert: Sa 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4)
CPU-Target: 64 Bit

Re: Problem mit Multibyte-Zeichen

Beitrag von BeniBela »

mse hat geschrieben:
Richtig, wenn man nach Zeichen >$d7ff sucht muss man UnicodeString statt UnicodeChar verwenden. Das ist genau gleich wie bei deinem gewohnten utf-8. Nur dass dort die Grenze bei $7f liegt und somit bereits deutsche Umlaute nicht mehr funktionieren.


Dann merkt man aber gleich, ob es funktioniert, oder nicht, statt nach ein paar Jahren

mse hat geschrieben:
Dein Text wird im Konqueror wie unten angezeigt, ganz so problemlos ist die Sache scheinbar nicht. ;-)


Man braucht vermutlich die richtigen Fonts: Symbola, DejaVu Sans, und FreeSerif verwendet Firefox hier, um es darzustellen

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Re: Problem mit Multibyte-Zeichen

Beitrag von theo »

mse hat geschrieben:@Patio:
Darum geht es ja gar nicht. Es geht um die Suche nach *bekannten* Zeichen. Ein Problem bestünde erst dann, wenn das Unicode Consortium das Zeichen 'ä' z.B. vom jetzigen $e5 auf $12345 verlegen würde. Ich versuche diesen Umstand schon mehrere Jahre "rüber zu bringen", scheinbar ist mir das immer noch nicht gelungen. :-)

Du versuchst einfach seit Jahren rüberzubringen, dass dein halbgares UCS-2 System einem UTF-8 System überlegen sei, weil es einen später, dafür umso heftiger in den Hintern tritt. :lol:


mse hat geschrieben:Dein Text wird im Konqueror wie unten angezeigt, ganz so problemlos ist die Sache scheinbar nicht.

Die passenden Fonts sollte man schon installiert haben. Unter Linux z.B. "gdouros-symbola-fonts"

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Problem mit Multibyte-Zeichen

Beitrag von mse »

BeniBela hat geschrieben:Dann merkt man aber gleich, ob es funktioniert, oder nicht, statt nach ein paar Jahren

Und du glaubst tatsächlich, dass das Unicode Consortium in ein paar Jahren 'ä' von $e5 auf z.B. $12345 verlegen wird? Ernsthaft?

Antworten