Comment identifier un personnage étrange?

J'essaie d'identifier un personnage étrange que j'ai trouvé dans un fichier avec lequel je travaille:

$ cat file
�
$ od file
0000000 005353
0000002
$ od -c file
0000000 353  \n
0000002
$ od -x file
0000000 0aeb
0000002

Le fichier utilise le codage ISO-8859 et ne peut pas être converti en UTF-8:

$ iconv -f ISO-8859 -t UTF-8 file
iconv: conversion from `ISO-8859' is not supported
Try `iconv --help' or `iconv --usage' for more information.
$ iconv  -t UTF-8 file
iconv: illegal input sequence at position 0
$ file file
file: ISO-8859 text

Ma principale question est de savoir comment puis-je interpréter la sortie d' odici? J'essaie d'utiliser cette page qui me permet de traduire entre différentes représentations de caractères, mais elle me dit qu'en 005353tant que "point de code hexadécimal" 卓ce qui ne semble pas correct et en 0aebtant que "point de code hexadécimal" est ૫ce qui, encore une fois, semble incorrect .

Alors, comment puis-je utiliser l'une des trois options ( 355, 005353ou 0aeb) pour savoir quel personnage ils sont censés représenter?

Et oui, j'ai essayé avec les outils Unicode mais il ne semble pas non plus être un caractère UTF valide:

$ uniprops $(cat file)
U+FFFD ‹�› \N{REPLACEMENT CHARACTER}
    \pS \p{So}
    All Any Assigned Common Zyyy So S Gr_Base Grapheme_Base Graph X_POSIX_Graph
       GrBase Other_Symbol Print X_POSIX_Print Symbol Specials Unicode

si je comprends la description du caractère Unicode U + FFFD, ce n'est pas du tout un vrai caractère mais un espace réservé pour un caractère corrompu. Ce qui est logique puisque le fichier n'est pas réellement encodé en UTF-8.

Votre fichier contient deux octets, EB et 0A en hexadécimal. Il est probable que le fichier utilise un jeu de caractères avec un octet par caractère, tel que ISO-8859-1 ; dans ce jeu de caractères, EB est ë:

$ printf "\353\n" | iconv -f ISO-8859-1
ë

Les autres candidats seraient δ dans la page de code 437 , Ù dans la page de code 850 ...

od -xLa sortie de confuse dans ce cas en raison de l'endianité; une meilleure option est celle -t x1qui utilise des octets simples:

$ printf "\353\n" | od -t x1
0000000 eb 0a
0000002

od -xles cartes od -t x2auxquelles lit deux octets à la fois, et sur les systèmes little-endian sortent les octets dans l'ordre inverse.

Lorsque vous rencontrez un fichier comme celui-ci, qui n'est pas UTF-8 valide (ou n'a aucun sens lorsqu'il est interprété comme un fichier UTF-8), il n'y a aucun moyen infaillible de déterminer automatiquement son encodage (et son jeu de caractères). Le contexte peut aider: s'il s'agit d'un fichier produit sur un PC occidental au cours des deux dernières décennies, il y a de fortes chances qu'il soit codé en ISO-8859-1, -15 (la variante Euro) ou Windows-1252; s'il est plus ancien que cela, les CP-437 et CP-850 sont probablement des candidats. Les fichiers des systèmes d'Europe de l'Est, des systèmes russes ou des systèmes asiatiques utiliseraient différents jeux de caractères que je ne connais pas beaucoup. Ensuite, il y a EBCDIC ... listera iconv -ltous les jeux de caractères connus iconv, et vous pouvez procéder par essais et erreurs à partir de là.

(À un moment donné, je connaissais par cœur la plupart des CP-437 et ATASCII, c'était l'époque.)

Notez que odc'est court pour le vidage octal , 005353les deux octets comme mot octal, od -xsont 0aeben hexadécimal comme mot, et le contenu réel de votre fichier est les deux octets ebet 0aen hexadécimal, dans cet ordre.

Donc, les deux 005353et 0aebne peuvent pas simplement être interprétés comme «point de code hexadécimal».

0aest un saut de ligne (LF) et ebdépend de votre encodage. fileest juste de deviner l'encodage, ça pourrait être n'importe quoi. Sans aucune autre information sur l'origine du fichier, etc., il sera difficile de le savoir.

Il est impossible de deviner avec 100% de précision le jeu de caractères des fichiers texte.

Des outils comme chardet , firefox , file -i quand aucune information explicite de jeu de caractères n'est définie (par exemple, si un HTML contient un méta jeu de caractères = ... dans la tête, les choses sont plus faciles) essaieront d'utiliser des heuristiques qui ne sont pas si mauvaises si le texte est assez gros.

Dans ce qui suit, je démontre la détection de charset avec chardet( pip install chardet/ apt-get install python-chardetsi nécessaire).

$ echo "in Noël" | iconv -f utf8 -t latin1  | chardet
<stdin>: windows-1252 with confidence 0.73

Après avoir un bon candidat de jeu de caractères, nous pouvons utiliser iconv, recodeou similaire, pour changer le fichier de caractères en votre jeu de caractères "actif" (dans mon cas utf-8) et voir s'il a bien deviné ...

iconv -f windows-1252  -t utf-8 file

Certains jeux de caractères (comme iso-8859-3, iso-8859-1) ont de nombreux caractères en commun - parfois, il n'est pas facile de voir si nous avons trouvé le jeu de caractères parfait ...

Il est donc très important d'avoir des métadonnées associées au texte pertinent (par exemple XML).

#!/bin/bash
#
# Search in a file, a known (part of a ) String (i.E.: Begrüßung),
# by testing all encodings
#
[[ $# -ne 2 ]] && echo "Usage: encoding-finder.sh FILE fUnKy_CHAR_FOR_SURE_IN_FILE" && exit
FILE=$1
PATTERN=$2
for enc in $( iconv -l | sed 's/..$//') 
do 
    iconv -f $enc -t UTF-8 $FILE  2>/dev/null | grep -m 1 $PATTERN && echo $enc 
done 

Si j'obtiens un fichier qui contient, par exemple, le mot Begrung, je peux en déduire que Begrüßung pourrait être voulu. Je le convertis donc par tous les encodindgs connus et regarde, s'il y en a un, qui le convertit correctement.

Habituellement, il existe plusieurs encodages qui semblent correspondre.

Pour les fichiers plus longs, vous pouvez couper un extrait au lieu de convertir des centaines de pages.

Donc je l'appellerais

encodingfinder.sh FILE Begrüßung

et les tests de script, que ce soit en les convertissant avec les encodages connus, lesquels produisent "Begrüßung".

Pour trouver de tels personnages, moins est généralement utile, car les personnages funky se distinguent souvent. Du contexte, le bon mot à rechercher peut généralement être déduit. Mais nous ne voulons pas vérifier avec un hexeditor, de quel octet il s'agit, puis visiter des tables infinies d'encodages, pour trouver notre délinquant. :)