Sonderzeichen • fehlerhaft

[T.Trefzger]

Hallo,
habe in einer Seite dieses Zeichen • eingesetzt.
Zunächst hatte ich das Zeichen aus einer Zeichentabelle herauskopiert.
Daraufhin bewertete der selfhtml-Validator es als ungültiges Zeichen (die Seite ist per header auf 8859-1 codiert).

Nun habe ich das Zeichen mit • definiert, jetzt sagt der Validator: Referenz auf nicht-SGML Zeichen.

Angezeigt wird es aber in beiden Fällen korrekt.

Was ist da genau fehlerhaft?

Gruss T.T.

[Der Martin]

Hi,

(die Seite ist per header auf 8859-1 codiert).
Nun habe ich das Zeichen mit • definiert, jetzt sagt der Validator: Referenz auf nicht-SGML Zeichen.

völlig zu Recht. Denn die Werte 0x80..0x9F sind in ISO-8859-1 nicht definiert. Was du meinst, ist nicht ISO-8859-1, sondern Windows-1252, das im Vergleich zur ISO-Codierung die Werte 0x80..0x9F mit zusätzlichen Zeichen belegt (z.B. 0x80 für das Euro-Symbol).

Entweder stellst du deine Codierung also auf Windows-1252 um, oder du suchst dir aus dem in ISO erlaubten Bereich ein anderes Zeichen aus, oder du suchst das gewünschte Zeichen in Unicode und stellst auf UTF-8 um.

Angezeigt wird es aber in beiden Fällen korrekt.

Auf einem Windows-basierten Browser? Vermutlich ja. ;-)

Ciao,
 Martin

[T.Trefzger]

danke Martin, leuchtet ein,

daher noch eine Nachfrage:

Nach welchen Gesichtspunkten sollte man bei welchen Webprojekten welchen Zeichensatz verwenden?

Gruss T.T.

[D.R.]

Hallo,

danke Martin, leuchtet ein,

daher noch eine Nachfrage:

Nach welchen Gesichtspunkten sollte man bei welchen Webprojekten welchen Zeichensatz verwenden?

Um deine Seiten mit UTF-8 zu kodieren, solltest du einen Editor haben, der Dateien in diesem Format abspeichern kann. Das kann z.B. der Editor von Windows oder Notepad 2 (mein fav. Editor).

Wenn du HTML-kompatible XHTML-Seiten erstellst, ohne einen header zur Zeichenkodierung vom Server zu schicken, solltest du auf jeden Fall UTF-8 verwenden, da dies die Standard-Zeichenkodierung von XHTML ist.

Ansonsten gilt: UTF-8 enthält alle Unicode-Zeichen. Damit die alle dargestellt werden können, sind Sonderzeichen größer als 1 Byte, während alle ASCII-Zeichen weiterhin nur einen Byte belegen.

Fazit: du kannst ALLE Zeichen (außer HTML-Steuerzeichen wie „&“ „<“ oder „>“) direkt notieren, ohne dass die Dateien merklich größer werden.

mfg. Daniel

[T.Trefzger]

Hallo Daniel,

wie man utf-8 abspeichert wusste ich, wollte nur wissen, wann was benutzt werden sollte. Danke für die Erklärung.

Wenn ich allerdings utf-8 benutze, werden alle Umlaute mit einem ? dargestellt. Wie ist das zu umgehen?

Gruss T.T.

[D.R.]

Hallo,

wie man utf-8 abspeichert wusste ich, wollte nur wissen, wann was benutzt werden sollte. Danke für die Erklärung.

Wenn ich allerdings utf-8 benutze, werden alle Umlaute mit einem ? dargestellt. Wie ist das zu umgehen?

Normalerweise nicht. Höchstens wenn du die Datei eben NICHT UTF-8 kodierst, selbige aber als UTF-8 auslieferst. Du meinst doch sowas oder?

Ansonsten wäre irgend ein Beispiel interessant. Meine Webseite liefere ich übrigens als UTF-8 aus.

Ach und nochwas: falls du statische (X)HTML-Dateien verwendest, solltest du sicherstellen, dass dein Provider keine ISO-Charset-Angabe im Header mitschickt.
Falls du Firefox und die Web-Developer-Toolbar hast, kannst du das ganz einfach herausfinden: Informationen > Antwort-Header anzeigen.

mfg. Daniel

[Der Martin]

Hallo,

Wenn ich allerdings utf-8 benutze, werden alle Umlaute mit einem ? dargestellt.

nein, das passiert nur dann, wenn du eine in ISO-xxxx codierte Datei hast und deinem Browser vorlügst, sie sei in UTF-8 codiert. Die Bytewerte, die in der ISO-Codierung z.B. die deutschen Umlaute darstellen, sind in UTF-8 nicht definiert.

Wie ist das zu umgehen?

Quelldatei im Editor öffnen und als UTF-8 neu speichern.
Oder hast du etwa nur immer die meta-Angabe im HTML-Kopf geändert? Das genügt nicht! Du kannst auf eine Haferflockenpackung zwar "Erdnüsse" draufschreiben, davon sind aber noch keine Erdnüsse drin. ;-)

Ciao,
 Martin

[Der Martin]

Hi,

Nach welchen Gesichtspunkten sollte man bei welchen Webprojekten welchen Zeichensatz verwenden?

das könnte hier in eine lange Diskussion ausarten. ;-)
Generell ist ISO-8859-1 (Windows-Bezeichnung: "Westeuropäisch ISO") sehr verbreitet und enthält die meisten Zeichen, die in mittel- und westeuropäischen Sprachen verwendet werden. Aber eben nicht alle.
Windows-1252 hat ein paar mehr, aber die Unterstützung außerhalb der Windows-Welt ist unsicher.

Mit UTF-8 bist du insofern fein raus, als damit Tausende von Zeichen darstellbar und definiert sind, aber es gibt eben immer noch eine Menge Software (vor allem im Windows-Bereich), die UTF-8 nicht unterstützt. Auch PHP tut sich da teilweise noch etwas schwer, bei den Stringfunktionen gibt es gelegentlich Stolperfallen.

