Erkennen ob das Zeichen ein UTF8 Zeichen ist

[pluto]

Nette Übersicht, sollte evtl. in die WissensDB aufgenommen werden.

[monta]

stimmt.

@mse: Hast du was dagegen?

[mse]

@mse: Hast du was dagegen?

Nein. Darum habe ich den Text ja geschrieben. Ich hoffe er ist korrekt, Diskussion eröffnet.

[theo]

Diskussion eröffnet.

Der Text ist fachlich sicherlich korrekt, soweit ich das beurteilen kann.

Wer jetzt etwas zum didaktischen Aspekt sagt, muss es selber besser machen. Drum sage ich nix.

[mschnell]

Diskussion eröffnet.

1) Sehr gut !

2.) OK......

Ich meine, "String" ist nicht ausschließlich zur Speicherung von Text sinnvoll.

String ist in allen nicht uralten Implementierungen ein Type der eine variable Anzahl von Elementen enthält und reference counting verwaltet wird. Die Elemente können beliebige Bitkombinationen annehmen. Die Codierung der Elemente wenn sie als Text betrachtet ist implementierungsabhängig. Leider ist anscheinend beim neuen Delphi auch nicht mehr sichergestellt, dass es 8-Bit Elemente sind, wie FPC das demnächst macht, seht anscheinend noch in den Sternen.

Ich habe den Type "String" schon oft für andere Zwecke als Text (völlig transparent) verwendet, z.B. als Buffer variabler Länge in Kommunikationsprogrammen. Ich werde mit demnächst dafür immer einen type "Bytestring" definieren, der dann auf einen passenden Stringtyp zugeordnet werden kann.

===================

Soweit ich das in der FPC Developers' List mitbekommen habe soll es geändert werden, dass unter Windows nicht reference counted ist. (läuft das dann auf einen von Widestring unterschiedenen Typ OLEString heraus ?)

===================

Pchar und PWidechar werden von der Linux und der Windows API benutzt und sind deshalb wichtig

