gedit ne peut pas reconnaître le codage de caractères, mais gvim peut
J'ai beaucoup de fichiers de texte brut qui proviennent d'un environnement Windows.
Beaucoup d’entre eux utilisent une page de code Windows par défaut, qui n’est ni ASCII (7 bits) ni UTF-8.
gvim n'a pas de problème à ouvrir ces fichiers, mais gedit ne le fait pas.
gvim rapporte le codage comme latin1.
Je suppose que gvim fait une hypothèse "intelligente" à propos de la page de code.
(Je crois que cette page de code a toujours international variantes).
Certaines questions découlent de ceci:
(1). Est-il possible que le gedit puisse reconnaître cette page de code?
** NB. [Mise à jour] Pour ce point (1), voir mon réponse ci-dessous.
** Pour les points (2) et (3). voir la réponse de Oli.(2). Existe-t-il un moyen d’analyser le système de fichiers pour identifier ces fichiers problématiques?
(3). Existe-t-il un outil de conversion par lots pour convertir ces fichiers au format UTF-8?
(.. Ce chaos de texte du vieux monde était en fait la goutte d’eau ultime qui m’a amené à Ubuntu ... Le système UTF-8 par défaut Brilliant )
[UPDATE]
** NB: ** Je considère maintenant que la mise à jour suivante est partiellement non pertinente, car les fichiers "problème" ne sont pas le "problème". "(voir mon réponse ci-dessous).
Je l’ai laissé ici, car c’est peut-être utile à quelqu'un.
J'ai mis au point un moyen rapide d'identifier les fichiers problématiques ...
La commande file ne convenait pas car elle identifiait mon fichier d'exemple en ASCII ... mais un fichier ASCII était conforme à 100% UTF-8 ...
Comme je l'ai mentionné dans un commentaire ci-dessous, le test d'un octet premier invalide d'un point de code UTF-8 est le suivant:
- si le premier octet (d'un point de code UTF-8) est compris entre 0x80 et 0xBF (réservé pour des octets supplémentaires) ou supérieur à 0xF7 ("forme trop longue"), il s'agit d'une erreur
Je sais que sed (un peu, via un port Win32), j'ai donc réussi à bricoler un motif RegEx qui trouve ces offending octets.
C'est une ligne laide, alors détour le regard maintenant si expressions régulières te faire peur :)
J'apprécierais vraiment si quelqu'un montrait comment utiliser hex valeurs dans une expression plage [] .. Je viens d'utiliser le o = opérateur \
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}"
Donc, je vais maintenant greffer ceci dans Oli solution par lots ... Merci Oli!
PS Voici l'octet UTF-8 invalide trouvé dans mon fichier d'exemple ...
"H.Bork, Gøte-borg." ... le "ø" = F8 hex ... lequel est un caractère UTF-8 non valide.
iconv est probablement ce que vous voudrez utiliser. iconv -l vous montrera les encodages disponibles et vous pourrez ensuite utiliser quelques commandes pour les recoder:
# 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
Si vous voulez faire cela avec des fichiers dont vous n'avez pas l'encodage (parce qu'ils sont partout), vous voulez introduire quelques commandes supplémentaires: find, file, awk et sed. Les deux derniers ne sont là que pour traiter la sortie du fichier.
for file in find . -type f -exec file --mime {} \; | grep "ascii" | awk '{print $1}' | sed s/.$//; do
...
Je ne sais pas si cela fonctionne réellement, donc je ne l'aurais certainement pas exécuté à partir de tout le répertoire le moins important que vous avez (créez un dossier de test contenant des fichiers ASCII connus). La syntaxe de find pourrait l'empêcher d'être dans une boucle for. J'espère que quelqu'un d'autre ayant plus d'expérience de base pourra intervenir et régler le problème pour que ce soit la bonne chose à faire.
Gedit peut détecter le bon jeu de caractères uniquement s'il est répertorié dans "Codage de fichier ouvert". Vous pouvez modifier cette liste, mais gardez à l'esprit que l'ordre est important.
J'y ai réfléchi un peu plus ...
Oui, le "ø" = 0xF8 hex * était certainement la raison pour laquelle gedit n'ouvrait pas le fichier ...
Pourquoi? Parce que ce n'est pas un octet UTF-8 valide.
Par défaut, gedit n'ouvrira que les fichiers UTF-8 ...
Cependant, gedit possède une fonctionnalité de détection automatique de page de code, mais vous devez d'abord Ajouter codepages à sa liste de "possibles".
La boîte de dialogue rouge vif qui apparaît lorsque gedit ne peut pas reconnaître la page de code, comporte un bouton qui vous permet de Ajouter une autre page de code ...
Problème résolu! ... presque ...
La question des nœuds relève maintenant la tête ... De quelle page de code s'agit-il?
Dans ma situation, je peux raisonnablement supposer qu'il s'agit de la page de codes Windows anglaise standard (pour ma région? Ou pour la région d'origine du fichier? .. J'ai mentionné "knarly":) ....
Quoi qu'il en soit, gedit vous permettra de charger un fichier une fois que vous aurez ajouté la page de code à sa liste ...
Ainsi, bien que toutes les commandes du terminal soient utiles et intéressantes, il semble que cette ligne de pensée se dirigeait dans la mauvaise voie.
Il n'y a rien intrinsèquement mauvais dans ces fichiers ...
Le problème semble être purement lié aux pages de codes.
gedit peut ouvrir le fichier, tout comme gvim le peut.
... mais la page de code correspondante doit d'abord être ajoutée à sa liste de pages de code.
par exemple. via la boîte de dialogue File-Open ou la boîte de dialogue d’avertissement rouge que j’ai rencontrée.
Vous pouvez utiliser l'une des 3 lignes de commande:
gedit --encoding=utf-8 filename
gedit --encoding=iso-8859-15 filename
gedit --encoding=utf-16 filename
. . . . .