technoforum.de: Zeichenkonvertierung Unix

»	technoforum.de » Produktions- & DJ-Technik, Hard- & Software » Zeichenkonvertierung Unix - OS390/ZOS

Autor

Thema: Zeichenkonvertierung Unix - OS390/ZOS

harryp

Usernummer # 5896

verfasst

Hi,

könnte mal Eure Hilfe brauchen. Quäle mich auf der Arbeit schon seit Tagen mit einem Zeichenkonvertierungsproblem rum.

Wir bekomme von einem UNIX-System Daten auf CD geliefert.
Die konvertiere ich mit Ultra-Edit von Unix nach DOS.
Dann schick ich das ganze mit FTP an unseren Host.

Alle Zeichen und Umlaute werden korrekt übertragen und dargestellt.
Nur das blöde ß nicht. Da kommt auf dem Host ein "halbes Unendlichzeichen" an.
Auf dem Host kommt HEX(59) an. Richtig wäre HEX(A1)

Kann mir jemand sagen woran das liegt und wie ich das abstellen kann?

Vielen Dank schonmal

[ 29.09.2004, 20:24: Beitrag editiert von: harryp ]

Aus: Kölle | Registriert: May 2002 | IP: [logged]

PigFace
500
Usernummer # 4299

verfasst

Check

sed, gibt's auch für DOS.

[piggy]

Aus: Somewhere in the skeleton | Registriert: Nov 2001 | IP: [logged]

Cy-Man

Usernummer # 274

verfasst

Das liegt wahrscheinlich daran, daß das UNIX-System eine andere Zeichencodierungs-Tabelle verwendet - das gleiche Problem tritt noch häufig auf, wenn man z.B. reine Text-Files (.txt) von Mac nach Win verschiebt oder umgekehrt.
Ich habe vor grauer Urzeit mal kurz mit Ultra Edit gearbeitet (es gibt keine Mac-Version), ich kann mich erinnern, daß es eine relativ mächtige Suche / Ersetzen-Funktion hat. Zumindest sollte das Ersetzen von "\x59" durch "\xA1" (ohne Anführungszeichen) das ß umwandeln. Ich glaube außerdem, daß Ultra Edit Suchen/Ersetzen über ein ganzes Verzeichnis machen kann, damit hättest Du Dein Problem auf einen Schlag gelöst. Vorsicht, falls noch nicht-Text-Dateien bzw. Dateien, die nicht angerührt werden sollen, in dem Verzeichnis liegen!

Aus: München | Registriert: Feb 2000 | IP: [logged]

Thomas Broda
BassFiMass PhonkAggressor
Usernummer # 72

verfasst

Zitat:
Ursprünglich geschrieben von: Cy-Man:
Das liegt wahrscheinlich daran, daß das UNIX-System eine andere Zeichencodierungs-Tabelle verwendet

Nee, nee...ASCII ist ASCII. Der Unterschied ist, daß Unix für das Zeilenende lediglich LF verwendet, während DOS dafür CR/LF nimmt. Das ist alles.

Aus: Jux und Dollerei | Registriert: Dec 1999 | IP: [logged]

sevo

Usernummer # 10461

verfasst

Zitat:
Ursprünglich geschrieben von: Thomas Broda:
Nee, nee...ASCII ist ASCII. Der Unterschied ist, daß Unix für das Zeilenende lediglich LF verwendet, während DOS dafür CR/LF nimmt. Das ist alles.

Allerdings ist das ß nicht ASCII, sondern erst in ISO-8859 etc. definiert. Im Regelfall handelt es sich um irgendeinen der ISO-Latin-Zeichensätze, wenn man heute von ASCII spricht. Und um es schlimmer zu machen, benutzen 390er oft sowieso noch was ganz anderes, nämlich EBCDIC.

