[gelöst] Memo in Ini-Datei

[mschnell]

Ein Programmierer sollte wissen, wie sich sein eigenes Programm verhält, wenn es mit unterschiedlichen Codierungen arbeitet. Das fängt schon bei dem Datenaustausch zwischen zwei Programminstanzen an. Der Entwickler sollte sicherstellen, dass eine Datei A von Computer 1 auch auf Computer 2 gelesen und wie gewünscht dargestellt wird -- unabhängig davon, was bei den Computern eingestellt ist.

Das sollte die mit Unicode arbeitende Programmiersystem-Infrastruktur sicherstellen, ohne dass sich der Programmierer darum kümmern muss.

Leider ist "Programm-interner Text" nur so lange intern, wie er nicht das Programm verlässt (zum Beispiel auf die Festplatte geschrieben wird).

Das ist natürlich richtig. beim Exportieren und Importieren muss die Codierung ja bekannt sein. (Neben Unicode und den diversen ANSI-Varianten ist da die (verrückte) HTML-Codierung noch ziemlich interessant. Die kann Delphi XE auch nicht.) Also muss man Im Code zum Exportieren und Importieren angeben, welch Codierung geschrieben/gelesen werden soll. Aber auch nur bei solchen Gelegenheiten.

-Michael

[theo]

Ich bin aber zuversichtlich, dass ich das vor der Rente noch erleben werde.

Die Welt dreht sich weiter. Man muss nicht jeden Schei* mitmachen, aber Unicode ist wichtig und sinnvoll. Sich damit zu beschäftigen auch.
Unicode ist nicht ganz gratis, auch nicht wenn man jahrelang quengelt.

[Socke]

Neben Unicode und den diversen ANSI-Varianten ist da die (verrückte) HTML-Codierung noch ziemlich interessant. Die kann Delphi XE auch nicht.

HTML selbst gibt keine Kodierung vor. Du meinst vermutlich HTML-Entitäten (z.B.   oder  ). Das ist eine zeichensatzübergreifende Umschreibung (d.h. die verwendeten Zeichen sind in allen unterstützten Zeichensätzen enthalten) der Unicode-Zeichen. Eine vollständige HTML-Implementierung ist damit immer Unicode-fähig.

HTML-Entitäten sind somit kein Bestandteil eines Zeichensatzes und gehören damit nicht zur Zeichenkettenverarbeitung sondern eindeutig zur Anwendung. Inwiefern eine Programmiersprache oder IDE diese unterstützen sollte, ist mir daher schleierhaft.

[mschnell]

Das ist eine zeichensatzübergreifende Umschreibung (d.h. die verwendeten Zeichen sind in allen unterstützten Zeichensätzen enthalten) der Unicode-Zeichen.

Also ist es doch eine 7-Bit Codierung für die 32-Bit Unicode-Zeichen so wie auch UTF-8, oder UTF-16 Codierungs-Varianten dafür sind, die eben auf 8 bzw 16 Bit Codewörten beruhen. (7 Bit, weil in allen Zeichensätzen die 7-Bít Codes $20 ..$7E gleich sind und die HTML-Entitäten die 7 Bit Codes $00 bis $1f und $7F nicht verwendet). Oder was meinst Du sonst ?

Es sind sicher noch jede Menge andere Codierungs-Varianten in Gebrauch, die es erlauben, 32-Bit Ketten von Wörter zu komprimieren und zu transparentisieren. Wenn es dafür eine allgemeingültige Beschreibung gibt, ist das für mich nicht "anwendungsspezifisch".

-Michael

[Socke]

Das ist eine zeichensatzübergreifende Umschreibung (d.h. die verwendeten Zeichen sind in allen unterstützten Zeichensätzen enthalten) der Unicode-Zeichen.

Also ist es doch eine 7-Bit Codierung für die 32-Bit Unicode-Zeichen so wie auch UTF-8, oder UTF-16 Codierungs-Varianten dafür sind, die eben auf 8 bzw 16 Bit Codewörten beruhen. (7 Bit, weil in allen Zeichensätzen die 7-Bít Codes $20 ..$7E gleich sind und die HTML-Entitäten die 7 Bit Codes $00 bis $1f und $7F nicht verwendet). Oder was meinst Du sonst ?

Ich meine, dass man in einem HTML-Dokument sämtliche Unicode-Zeichen verwenden kann, egal welche Zeichenkodierung oder Zeichensatz der umgebende Text verwendet. Man kann zum Beispiel ein HTML-Dokument in Latin-15 erstellen und gleichzeitig kyrillische Zeichen (als HTML-Entität) verwenden. Der Browser sollte dann Latin-15 in Unicode konvertieren um zur Darstellung nicht zwischen verschiedenen Zeichensätzen zu wechseln.

Es sind sicher noch jede Menge andere Codierungs-Varianten in Gebrauch, die es erlauben, 32-Bit Ketten von Wörter zu komprimieren und zu transparentisieren. Wenn es dafür eine allgemeingültige Beschreibung gibt, ist das für mich nicht "anwendungsspezifisch".

Du sagst es: komprimieren. Weder UTF-8 noch UTF-16 komprimieren jeden Text (allgemeingültig). Für europäische Sprachen mag dies zutreffen, für andere nicht (damit nicht allgemeingültig). [auf transparentisieren, gehe ich nicht weiter ein, da ich nicht verstehe, was du mir damit sagen willst]
HTML-Entitäten sind keine allgemeine Möglichkeit um Unicode-Codepunkte/-Zeichen zu referenzieren. Sie sind allein für SGML definiert (SGML ist die Auszeichnungssprache, die in HTML verwendet wird).

[mschnell]

Weder UTF-8 noch UTF-16 komprimieren jeden Text (allgemeingültig).

Ich meinte: in den allermeisten Fällen ist UTF-8 und UTF-16 kompakter als UTF-32.

transparentisieren

Bei einer Folge von Codes muss erkannt werden, wo ein Abschnitt beginnt, damit man die Folge sinnvoll interpretieren kann. Bei manchen ASCII-basierten Übertragungs-Verfahren auf Leitungen werden dafür die Zeichen SOH, STX, ETX etc. verwendet, die eine reine Transport-Organisations-Bedeutung haben und nicht zum Inhalt gehören. Damit auch diese Zeichen im Inhalt übertragen werden können muss man eine Transparentisierung anwenden (z.B. ESC und einen "Ersatzcode" für die verbotenen Zeichen verwenden). (Ohne das ist der Nutz-Inhalt nicht beliebig und die Übertragung nicht "transparen"). UTF-8 verwendet dafür (u.a.) das Bit 7 in etwa in der Bedeutung "es kommen noch mehr Codes für diesen Unicode-Codepunkt".

HTML-Entitäten sind keine allgemeine Möglichkeit um Unicode-Codepunkte/-Zeichen zu referenzieren.

Meinst Du damit, dass es nicht für alle Codepunkte eine Definition durch eine HTML-Entitäten - Zeichenfolge gibt ?

