wordfreq und iconv

torquato · 10.07.18 11:22

(10.07.18 08:20)vdrummer schrieb: PS: Ich habe mir gerade mal die wordfreq-Datei angesehen. In diesem konkreten Fall war die Kodierung EUC-JP-MS.

Ach, deswegen!

Interessant, daß Du das erwähnst. Ich habe gerade erst vor zwei, drei Wochen in einem kleinen Programmierprojekt diese Datei angefaßt und wäre an der Kodierung fast verzweifelt. Die ganze Datei einlesen als 'normales' EUC-JP kodierter String in der Sprache/ API meiner Wahl ging einfach nicht. Transkodieren im Browser war so ein quick und dirty Hack, den ich ausprobiert habe. Hat mich nur der Zeilenumbrüche beraubt, die ich aber unbedingt zum Tokenizing brauchte. Hab das dann als UInt8 Data eingelesen und stückweise die Bereiche, die mich interessierten, transkodiert.
Das hat zwar geklappt, aber jetzt bin ich am grübeln, ob sich da mapping-Fehler eingeschlichen haben könnten… kratz

Zumindest weiß ich jetzt, warum die Datei so komische Probleme gemacht hat. Danke!^^

Gibt es ein Standard-Unix-Tool, mit dem man das (also diese spezielle EUC-JP-Variante) _zuverlässig_, sagen wir nach UTF8, transkodieren kann?

vdrummer · 10.07.18 13:14

(10.07.18 11:22)torquato schrieb: Zumindest weiß ich jetzt, warum die Datei so komische Probleme gemacht hat. Danke!^^

Gern geschehen. Ich hatte da aber auch erst Probleme mit. Es heißt ja, dass das Ding in EUC kodiert ist und da geht man natürlich von EUC-JP aus. Zumal das beim EDICT ja auch klappt... Hab dann dank intelligenter Autovervollständigung der zsh rausgefunden, dass es auch noch EUC-JP-MS gibt und das einfach mal probiert hoho

Zitat:Gibt es ein Standard-Unix-Tool, mit dem man das (also diese spezielle EUC-JP-Variante) _zuverlässig_, sagen wir nach UTF8, transkodieren kann?

Ich nehme dafür immer iconv. Das sieht dann am Beispiel von wordfreq folgendermaßen aus:

Code:

$ iconv -f EUC-JP-MS -t UTF-8 wordfreq_ck > wordfreq_utf8.tsv

Ich hab hier die _ck-Variante genommen, bei der ein bisschen aufgeräumt wurde.

iconv setzt natürlich voraus, dass man das Encoding der Quelldatei kennt. Wenn man ein falsches Encoding angibt, bekommnt man eine Meldung, die z.B. so aussieht:

Code:

$ iconv -f EUC-JP -t UTF-8 wordfreq_ck > wordfreq_utf8.tsv

iconv: illegal input sequence at position 787266

Die Ausgabe-Datei wird trotzdem erstellt, allerdings sieht sie komisch aus:

Jetzt, wo ich versuche, das Ganze zu reproduzieren, klappt es auf einmal mit EUC-JP! Sobald ich herausgefunden habe, was hier los ist, melde ich mich nochmal hoho

Immerhin hast du jetzt schon mal das Tool...

torquato · 10.07.18 14:00

Danke @vdrummer!

Ich sitze jetzt gerade selber wieder an der Datei. Dachte ja, die wäre für mein Miniprojekt erledigt. augenrollen

Klar, iconv. Einmal Tante Google fragen und dann bin ich vorhin auch selbst drauf gekommen. Hatte ich nur sonst noch nie benutzt. Damit habe ich es anstandslos von normalem EUC-JP nach UTF8 konvertiert bekommen. Komisch, laut iconv -l kennt er bei mir EUC-JP-MS aber auch gar nicht… kratz

Meine Dateien heißen wordfreq und word_freq_k. Ich beschäfftige mich mit der kompletten Datei, wobei ich auch da kanjilose Wörter rausfiltere. Ich bin aber der Meinung, eine wordfreq_ck auch schon mal gesehen zu haben… Da scheinen wohl auch noch unterschiedliche Fassungen im Umlauf zu sein… kratz

Jetzt, wo ich wieder drann sitze, sehe ich, daß ich beim letzten Mal da einen Fehler beim Tokenizing gemacht habe. Den kann ich dann jetzt bei der Gelegenheit gleich ausbügeln. Also für mich wirklich prima, daß Du das Thema angesprochen hast! grins