Ich persönlich mag UTF-8 nicht, weil damit die Regel "Ein Byte, ein Zeichen", die für mich viele Jahre lang fast schon ein Dogma war, nicht mehr gilt; die Anzahl der Bytes pro Zeichen ist nicht einmal mehr konstant. Ein Zeichen wird hier mit bis zu 4 Bytes codiert. Das macht den Umgang mit UTF-8 aufwendiger als mit konstant-8bit-Codierungen und führt an den Übergabestellen u.U. zu Problemen, wenn eines der beteiligten Systeme kein UTF-8 kennt.
Wenn man aber durchgängig in ALLEN Komponenten (Editor, Webserver, PHP, ggf. Datenbank) konsequent UTF-8 verwendet, dürfte das die zukunftssichere Methode sein.

So long,
 Martin

[Gunnar Bittersmann]

Hello out there!

Windows-1252 hat ein paar mehr, aber die Unterstützung außerhalb der Windows-Welt ist unsicher.

Mir ist noch kein Browser begegnet, der das nicht könnte. (Selbst so einer wie Konqueror unter Linux kommt damit klar.)

Ich persönlich mag UTF-8 nicht,

Du beschränkst dich lieber auf 223 darstellbare Zeichen und verwendest windows-1252?

Oder beschränkst dich gar auf noch weniger Zeichen (ISO 8859-1) und kannst weder vernünftige[tm] Anführungszeichen noch Gedankenstriche darstellen?

dürfte [UTF-8] die zukunftssichere Methode sein.

Das denke ich auch.

See ya up the road,
Gunnar

[Der Martin]

Hi,

Ich persönlich mag UTF-8 nicht,
Du beschränkst dich lieber auf 223 darstellbare Zeichen und verwendest windows-1252?

nein.

Oder beschränkst dich gar auf noch weniger Zeichen (ISO 8859-1) und kannst weder vernünftige[tm] Anführungszeichen noch Gedankenstriche darstellen?

Richtig. Das genügt mir.

dürfte [UTF-8] die zukunftssichere Methode sein.
Das denke ich auch.

Dieser letzte Satz war das Ergebnis meiner Bemühung, die Sache objektiv zu beurteilen. Der Rest davor war stark von meiner persönlichen Meinung durchsetzt. :)

Ciao,
 Martin

[Gunnar Bittersmann]

Hello out there!

Ich persönlich mag UTF-8 nicht, weil damit die Regel "Ein Byte, ein Zeichen", die für mich viele Jahre lang fast schon ein Dogma war, nicht mehr gilt; die Anzahl der Bytes pro Zeichen ist nicht einmal mehr konstant.

Warum auch?

Ein Zeichen in einem String (1) ist das eine; wie das Zeichen codiert gespeichert wird (2) was ganz Anderes.

Wenn man sauber programmiert, mischt man die beiden Ebenen auch nicht. Genauer gesagt, geht einen (2) überhaupt gar nichts an; man bewegt sich ausschließlich in der Ebene (1). Ein Zeichen ist ein Zeichen ist ein Zeichen, der Begriff „Byte“ existiert auf dieser Abstraktionsebene gar nicht.

Die Umwandlung der Zeichen in die Bytewerte ist Sache des Systems (Interpreters/Compilers der verwendeten Programmiersprache), nicht die des Programmieres.

See ya up the road,
Gunnar

[Der Martin]

n'Abend,

Ein Zeichen in einem String (1) ist das eine; wie das Zeichen codiert gespeichert wird (2) was ganz Anderes.

da ich mich als Programmierer häufig an der Schnittstelle beider Welten befinde, interessieren sie mich auch beide.

Wenn man sauber programmiert, mischt man die beiden Ebenen auch nicht. Genauer gesagt, geht einen (2) überhaupt gar nichts an; man bewegt sich ausschließlich in der Ebene (1).

Im Gegenteil: Ich bewege mich häufiger auf der Ebene (2) als auf der Ebene (1).

Ein Zeichen ist ein Zeichen ist ein Zeichen, der Begriff „Byte“ existiert auf dieser Abstraktionsebene gar nicht.

Diese oft propagierte Trennung halte ich für kontraproduktiv. Sie führt u.U. zu gut strukturiertem, aber ineffizientem Code.

Die Umwandlung der Zeichen in die Bytewerte ist Sache des Systems (Interpreters/Compilers der verwendeten Programmiersprache), nicht die des Programmieres.

Nein, was du beschreibst, ist Sache des Anwenders. Der Programmierer sollte die Abbildung durchgängig bis auf Maschinenebene vor Augen haben.

Ciao,
 Martin

[Gunnar Bittersmann]

Hello out there!

Im Gegenteil: Ich bewege mich häufiger auf der Ebene (2) als auf der Ebene (1).

Du programmierst in Assembler?

Diese oft propagierte Trennung halte ich für kontraproduktiv. Sie führt u.U. zu gut strukturiertem, aber ineffizientem Code.

Oh ja, du programmierst in Assembler. Denn höhere Programmiersprachen liefern ja keine effizient ausführbare Progamme. Nieder mit den höheren Programmiersprachen!

Der Programmierer sollte die Abbildung durchgängig bis auf Maschinenebene vor Augen haben.

Nein, soll er nicht. Er soll das vor Augen haben, was in dem Modul, an dem er gerade arbeitet, relevant ist. Und wenn in dem Modul Zeichenketten verarbeitet werden, ist es schnurzpiepegal, wie diese Zeichen im Speicher als Oktetts codiert abgelegt werden.

See ya up the road,
Gunnar

[Der Martin]

Hallo,

Du programmierst in Assembler?

überwiegend C, aber viel mit Assembler gemischt.

Oh ja, du programmierst in Assembler. Denn höhere Programmiersprachen liefern ja keine effizient ausführbare Progamme.

Richtig - IMHO ist C hart an der Grenze, aber noch ein brauchbarer Kompromiss.

Er [der Programmierer] soll das vor Augen haben, was in dem Modul, an dem er gerade arbeitet, relevant ist. Und wenn in dem Modul Zeichenketten verarbeitet werden, ist es schnurzpiepegal, wie diese Zeichen im Speicher als Oktetts codiert abgelegt werden.

Genau das führt zur Programmierung im Scheuklappenstil. Bloß nicht sehen, was in der Ebene darüber oder darunter abläuft. Die Modularisierung und Abstraktion so weit zu treiben, halte ich für absurd. Das ist in der Theorie eine glänzende Sichtweise, aber praxisfeindlich.

Gute Nacht erstmal,
 Martin

[Gunnar Bittersmann]

Hello out there!

Richtig - IMHO ist C hart an der Grenze, aber noch ein brauchbarer Kompromiss.

Für wirklich zeitkritische Anwendungen/Teile. Diese machen i.a.R. nur  einen Bruchteil aus.