Das mag sein: ( http://unicode.e-workers.de/entities.php )

Ist in dieser Diskussion aber kein KO für diesen Code. Delphi XE unterstützt in den dynamisch codierten Strings ja auch die diversen Varianten von ANSI (mit automatischer Konvertierung von und zu einer anderen Codierungsart, wenn der String-Typ vorher entsprechend definiert wurde), mit denen ja auch nicht alle Unicode Codepunkte erreicht werden können, aber in einem entsprechen "simplen" Programm völlig ausreichen.
-Michael

[Socke]

Weder UTF-8 noch UTF-16 komprimieren jeden Text (allgemeingültig).

Ich meinte: in den allermeisten Fällen ist UTF-8 und UTF-16 kompakter als UTF-32.

Suchst du eigentlich nach einer allgemeingültigen Möglichkeit Texte zu komprimieren oder nur für Text in bestimmten Sprachen unter Verwendung einer bestimmten Zeichenkodierung und eines bestimmten Zeichensatzes?

HTML-Entitäten sind keine allgemeine Möglichkeit um Unicode-Codepunkte/-Zeichen zu referenzieren.

Meinst Du damit, dass es nicht für alle Codepunkte eine Definition durch eine HTML-Entitäten - Zeichenfolge gibt ?

Mittels nummerischer HTML-Entitäten kann jedes Unicode-Zeichen referenziert werden; daher ist Unicode auch eine Anforderung von HTML 4.

Ist in dieser Diskussion aber kein KO für diesen Code. Delphi XE unterstützt in den dynamisch codierten Strings ja auch die diversen Varianten von ANSI (mit automatischer Konvertierung von und zu einer anderen Codierungsart, wenn der String-Typ vorher entsprechend definiert wurde), mit denen ja auch nicht alle Unicode Codepunkte erreicht werden können, aber in einem entsprechen "simplen" Programm völlig ausreichen.

Nochmals: HTML-Entitäten sind dazu da, nicht direkt verwendbare Zeichen zu "transparentisieren" (denglisch: zu escapen). Sie stellen weder einen Zeichensatz noch eine Zeichenkodierung dar. Im Gegenteil benötigen sie sogar eine solche!
HTML-Entitäten beziehen sich (seit HTML 4) immer auf Unicode-Codepoints. Die Entität selbst kann aber in einem frei wählbaren Zeichensatz und einer frei wählbaren Zeichenkodierung geschrieben werden.

[mschnell]

Mittels nummerischer HTML-Entitäten kann jedes Unicode-Zeichen referenziert werden; daher ist Unicode auch eine Anforderung von HTML 4.

Umso mehr stimmt, dass sie als Unicode-Ciodierung verwendet werden können.

Nochmals: HTML-Entitäten sind dazu da, nicht direkt verwendbare Zeichen zu "transparentisieren" (denglisch: zu escapen).

Ich diskutiere nicht "wozu sie erfunden worden sind", sondern ob man sie für als Unicode Codierung verwenden kann. und es damit theoretisch möglich ist, z.B. ein "UTF-8 <-> (Text mit Entitäten) - Umnkodier-Funktionen-Paar" zu schreiben, dass eine ähnliche "Qualität" aufweist wie die automatische Code-Convertierung bei Strings in Delphi XE (wobei wohl zusäzlich die Grund-Codierung des (Text mit Entitäten) angegeben werden muss).

Die Entität selbst kann aber in einem frei wählbaren Zeichensatz und einer frei wählbaren Zeichenkodierung geschrieben werden.

In der linken Spalte in http://unicode.e-workers.de/entities.php stehen ausschließlich 7-Bit ASCII Zeichen. Aber vielleicht gibt es ja tatsächlich alt-Ägyptischen Entitäten...

-Michael

[Socke]

Die Entität selbst kann aber in einem frei wählbaren Zeichensatz und einer frei wählbaren Zeichenkodierung geschrieben werden.

In der linken Spalte in http://unicode.e-workers.de/entities.php stehen ausschließlich 7-Bit ASCII Zeichen. Aber vielleicht gibt es ja tatsächlich alt-Ägyptischen Entitäten...

Hier beziehst du dich auf eine Liste, die aus der HTML-Definition entspringt. Die named Entities können an sich jede beliebige Zeichenfolge annehmen.

Was ich schon einige Beiträge vorher geschrieben hatte war: "ää" wird nach "ää" übersetzt, wenn eine Zeichenkodierung verwendet wird, in der das Eingabe "ä" auf das Unicode "ä" gemappt wird. "ää" in UTF-8 interpretiert als Codepage Windows-1252 als "ää" ausgegeben.
Ergebnis: Die Referenzierung über eine Entität ergibt immer das Unicode-Zeichen, unabhängig davon, welcher Zeichensatz verwendet wurde.

Mittels nummerischer HTML-Entitäten kann jedes Unicode-Zeichen referenziert werden; daher ist Unicode auch eine Anforderung von HTML 4.

Umso mehr stimmt, dass sie als Unicode-Ciodierung verwendet werden können.

Dann musst du aber noch eine Codierung angeben, in der die Nicht-Entitäten zu interpretieren sind. Andernfalls wirst du außerhalb deiner eigenen Anwendungen wenig Akzeptanz erreichen. Ansonsten siehe. unten.

Nochmals: HTML-Entitäten sind dazu da, nicht direkt verwendbare Zeichen zu "transparentisieren" (denglisch: zu escapen).

Ich diskutiere nicht "wozu sie erfunden worden sind", sondern ob man sie für als Unicode Codierung verwenden kann. und es damit theoretisch möglich ist, z.B. ein "UTF-8 <-> (Text mit Entitäten) - Umnkodier-Funktionen-Paar" zu schreiben, dass eine ähnliche "Qualität" aufweist wie die automatische Code-Convertierung bei Strings in Delphi XE (wobei wohl zusäzlich die Grund-Codierung des (Text mit Entitäten) angegeben werden muss).

Wenn das so ist ... dann kann ich den Text direkt in UTF-32 mit BOM abspeichern. Dann spare ich sogar noch Speicherplatz und jede Menge Rechenzeit.

[mschnell]

Ergebnis: Die Referenzierung über eine Entität ergibt immer das Unicode-Zeichen, unabhängig davon, welcher Zeichensatz verwendet wurde.

Klar, weil die Zeichenfolge zwischen & und ; 7-Bit ASCII ist, was in allen normalen Zeichensätzen gleich interpretiert wird. Aber Du hast natürlich recht, dass diese Zeichen in unterschiedlichen Codierungen auch mit anderen Bitfolgen als in UTF-8 und ANSI codiert sein können (in UTF-16 und UTF-32 mit 8 oder 24 0 Bits mehr, und wiederum abhängig von high oder low Endian Darstellung.

Wenn das so ist ...

Sinn der Diskussion war nicht eine technisch optimierte Methodik für den Umgang mit Strings zu finden, sondern aufzuzeigen, dass die dynamisch kodierten Strings das Potential haben, auf jede Menge weiter Codierungen erweitert zu werden (HTML Entities war nur ein Beispiel). Wenn man also (wieder zum Beispiel) ein "GGI" - Programm macht, das mit einem Browser sprechen soll, oder umgekehrt ein Programm das auf Webseiten auf einem Server zugreifen soll, wäre es durchaus praktisch, wenn eine solche Unterstützung eingebaut wäre, und der Pascal Programmierer sich nicht um die Umcodierung kümmern müsste wenn er HTML-Texte absetzen oder empfangene HTML-Texte weiterverarbeiten möchte, sondern einfach den Passenden String-Typ verwenden kann. (In solchen Anwendungen ist Performance i.A. unkritisch, ein erfahrener Programmierung kann aber die Performance tunen indem er die passenden Typen in den richtigen Aktionen verwendet.)

-Michael