vdrummer · 10.07.18 18:45

(10.07.18 14:00)torquato schrieb: Klar, iconv. Einmal Tante Google fragen und dann bin ich vorhin auch selbst drauf gekommen. Hatte ich nur sonst noch nie benutzt. Damit habe ich es anstandslos von normalem EUC-JP nach UTF8 konvertiert bekommen. Komisch, laut iconv -l kennt er bei mir EUC-JP-MS aber auch gar nicht…

Bei wordfreq_ck hat mir iconv mit EUC-JP zwar einen Fehler ausgeworfen, aber das Ergebnis sieht akzeptabel aus. Bei EUC-JP-MS gibt's diesen Fehler nicht...
Komisch, bei mir gibt's das...

Code:

$ iconv -l | grep EUC

CSEUCKR//

CSEUCPKDFMTJAPANESE//

EUC-CN//

EUC-JISX0213//

EUC-JP-MS//

EUC-JP//

EUC-KR//

EUC-TW//

EUCCN//

EUCJP-MS//

EUCJP-OPEN//

EUCJP-WIN//

EUCJP//

EUCKR//

EUCTW//

Und wordfreq wirft bei mir sowohl bei EUC-JP als auch bei EUC-JP-MS einen Fehler aus.
Hier mal die MD5 meiner (unmodifizierten) wordfreq-Datei zum Vergleichen:

Code:

$ md5sum wordfreq 

74c92cae87bb69b0a75046f04d4ee977

Zitat:Meine Dateien heißen wordfreq und word_freq_k. Ich beschäfftige mich mit der kompletten Datei, wobei ich auch da kanjilose Wörter rausfiltere. Ich bin aber der Meinung, eine wordfreq_ck auch schon mal gesehen zu haben… Da scheinen wohl auch noch unterschiedliche Fassungen im Umlauf zu sein…

Die wordfreq_ck hab ich von hier: http://ftp.usf.edu/pub/ftp.monash.edu.au...freq_ck.gz

Aus den Kommentaren am Anfang:

Code:

# This is what I did [to the original file].

# The counts for the various forms of the same word were merged.

# Certain words/items were removed: numbers, English and romaji,

# punctuation, phrases ending in the particle "wo", lines beginning with

# "n" or the particle "wo." 

# Then the file was sorted by "the count."

Zitat:Jetzt, wo ich wieder drann sitze, sehe ich, daß ich beim letzten Mal da einen Fehler beim Tokenizing gemacht habe. Den kann ich dann jetzt bei der Gelegenheit gleich ausbügeln. Also für mich wirklich prima, daß Du das Thema angesprochen hast!

Darf ich fragen, was es da noch großartig zu tokenisieren gab? Das sind doch schon einzelne Wörter und wo nötig steht sogar die Grundform dabei, wenn ich das richtig sehe:

Code:

$ grep "+.*+" wordfreq_utf8.tsv | shuf | head

育ん+育む+248	7

締め切り+締め切る+269	223

たれこめ+たれこめる+101	5

担っ+担う+349	566

割+割る+101	83

掘り崩さ+掘り崩す+187	3

押し倒し+押し倒す+193	21

好き好ん+好き好む+248	5

くっつけれ+くっつける+104	5

生じ+生じる+101	337

Edit: Der Grund, warum es vorhin bei mir nicht geklappt hat, war dass ich dachte, ich hätte die original wordfreq-Datei benutzt, dabei habe ich seit heute morgen wordfreq_ck verwendet.

@Frostschutz:
Vielleicht wäre es sinnvoll, unsere Diskussion über die wordfreq-Dateien in einen extra Thread auszulagern. Das hat ja nur noch bedingt mit dem Link-ABC zu tun.

frostschutz · 10.07.18 22:07

(10.07.18 18:45)vdrummer schrieb: @Frostschutz:
Vielleicht wäre es sinnvoll, unsere Diskussion über die wordfreq-Dateien in einen extra Thread auszulagern. Das hat ja nur noch bedingt mit dem Link-ABC zu tun.

Mal vorsichtig erledigt... wenn ihr meint der vorige Post gehört auch noch dazu, kann ich den noch mit reinnehmen.

Der strittige Abschnitt scheint das hier zu sein:

Code:

 ⑤+491  2

 ⑰+491  2

 ㎡+491 2

