it-swarm.com.de

gedit kann die Zeichenkodierung nicht erkennen, gvim jedoch

Ich habe viele einfache Textdateien, die aus einer Windows-Umgebung stammen.
Viele von ihnen verwenden eine verrückte Standard-Windows-Codepage, die weder ASCII (7 Bit) noch UTF-8 ist.

gvim hat keine Probleme beim Öffnen dieser Dateien, aber gedit schlägt fehl.
gvim gibt die Kodierung als latin1 an.

Ich gehe davon aus, dass gvim eine "kluge" Annahme über die Codepage macht.
(Ich glaube, diese Codepage hat noch internationale Varianten).

Hieraus ergeben sich einige Fragen:

  • (1). Gibt es eine Möglichkeit, mit der gedit diese Codepage zu erkennen?
    ** NB. [Update] Zu diesem Punkt (1) siehe my Antwort unten.
    ** Für die Nummern 2 und 3. siehe Olis Antwort.

  • (2). Gibt es eine Möglichkeit, das Dateisystem zu scannen, um diese problematischen Dateien zu identifizieren?

  • (3). Gibt es ein Batch-Konvertierungs-Tool, um diese Dateien nach UTF-8 zu konvertieren?

(.. dieses Text-Chaos in der alten Welt war eigentlich der letzte Schrei, der mich zu Ubuntu brachte ... UTF-8 standardmäßig systemweit Brilliant )

[UPDATE]
** NB: ** Ich halte das folgende Update jetzt für teilweise irrelevant, da die "Problem" -Dateien nicht das "Problem" sind "(siehe mein Antwort unten).
Ich habe es hier gelassen, weil es für jemanden von allgemeinem Nutzen sein kann.


Ich habe einen groben und einfachen Weg gefunden, um die problematischen Dateien zu identifizieren ...
Der Befehl file war nicht geeignet, da er meine Beispieldatei als ASCII identifiziert hat ... aber eine ASCII -Datei ist 100% UTF-8-konform ...

Wie ich weiter unten in einem Kommentar erwähnt habe, lautet der Test für ein ungültiges erstes Byte eines UTF-8-Codepunkts:

  • Wenn das erste Byte (eines UTF-8-Codepunkts) zwischen 0x80 und 0xBF liegt (reserviert für zusätzliche Bytes) oder größer als 0xF7 ("überlange Form"), wird dies als Fehler angesehen

Ich kenne sed (ein bisschen über einen Win32-Port), also habe ich es geschafft, ein RegEx-Muster zusammenzusetzen, das diese beleidigenden Bytes findet.

Es ist eine hässliche Linie, also schau weg, wenn reguläre Ausdrücke dich erschrecken :)

Ich würde es wirklich begrüßen, wenn jemand darauf hinweist, wie man hex -Werte in einem range [] -Ausdruck verwendet. Ich habe gerade oder verwendet = operator \

fqfn="/my/fully/qualified/filename"  
sed -n "/\x80\|\x81\|\x82\|\x83\|\x84\|\x85\|\x86\|\x87\|\x88\|\x89\|\x8A\|\x8B\|\x8C\|\x8D\|\x8E\|\x8F\|\x90\|\x91\|\x92\|\x93\|\x94\|\x95\|\x96\|\x97\|\x98\|\x99\|\x9A\|\x9B\|\x9C\|\x9D\|\x9E\|\x9F\|\xA0\|\xA1\|\xA2\|\xA3\|\xA4\|\xA5\|\xA6\|\xA7\|\xA8\|\xA9\|\xAA\|\xAB\|\xAC\|\xAD\|\xAE\|\xAF\|\xB0\|\xB1\|\xB2\|\xB3\|\xB4\|\xB5\|\xB6\|\xB7\|\xB8\|\xB9\|\xBA\|\xBB\|\xBC\|\xBD\|\xBE\|\xBF\|\xF8\|\xF9\|\xFA\|\xFB\|\xFC\|\xFD\|\xFE\|\xFF/p" "${fqfn}"  