Genau das führt zur Programmierung im Scheuklappenstil. Bloß nicht sehen, was in der Ebene darüber oder darunter abläuft. Die Modularisierung und Abstraktion so weit zu treiben, halte ich für absurd. Das ist in der Theorie eine glänzende Sichtweise, aber praxisfeindlich.

Im Gegenteil. Es geht in der Praxis gar nicht anders als im „Scheuklappenstil“; jedenfalls nicht bei umfangreicher Software und wenn mehrere Programmierer an ihr arbeiten.

Jeder Programmierer kümmert sich um sein Modul. Dabei ist es ihm völlig Wurst, wie andere Module auf gleicher, höherer oder tieferer Ebene implementiert sind. Was zählt, sind wohl definierte Schnittstellen.

See ya up the road,
Gunnar

[Der Martin]

Moin,

Richtig - IMHO ist C hart an der Grenze, aber noch ein brauchbarer Kompromiss.
Für wirklich zeitkritische Anwendungen/Teile. Diese machen i.a.R. nur  einen Bruchteil aus.

alle Anwendungen/Teile sind zeitkritisch. Lieber nehme ich mir beim Entwurf oder bei der Implementierung ein paar Stunden mehr Zeit, als dass ich (oder andere Benutzer des Programms) mich später monatelang darüber ärgere, dass die Anwendung träge ist oder unnötig viel Speicher braucht.

Im Gegenteil. Es geht in der Praxis gar nicht anders als im „Scheuklappenstil“; jedenfalls nicht bei umfangreicher Software und wenn mehrere Programmierer an ihr arbeiten.

Nein, das ist Unsinn. Jeder Programmierer muss auch mit seinen "Nachbarn" zusammenarbeiten. Also müssen die Schnittstellen zwischen interagierenden Modulen so definiert werden, dass sie für beide Seiten praktikabel und sinnvoll sind. Das geht nicht, wenn man sich nur auf sein eigenes zugewiesenes Modul beschränkt und danach schreit "ich will das Datenformat aber so haben".

Jeder Programmierer kümmert sich um sein Modul. Dabei ist es ihm völlig Wurst, wie andere Module auf gleicher, höherer oder tieferer Ebene implementiert sind. Was zählt, sind wohl definierte Schnittstellen.

Eben, und die werden auf der Basis eines gemeinsamen Kompromisses zwischen den Modulen definiert, andernfalls würde man mindestens einem der Programmierer unnötig Knüppel zwischen die Beine werfen. Dadurch wird die Realisierung des Projekts aufwendiger, braucht mehr Zeit, und das fertige Programm wird umfangreicher und schwerfälliger, ohne einen Mehrwert zu bieten.

Schönen Sonntag noch,
 Martin

[Gunnar Bittersmann]

Hello out there!

alle Anwendungen/Teile sind zeitkritisch.

Nein. Mit zeitkritisch meine ich _wirklich_ zeitkritisch.

Ob eine Anwendung für die Reaktion auf einen Tastendruck des Nutzers eine oder drei Millisekunden braucht, ist ziemlich egal, da in dieser Zeit keine weiteren Tastendrücke erfolgen.

Lieber nehme ich mir beim Entwurf oder bei der Implementierung ein paar Stunden mehr Zeit, als dass ich (oder andere Benutzer des Programms) mich später monatelang darüber ärgere, dass die Anwendung träge ist oder unnötig viel Speicher braucht.

Ja, das sollte man auch bei modalem Programmieren tun.

Nein, das ist Unsinn. Jeder Programmierer muss auch mit seinen "Nachbarn" zusammenarbeiten. Also müssen die Schnittstellen zwischen interagierenden Modulen so definiert werden, dass sie für beide Seiten praktikabel und sinnvoll sind. Das geht nicht, wenn man sich nur auf sein eigenes zugewiesenes Modul beschränkt und danach schreit "ich will das Datenformat aber so haben".

Nein, das ist Unsinn. Die Schnittstelle wird möglicherweise von einem Dritten bestimmt, völlig außerhalb der Reichweite der Programmierer des einen oder des anderen Moduls.

Und die Schnittstellen werden wohl nicht danach definiert, was sich der eine oder der andere Programmierer für sein Modul wünscht, sondern anhand der Daten, die in den Modulen verfügbar sein müssen.

Eben, und die werden auf der Basis eines gemeinsamen Kompromisses zwischen den Modulen definiert,

Eben nicht.

andernfalls würde man mindestens einem der Programmierer unnötig Knüppel zwischen die Beine werfen. Dadurch wird die Realisierung des Projekts aufwendiger, braucht mehr Zeit, und das fertige Programm wird umfangreicher und schwerfälliger, ohne einen Mehrwert zu bieten.

Der Mehrwert ist lesbarer Code, sind einfache Schnittstellen. Ein Modul hat eine bestimmte Aufgabe: bekommt Daten, verarbeitet sie und stellt das Ergebnis zur Verfügung. Wenn die Implementation eines Moduls bei komplizierterer Schnittstelle einfacher sein sollte, würde ich diesen minimalen scheinbaren Vorteil auf jedem Fall der Einfachheit der Schnittstelle opfern.

See ya up the road,
Gunnar

[Der Martin]

Hallo,

Ob eine Anwendung für die Reaktion auf einen Tastendruck des Nutzers eine oder drei Millisekunden braucht, ist ziemlich egal, da in dieser Zeit keine weiteren Tastendrücke erfolgen.

ob eine Anwendung aber schon nach drei Millisekunden wieder bereit ist, ein Datenpaket über eine Schnittstelle zu empfangen oder erst nach zehn, kann für den späteren Einsatzfall durchaus entscheidend sein. Das Ziel sollte daher IMO *immer* sein, Software so zu implementieren, dass sie bei gegebener Hardware- und Systemumgebung das Optimum an Performance erreicht. Das bedeutet z.B., dass Daten in dem Format gespeichert und übertragen werden, das für die Verarbeitung am besten geeignet ist. Immer davon ausgehen, dass der spätere Anwender eine Hardware-Plattform hat, die den Anforderungen nur gerade so eben genügt.

Ja, das sollte man auch bei modalem Programmieren tun.

Modal? Du meintest modular? Wenn du wirklich "modal" meintest, erklär bitte, was du darunter verstehst.

Nein, das ist Unsinn. Die Schnittstelle wird möglicherweise von einem Dritten bestimmt, völlig außerhalb der Reichweite der Programmierer des einen oder des anderen Moduls.

Auch das kann vorkommen - wenn es um Schnittstellen des entstehenden Software-Projekts zur Außenwelt geht. Aber wir sprachen ja von internen Schnittstellen der einzelnen Module untereinander. Da hat kein Dritter reinzupfuschen, der mit dem Projekt gar nichts zu tun hat.

Und die Schnittstellen werden wohl nicht danach definiert, was sich der eine oder der andere Programmierer für sein Modul wünscht, sondern anhand der Daten, die in den Modulen verfügbar sein müssen.

Richtig, und sie werden dann so definiert, dass die Module auf beiden Seiten der Schnittstelle so effizient wie möglich implementiert werden können.

Wenn die Implementation eines Moduls bei komplizierterer Schnittstelle einfacher sein sollte, würde ich diesen minimalen scheinbaren Vorteil auf jedem Fall der Einfachheit der Schnittstelle opfern.

Auf keinen Fall. An erster Stelle der Prioritäten steht für mich immer die Leistungsfähigkeit des fertigen Produkts. Dazu gehört auch, dass interne Abläufe technisch optimiert und sauber dokumentiert werden. An zweiter Stelle wird man sich dann bemühen, den Code auch noch "schön" zu machen - wobei nach einer kurzen Eingewöhnungsphase (und wenn man fähig ist, hardwarenah zu denken) C-Code in vielen Fällen umso besser lesbar und verständlich ist, je "optimierter" er ist.
Und erst an der Mensch-Maschine-Schnittstelle sollte man anfangen, den Aspekt "Mensch" den technischen Bedürfnissen überzuordnen - nicht durchgängig in allen Ebenen.

Ciao,
 Martin

[Gunnar Bittersmann]

Hello out there!

ob eine Anwendung aber schon nach drei Millisekunden wieder bereit ist, ein Datenpaket über eine Schnittstelle zu empfangen oder erst nach zehn, kann für den späteren Einsatzfall durchaus entscheidend sein.

ACK. (Pun intended.)

Das ist zeitkritisch. Da mag etwas Assemblercode oder hardwarenaher C-Code angebracht sein.

Das Ziel sollte daher IMO *immer* sein, Software so zu implementieren, dass sie bei gegebener Hardware- und Systemumgebung das Optimum an Performance erreicht.

Nein. Bei zeitunkritischen Programmteilen steht Lesbarkeit und Wartbarkeit in Vordergrund. Der ursprüngliche Programmierer kann bei späteren Änderungen längst nicht mehr da sein.

Zu den Stärken von OOP gehört sicher nicht die Erzeugung des schnellsten  Programmcodes.

Modal? Du meintest modular? Wenn du wirklich "modal" meintest, erklär bitte, was du darunter verstehst.

Einen Typo. Ich meinte modular.

Aber wir sprachen ja von internen Schnittstellen der einzelnen Module untereinander. Da hat kein Dritter reinzupfuschen, der mit dem Projekt gar nichts zu tun hat.

Da sprach ich auch von. Wer sagt, dass der dritte nichts mit dem Projekt zu tun hat? Nur eben gerade nicht mit der Implementierung der beiden Module.

Richtig, und sie werden dann so definiert, dass die Module auf beiden Seiten der Schnittstelle so effizient wie möglich implementiert werden können.

Nein, das kann nicht Sinn des Schnittstellendesigns sein (jedenfalls nicht der vordringlichste).

Wenn die Implementation eines Moduls bei komplizierterer Schnittstelle einfacher sein sollte, würde ich diesen minimalen scheinbaren Vorteil auf jedem Fall der Einfachheit der Schnittstelle opfern.

Auf keinen Fall.

Aber auf jeden.

An erster Stelle der Prioritäten steht für mich immer die Leistungsfähigkeit des fertigen Produkts.

Von der du gar nichts hast, wenn notwendige Änderungen später kaum zu machen sind.

(und wenn man fähig ist, hardwarenah zu denken) C-Code in vielen Fällen umso besser lesbar und verständlich ist, je "optimierter" er ist.

Das kann nicht dein Ernst sein.

See ya up the road,
Gunnar

[Der Martin]

Mahlzeit,

Bei zeitunkritischen Programmteilen steht Lesbarkeit und Wartbarkeit in Vordergrund. Der ursprüngliche Programmierer kann bei späteren Änderungen längst nicht mehr da sein.

macht ja nichts - dann ist ein anderer da, der aber auch Fachmann ist und mit dem Code zurechtkommt. Wenn nicht, soll er sich bitte einarbeiten.

Wer sagt, dass der dritte nichts mit dem Projekt zu tun hat? Nur eben gerade nicht mit der Implementierung der beiden Module.

Dann hat er aber an genau der Stelle, nämlich an der Schnittstelle dieser beiden Module, nichts verloren und soll sich raushalten. Das sollen bitte nur diejenigen, die an der Stelle überhaupt mitwirken, unter sich ausmachen. Die Aussage gilt entsprechend, wenn an einer Schnittstelle nicht nur zwei, sondern mehr Module zusammentreffen.

und sie werden dann so definiert, dass die Module auf beiden Seiten der Schnittstelle so effizient wie möglich implementiert werden können.
Nein, das kann nicht Sinn des Schnittstellendesigns sein (jedenfalls nicht der vordringlichste).

Dir scheint nicht bewusst zu sein, dass die Welt nicht nur aus Hochleistungscomputern besteht. Im Gegenteil: Der Anteil an Microcontrollern und Embedded-PCs ist wesentlich höher als der von Desktop-PCs und noch leistungsfähigeren Maschinen. Was in der µC-Welt notwendige Pflicht ist -nämlich das bewusste Haushalten mit den verfügbaren Ressourcen- ist im PC-Bereich auch nicht falsch, wenn auch vielleicht unkonventionell.

An erster Stelle der Prioritäten steht für mich immer die Leistungsfähigkeit des fertigen Produkts.
Von der du gar nichts hast, wenn notwendige Änderungen später kaum zu machen sind.

Warum? Hast du ein Problem, zielgerichtet und kompakt formulierten Programmcode nachzuvollziehen? Saubere Dokumentation vorausgesetzt, versteht sich. Daran hapert's leider oft.

(und wenn man fähig ist, hardwarenah zu denken) C-Code in vielen Fällen umso besser lesbar und verständlich ist, je "optimierter" er ist.
Das kann nicht dein Ernst sein.

Mein voller Ernst. Als Beispiel eine generische Funktion, die für ihre Aufgabe einen Speicherbereich als Puffer braucht, der optional von der aufrufenden Funktion vorgegeben werden kann. Im Erfolgsfall möge die Funktion einen Zeiger auf den Puffer zurückgeben, sonst NULL:

Beispiel 1:
  BYTE *DoSomething(BYTE *UserBuffer, WORD size)
   { BYTE *buffer;
     if (UserBuffer!=NULL)
      { buffer = UserBuffer;
      }
     else
      { buffer = malloc(size);
      }
     if (buffer==NULL)
      { return (NULL);
      }
     // weitere Verarbeitung
     return (buffer);
   }

Beispiel 2:
  BYTE *DoSomething(BYTE *UserBuffer, WORD size)
   { BYTE *buffer;
     if (buffer=(UserBuffer ? UserBuffer : malloc(size)))
      { // weitere Verarbeitung
      }
     return (buffer);
   }

Ich weiß ja nicht, wie es dir geht - aber für mich ist die zweite Variante wesentlich klarer und besser lesbar. Bei der ersten geht wegen der vielen Einzelschritte leicht der Zusammenhang und damit der Überblick verloren.
Und ich bin mir mit meinen Kollegen über diesen kompakten Stil ziemlich einig. Die beiden Neuen, die im Lauf der Jahre dazukamen, fanden es zwar anfangs etwas schwer, sich an den "harten" Stil zu gewöhnen; mittlerweile vertreten sie ihn aber ebenso überzeugt wie ich, weil sie gemerkt haben, dass man sich dabei leichter auf das Wesentliche konzentrieren kann.

Schönen Tag noch,
 Martin

[molily]

Hallo,

Er [der Programmierer] soll das vor Augen haben, was in dem Modul, an dem er gerade arbeitet, relevant ist. Und wenn in dem Modul Zeichenketten verarbeitet werden, ist es schnurzpiepegal, wie diese Zeichen im Speicher als Oktetts codiert abgelegt werden.

Genau das führt zur Programmierung im Scheuklappenstil. Bloß nicht sehen, was in der Ebene darüber oder darunter abläuft. Die Modularisierung und Abstraktion so weit zu treiben, halte ich für absurd. Das ist in der Theorie eine glänzende Sichtweise, aber praxisfeindlich.

Ganz im Gegenteil. Frühere Software im Web war bewusst Byte-basiert geschrieben, womit implizit ein Zeichensatz samt Kodierung hartkodiert wurde. Zeichenketten wurden als Byteketten begriffen. Das System war geschlossen und für immer und ewig festgelegt. Internationalisierung war unmöglich, für mehr als 256 Zeichen (brutto) mussten Kodierungen in der Kodierung erfunden werden. Man denke an Webseiten, Mails, Chat, Foren, Gästebücher und sonstige Webanwendungen - alle festgenagelt auf bestimmte sich ausschließende Zeichensätze. *Das* hat sich als praxisfeindlich herausgestellt.

Was auf Byteebene abläuft, ist in fast allen Fällen wirklich egal - gute Schnittstellen und Formate arbeiten mit definierten Kodierungen. Und gute Software legt sich entweder auf eine universale Möglichkeit zur Kodierung fest oder ist tolerant gegenüber verschiedenen - die dann aber angegeben sein müssen. Konvertierung erfolgt automatisch. Solche Software braucht sich im Idealfall nicht mehr um die Speicherung in Nullen und Einsen zu kümmern, es geht schließlich um Zeichen.

Mathias

[Gunnar Bittersmann]

Hello out there!

Denn die Werte 0x80..0x9F sind in ISO-8859-1 nicht definiert.

Natürlich sind sie das. Das sind Codierungen für die UCS/Unicode-Zeichen U+0080 bis U+009F. Allesamt keine darstellbaren Zeichen, sondern Steuerzeichen. U+0095 ist bspw. MESSAGE WAITING.

Was du meinst, ist nicht ISO-8859-1, sondern Windows-1252, das im Vergleich zur ISO-Codierung die Werte 0x80..0x9F mit zusätzlichen Zeichen belegt (z.B. 0x80 für das Euro-Symbol).

So weit, so gut ...

Entweder stellst du deine Codierung also auf Windows-1252 um, oder du suchst dir aus dem in ISO erlaubten Bereich ein anderes Zeichen aus, oder du suchst das gewünschte Zeichen in Unicode und stellst auf UTF-8 um.

... aber das ist Unsinn. Du verwechselst Zeichensatz (UCS/Unicode) und Zeichencodierung.

'&#x95;' referenziert IMMER (unabhängig von der Zeichencodierung!) auf U+0095; nicht (zwangläufig) auf das Zeichen, das in der verwendeten Codierung durch das Oktett 0x95 repräsentiert wird.

Das Zeichen '•' (0x95 in der Codierung windows-1252) ist übrigens U+2022; in HTML gibt’s dafür auch die Entity-Referenz '&bull;'.

See ya up the road,
Gunnar

[Der Martin]

Hallo,

Denn die Werte 0x80..0x9F sind in ISO-8859-1 nicht definiert.
Natürlich sind sie das. Das sind Codierungen für die UCS/Unicode-Zeichen U+0080 bis U+009F. Allesamt keine darstellbaren Zeichen, sondern Steuerzeichen. U+0095 ist bspw. MESSAGE WAITING.

das war mir neu, dass diese Zeichen mit einer Bedeutung versehen sind, danke.

Du verwechselst Zeichensatz (UCS/Unicode) und Zeichencodierung.

Ich halte die Unterscheidung von Zeichensatz und Zeichencodierung schon seit jeher für Unsinn (für mich gehört beides untrennbar zusammen) und mache mir daher gar nicht erst die Mühe, das zu unterscheiden.

So long,
 Martin

[molily]

Hallo,

Ich halte die Unterscheidung von Zeichensatz und Zeichencodierung schon seit jeher für Unsinn (für mich gehört beides untrennbar zusammen) und mache mir daher gar nicht erst die Mühe, das zu unterscheiden.

Vielleicht solltest du damit anfangen und dir die Mühe machen, sonst lässt sich nämlich gar nichts davon verstehen, was Gunnar an deinem Posting korrigiert hat.

Im Übrigen ist die Unterscheidung ziemlich trivial:

Ein Zeichensatz (wie Unicode) ist eine Liste, die gewissen Zeichen erst einmal Nummern zuweist. Dann sind in dieser Liste noch viele weitere Informationen zu den Zeichen gespeichert, sodass Unicode letztlich eine riesige Datenbank ist.

Eine Kodierung beschreibt, wie man mit Nullen und Einsen diese Zeichen (genauer gesagt deren Unicode-Nummern) kodiert, also im Computer darstellt und speichert. Je nach Kodierung können nur einige bis alle Zeichen aus Unicode kodiert werden (Zeichenvorrat).

Natürlich gehört beides zusammen, aber erst die Unterscheidung lässt verstehen, wie numerische Zeichenreferenzen in (X)HTML/XML unabhängig von der jeweiligen Dokumentkodierung funktionieren - sie verweisen nämlich auf den Zeichenvorrat von Unicode als mögliche Zeichen in (X)HTML/XML-Dokumenten und auf die in Unicode festgesetzten Zeichennummern (Codes).

Eigentlich kann der Begriff »Zeichensatz« sterben, SELFHTML habe ich z.B. so modifiziert, dass nur noch von Zeichen-/Codetabellen, Kodierungen und Zeichenvorrat einer Kodierung die Rede ist. Der Dreischritt sollte dadurch noch immer ersichtlich sein:
1. Nummerierung aller Zeichen der Welt,
2. Auswahl von Zeichen, die mit der Kodierung kodiert werden sollen (ggf. neue, kleinere Codetabelle mit neuen Nummern/Codes, die wiederum auf Unicode verweist),
2. ein Kodierungsalgorithmus, der diese Nummern in Nullen und Einsen (Bytes) übersetzt, sodass sie wieder eindeutig dekodiert, auf die Codetabelle der Kodierung und somit auf Unicode abgebildet werden können.

Mathias

[Der Martin]

Moin Mathias,

[...] und mache mir daher gar nicht erst die Mühe, das zu unterscheiden.
Vielleicht solltest du damit anfangen und dir die Mühe machen, sonst lässt sich nämlich gar nichts davon verstehen, was Gunnar an deinem Posting korrigiert hat.

doch, ich denke schon, dass ich die Kritik und Denkweise verstehe - nur halte ich diese Denkweise für nicht angebracht bzw. in den meisten Fällen für zu kompliziert (s.u.).

Ein Zeichensatz (wie Unicode) ist eine Liste, die gewissen Zeichen erst einmal Nummern zuweist. Dann sind in dieser Liste noch viele weitere Informationen zu den Zeichen gespeichert, sodass Unicode letztlich eine riesige Datenbank ist.
Eine Kodierung beschreibt, wie man mit Nullen und Einsen diese Zeichen (genauer gesagt deren Unicode-Nummern) kodiert, also im Computer darstellt und speichert. Je nach Kodierung können nur einige bis alle Zeichen aus Unicode kodiert werden (Zeichenvorrat).

So, das klingt verständlich, danke. Und soweit war mir das auch klar. Damit ist klar, dass z.B. die Codierungen UTF-x durch unterschiedliche Repräsentation desselben Codes Zeichen aus dem Unicode-Zeichensatz auswählen.
Trotzdem halte ich es für legitim und in gewissem Maß sinnvoll, auch UTF-8 als Zeichensatz zu bezeichnen und damit den gesamten Komplex (Codierung UTF-8 und Zeichensatz Unicode) zu meinen, da die Assoziation UTF-8 -> Unicode eindeutig, wenn auch nicht umkehrbar eindeutig ist.

Ebensowenig verstehe ich, warum Gunnar Bittersmann als "Keeper of Charsets and Encodings" vehement darauf besteht, dass auch z.B. ISO-8859-x oder Windows-nnnn "nur" Zeichencodierungen seien. Sie erfüllen nämlich *beide* Teile deiner obigen Beschreibung: Sie definieren eine jeweils unterschiedliche Menge von Symbolen (auch wenn "zufällig" alle eine Teilmenge von Unicode sind), und sie definieren auch die Zuordnung von Codes und Symbolen. Dementsprechend wäre ISO-8859-1 Codierung und Zeichensatz in einem.

Natürlich gehört beides zusammen, aber erst die Unterscheidung lässt verstehen, wie numerische Zeichenreferenzen in (X)HTML/XML unabhängig von der jeweiligen Dokumentkodierung funktionieren - sie verweisen nämlich auf den Zeichenvorrat von Unicode als mögliche Zeichen in (X)HTML/XML-Dokumenten und auf die in Unicode festgesetzten Zeichennummern (Codes).

Ist das wirklich so? Meint nicht die numerische Zeichenreferenz eher das Zeichen in der Codierung des Dokuments? Steht nicht in einem Dokument, das etwa in Windows-1252 codiert ist, die NCR &#x80; für das Euro-Zeichen? Bei der Notation U+0080 ist die Zuordnung zum Zeichensatz wiederum eindeutig, da ist es definitiv *nicht* das Euro-Zeichen.

Eigentlich kann der Begriff »Zeichensatz« sterben,

Nein, der Ansicht bin ich gerade nicht. Das ist für Fälle, in denen man nicht auf die Einzelheiten der Grund- und Zwischencodierung eingehen muss (oder will), die treffendste Bezeichnung für das Gesamtkonzept vom Code bis zum Symbol - genauso, wie im Laien- und Verkäuferjargon das PC-Gehäuse mit all seinen Einbauteilen als "CPU" bezeichnet wird. Das ist eigentlich auch nicht richtig (es *enthält* u.a. auch die CPU), aber es genügt, denn aus dem Kontext versteht trotzdem jeder, was gemeint ist, ohne dass alle Beteiligten nun wissen müssten, was Mainboard, Grafikkarte, xyz-Controller sind.

Schönes Wochenende noch,
 Martin

[Gunnar Bittersmann]

Hello out there!

doch, ich denke schon, dass ich die Kritik und Denkweise verstehe - nur halte ich diese Denkweise für nicht angebracht bzw. in den meisten Fällen für zu kompliziert (s.u.).

IMHO wird es erst dann kompliziert, wenn man Zeichesatz und Zeichencodierung nicht sauber voneinander trennt.

Trotzdem halte ich es für legitim und in gewissem Maß sinnvoll, auch UTF-8 als Zeichensatz zu bezeichnen

Ich nicht. Schon der Name macht das deutlich: UTF-8 (Abk. für 8-bit Unicode Transformation Format) [Wikipedia]

Wie kann ein „Transformation Format“ eines Zeichensatzes selbst wieder ein Zeichensatz sein?

Ebensowenig verstehe ich, warum Gunnar Bittersmann als "Keeper of Charsets and Encodings" vehement darauf besteht, dass auch z.B. ISO-8859-x oder Windows-nnnn "nur" Zeichencodierungen seien.

Es sind Zeichencodierungen, Punkt. Zur Unterscheidung von diesen sollte man den entsprechenden Zeichensatz "Latin 1" nennen.

numerische Zeichenreferenzen in (X)HTML/XML […] verweisen nämlich auf […] die in Unicode festgesetzten Zeichennummern (Codes).

Ist das wirklich so? Meint nicht die numerische Zeichenreferenz eher das Zeichen in der Codierung des Dokuments? Steht nicht in einem Dokument, das etwa in Windows-1252 codiert ist, die NCR &#x80; für das Euro-Zeichen?

Nein, niemals.

Wenn du schon Zweifel an molilys und meinen Ausführungen hegst, warum liest du dann nicht erstmal nach? [HTML401 §5.3.1, XML §4.1]

Eigentlich kann der Begriff »Zeichensatz« sterben,

Wenn es sowieso immer UCS ist, braucht man ihn wirklich nicht mehr.

Nein, der Ansicht bin ich gerade nicht. Das ist für Fälle, in denen man nicht auf die Einzelheiten der Grund- und Zwischencodierung eingehen muss (oder will), die treffendste Bezeichnung für das Gesamtkonzept vom Code bis zum Symbol

Warum verweigerst du dich, dazu „Zeichencodierung“ zu sagen?

genauso, wie im Laien- und Verkäuferjargon das PC-Gehäuse mit all seinen Einbauteilen als "CPU" bezeichnet wird.

Ist das so? Hab ich noch nicht gehört. Andere Ländle, andere Sprache ...

Ich bin nicht sicher, ob ich bei einem solchen Verkäufer etwas kaufen würde.

See ya up the road,
Gunnar

[Der Martin]

Hallo Gunnar,

IMHO wird es erst dann kompliziert, wenn man Zeichesatz und Zeichencodierung nicht sauber voneinander trennt.

sehe ich nicht so - ich habe kein Problem, die beiden Dinge zu verschmelzen. Aber wenn es die Situation unbedingt erfordert -und nur dann- bin ich auch bereit und in der Lage, das zu unterscheiden.

Trotzdem halte ich es für legitim und in gewissem Maß sinnvoll, auch UTF-8 als Zeichensatz zu bezeichnen
Ich nicht. Schon der Name macht das deutlich: UTF-8 (Abk. für 8-bit Unicode Transformation Format) [Wikipedia]

Der Name macht aber ebenso deutlich, dass die Codierung untrennbar mit dem Unicode-Zeichensatz verbunden ist.

Ebensowenig verstehe ich, warum Gunnar Bittersmann als "Keeper of Charsets and Encodings" vehement darauf besteht, dass auch z.B. ISO-8859-x oder Windows-nnnn "nur" Zeichencodierungen seien.
Es sind Zeichencodierungen, Punkt. Zur Unterscheidung von diesen sollte man den entsprechenden Zeichensatz "Latin 1" nennen.

Das meine ich: Warum hast du so ein Problem, die verschiedenen Codierungen als vollkommen getrennte Systeme, eben als eigenständige Zeichensätze mit einer 1:1-Zuordnung vom Code zum Symbol zu sehen? Du krallst dich IMHO viel zu sehr an den offiziellen Bezeichnungen fest. Die mögen korrekt sein, dagegen sag' ich ja gar nichts, aber alles andere als anschaulich. Jemand, der sich mit dem Thema nicht schon jahrelang beschäftigt, tut sich viel leichter, wenn man ihm das System Code=Symbol als Zeichensatz verkauft, anstatt zwischen Codierung und Zeichensatz nochmal zu unterscheiden.

Ach, waren das noch herrlich einfache Zeiten, als der Begriff "Zeichensatz" nicht nur die Zuordnung von Codes zu Symbolen, sondern sogar noch das Aussehen jedes Symbols, also die zugehörigen Bitmap-Definitionen umfasste. Wenn in den 80er Jahren einer von meinen C64-Kumpanen erzählte, er habe "einen Zeichensatz entworfen", dann hieß dass, er hatte einen Satz von bis zu 256 Symbolen als Bitmaps angefertigt. Dass diese Symbole den Codes 0x00..0xFF zugeordnet waren, war selbstverständlich und bedurfte keiner Erwähnung.
Solche einfachen Denkmodelle wären auch mit den heutigen Systemen noch vorstellbar, aber es wird von den Theoretikern meist unnötig verkompliziert.

Wenn du schon Zweifel an molilys und meinen Ausführungen hegst, warum liest du dann nicht erstmal nach? [HTML401 §5.3.1, XML §4.1]

Weil ich nie weiß, wo genau ich im Wust von Dutzenden von Spezifikationen nach solchen Hinweisen suchen soll.

Eigentlich kann der Begriff »Zeichensatz« sterben,
Wenn es sowieso immer UCS ist, braucht man ihn wirklich nicht mehr.

Oder Latin-1, wie du weiter oben selbst eingeräumt hast.

Warum verweigerst du dich, dazu „Zeichencodierung“ zu sagen?

Ich weigere mich nicht. Ich suche nur nach anschaulichen Darstellungen, um die korrekten, aber komplizierten auch einem Laien verständlich zu machen.

genauso, wie im Laien- und Verkäuferjargon das PC-Gehäuse mit all seinen Einbauteilen als "CPU" bezeichnet wird.
Ist das so? Hab ich noch nicht gehört. Andere Ländle, andere Sprache ...

Schau dir mal Kataloge von Büromöbel-Anbietern an. Da gibt's oft spezielle Computerschreibtische, auch platzsparende Modelle für zuhause, die meistens ein separates Fach oder eine Ablage "für die CPU" haben. Das ist kein regionaler Ausdruck!

Ich bin nicht sicher, ob ich bei einem solchen Verkäufer etwas kaufen würde.

Mir wäre egal, was der mir erzählt - wenn er mir das verkauft, was ich haben möchte, und zu einem Preis, den ich akzeptieren kann. Dass Verkäufer wirklich Ahnung von dem haben, was sie verkaufen, ist leider eine rühmliche Ausnahme.

