Tach!
Um die Sache zu vereinfachen, behandelt man heutzutage die Zeichenkodierung getrennt von der Struktur der Daten, solange es sich durchgängig um ein Textformat mit derselben Kodierung handelt, wie es zum Beispiel bei XML oder JSON der Fall ist.
Genau. Die zur Strukturierung verwendeten Zeichen haben deswegen stets eine bekannte Länge, z.B. 1 Byte.
Nein, nichts mit "genau". Meine Aussage war eine andere. Ich sehe da auch keinen kausalen Zusammenhang. Es liegt wohl vielmehr in der Verfügbarkeit dieser Zeichen auf der Tastatur begründet.
Und da ASCII schon immer eine Teilmenge der für XML/JSON zwingend vorgesehenen Deklaration einer Kodierung ist, müssen solche Dateien im Fall einer UTF-8-Kodierung in Schritten von 1 Byte gelesen werden. Ansonsten würde der Parser diese Zeichen nicht finden.
Auch hier wieder nein, der Parser in meiner Argumentation arbeitet nicht mit Bytelängen, weil er bereits die Zeichen bekommt und die internen physikalisch-technisch bedingten Merkmale der Daten für ihn uninteressant sind. Wie der Zugriff im Speicher zu erledigen ist, wissen die Systemfunktionen, derer er sich bedient. Der Parser braucht dazu kein Wissen. Natürlich kann man aus Optimierungsgründen diese Trennung aufgeben, der Preis ist dann aber ein Code, der mehrere Aufgaben zu erledigen hat. Davon geht man aber lieber weg, weil es eine unnötig hohe Komplexität auf eine Stelle konzentriert.
Zudem ist ein Arbeiten anhand von Bytelängen ja nur bei auf ASCII basierenden Kodierungen möglich. Es gibt andere Kodierungen, bei denen sind die ASCII-Zeichen nicht vorwärts und rückwärts eindeutig anhand ihres Bytewertes erkennbar. Man möchte auch nicht für jede Kodierung einen eigenen Parser schreiben. Deswegen erst dekodieren und dann unabhängig von der Transportkodierung interpretieren.
Die Typisierung ist eine Grundvoraussetzung für den wahlfreien Zugriff und dafür dass Daten gespeichert sowie transportiert werden können
Wahlfreier Zugriff - in dem Sinne, dass man genau berechnen kann, wo bestimmte Daten liegen - ist heutzutage nicht mehr so wichtig. Das hat man damals in den 70/80/90ern gebraucht, weil da die Technik noch nicht so schnell und Speicher teuer und damit knapp war. Heutzutage ist es wesentlich unkomplizierter, auch mit sequenziellen Daten zu arbeiten.
Ich sehe auch keine zwingende Notwendigkeit, einen Typ wissen zu müssen, um Daten zu transportieren. Der Mensch speichert und übermittelt schon seit langer Zeit erfolgreich Informationen, ohne sich über Typisierungen Gedanken zu machen. Meist bestimmt nur der Kontext, wie die Daten zu interpretieren sind. Aber auch bei einigen der heute üblichen Datenübertragungen spielt ein Typ keine Rolle. Zwei Beispiele:
http://example.com/path?foo=bar;qux=42 -> keine Typen, lediglich Trennzeichen.
foo;bar;23
bla;fasel;4711
-> CSV: Keine Typen, lediglich Trennzeichen.
Es liegt bei solchen Formaten am Empfänger, ob er die Einzeldaten in für ihn interessanten Typen ablegt oder auch nicht. Solange keine weitergehende Verarbeitung stattfindet, für die Typen einen Vorteil bieten (z.B. Berechnungen), ist ein Typ von Bestandteilen in einem Datenstrom belanglos.
dedlfix.
Tabellenkalk
dedlfix
MudGuard
Matthias Apsel