Problem mit sed und UTF-16-formatierter Datei

[berland]

Hallo,

könnte mir bitte jemand bei folgendem Problem behilflich sein. Die Situation ist die folgende.

Ich habe eine Tabelle (Filemaker) mit Vokabeln, die ich in eine kommagetrennte (CSV-)Datei exportieren möchte, um sie in ein anderes Programm (jMemorize) zu importieren.

Da jMemorize nur 2 Spalten zulässt (Frontside und Flipside), ich aber Informationen aus 3 Spalten in FM verwenden muss, möchte ich 2 der Spalten in eine einzige zusammenführen.

Ich kenne keine Möglichkeit dies in Filemaker selbst zu erreichen (und ich plane auch möglichst bald zu MySQL zu migrieren, sodass eine Filemaker-interne Lösung zwar sehr hilfreich, aber nicht perfekt wäre).

Ich versuche nun, die exportierte CSV-Datei mit sed zu bearbeiten, das aber offenbar ein großes Problem mit den UTF-16-formatierten Dateien oder den chinesischen Schriftzeichen hat. UTF-16 ist das einzige Format, das beim Export aus FM die chinesischen Schrifzeichen und die speziellen Buchstaben der Umschrift erhält.

Gibt es Hoffnung, sed mit diesen Dateien zu verwenden? Ich habe sed niemals vorher benutzt und ich bin fast sicher, irgendetwas falsch zu machen.

Die Manipulation, die ich mit sed erreichen möchte, ist eigentlich sehr einfach, aber leider nicht einfach genug, um sie in einem Texteditor durchzuführen. Aber vielleicht gibt es auch hier einen Lösungsweg mit dem richtigen Texteditor.

Um das herauszufinden, gebe ich im Folgenden ein Beispiel der Aufgabe. Ich hoffe, dass Chinesisch bei jedem dargestellt wird.

Exportierte CSV-Datei

"历史系","lìshǐxì","History Department","1"
"打算","dǎsuàn","to be going to, to plan; plan","1"
"进修","jìnxiū","to engage in advanced studies","1"
"入系","rù xì","to be enrolled into a department","1"

Erwünschte Änderung

"历史系	


lìshǐxì","History Department","1"
"打算	


dǎsuàn","to be going to, to plan; plan","1"
"进修	


jìnxiū","to engage in advanced studies","1"
"入系	


rù xì","to be enrolled into a department","1"

Es soll also bloß das erste "," (inkl. der Klammern) durch einen Zeilenumbruch, TAB o.ä. ersetzt werden.

Diese Änderung ist mir in einem Texteditor nur semi-automatisch möglich, da nur das erste der mehrfach vorkommenden Zeichenkombination ersetzt werden soll.


Kann bitte jemand versuchen mir weiterzuhelfen.
Vielen Dank

 

[maceis]

Dürfte nicht ganz einfach werden.
Ein Problem dabei ist, dass das Terminal UTF-16 gar nicht unterstützt.

Eine Lösung könnte u.U. ein Texteditor sein, der einerseits UTF-16 und andereseits globales Ersetzten mir regulären Ausdrücken unterstützt.
Evtl. geht's mit vim als grafische Anwendung kompiliert.

 

[Lor-Olli]

wenn du die Möglichkeit hast Excel zu verwenden, exportierst du die Filemaker Datei nach Excel (alle Spalten unverändert lassen). Es gibt dann eine Excel Erweiterung die nennt sich "Mac Exel Expander", die eine Textmanipulation zulässt mit der man mehrere Spalten zu einer zusammenfassen kann (Combine Cell Content). Ich habe so genau dein Problem lösen können, eine Datei mit 5 Spalten in eine Datei mit zwei Spalten umgewandelt, und als CSV Datei exportiert. Musste noch einige weitere Textmanipulationen vornehmen, für die in meinem Fall Word ganz hilfreich war. (Komma durch Tab, Semikolon durch Zeilenschaltung ersetzen)

 

[pseudogc]

oder mit awk *?*

geneigte Leser,

habe eben mal das Beispiel in eine Textdatei ("test.dat") kopiert. Mit:

awk '{FS=",";print $2,$3,$4,$1}' test.dat

im Terminal kriege ich als Ausgabe:

"dǎsuàn" "to be going to to plan; plan" "打算"
"jìnxiū" "to engage in advanced studies" "1" "进修"
"rù xì" "to be enrolled into a department" "1" "入系"

das Ganze in eine Datei umgeleitet wuerde Dir reichen?

cheers,

pseudogc


edit: aaah, gerade habe ich gesehen, dass Du ja was anderes willst - also das Skript erweitern und ein "newline" mit eingebaut… so was passiert ganz klar wenn man halt der Sprache nicht maechtig ist und ubernaechtig postings liest

awk '{FS=",";print $1"\r";print $2"," $3","$4}' test.dat >Neuedatei.dat

allerdings braucht es da noch eine Leerzeile zu Beginn der Deiner Datei - und einen Preis fuer das schoenste awk-Skript gewinnt das auch nicht, macht aber was Du willst.

 

[winkelmr]

Dürfte nicht ganz einfach werden.
Ein Problem dabei ist, dass das Terminal UTF-16 gar nicht unterstützt.

Eine Lösung könnte u.U. ein Texteditor sein, der einerseits UTF-16 und andereseits globales Ersetzten mir regulären Ausdrücken unterstützt.
Evtl. geht's mit vim als grafische Anwendung kompiliert.

Der fehlenden UTF-Unterstützung des Terminals ist leicht abhilfe zu schaffen: Einfach eine aktuelle Version der GNU bash runterladen (bourne again shell), kompilieren (./configure, make, make install), das Terminal auf UTF8 stellen und die Umwandlung in Escapesequenzen abschalten. Fertig.
Es heißt zwar immer man käme am Mac ums kompilieren herum, jedoch ist spätestens wenn man Umlaute ins Terminal bzw. die GNU-Tools/Editoren bekommen möchte genau jenes gefragt. Schade, dass Apple seinem Betriebssystem Steinzeit-Versionen von bash, gnutools, vim, nano etc. beilegt, die nicht Unicode-fest sind. Erst recht, wenn man bedenkt, wie schön Unicode-basierend der Rest des Systems ist.

 

[maceis]

Mit den Umlauten habe ich keine Probleme.
Nur die UTF-16 Zeichen geh'n bei mir im Terminal nicht.

Wäre mal interessant, wie pseudogc das schafft.

 

[pseudogc]

Mit den Umlauten habe ich keine Probleme.
Nur die UTF-16 Zeichen geh'n bei mir im Terminal nicht.

Wäre mal interessant, wie pseudogc das schafft.

geneigte Leser,

der Test fand auf einem MacOSX 10.3.x-Rechner in der tcsh statt – Standard Apple-Installation. Ich probiere das spaeter gern nochmal unter 10.4.x.. Auf den zweiten Blick kann es natuerlich sein, das die Zeichen im obigen Beispiel auch mit UTF-8 abgedeckt werden *?*
Perl 5.8.x sollte das im uebrigen doch auch problemlos koennen…

cheers,

pseudogc

n.b.: was fuer Umlaute?

 

[maceis]

Danke für die Info.
Mich wundert es, da die tcsh als nicht 8-bit fest gilt.

 

[pseudogc]

Danke für die Info.
Mich wundert es, da die tcsh als nicht 8-bit fest gilt.

geneigte Leser,

ohne jetzt unbedingt Haare spalten zu wollen - die Shell spielt doch hier nur eine untergeordnete Rolle, all die weil eine Ausgabe via stdIO ja eigentlich gar nicht gewuenscht ist, oder? (Funktioniert allerdings zumindest fuer das Beispiel.) Ich habe die Beispielzeilen halt im Browser kopiert (Camino 1.0.3) und in TextWrangler eine Textdatei angelegt (TextWrangler 2.1.1; UTF-8 kodiert) und dann das Skript ausgefuehrt. Wenn ich das richtig sehe, dann ist beispielsweise awk schon eine ganze Weile "8-bit clean" und daher sollte die Ausgabe eigentlich funktionieren - solange die Field- und Record-Separatoren als ASCII-Zeichen vorliegen (und das ist hier ja der Fall.)

Fuer den Interessierten findet sich hier im uebrigen eine nawk-version die Unicode vollstaendig unterstuetzen soll.

cheers,

pseudogc

 

[maceis]

ohne Haare spalten zu wollen ():
Du schriebst oben "im Terminal kriege ich als Ausgabe: ..."
Das war's was mich gewundert hat, denn für die Ausgabe im Terminal sind zum einen die Shell und zum anderen das Programm Terminal zuständig. Beide können kein UTF-16 (okay - schint mit UTF-8, was von terminal unterstützt wird, auch zu gehen), tcsh kann noch nicht einmal UTF-8 oder Latin1

 

[pseudogc]

tcsh kann noch nicht einmal UTF-8 oder Latin1

geneigte Leser,

Bist Du sicher? Sowohl UTF-8, oder auch ISO-latin-1 lassen sich ueber den Terminal-Inspector als Zeichensatzkodierung einstellen. Ich benutze UTF-8 als Standard - da funkioniert dann auch scheinbar die Ausgabe im Terminal mit tcsh als voreingestellte Shell. Probleme gibt es eventuell bei Dateinamen und Programme wie awk haben individuelle Anforderungen (wie geschrieben bedarf es z.B.: bei den awk-Versionen, die mit MacOSX >= 10.3 mitgeliefert werden, eines ASCII-Feldseparators).

cheers,

pseudogc

n.b.: mehr dazu auch zum Beispiel hier

 

[winkelmr]

Wie bereits von mir geschrieben:
Terminal kann UTF-8, aber die verwendete GNU-bash-Version ist eine veraltete. Lad dir bash 3.2 runter, kompilier' und installiere sie.
Dann noch UTF-8 (oder was auch immer) einstellen, die Anweisungen aus deiner Anleitung beachten und voila: Ein Terminal, das Unicode kann.
Wahrscheinlich wird man auch noch die GNU-coreutils, vim, nano etc... neu laden und kompilieren müssen. Je nach Bedarf. Mit neuen Versionen funktioniert's recht gut - von mir selbst getestet.