ANSIString (=UTF8String) und Widestring sind Inhalts-kompatibel zu pchar, so dass eine TypeUmwandling pchar(myString) keine Kopie erstellt. (deshalb wird bei ANSIString ein "überflüssiges" #0 angefügt)

===================

Es gibt auch "länderspezifiasche" ASCII - Codetabellen, die z.B. Umlaute mit Codes < 128 darstellen

-Michael

[mse]

Soweit ich das in der FPC Developers' List mitbekommen habe soll es geändert werden, dass unter Windows nicht reference counted ist. (läuft das dann auf einen von Widestring unterschiedenen Typ OLEString heraus ?)

Nein, der neue, auf allen Systemen Referenz-gezählte widestring Typ heisst UnicodeString. Auf Linux ist UnicodeString identisch mit widestring, unter Windows nicht.
MSEgui ist auf UnicodeString bereits vorbereitet:

Code: Alles auswählen

 
type
 {$ifdef mse_unicodestring}
 msestring = unicodestring;
 msechar = unicodechar;
 pmsechar = punicodechar;
 {$else}
 msestring = widestring;
 msechar = widechar;
 pmsechar = pwidechar;
 {$endif}
 

[mschnell]

Auf Linux ist UnicodeString identisch mit widestring, unter Windows nicht.

UnicodeString ist also immer Reference counted, Widestring nur auf Linux. Also am besten Widestring nicht verwenden, wenn man nicht in Windows OLE machen will.

Da es bei Delhi aber nur Widestring und nicht Unicodestring gibt (oder kommt das bei D2009 dazu ?) ist es ganz schön verwirrend.

Für "professionelle" Programme also am besten _immer_ einen eigenen String-Typ deklariere und dann u.u. je nach bedarf entsprechend der Compiler-Version und der verwendeten Compiler-Optionen zuweisen .

-Michaeö

[mschnell]

Weiter ......

Vielleicht sollte erwähnt werden, dass UCS2 im Gegensatz zu UTF16 "Surrogates" anders behandelt. Wenn ich das richtig mitbekommen habe ist das zwar nur bei Mac wirklich relevant, aber den soll es ja tatsächlich geben, habe ich mir sagen lassen .

================

Wenn ich das richtig sehe, ist bei allen Bytes eines UTF8-Code immer das höchste Bit gesetzt, außer er besteht nur aus einem Byte und dieses ist ein ASCII-Zeichen.

Damit wäre die einfache Antwort auf das Topic des Threads gefunden:

Code: Alles auswählen

function is_utf8_zeiche(s: UTF8STring; index: Integer): booelan;
begin
  Result := (ord(s[index]) and $80) <> 0;
end;

-Michael

[mse]

Da es bei Delhi aber nur Widestring und nicht Unicodestring gibt (oder kommt das bei D2009 dazu ?)

D2009 hat den Typ UnicodeString AFAIK, ich weiss aber nicht, ob er zu FPC UnicodeString kompatibel ist. Kann ein D2009 Besitzer dazu genaueres sagen?

[theo]

Ich wüsste nicht warum er es nicht sein sollte.
Das Problem ist genau das gleiche wie beim FPC UnicodeString WideString:

http://www.micro-isv.asia/2008/08/get-r ... d-unicode/" onclick="window.open(this.href);return false;

[mse]

Vielleicht sollte erwähnt werden, dass UCS2 im Gegensatz zu UTF16 keine Surrogates kann.

Das wird erwähnt.

Wenn ich das richtig mitbekommen habe ist das zwar nur bei Mac wirklich relevant, aber den soll es ja tatsächlich geben, habe ich mir sagen lassen.

Da muss ich dich korrigieren. Der erwähnte "Mac-Effekt" hat mit surrogate pairs nichts zu tun, sondern mit dem Umstand, dass unter Mac Dateinamen decomposed sind. Das heisst z.B. dass statt
ä (U+00E4 LATIN SMALL LETTER A WITH DIARESIS)
a (U+0061 LATIN SMALL LETTER A) gefolgt von ¨ (U+0308, COMBINIG DIARESIS)
geschrieben wird. Alle diese codepoints sind Bestandteil von UCS2.

[mschnell]

Weiter ......

Was passiert, wenn bei der (automatischen) Umwandlung von Unicode nach ANSI, in der eingestellten System-Ansi-Tabelle das Unicode-Zeichen nicht definiert ist ?

- Michael

[mse]

Ich wüsste nicht warum er es nicht sein sollte.
Das Problem ist genau das gleiche wie beim FPC UnicodeString WideString:

http://www.micro-isv.asia/2008/08/get-r ... d-unicode/" onclick="window.open(this.href);return false;

In D2009 gibts aber auch noch den string Typen mit gespeicherter Codierungsinformation. Hat der mit UnicodeString nichts zu tun? Da ich kein D2009 besitze kann ich der Sache leider nicht auf den Grund gehen.

[mschnell]

Alle diese codepoints sind Bestandteil von UCS2.

Verstehe.

Meine Frage ist: unter welchen Umständen (außer wenn bei Mac bekloppte Dateinamen verwendet werden) wird man tatsächlich mit surrogate pairs konfrontiert werden ?

-Michael

[theo]

Ich wüsste nicht warum er es nicht sein sollte.
Das Problem ist genau das gleiche wie beim FPC UnicodeString WideString:

http://www.micro-isv.asia/2008/08/get-r ... d-unicode/" onclick="window.open(this.href);return false;

In D2009 gibts aber auch noch den string Typen mit gespeicherter Codierungsinformation. Hat der mit UnicodeString nichts zu tun? Da ich kein D2009 besitze kann ich der Sache leider nicht auf den Grund gehen.

Ich besitze auch keines.
Das hier sind interessante Info-Quellen:

http://dn.codegear.com/article/38437" onclick="window.open(this.href);return false;
http://dn.codegear.com/article/38498" onclick="window.open(this.href);return false;

Ich könnte aber damit die Frage auch nicht abschliessend beantworten.
"A UnicodeString can contain either a Unicode-sized character, or an ANSI byte-sized character. "