nicht angemeldet
Codierungs-"Rätsel"
MudGuard
Codierungs-"Rätsel"
MudGuard
Tabellenkalk
Auge
Rolf BHi,
ich hab hier einen Text vorliegen, der seltsam codiert ist.
- ein großes Ä ist durch die Bytes C6 und 92 dargestellt (u0192 - kleines f mit Haken)
- ein kleines ä sieht so aus: e2 80 b0 (u2030 - Promillezeichen)
- ein kleines ö ist durch die Bytes C8 und 86 dargestellt (u02c6 - Modifier Circonflex)
- das große Ü kommt mit den Bytes E2 80 B9 daher (u2039 - Single leftpointing angle quotation)
- das kleine ü kommt mit den Bytes C2 und B8 daher (u00b8 - Cedille (ohne c))
Mehr nicht-ASCII-Zeichen hab ich noch nicht gefunden.
Durch welchen Codierungsunfall kann dieses "Encoding" zustandegekommen sein?
cu,
Andreas a/k/a MudGuard
-
Hi,
ich hab hier einen Text vorliegen, der seltsam codiert ist.
- ein großes Ä ist durch die Bytes C6 und 92 dargestellt (u0192 - kleines f mit Haken)
- ein kleines ä sieht so aus: e2 80 b0 (u2030 - Promillezeichen)
- ein kleines ö ist durch die Bytes C8 und 86 dargestellt (u02c6 - Modifier Circonflex)
- das große Ü kommt mit den Bytes E2 80 B9 daher (u2039 - Single leftpointing angle quotation)
- das kleine ü kommt mit den Bytes C2 und B8 daher (u00b8 - Cedille (ohne c))
Mehr nicht-ASCII-Zeichen hab ich noch nicht gefunden.
Durch welchen Codierungsunfall kann dieses "Encoding" zustandegekommen sein?
Keine Ideen? Doppelt von ISO- nach UTF-8-codiert ist's nicht, da wäre ja das A mit Tilde und ähnliches zu sehen …
cu,
Andreas a/k/a MudGuard-
Hallo,
Keine Ideen?
Bei kreativen Codierungen kommt mir immer Apple in den Sinn. k.A. warum…
Gruß
Kalk-
Hi,
Keine Ideen?
Bei kreativen Codierungen kommt mir immer Apple in den Sinn. k.A. warum…
hm.
Die betroffenen Dateien kommen von einem Versicherer.
Da ist eher Mainframe angesagt, nicht so was modernes wie ein Apple.
Immerhin kommen die Dateien schon elektronisch, nicht mehr als Lochkarten ...
cu,
Andreas a/k/a MudGuard-
Hallo
Immerhin kommen die Dateien schon elektronisch, nicht mehr als Lochkarten ...
Mit Lochkarten könntest du deine Frage aber eventuell durch durchzählen beantworten. 😁
Tschö, Auge
--
„Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde -
Hallo MudGuard,
wenn der Übeltäter der Mainframe eines Versicherers ist, dann könnten die Herkunftsdaten EBCDIC codiert gewesen sein. Auch diesen Code gibt's in verschiedenen Codepages - Deutschland verwendet eigentlich EBCDIC 237 und die USA EBCDIC 037.
Normalerweise würde ich es ja bei solchen Codierungsunfällen mit Elvis halten: Return To Sender, This Mess Unknown - aber wenn dort irgendein COBOL Urgestein am Werk war, das froh ist, überhaupt die Daten vom Mainframe herunterbekommen zu haben, könnte es schwierig werden. Das Urgestein könnte die Datei nämlich auch per TSO Filetransfer auf seinen Computer gezogen und dort nach Belieben verunstaltet haben.
Du solltest das nicht per Reverse Engineering zu lösen versuchen. Verlange korrekt codierte Daten.
Rolf
--
sumpsi - posui - obstruxi-
Hi,
Du solltest das nicht per Reverse Engineering zu lösen versuchen. Verlange korrekt codierte Daten.
Das sowieso.
Aber ich kenne die Update-Zyklen des Versicherers (wir hatten mal im Juli eines Jahres eine neugegründete Bank, die wurde an einer Schnittstelle des Versicherers nicht erkannt. Auf die Meldung an den Versicherer im Juli bekamen wir die Antwort: ja, klar, nehmen wir auf. Kommt dann mit dem April-Release ...)
Mich hätte nur interessiert, wie es zu dieser seltsamen Codierung kommt.
cu,
Andreas a/k/a MudGuard-
Hallo MudGuard,
solange Du nicht weißt, welche Arbeitsschritte die Datei beim Lieferanten durchlaufen hat, kannst du das kaum erraten. Da gibt's soviel, was gerade bei Filetransfers Host->PC falsch konfiguriert sein oder fehlbedient werden kann… Die Systemtruppe eines Mainframes besteht typischerweise aus Leuten Baujahr < 1960, für die ein PC ein unnützes Spielzeug ist und denen File Transfers höchst suspekt sind. Codepage-Fehler sind nicht etwa ein Ding vom anderen Stern, nö, es ist ein anderer Blob im Multiversum. Und diese tief verwurzelte Fremdartigkeit stößt dann auf User, die weder vom Host noch vom PC Ahnung haben und daher nicht die geringste Ahnung haben, was sie eigentlich tun.
Ein gelungener Filetransfer ist nicht der Normal-, sondern ein Glücksfall.
Ich weiß es, ich habe Mainframes und PCs programmiert (mit Systemleuten, die umgeschulte Versicherungskaufleute aus den 60er Jahren waren) und musste oft genug Dateien übertragen. Vor meiner File-Transfer Apotheke haben sie irgendwann eine extrabreite Abflussrinne eingebaut, damit die Pferdekotze nicht ständig bis auf die Straße lief…
Seit wir die meisten Dinge vom Mainframe runtergeholt haben und in der Systemabteilung auch ein paar Leute rumlaufen, die etwas jünger sind als ich, ist es besser geworden.
Rolf
--
sumpsi - posui - obstruxi
-
-
-
-
-
Große und kleine Buchstaben, mal 3, mal zwei Bytes … mir scheint, die Bits sind da nicht zwingend zu acht angehäuft. Und stehen vielleicht auch, BOM läßt grüßen, mehr oder weniger „durcheinander“.