Schönen Abend noch,
 Martin

[Gunnar Bittersmann]

Hello out there!

Du krallst dich IMHO viel zu sehr an den offiziellen Bezeichnungen fest.

Die Bezeichnungen sind nun mal da. Und IMHO macht es auch Sinn, sie entsprechend zu verwenden. Nur dann können sich Sprecher (Schreiber) und Zuhörer (Leser) sicher sein, was gemeint ist.

Die mögen korrekt sein, […] aber alles andere als anschaulich.

?? Geschmackssache.

Ach, waren das noch herrlich einfache Zeiten, als der Begriff "Zeichensatz" nicht nur die Zuordnung von Codes zu Symbolen, sondern sogar noch das Aussehen jedes Symbols, also die zugehörigen Bitmap-Definitionen umfasste.

Und auch den Registersatz der CPU, da stehen ja auch Zeichen drin. Prima, wenn man ein Wort für alles verwenden kann. Nur blöd, dass keiner genau weiß, was dann mit diesem Wort gemeint ist.

Weil ich nie weiß, wo genau ich im Wust von Dutzenden von Spezifikationen nach solchen Hinweisen suchen soll.

Wenn’s um HTML geht, in der HTML-Spezifikation. Wenn’s um XML geht, in der XML-Spezifikation. Ich hatte in beiden die entsprechenden Stellen problemlos im Inhaltsverzeichnis gefunden.

genauso, wie im Laien- und Verkäuferjargon das PC-Gehäuse mit all seinen Einbauteilen als "CPU" bezeichnet wird.
Schau dir mal Kataloge von Büromöbel-Anbietern an.

Ach so, ich dachte, du meintest, Computerhändler würden solch Unsinn von sich geben.

See ya up the road,
Gunnar

[molily]

Hallo,

Solche einfachen Denkmodelle wären auch mit den heutigen Systemen noch vorstellbar, aber es wird von den Theoretikern meist unnötig verkompliziert.

Nein, sie wären heute nicht mehr vorstellbar und es wird auch nicht unnötig verkompliziert. Die alten Denkmodelle wurden von Praktikern überwunden, das ist es.

In einer »internationalisierten« Computerwelt bezieht sich letztlich alles auf den großen Nenner Unicode. In HTML, XML, JavaScript und anderen Unicode-fähigen Programmiersprachen und Speichersystemen (Datenbanken) ist Unicode und dessen Kodierungen mittlerweile Standard. Schnittstellen von Diensten benutzen aus naheliegenden Gründen Unicode-Kodierungen.

Unicode steht als Ausgangspunkt fest, und da lässt sich auch nichts didaktisch vereinfachen. Es hat auch keinen Sinn, hinter Unicode zurückzufallen und wieder zum 8-Bit-Denken zurückzukehren. Kein Webautor, selbst jemand, der nur in Deutsch schreibt, kann heutzutage nur mit 256 Zeichen (abzüglich Steuerzeichen) arbeiten (bzw. kann zwischen verschiedenen, sich ausschließenden Zeichensätzen wählen). Wer Kontakt mit Unicode vermeiden will, kann sich höchstens in einen dunklen, schalldichten Raum einschließen, aber wer im Web aktiv ist, kommt nicht drumherum.

Gut, man könnte Unicode als großen, weit entfernten Horizont erwähnen, hinter dem die Sonne auf- und untergeht. So machte es SELFHTML: Unicode gibt es zwar, aber in der Praxis betrachten wir nur 8-Bit-ISO-Codetabellen mit denkbar einfacher Kodierung (1 Bit = 1 Zeichen). Die Rückanbindung an Unicode wurde nicht näher erläutert, ebensowenig echte Unicode-Kodierungen, die nicht nochmal einen Unter-Zeichenvorrat dazwischenschieben. Man weigerte sich, die fundamentale Umwendung des Denkens durchzumachen, dass alle im Computer gespeicherten und durchs Internet gepusteten Zeichen ganz bestimmt kodiert sind.

Das war einer der Gründe, warum aus SELFHTML die ganze Chose mit den Unicode-Zeichennummern nie klar wurde, obwohl sie in HTML und JavaScript an vielen Stellen benötigt wird. Ständig kommen Leute an: Himmel, wie bringe ich jetzt die-und-die Zeichen in meinem HTML, JavaScript usw. unter? Und was hat das mit den Nummern auf sich? Wieso sind die Umlaute kaputt oder wieso sehe ich ö statt ö usw., wenn ich das-und-das mache?

Es herrschte Unwissenheit und Gleichgültigkeit gegenüber dem Thema, weil letztlich alles trotzdem zu klappen schien (»Latin-1 ist Standard und gut ist«). Leute, die sich mit dem Thema auskannten, schrieben hochkomplizierte ultra-tolerante Software, sodass sich die anderen in der Fehlertoleranz-Hängematte ausruhten.

Mittlerweile sind geordnete, strenge Datenaustauschformate im Web alles und die gegenwärtigen Massenanwendungen sind vollkommen internationalisiert. Da viele jetzt auch die Vorteile der Internationalisierung begreifen, anstatt sich mit der möglichst kleinsten, in sich geschlossenen (Insel-)Lösung zufrieden zu geben, kommt das Thema Zeichenkodierung den Menschen überhaupt erst ins Bewusstsein. Da stoßen sie auf Unicode und dessen Kodierungen und merken erst einmal, dass sie eine ganz andere Sichtweise auf Datenverarbeitung bekommen.

Das ist wichtig und gut so - eine Umkehr zur vermeintlichen »Einfachheit« der 8-Bit-Denkweise ist weder praktikabel, noch wünschenswert, noch zielführend. Wirkliche Einfachheit findet sich in Unicode: Jedes Zeichen hat eine eindeutige Nummer in einer großen, geordneten Tabelle, es gibt nicht mehr dutzende unterschiedliche Winzigtabellen mit gleichen Nummern, aber unterschiedlichen Zeichen. Und als universelle Eingabe- und Ausgabe-Kodierung nimmt man standardmäßig UTF-8, womit man in fast allen Fällen richtig liegt. Dass damit durchaus die Einfachheit der Abbildung von Zeichen auf Byte verloren geht, ist zwar schade, letztlich aber nicht so wichtig. Das hat Gunnar schön auf den Punkt gebracht: Kein Denken in Bytes mehr, sondern ein abstrahiertes Denken in Zeichen und, falls nötig, Unicode-Nummern.

Mathias