recode Fehlermeldung
Ralph Stahl
da ich folgendes vergeblich in d.c.o.linux.misc gepostet habe, hier also
nochmal. Ist ja auch mehr ein app- statt ein Linux-Problem :).
Was ist gemeint, wenn bei
recode utf-8..iso-8859-1 adressen.csv
die Fehlermeldung
recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
und folglich nicht konvertiert werden können? Die Idee der Konvertierung
kam mir nur, weil sonst beim nachfolgenden Import in OpenOffice-Calc die
Ümläute mit 2 kryptischen Byte dargestellt werden. Logisch ist das wegen
dem Folgenden eigentlich nicht:
Die Datei stammt aus einem Export von JPilot, bei dem von Haus aus die
merkwürdige Kodierung "UTF: Latin1, Western Europe (CP1252)" eingestellt
ist (was denn nun: utf oder latin1?). Die Daten stammen aus einem Palm
Pilot Z22.
Dazu am Rande noch die Frage: wie, außer durch trial+error, kann ich die
Kodierung einer Textdatei (ohne BOM) bestimmen, um sie passend
konvertieren zu können?
Ralph
Sven Joachim
> Was ist gemeint, wenn bei
>
> recode utf-8..iso-8859-1 adressen.csv
>
> die Fehlermeldung
>
> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>
> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
> und folglich nicht konvertiert werden können?
So würde ich das interpretieren, ja. Was sagt iconv(1) zu der Datei?
> Dazu am Rande noch die Frage: wie, außer durch trial+error, kann ich die
> Kodierung einer Textdatei (ohne BOM) bestimmen, um sie passend
> konvertieren zu können?
Das geht im allgemeinen nur mit Trial+Error, weil eine Textdatei gar
keine einheitliche Kodierung zu haben braucht, siehe etwa Mails im
mbox-Format.
Sven
Michael Mauch
> Was ist gemeint, wenn bei
>
> recode utf-8..iso-8859-1 adressen.csv
>
> die Fehlermeldung
>
> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>
> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
> und folglich nicht konvertiert werden können?
Ja, genau.
> Die Idee der Konvertierung
> kam mir nur, weil sonst beim nachfolgenden Import in OpenOffice-Calc die
> Ümläute mit 2 kryptischen Byte dargestellt werden.
Siehst Du diese 2 Bytes bei allen Umlauten, oder sind da doch auch schon
normal dargestellte Umlaute zu finden? Dann hättest Du ein lustiges
Mischmasch, das anscheinend weder von recode noch von iconv repariert
werden kann. iconv kennt //TRANSLIT und //IGNORE, aber leider kein
//PASSTHROUGH-IF-UNCONVERTABLE.
> Logisch ist das wegen dem Folgenden eigentlich nicht:
>
> Die Datei stammt aus einem Export von JPilot, bei dem von Haus aus die
> merkwürdige Kodierung "UTF: Latin1, Western Europe (CP1252)" eingestellt
> ist (was denn nun: utf oder latin1?). Die Daten stammen aus einem Palm
> Pilot Z22.
"UTF: Latin1, Western Europe (CP1252)" hört sich sehr merkwürdig an.
Evtl. ist damit gemeint "lass alles durch, egal wie komisch es aussieht".
> Dazu am Rande noch die Frage: wie, außer durch trial+error, kann ich die
> Kodierung einer Textdatei (ohne BOM) bestimmen, um sie passend
> konvertieren zu können?
Ausser "anschauen und raten, was es wohl ist" kann man da wohl nichts
machen.
Michael
Christian Weisgerber
> Was ist gemeint, wenn bei
> recode utf-8..iso-8859-1 adressen.csv
> die Fehlermeldung
> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>
> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
> und folglich nicht konvertiert werden können?
Entweder das, oder es sind gültige UTF-8-Zeichen enthalten, welche
die Zielkodierung nicht umfasst. Dass diese beiden verschiedenen
Fehler zur selben Meldung führen, ist ungeschickt.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Jan Kandziora
>
> Die Datei stammt aus einem Export von JPilot, bei dem von Haus aus die
> merkwürdige Kodierung "UTF: Latin1, Western Europe (CP1252)" eingestellt
> ist (was denn nun: utf oder latin1?). Die Daten stammen aus einem Palm
> Pilot Z22.
>
Müll im Eingabestring oft nicht so allergisch reagiert.
Mit freundlichem Gruß
Jan
Ralph Stahl
> Am 16.12.2008 um 20:04 schrieb Ralph Stahl:
>
>> Was ist gemeint, wenn bei
>>
>> recode utf-8..iso-8859-1 adressen.csv
>>
>> die Fehlermeldung
>>
>> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>>
>> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
>> und folglich nicht konvertiert werden können?
>
> So würde ich das interpretieren, ja. Was sagt iconv(1) zu der Datei?
Das stolpert an dem "ä" in "Geschäft", welches als e4 codiert ist. Okay,
das ist wirklich kein utf8 - was ist es dann? Desgleichen alle anderen
Ümläute. Kann ich das überhaupt so konvertieren, daß ich es in
OpenOffice einlesen kann?
Danke für den Tip mit iconv!
>> Dazu am Rande noch die Frage: wie, außer durch trial+error, kann ich die
>> Kodierung einer Textdatei (ohne BOM) bestimmen, um sie passend
>> konvertieren zu können?
>
> Das geht im allgemeinen nur mit Trial+Error, weil eine Textdatei gar
> keine einheitliche Kodierung zu haben braucht, siehe etwa Mails im
> mbox-Format.
Klar.
Ralph
Ralph Stahl
> Ralph Stahl wrote:
>
>> Was ist gemeint, wenn bei
>>
>> recode utf-8..iso-8859-1 adressen.csv
>>
>> die Fehlermeldung
>>
>> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>>
>> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
>> und folglich nicht konvertiert werden können?
>
> Ja, genau.
>
>> Die Idee der Konvertierung
>> kam mir nur, weil sonst beim nachfolgenden Import in OpenOffice-Calc die
>> Ümläute mit 2 kryptischen Byte dargestellt werden.
>
> Siehst Du diese 2 Bytes bei allen Umlauten, oder sind da doch auch schon
> normal dargestellte Umlaute zu finden? Dann hättest Du ein lustiges
> Mischmasch, das anscheinend weder von recode noch von iconv repariert
> werden kann. iconv kennt //TRANSLIT und //IGNORE, aber leider kein
> //PASSTHROUGH-IF-UNCONVERTABLE.
Ja, überall. Entweder das oder "?", je nach Einstellung von OO. Das
stammt aus z.B. E4h für "ä".
>> Logisch ist das wegen dem Folgenden eigentlich nicht:
>>
>> Die Datei stammt aus einem Export von JPilot, bei dem von Haus aus die
>> merkwürdige Kodierung "UTF: Latin1, Western Europe (CP1252)" eingestellt
>> ist (was denn nun: utf oder latin1?). Die Daten stammen aus einem Palm
>> Pilot Z22.
>
> "UTF: Latin1, Western Europe (CP1252)" hört sich sehr merkwürdig an.
> Evtl. ist damit gemeint "lass alles durch, egal wie komisch es aussieht".
<ggg> Keine Ahnung, was sich die JPilot-Erfinder dabei gedacht haben.
>> Dazu am Rande noch die Frage: wie, außer durch trial+error, kann ich die
>> Kodierung einer Textdatei (ohne BOM) bestimmen, um sie passend
>> konvertieren zu können?
>
> Ausser "anschauen und raten, was es wohl ist" kann man da wohl nichts
> machen.
Also /usr/bin/glaskugel? Prima, aber verständlich.
Ralph
Ralph Stahl
> Michael Mauch schrieb:
>> Ralph Stahl wrote:
>>
>>> Was ist gemeint, wenn bei
>>>
>>> recode utf-8..iso-8859-1 adressen.csv
>>>
>>> die Fehlermeldung
>>>
>>> recode: adressen.csv failed: Ungültige Eingabe in step `UTF-8..ISO-8859-1'
>>>
>>> auftaucht? Heißt das, daß Zeichen enthalten sind, die nicht utf-8 sind
>>> und folglich nicht konvertiert werden können?
>> Ja, genau.
>>
>>> Die Idee der Konvertierung
>>> kam mir nur, weil sonst beim nachfolgenden Import in OpenOffice-Calc die
>>> Ümläute mit 2 kryptischen Byte dargestellt werden.
>> Siehst Du diese 2 Bytes bei allen Umlauten, oder sind da doch auch schon
>> normal dargestellte Umlaute zu finden? Dann hättest Du ein lustiges
>> Mischmasch, das anscheinend weder von recode noch von iconv repariert
>> werden kann. iconv kennt //TRANSLIT und //IGNORE, aber leider kein
>> //PASSTHROUGH-IF-UNCONVERTABLE.
>
> Ja, überall. Entweder das oder "?", je nach Einstellung von OO. Das
> stammt aus z.B. E4h für "ä".
Ich muß mich korrigieren: ich habs gerade mal mit 8859-1 in OO
importiert, und da steht nun zwar "Geschäft", aber auch "Günter" (C3h
BCh, also wohl utf8) statt "Günter". Jetzt wird putzig... Also doch
Mischmasch?
[...]
Übrigens: pconv (Posting von Jan, danke!) ist tatsächlich toleranter und
läuft wenigstens durch, die bunte Mischung bekomme ich aber auch durch
hin-und-her-Konvertierung nicht weg.
Ralph
Michael Mauch
> Ich muß mich korrigieren: ich habs gerade mal mit 8859-1 in OO
> importiert, und da steht nun zwar "Geschäft", aber auch "GÃ?nter" (C3h
> BCh, also wohl utf8) statt "Günter". Jetzt wird putzig... Also doch
> Mischmasch?
Ja, sieht so aus.
> Übrigens: pconv (Posting von Jan, danke!) ist tatsächlich toleranter und
> läuft wenigstens durch, die bunte Mischung bekomme ich aber auch durch
> hin-und-her-Konvertierung nicht weg.
piconv ist interessant, mit -C -1 ("something interesting happens when
it encounters an invalid character") gibt es immerhin das erste "böse"
Zeichen aus.
Hin- und Herkonvertieren bringt's nicht, weil die UTF-8-Umlaute zwei
8-Bit-Zeichen darstellen, d.h. bei der Konvertierung l1..utf8 werden die
bestehenden UTF-8-Zeichen nochmal mitgewandelt.
Aber man kann die paar Umlaute "von Hand" in UTF-8 wandeln.
In ISO-8859-1 als "umlaut.sh" abspeichern und ausführbar machen:
#! /bin/bash
cmd=$(
printf "sed '"
for c in ä ö ü Ä Ö Ü ß ; do
printf "s/$c/$(echo "$c" | iconv -f l1 -t utf8)/g;"
done
echo "'"
)
eval "$cmd"
Die for-Schleife bastelt eine sed-Zeile zusammen, die die
ISO-8859-1-Umlaute und ß in UTF-8 übersetzt. eval für dann den
sed-Befehl aus.
Die Ausgabe von
./umlaut.sh <umlaut.txt
sollte nur noch UTF-8 enthalten.
./umlaut.sh <umlaut.txt | iconv -f utf8 -t l1
bringt das dann in UTF-8, falls nicht noch ein anderes Zeichen ausser
äöüÄÖÜß übersetzt werden müsste.
Michael
Ralph Stahl
Uiii, ist ja nen Krampf :-). Aber okay, ich probiers mal. Allerdings
werde ich vorher mal gucken, wer die bunte Mischung erzeugt, vielleicht
hab ich ja was falsch gemacht (soll vorkommen).
Danke!
Ralph
Thomas Rachel
> Hin- und Herkonvertieren bringt's nicht, weil die UTF-8-Umlaute zwei
> 8-Bit-Zeichen darstellen, d.h. bei der Konvertierung l1..utf8 werden die
> bestehenden UTF-8-Zeichen nochmal mitgewandelt.
Aber es sollte, denke ich, möglich sein, 2x von UTF8 nach latin1 zu
wandeln. Die, die nach dem ersten Mal bereits richtig waren, sollten
nach dem im Thread Geschriebenen nach dem 2. Mal so bleiben. Danach dann
einmal von latin1 nach UTF8 konvertieren und man hat was Konsistentes...
Thomas
Michael Mauch
> Michael Mauch schrieb:
>
>> Hin- und Herkonvertieren bringt's nicht, weil die UTF-8-Umlaute zwei
>> 8-Bit-Zeichen darstellen, d.h. bei der Konvertierung l1..utf8 werden die
>> bestehenden UTF-8-Zeichen nochmal mitgewandelt.
>
> Aber es sollte, denke ich, möglich sein, 2x von UTF8 nach latin1 zu
> wandeln.
Nein, das geht leider nicht, da bereits das erste Mal von UTF8 nach
latin1 nicht funktioniert:
# cat umlaut.txt
GÃŒnter
Geschäft
# iconv -f utf8 -t l1 <umlaut.txt
Günter
Geschiconv: ungültige Eingabe-Sequenz an der Stelle 13
Wie bereits angedeutet, kann man iconv zwar per //IGNORE dazu überreden,
nicht nach dem ersten unkonvertierbaren Zeichen abzubrechen. Allerdings
wird das unkonvertierbare Zeichen dabei verschluckt anstatt einfach
durchgereicht:
# iconv -f utf8 -t l1//IGNORE <umlaut.txt
Günter
Geschft
iconv: ungültige Eingabe-Sequenz an der Stelle 17
Einen "wenn Du es nicht konvertieren kannst, lass es um Himmels willen
stehen"-Schalter gibt es anscheinend nicht.
Michael