1 votes

Quelqu'un peut-il expliquer ce comportement lié à l'encodage ?

Le codage n'est pas mon point fort, bien que j'en aie lu pas mal.

Il y a un fichier que je veux éditer, son extension est .tdl, mais cela ne veut rien dire en particulier.

Il s'agit d'un fichier XML. La première ligne ressemble à ceci :

<?xml version="1.0" encoding="utf-16"?>

Lorsque j'essaie d'ouvrir ce fichier avec gedit, j'obtiens un gros message sur fond jaune, disant :

"Il y a eu un problème lors de l'ouverture du fichier ... Le fichier que vous avez ouvert a des caractères non valides. Si vous continuez à éditer ce fichier, vous pourriez corrompre ce document. Vous pouvez également choisir un autre encodage de caractères et réessayer"

La liste déroulante "Character Encoding" (codage des caractères) indique "Current Locale (UTF-8)".

J'essaie de le régler sur "Unicode (UTF-16)" et je clique sur "Réessayer". Le message désagréable réapparaît et la liste déroulante est à nouveau réglée sur "Current Locale (UTF-8)".

J'ai également essayé d'ouvrir le fichier en allant dans Fichier --> Ouvrir --> Encodage des caractères : passer de "Détecté automatiquement" à "Unicode (UTF-16)". Mais j'obtiens à nouveau ce message désagréable, toujours avec le menu déroulant réglé sur "Current Locale (UTF-8)".

De manière programmatique (en utilisant Groovy, groovy.xml.XMLParser ) Je suis en mesure d'analyser ce fichier et de produire un message apparemment valide. groovy.util.Node structure. Je n'en suis pas encore à essayer de sauvegarder cette structure interne des nœuds, qu'elle soit modifiée ou non.

Quelqu'un peut-il me dire ce qui ne va pas (s'il y a quelque chose) avec ce fichier, et comment je pourrais le modifier en toute sécurité ?

1voto

xenoid Points 9208

En UTF-16, les caractères sont sur deux octets, et pour les caractères ASCII, l'octet de poids fort est 0x00.

Par exemple, "Something" en UTF-16 est :

00000000  ff fe 53 00 6f 00 6d 00  65 00 74 00 68 00 69 00  |..S.o.m.e.t.h.i.|
00000010  6e 00 67 00 0a 00                                 |n.g...|

(Le OxFFFE au début est la marque d'ordre des octets, si vous voyez 0xFEFF, vous savez que vous devez échanger des octets...).

Les caractères NUL disséminés un peu partout perturbent les logiciels...

Vous pouvez convertir en un UTF-8 plus raisonnable, en utilisant iconv :

iconv -f UTF-16 -t UTF-8 <utf16file >utf8file

Et n'oubliez pas de modifier l'encodage dans l'en-tête du fichier

-1voto

vonbrand Points 2343

Si le fichier est en UTF-16 (encodage typique de Windows), vous aurez des problèmes sous Linux (UTF-8 natif, militant...). Au moins GNU emacs dit qu'il supporte l'UTF-16, je ne l'ai jamais utilisé dans la colère.

Vous pouvez essayer recode(1) pour traduire en UTF-8 (et corriger les en-têtes et autres pour les faire correspondre), mais cela risque de casser les outils qui s'attendent à UTF-16 de manière horrible.

Mise à jour : Je viens d'y penser : recodez en UTF-8 ; malaxez, broyez, défigurez à loisir ; recodez en UTF-16. De cette façon, vous pouvez utiliser des outils familiers au milieu. Mais faire corriger l'encodage UTF-16 annoncé, qui sait si les outils se confondent. Ou peut-être que les outils de traitement XML en tiennent compte...

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X