++491   2

bzw.

Code:

--- wordfreq.CSEUCPKDFMTJAPANESE.ignore 2018-07-10 22:59:37.227812001 +0200

+++ wordfreq.EUC-JP-MS.ignore   2018-07-10 22:59:37.396806954 +0200

@@ -260182,11 +260182,11 @@

 κ+468	1

 λ+468	1

 φ+468	1

-+491	1

-+491	1

-+491	1

-+491	1

-+491	1

+⑥+491	1

+Ⅱ+491	1

+Ⅳ+491	1

+Ⅵ+491	1

+㎞+491	1

 亜希+471	1

 亜希美+471	1

 亜規+471	1

Ansonsten nimmt euc-jp-ms manchmal die falschen Zeichen:

Code:

--- wordfreq.CSEUCPKDFMTJAPANESE.ignore 2018-07-10 22:59:37.227812001 +0200

+++ wordfreq.EUC-JP-MS.ignore   2018-07-10 22:59:37.396806954 +0200

@@ -1592,7 +1592,7 @@

 悪い+381       4359

 議席+1 4355

 スタート+13    4353

-〜+468 4346

+～+468 4346

 身+1   4345

 二百+15        4344

 報告書+1       4343

@@ -3755,7 +3755,7 @@

 里+1   1780

 大戦+1 1779

 ますます+416   1778

-−+468  1776

+－+468 1776

 再生+1 1776

 鳥+1   1775

 別に+415       1775

Also nicht die wide-variante von ~, - usw. Ich nehme an, das ist ein Bug...

Also entweder im euc-jp-ms Ergebnis diese Zeichen wieder umwandeln oder euc-jp die fehlenden Zeichen reinpatchen.

Edit: ach hmm das ist auch nicht ganz richtig kratz

iconv braucht eine Option, die Dateien bei ungültigen Zeichen splittet, damit man das wieder findet...

Phil. · 11.07.18 00:03

Was hab ich denn da wieder angerichtet?
Da durchforste ich das Internet auf der Suche nach verlorene Spuren und bringe dann noch Probleme ins Forum.
Eine gute Nachricht fuers Forum. Als download sind noch 10 MB im Forum belegt.
18 MB sind geloescht worden.
Gut so?

torquato · 11.07.18 07:19

Danke @frostschutz auch für Deine Expertise!^^

(10.07.18 22:07)frostschutz schrieb: Edit: ach hmm das ist auch nicht ganz richtig iconv braucht eine Option, die Dateien bei ungültigen Zeichen splittet, damit man das wieder findet...

Aus der iconv manpage:

Code:

       --unicode-subst=formatstring

              When this option is given, Unicode characters that cannot be represented in the  target  encoding  are  replaced

              with  a  placeholder  string that is constructed from the given formatstring, applied to the Unicode code point.

              The formatstring must be a format string in the same format as for the printf command or the printf()  function,

              taking either no argument or exactly one unsigned integer argument.

       --byte-subst=formatstring

              When  this  option  is  given,  bytes in the input that are not valid in the source encoding are replaced with a

              placeholder string that is constructed from the given formatstring, applied to the  byte's  value.  The  format-

              string  must  be  a  format string in the same format as for the printf command or the printf() function, taking

              either no argument or exactly one unsigned integer argument.

Die md5checksum ist bei mir gleich.
Ich habe bei der ersten Konvertierung auch einen falschen Schalter gesetzt. Letztendlich gibt's da bei mir die gleichen Fehler.

Die wordfreq_ck werde ich mir heute mal genauer angucken. Klingt vielversprechend. Danke für den Hinweis!^^

Die in iconv zur verfügung stehenden Zwichensätze sind wohl sehr systemabhängig. Die manpage dazu:

Code:

       The encodings permitted are system dependent. For the libiconv implementation, they are  listed  in  the  iconv_open(3)

       manual page.

Bei mir sind das dann:

Zitat:$ iconv -l | grep EUC
EUC-JP EUCJP EXTENDED_UNIX_CODE_PACKED_FORMAT_FOR_JAPANESE CSEUCPKDFMTJAPANESE
CN-GB EUC-CN EUCCN GB2312 CSGB2312
EUC-TW EUCTW CSEUCTW
EUC-KR EUCKR CSEUCKR
EUC-JISX0213

Blödes abgespecktes Darwin/ MacOS…! grr

vdrummer · 11.07.18 07:45

