Tach!
Wobei die Zeichenkodierung im Grunde genommen ja auch nur eine Typisierung ist, was UTF-32 abstrahiert bzw. andeutet:
Um in einer Datei ein bestimmte Zeichen zu finden, würde es, wenn sichergestellt ist daß jedes Zeichen mit genau 4 Byte kodiert ist, genügen die Datei in Schritten von genau 4 Byte zu lesen. Ansonsten müsste man, da es ja auch Zeichen mit 1 Byte Länge gibt, die Datei in Schritten von 1 Byte lesen.
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. Der File-Reader liest die Datei/den Stream entsprechend der Zeichenkodierung und liefert nur noch einen String oder allgemein gesagt eine Folge von Unicode-Zeichen, wobei der Datentyp des Zeichen wegabstrahiert hat, wie es intern im Speicher liegt. Nun interpretiert man nur noch zeichenweise, ohne darüber nachdenken zu müssen, ob das Ding als ein oder mehrere Bytes dahergekommen ist, weil das auf dieser Ebene der Verarbeitung nicht mehr relevant ist.
Auf diese Weise kann man Systeme wie Javascript schaffen, die größtenteils (sprich: solange es nicht um einen Transport von und nach extern geht) ohne Betrachtung/Beachtung irgendwelcher Zeichenkodierung auskommen. Das macht das Arbeiten damit einfacher, weil man sich nicht noch um einen Nebenschauplatz kümmern muss.
Somit ist abstrakt gesehen die Zeichenkodierung im Gunde genommen eine Typisierung und wenn es Letztere nicht geben würde, wäre ist nicht möglich eine CSV-Datei am Trennzeichen zu splitten oder eine XML-Datei zu parsen.
Seh ich nicht zwangsläufig so, weil man Dekodierung und anschließendes Interpretieren arbeitstechnisch und damit auch gedanklich voneinander trennen kann.
dedlfix.