ubuntuusers.de

Hallo zusammen,

ich versuche gerade herauszufinden wieviele Zeichen einer Datei vom file Kommando eingelesen werden um den Mimetyp zu ermitteln.

Hintergrund ist, das eine Datei als ASCII-Text erkannt wird, obwohl diese UTF-8 Zeichen enthält, allerdings erst ab Zeile 1700. Zuvor ist wirklich reiner ASCII Text.

Die Überprüfung führt dann zu einem iconv Aufruf, der diese Datei von ASCII nach UTF-8 konvertieren möchte, was dann natürlich fehlschlägt. Ich habe keinen Einfluss auf den Aufbau der Datei und eine Option, das file immer die ganze Datei prüft, habe ich leider auch nicht gefunden.

Gibt es eventuell Alterntiven?

VG

Rainer

Das Problem ist nicht allgemein lösbar, würde ich sagen. Wenn nicht irgendwo an/in der Datei gespeichert ist, „ich bin UTF-8“ oder „ich bin latin1“, dann kann man nur raten.

Kannst du noch etwas mehr über deine Eingabedaten sagen? Welche Encodings kommen vor? (Wenn es nur ASCII und UTF-8 ist, wäre das Unterfangen ja sinnlos, weil ASCII eine Teilmenge von UTF-8 ist.) UTF-8 ist wohl immer das Zielencoding? Geht es um 10 Eingabedateien oder 10 Millionen? Wo kommen die Dateien her, sprich, gibt es nicht vielleicht doch irgendwo eine Stelle, an der das Encoding definiert wurde?

Hallo Vain,

danke für die Rückmeldung.

Das ganze Thema ist bei uns schon seit einigen Jahren im Einsatz.

Wir bekommen aus einer anderen Anwendung (SAP ☹ ) eine CSV Datei geliefert die wir in unsere Datenbank importieren. Die Daten werden dann von uns Druckaufbereitet und an unsere Druckstraße übergeben.

Die Teile der Daten in der CSV kommen bzw. kamen teilweisen von anderen System um dann via SAP an uns weitergeleitet zu werden. So waren in der Vergangenheit unterschiedliche Charsets vorhanden (ISO-8859-1, EBCDIC, irgendwas 9-Bittiges von einem Bull Großrechner, usw.) Aus dem Grund wird vorab mit "file" geprüft was das für eine Datei ist um diese dann mit iconv entsprechend nach UTF-8 zu konvertieren.

Normalerweise liefert SAP seit geraumer Zeit die Daten artig im UTF-8 Format. Es ist aber leider nicht auszuschließen das hier sich mal ein anderes Format dazwischen mogelt. Von daher möchten wir die Prüfung ungern entfernen. Wir haben auch gecheckt, dass wenn die UTF-8 Zeichen früher gekommen wären, die Prüfung das richtige Ergebnis ergeben hätte.

Das also unsere Situation und ich befürchte das wird sich wohl nicht ändern lassen.

Kannst du nicht einfach auch ASCII wie UTF-8 behandeln? Das sollte zu keinen Fehlern fuehren.

Wenn am Beginn der Datei ein Byte Order Mark steht, wuerde ich eine einfachere Erkennung erwarten, aber BOMs sind mancherorts nicht recht beliebt.

EDIT: Ein paar Sekunden zu spaet abgesendet

Es gibt auch noch andere Programme, um das wahrscheinliche Encoding von Dateien automatisiert bestimmen zu lassen, z.B. chardet (oder cchardet und uchardet).

sebix schrieb:

Kannst du nicht einfach auch ASCII wie UTF-8 behandeln? Das sollte zu keinen Fehlern fuehren.

Wenn am Beginn der Datei ein Byte Order Mark steht, wuerde ich eine einfachere Erkennung erwarten, aber BOMs sind mancherorts nicht recht beliebt.

EDIT: Ein paar Sekunden zu spaet abgesendet

Ja, da habe ich auch schon drüber nachgedacht. Die Wahrscheinlichkeit das in so einer Datei andere Charsets als UTF-8 kommen ist sehr gering. Von daher könnte man US-ASCII tatsächlich beim iconv Aufruf ignorieren.

seahawk1986 schrieb:

Es gibt auch noch andere Programme, um das wahrscheinliche Encoding von Dateien automatisiert bestimmen zu lassen, z.B. chardet (oder cchardet und uchardet).

Das werde ich mal prüfen. Danke ☺

chardet funktioniert besser als file.

Wir werden das script damit umrüsten.

Danke für den Hinweis.