@harryp: Du bekommst also irgendwas undefiniertes (denn ASCII ist's nicht, da gibt es kein ß), korrigierst lediglich die Zeilenenden, und versuchst das Resultat dann per FTP und dessen TEXT-Übertragung auf das Format des Servers (vermutlich irgendeine EBCDIC-Variante) konvertieren zu lassen?!?

Da ist kein Wunder, wenn merkwürdige Dinge passieren - das wandeln mit FTP Text würde nur zwischen Unix-ASCII, PC-DOS-ASCII und US-EBCDIC funktionieren - sobald eines der beteiligten Systeme eine internationale Zeichentabelle benutzt, geht das schief.

Ich würde mir da einen Schritt und diese Fehlerquelle sparen und vom Absender und der Serverbetreuung die Zeichensätze exakt rausbekommen (wie gesagt, neben dem System ist auch die Sprachversion wichtig - im Idealfall sagt man dir was so detailliertes wie "ISO-8859-15 zu EBDIC-INT1"), und dann ohne Umweg über Editor und FTP-Text direkt mit recode konvertieren und das Resultat dann mit FTP binär auf den Server schieben!

Gruß Sevo

Aus: Frankfurt | Registriert: Aug 2003 | IP: [logged]

XcypherX
Minimal & Kompakt
Usernummer # 3451

verfasst

Kann mich erinnern, dass es bei uns auch immer Probleme mit Sonderzeichen zwichen AS/400 und anderen Systemen gibt. Kann wirklich an EBCDIC liegen. Wie wir es gelöst haben frage ich morgen mal , hab selber nicht so viel Ahnung davon. Aber bei uns werden Daten auch über FTP zwischen AS/400 und SAP, Scala etc. hin- und hergeschickt.

Aus: ... | Registriert: Aug 2001 | IP: [logged]

harryp

Usernummer # 5896

verfasst

Vielen Dank erstmal an alle für die ausführlichen und schnellen Antworten. Klasse!

@PigFace
Sed probier' ich morgen direkt aus. Könnte mir damit den manuellen Aufwand mit Ultra Edit ersparen und alles in einer .bat mit sed konvertieren.
Den LF in CR/LF und das blöde ß.
Wir bekommen nämlich immer 19 Dateien, die ich alle manuell konvertieren muss.
Thanks'

@Cy-Man
Da ich immer 19 Dateien konvertieren muß, würde ich mir zusätzlichen manuellen Aufwand gern ersparen.

@sevo
Genauso so, hab ich's gemacht. Bin halt n Hostprogrammierer! ;-)
recode hört sich gut an und wäre wahrscheinlich einfacher als sed.
Ich finde aber nur Versionen für Unix/Linux. Gibts das auch für Windoof???

Aus: Kölle | Registriert: May 2002 | IP: [logged]

nuc
Asra
Usernummer # 4824

verfasst

Zitat:
Ursprünglich geschrieben von: harryp:

recode hört sich gut an und wäre wahrscheinlich einfacher als sed.
Ich finde aber nur Versionen für Unix/Linux. Gibts das auch für Windoof???

http://www.hp-eloquence.com/sdb/html/899906321.html

..googlehit#3..

[hand]

DDL

Aus: Wellington | Registriert: Jan 2002 | IP: [logged]

Thomas Broda
BassFiMass PhonkAggressor
Usernummer # 72

verfasst

Zitat:
Ursprünglich geschrieben von: harryp:
Wir bekommen nämlich immer 19 Dateien, die ich alle manuell konvertieren muss.

Da biste mit dem sed bestens bedient. Ist neben awk das Tool zur Aufbereitung von Textdateien.

Aus: Jux und Dollerei | Registriert: Dec 1999 | IP: [logged]

requital

Usernummer # 4539

verfasst

ein kumpel hat so ein ähnliches problem der hat in seinen programmen immer \n für den zeilen umbruch aber die maschine auf der er nun seine prog. laufen lassen will kennt nur carriage return.

dafür hab ich n kleines java tool geschrieben, das ganz simpel nach \n sucht und das durch \r ersetzt.

müsste auch mit deinem ß funzten. oder schreib's dir selber sind 20 zeilen. aber oben genannte tools sollten auch gehen [Wink]

Aus: Wiesbaden | Registriert: Dec 2001 | IP: [logged]

Cy-Man

Usernummer # 274

verfasst

Zitat:
Ursprünglich geschrieben von: sevo:
das wandeln mit FTP Text würde nur zwischen Unix-ASCII, PC-DOS-ASCII und US-EBCDIC funktionieren

Oh, führt FTP bei einer Übertragung im ascii-Modus zwischen zwei "verschiedensprachigen" Hosts eine Konvertierung durch?

Aus: München | Registriert: Feb 2000 | IP: [logged]

harryp

Usernummer # 5896

verfasst

Hilfe !!!

Das Problem ist noch schlimmer, als ich gedacht habe.

Die 19 Dateien werden auf unterschiedliche Arten erstellt und transportiert.
Fragt mich bitte nicht warum!!!
Es ist auf jeden Fall so, dass bei einigen Dateien nur das ß falsch ist, bei anderen sind allerdings alle Umlaute falsch.

Zeichensätze zu den einzelnen Dateien sind trotz 1000000000000 Telefonaten heute nicht raus zu bekommen. Meistens muss ich stundenlang erklären, was ich überhaupt will.

Gibt es ein Tool, dass die Dateien analysiert und herausfindet, welcher Zeichensatz verwendet wurde???

Aus: Kölle | Registriert: May 2002 | IP: [logged]

PigFace
500
Usernummer # 4299

verfasst

Es gibt solche Tools, gib mal

convert "character sets"

als Suchbegriffe in die Suchmaschine deiner Wahl ein, da kommt so einiges.

[piggy]

Aus: Somewhere in the skeleton | Registriert: Nov 2001 | IP: [logged]

sevo

Usernummer # 10461

verfasst

Zitat:
Ursprünglich geschrieben von: harryp:

Gibt es ein Tool, dass die Dateien analysiert und herausfindet, welcher Zeichensatz verwendet wurde???

Hm, das wird nur für einige Multibyte-Zeichensätze (SGML-encoded, UTF-8 usw.) ohne sprachliche Lexika möglich sein - Umwandlungen aus solchen eindeutig identifizierbaren Zeichensätzen kann recode automatisch.

Ansonsten könnte man nur aufgrund einer Textanalyse feststellen, ob da z.B. ein ISO-646-DE "ö" oder ein ASCII "_" gemeint waren. Sowas kann meines Wissens kein Tool - aber man könnte das, wenn die möglichen Text-Sprachen bekannt sind, recht leicht selber mit recode und einer Spellcheck-Library scripten.

Ansonsten: Den Arbeitgeber darauf aufmerksam machen, daß da dringend ein interner Standard definiert werden muß - wenn da jeder benutzt was er will, ist nur eine Frage der Zeit, bis eine Abteilung nur noch für alle andere unlesbare Dokumente produziert...

Gruß Sevo

PS (@Cy-Man): Yep, der "ASCII"-Modus macht der Definition nach deutlich mehr als eine bloße Konversion der Zeilenenden. Die vorgesehene Übersetzung zwischen variablen Zeichentabellen ist aber fast nur auf Unix und Mainframe-Betriebssystemen implementiert, und krepiert auch da fürchterlich, wenn die Datei nicht den zur im Environment des Absenders gesetzten Sprache passenden Zeichensatz enthält.

Unter Windows wird von den mir bekannten FTP-Clients stets US-ASCII oder bestenfalls ISO-8859-1 als lokales Format angenommen, und damit alles andere nichts korrekt gewandelt - außerdem krankt das System sowieso daran, daß es altersbedingt nur eine 8-bit Konversionstabelle definiert und somit keine Multibyte-Zeichen wandeln kann.

Aus: Frankfurt | Registriert: Aug 2003 | IP: [logged]

harryp

Usernummer # 5896

verfasst

Ah!
Wenn man endlich den Richtigen erreicht hat, klappt es auch mit den Sonderzeichen/Umlauten.

Die haben auf ihrer Unix-Maschine irgendeine Sonderlösung und setzen Umlaute und Sonderzeichen selbst um. Fragt mich bitte nicht nach Details...

Wir bekommen auf jeden Fall jetzt die Daten in schönem ASCII Format geliefert und ich kann sie ohne Probleme einspielen.

Vielen Dank nochmal an Alle!

Aus: Kölle | Registriert: May 2002 | IP: [logged]

Druckversion