Also werde ich das jetzt in Oli's Batch-Lösung einpfropfen ... Danke Oli!

PS. Hier ist das ungültige UTF-8-Byte, das es in meiner Beispieldatei gefunden hat ...
"H.Bork, Gøte-borg." ... das "ø" = F8 hex ... welches ist ein ungültiges UTF-8-Zeichen.

4
Peter.O

iconv ist wahrscheinlich das, was Sie verwenden möchten. iconv -l zeigt Ihnen die verfügbaren Codierungen an und Sie können dann einige Befehle verwenden, um sie alle neu zu codieren:

# all text files are in ./originals/
# new files will be written to ./newversions/

mkdir -p newversions
cd originals
for file in *.txt; do
    cat $file | iconv -f ASCII -t utf-8 > ../newversions/$file;
done

Wenn Sie dies mit Dateien tun möchten, für die Sie keine Kodierung haben (weil sie überall sind), müssen Sie ein paar weitere Befehle eingeben: find, file, awk und sed. Die letzten beiden sind nur dazu da, die Ausgabe der Datei zu verarbeiten.

for file in find . -type f -exec file --mime {} \; | grep "ascii" | awk '{print $1}' | sed s/.$//; do
    ...

Ich habe keine Ahnung, ob dies tatsächlich funktioniert, daher würde ich es auf keinen Fall von dem unwichtigsten Verzeichnis ausführen, das Sie haben (erstellen Sie einen Testordner mit einigen bekannten ASCII -Dateien in). Die Syntax von find verhindert möglicherweise, dass es sich in einer for-Schleife befindet. Ich hoffe, dass jemand anderes mit mehr Bash-Erfahrung hineinspringen und es klären kann, damit es das Richtige tut.

4
Oli

Gedit kann den korrekten Zeichensatz nur erkennen, wenn er unter "Datei-Öffnen-Zeichensatz" aufgeführt ist. Sie können diese Liste ändern, aber beachten Sie, dass die Reihenfolge wichtig ist.

1
skarmoutsosv

Ich habe ein bisschen mehr darüber nachgedacht ...

Ja, das "ø" = 0xF8 hex * war definitiv der Grund, warum gedit die Datei nicht öffnen konnte ...
Warum? Weil es kein gültiges UTF-8-Byte ist.
Standardmäßig öffnet gedit nur UTF-8-Dateien ...

Allerdings hat gedit eine Codepage-Auto-Erkennungsfunktion, aber Sie müssen zuerst Add Codepages zu seiner Liste der "Possible" hinzufügen.

Der hellrote Dialog, der erscheint, wenn gedit die Codepage nicht erkennen kann, hat einen Button, mit dem Sie Add eine andere Codepage hinzufügen können ...

Problem gelöst! ... fast ...

Die knarly Ausgabe hebt jetzt wieder den Kopf .... Um welche Codepage handelt es sich?

In meiner Situation kann ich davon ausgehen, dass es sich um die englische Standard-Windows-Codepage handelt (für meine Region? Oder für die Region, in der die Datei erstellt wurde? .. Ich habe "knarly" erwähnt:) ....

Wie auch immer, mit gedit können Sie eine Datei laden, sobald Sie Added die Codepage zu ihrer Liste hinzugefügt haben ...

Obwohl alle Terminal-Befehle für sich genommen nützlich und interessant sind, scheint es, dass diese Gedankenrichtung auf dem falschen Weg war.

Diese Dateien enthalten an sich nichts falsches ...
Es geht anscheinend nur um Codepages.

gedit kann die Datei genauso öffnen wie gvim.
... aber die entsprechende Codepage muss zuerst Hinzugefügt zu ihrer Codepage-Liste hinzugefügt werden.
z.B. über den Datei-Öffnen-Dialog oder den roten Warndialog, den ich getroffen habe.

0
Peter.O

Sie können eine der 3 Befehlszeilen verwenden:

gedit --encoding=utf-8 filename
gedit --encoding=iso-8859-15 filename
gedit --encoding=utf-16 filename
. . . . .
0
flaja94