Trotzdem ist das falsch. Wenn ich in meinem Editor eine Datei öffne gibt es erstmal keine Kodierung, sie spielt also beim lesen keine Rolle. Sie spielt erst eine Rolle, wenn die Zeichen interpretiert werden sollen und das ist für mich darstellen.
Es gibt so viel eine Codierung wie bei einer existierenden umfassenden Datei.
Trotzallem sind die Daten in der Datei, immer nur eine Folge von Bytes. Also die Zahlen von 0-255, da spielt die Kodierung keine Rolle.
Aber sie spielt beim Lesen eine Rolle und ein Encoding wird immer angewendet, sobald ein type=text festgestellt wird.
Viele Editoren speichern ja extra Dateien als Metadaten zu den Files.
Während du Recht hast, dass eine Datei kein Encoding hat, und ein solches eher via charset=Kabbala von I/O zu I/O geschleift wird, ist eben die Notwendigkeit einer solchen Angabe so gross, dass sich jedes bessere Programm zu helfen sucht.
PS.
Ich bin gerade dabei, meinem CMS ein Extra-Tool für die Konversion des Charsets mitzugeben.
Ich habe hier auch verschiedene Szenarien zur Verfügung.
weil aber Encode::Guess nicht zwischen verschiedenen IDO-typen unterscheiden kann (fast jeder ISO-typ enthält definierte bytes auf allen 255 Positionen), kann ich guess nicht verwenden.
Ich muss die Kabbala bemühen. Das ist, ich muss das Encoding als Quelle anwenden, welches im CMS als Encoding angegeben wurde.
Zwei Konversionen sind vorgesehen:
Upgrade:
von einem ISO-Typ zu UTF-8.
Wie prüfe ich, dass der Input wirklich in ISO-xy vorliegt?
Ich darf ganz einfach dem CMS-Eintrag glauben. Jedes Byte erzeugt einen legalen Unicode-Punkt.
Downgrade: (der Nonsens nur wegen Perl 5.6)
Ich akzeptiere den Input als UTF-8 und encode als ISO.
Danach teste ich, ob FFFE vorhanden ist (Hinweis auf destruktive Konversion.)
(User entscheidet, ob in dem Fall die Konversion auch gespeichert wird.
Ursache war möglicherweise ein Missmatch des decode Parts)
mfg Beat
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische