Unicode Dateien erkennen

[Webturtle]

Hallo,

 

gibt es eine Möglichkeit aus einem Script zu erkennen, ob eine DVBViewer-EPG.TXT Datei Unicode- oder normale Windows-Ansi-Zeichen enthält?

 

Ich möchte die EPG-TXT-Dateien, die DVBViewer bei einer Aufnahme anlegt, von Unicode nach Ansi konvertieren. Meine Desktop-Search-Programme (Yahoo und Copernic) finden zwar auch in Unicode-Dateien Umläute richtig, aber die Anzeige ist dann fehlerhaft. Ein Script zur Konvertierung habe ich schon mit Autohotkey_L geschrieben, aber ich möchte nur die Dateien von *.txt zu *.ans konvertieren, die auch wirklich Unicode enthalten, sonst ensteht wieder Datenmüll.

 

Wie erkennt der Windows-Editor, um was es sich handelt? Beim Öffnen der TXT-Dateien werden die Umlaute immer richtig angezeigt, gleichgültig ob es sich um alte oder neue DVBViewer TXT-Dateien handelt.

 

 

Viele Grüße

 

Webturtle

[erwin]

ob eine DVBViewer-EPG.TXT Datei Unicode- oder normale Windows-Ansi-Zeichen enthält?

 

Hopla, es geht hier doch so einiges begrifflich durcheinander.

 

Zunächst was sind Unicodezeichen?

 

Es gibt Unicode (aber Zeichen?). Siehe Wikipedia.

 

In meinen Worten:

Es gibt abstrakte Zeichensymbole mit einer gewissen Bedeutung. Z.B. die Buchstaben a,b,c aber auch Ä, Ö, Ü. Und auch Verkehrzeichen und sogar Sybole für Schachspielfiguren gehören dazu. Und viele, viele mehr. Unicode belegt das Abstraktum solcher Symbole mit bestimmten Hexbytes als ID. Abstraktum deshalb weil die konkrete Darstellungsform eine Aufgabe der verwendeten Fonds ist. Die ID heisst dann Unicode-Codepoint.

Diese Unicodecodepoints wirst du jedoch nicht in den Dateien mittels Hexeditor z.B. sehen können. Die Codepoints unterliegen einer CODIERUNG von denen es mehrere gibt. Da ist z.B. UTF8. Fast wie ANSI (aber ich denke du hast gar nicht ANSI gemeint sondern eine der Windows-Codierungen). Umlaute werden aber per 3er Escape-Code kodiert.

 

So gesehen verstehe ich deine Frage so, ob solche Escapes im Text vorkommen.

 

Wie erkennt der Windows-Editor, um was es sich handelt? Beim Öffnen der TXT-Dateien werden die Umlaute immer richtig angezeigt, gleichgültig ob es sich um alte oder neue DVBViewer TXT-Dateien handelt.

 

UTF8 kodierte Textfiles sind meisst mit einer sogenannte BOM (Byte Order Mask) am Beginn versehen. Ein hexa-3-Byte code. Nimm dir einen Hexeditor und geh auf die Pirsch.

 

erwin

[Tjod]

Die Info Dateien die der RS bei der Aufnahme erstellt sind UTF-8 codiert aber ohne BOM (wie die allermeisten anderen Programme auch die BOM Bits bei der Weiterverarbeitung leicht Probleme verursachen können ).

Das heiß du kannst das nur erkennen wenn du die Datei durchsuchst und du ein UTF-8 Zeichen findest das nicht mit US-ASCI deckungsgleich ist.

 

Bei einer Datei die nur US-ASCI Zeichen enthält dürfte es keinen unterschied zu einer reinen ASCI Codierten Datei geben.

[Webturtle]

Hallo,

 

vielen Dank für die Antworten!

 

Zur Klarstellung: Es geht vor allem um die Umlaute und Sonderzeichen im Text, die in Unicode codiert sind (flapsig von mir Unicode-Zeichen genannt), die also von Programmen, die nur für normale Ansi-codierte Zeichen konzipiert sind, nicht korrekt dargestellt werden. Mir ist schon klar, daß es sich eigentlich nur um Zahlen handelt, denen ein bestimmtes Zeichen zugeordnet ist. Ich kenne noch die alten ASCII- bzw. ANSI-Tabellen in denen die Zahlen und die ihnen korrespondierenden Zeichen aufgelistet waren (sehr praktisch beim Programmieren).

 

Putzigerweise finden die genannten Desktop-Search-Programme die Umlaute richtig, zeigen aber in der Ansicht der Fundstelle "Unsinn" an. Dieses Problem gab es früher auch schon bei DOS-ASCII und Windows-ANSI oder bei ASCII und EBCDIC.

 

Also werde ich mich mal auf die Pirsch begeben und mir die Beschreibungs-Texte des DVBViewer mit dem Hex-Editor ansehen.

Bloß was ist ein hexa-3-Byte code bzw. wie sieht der aus? Im Hex-Editor findet man ja normalerweise rechts den Klartext und links Zweiergruppen aus Zahlen und Buchstaben, eben hexadezimal. Außerdem ist mir am Anfang des Textes noch nie etwas ungewöhnliches aufgefallen. Allerdings habe ich die Text-Dateien in der Regel mit dem Windows-Editor und nicht mit einem alten Filelister angesehen. Und der Editor zeigt die Unicode-codierten Zeichen ja genauso korrekt an wie normale ANSI-codierte.

 

Ideal wäre es, wenn das Script einfach nachsehen könnte, ob sich am Anfang eine BOM befindet und wenn nicht die Datei überspringen würde.

Für einen Hinweis, der zum Finden der "Beute" dienlich ist, wäre ich sehr dankbar!

 

 

Viele Grüße

 

Webturtle

[Tjod]

Keine der Dateien wird einen BOM haben.

Da der DVBViewer und RS keine Dateien mit BOM erstellen.

[erwin]

Ich möchte die EPG-TXT-Dateien, die DVBViewer bei einer Aufnahme anlegt, von Unicode nach Ansi konvertieren.

 

Nimm Notepad, öffne die Datei als UTF-8 kodiert, dann "Speichern unter..." als ANSI kodiert. Fertig.

 

 

Falls dich die HEX interressieren: Freeware PSPad!

 

 

erwin

[mague]

Hallo,

 

gibt es eine Möglichkeit aus einem Script zu erkennen, ob eine DVBViewer-EPG.TXT Datei Unicode- oder normale Windows-Ansi-Zeichen enthält?

 

 

Webturtle

 

Hi,

 

bei Unicode steht Charset=255 drin, bei ANSI sollte Charset=1 drin stehen.

 

In Windows Skripten kannst du findstr nehmen.

[Webturtle]

Hallo,

 

vielen Dank für die vielen Hinweisen!

 

@Tjod: Danke für den Hinweis! Ich hätte sonst umsonst nach dieser BOM gesucht. Was meinst Du zu mague: "bei Unicode steht Charset=255 drin, bei ANSI sollte Charset=1 drin stehen"? Gilt dies auch für DVBViewer Pro bzw. RS? Irgendwas muß ja bei den neueren Unicode-TXT-Dateien anders sein als bei den alten. Jedenfalls zeigt mir das Windows-Notepad diese korrekt mit Unlauten an, ebenso wie die alten EPG-Beschreibungs-TXT-Dateien.

 

@erwin: Danke für den Tip mit Notepad. So habe ich es anfangs auch versucht. Aber es ist viel zu umständlich und dauert auch viel zu lange. Ich habe mir daher mit Autohotkey_L (die erweiterte Version beherrscht auch Unicode) ein Script geschrieben, das die Unicode-Datei (*.txt) konvertiert und als neue ANSi-Datei (*.ans) speichert. Gehe ich richtig, daß "Freeware PSPad" ein Hex-Editor ist?

 

 

Viele Grüße

 

Webturtle

[Tjod]

mague hat recht im Text der Informationsdatei steht eine Zeile mit Charset=255 (UTF-8 Dateien) oder Charset=1.

Also einfach nach Datei mit die "Charset=255" enthalten Suchen dann solltest du alle finden.

Und beim ändern am besten Charset=255 gleich noch in Charset=1 ändern.

[erwin]

@erwin: Danke für den Tip mit Notepad. So habe ich es anfangs auch versucht. Aber es ist viel zu umständlich und dauert auch viel zu lange. Ich habe mir daher mit Autohotkey_L (die erweiterte Version beherrscht auch Unicode) ein Script geschrieben, das die Unicode-Datei (*.txt) konvertiert und als neue ANSi-Datei (*.ans) speichert.

 

Wo ist jetzt eigentlich noch dein Problem? Dir wurde gesagt: Es SIND (zwar ohne BOM) UTF-8 kodierte Dateien, also braucht dein Script da nichts zu "erkennen".

 

Es muss nur eine stupide Zeichenersetzung machen: code < 128: lasse es wie es ist. Kommt ein 0xC3 ist das nächste Zeichen auszuwerten. Beispiel: 0xC3 0x96 ist ein 'Ö'. Das dann nach ANSI und fertig. Brauchst also nur die UTF-8 und ANSI-Kodierungsregeln nachzuschlagen.

 

 

Gehe ich richtig, daß "Freeware PSPad" ein Hex-Editor ist?

 

PSPad ist ein Freeware Editor (für Programmierer) der u.a. auch hex kann. Was ich an ihm liebe ist neben seiner enormen Funktionsvielfalt vorallem seine schnelle Start/Ladezeit nach aktivierung über Kontextmenü bezüglich einer Datei. Und zweitens: er kann auch sehr große Dateien. Lade mal spaßenshalber eine 100MB große Datei mit einem BELIEBIGEN Editor aus dem Hause MS. Überhaupt, wenn bei MS große Dateien ins Spiel kommen, ist es aus mit der Herrlichkeit ...

 

 

erwin

[Webturtle]

Hallo,

 

vielen Dank für die Hinweise.

 

Wenn ich zuhause am Rechner bin, werde ich mir mal die Txt-Dateien mit einem Editor ansehen, die in der Desktopsearch-Ansicht nicht korrekt dargestellt werden. Wenn ich Tjods Charset=1 mit dem Script finden kann, kann dieses die betreffende Datei einfach überspringen.

 

@erwin: Mein Problem war, daß das Script beim Konvertieren dann ein unbrauchbares Ergebnis geliefert hat, wenn die Quelldatei nicht Unicode sondern Ansi (also eine alte DVBViewer-TXT-Datei) war. Ich habe es vor etwa einem halben Jahr quick und dirty geschrieben . Aber ich werden es mir noch einmal ansehen und wenn die Konvertierung nicht von einer Autohotkey-Funktion vrogenommen wird, Deinen Hinweis berücksichtigen. Ich habe zwar schon einen Hex-Editor, aber den Freeware PSPad werde ich mir auf alle Fälle einmal ansehen.

 

 

Mit freundlichen Grüßen

 

Webturtle