(10.07.18 22:07)frostschutz schrieb: Mal vorsichtig erledigt... wenn ihr meint der vorige Post gehört auch noch dazu, kann ich den noch mit reinnehmen.

Der vorige Post bezog sich ja hauptsächlich aus Links aus dem ABC. Außerdem hat torquato den relevanten Teil zitiert. Passt also alles. Danke!

Danke auch für die diffs. Ich bin gestern irgendwie gar nicht auf die Idee gekommen, mir mal anzusehen, welches Zeichen genau Probleme macht...

torquato · 11.07.18 09:23

So, die wordfreq_ck sieht wirklich viel besser (für meine Zwecke) aus.

(10.07.18 18:45)vdrummer schrieb: Bei wordfreq_ck hat mir iconv mit EUC-JP zwar einen Fehler ausgeworfen, aber das Ergebnis sieht akzeptabel aus. Bei EUC-JP-MS gibt's diesen Fehler nicht...

Mit EUC-JP komme ich auf 5 fehlerhafte/ nichtkonvertierbare Stellen. Da ich auf meinem System ja kein EUC-JP-MS habe; könntest Du eine richtig nach UTF-8 konvertierte Fassung davon hier bereitstellen? Das wäre wirklich sehr nett!

(10.07.18 18:45)vdrummer schrieb: Darf ich fragen, was es da noch großartig zu tokenisieren gab? Das sind doch schon einzelne Wörter und wo nötig steht sogar die Grundform dabei, wenn ich das richtig sehe:

'Tokenisieren' war wohl der falsche Begriff, eher 'weiter parsen'. Mir geht's letztendlich nur um die Begriffe, die mindestens ein Kanji enthalten, und den count. Das will ich dann mit zwei ähnlichen Häufigkeitsdateien als tsv zusammenbringen und dann wieder weiterverarbeiten…

Plan ist ein kleines Komandozeilentool, das zu einem gegebenen Kanji die Wörter ausgibt, die dieses Zeichen enthalten (nach Häufigkeit sortiert) und dazu noch Lesung, Bedeutungen und die Schulstufen, zu denen die Kanji des Wortes jeweils gehören…

vdrummer · 11.07.18 13:50

(11.07.18 09:23)torquato schrieb: Mit EUC-JP komme ich auf 5 fehlerhafte/ nichtkonvertierbare Stellen. Da ich auf meinem System ja kein EUC-JP-MS habe; könntest Du eine richtig nach UTF-8 konvertierte Fassung davon hier bereitstellen? Das wäre wirklich sehr nett!

Na klar. Da das Ganze 2 MB groß ist, hab ich's auf meine Dropbox geladen:
https://www.dropbox.com/s/3n61w09ysq84g5...8.tsv?dl=1

(Edit: Ich hatte die 1MB-Begrenzung vom Moodle meiner Uni im Kopf. Hier hätte das ja geklappt. Geht aber trotzdem nicht...)

Viel Spaß damit grins

Zitat:'Tokenisieren' war wohl der falsche Begriff, eher 'weiter parsen'. Mir geht's letztendlich nur um die Begriffe, die mindestens ein Kanji enthalten, und den count. Das will ich dann mit zwei ähnlichen Häufigkeitsdateien als tsv zusammenbringen und dann wieder weiterverarbeiten…

Ich würde sogar sagen, dass man da von "filtern" sprechen kann. Aber wenn man's genau nimmt, zerlegst du die Wörter ja in Grapheme, die wiederum Tokens sein können zwinker

Als Linguist verstehe ich unter "Tokenisieren" halt eher das Transformieren von einem String in eine Liste von Wörtern.

Zitat:Plan ist ein kleines Komandozeilentool, das zu einem gegebenen Kanji die Wörter ausgibt, die dieses Zeichen enthalten (nach Häufigkeit sortiert) und dazu noch Lesung, Bedeutungen und die Schulstufen, zu denen die Kanji des Wortes jeweils gehören…

Sowas Ähnliches hatte ich vor ein paar Wochen vor zu schreiben hoho

Allerdings nicht nach Häufigkeit, sondern nach JLPT-Level sortiert. Hab das Projekt dann aber doch erstmal abgebrochen und mir stattdessen massenhaft Kanji-Übungen heruntergeladen (in der Hoffnung, dass damit genug Komposita abgedeckt werden).

wordfreq und iconv
Verfasser	Nachricht