Problèmes d'encodage et commandes pour les résoudre

Il faudra encore un peu ajuster le script publié hier. En fait, aujourd’hui on s’est posées la question de l’encodage du fichier correspondant à la page aspirée de l’URL de départ. S’il n’est pas en UTF-8, il faudra le convertir en UTF-8. Donc, avant de faire le « dump », on doit contrôler l’encodage de départ ! Mais comment on repère l’encodage d’un fichier ?

Pour ce faire, on utilisera la commande file, comme dans l’exemple suivante :

file -i toto.txt
Le terminal donne come résultat : charset=utf-8

Il faut dire à la commande lynx qu’il fasse le « dump » selon cet encodage. Pour extraire l’encodage « utf-8 », il faut utiliser la commande cut : si on  imagine un fichier avec plusieurs colonnes, la commande cut nous permet d’extraire la colonne qui nous intéresse (la deuxième colonne, après l’« = »). On utilisera alors :

Cut –f (pour définir les colonnes)

Cut –d (pour spécifier le marquer de colonnes : dans notre cas, le marquer est le caractère « = »)

Cut –f2 –d (pour extraire la deuxième colonne après le « = »)
Comme ça, j’obtiens la valeur que je veux et je peux la stocker dans la variable « encodage » :
Encodage= $(file –i  toto.txt) | Cut –f2 –d=
En plus, on doit spécifier l’encodage de sortie, par exemple :
Lynx –dump –nolist –dc = $encodage ./PAGES-ASPIREES/3/2.html > toto.txt (doit être en UTF-8)

La commande iconv permet de transformer un encodage donné dans un autre encodage donné. Elle travaille avec un liste d’encodages qu’elle sait traiter, mais parfois elle rencontre un encodage inconnu : comment faire ? Pour repérer l’information qui nous sert, il faut contrôler l’encodage dans les balises HTML. Cette type d’information se trouvera après « charset ». Il faudra interroger le fichier de manière qu’il nous donne quelque chose comme « charset ». Pour ce faire, on peut utiliser la commande egrep : il s'agit d'une commande de filtrage. Elle va chercher un « motif », ou une chaine de caractères dans un fichier. Exemple:
Egrep “charset=” ./PAGES-ASPIREES/3/8.html (pipe) cut -f4 -d=

On doit utiliser la commande cut pour récupérer le charset et peut être que la personne qui a écrit la balise HTML n’a pas écrit le charset dans la bonne position. Donc, comment être sures du charset récupéré ? Comment peut-on récupérer la bonne colonne ? A quel niveau la personne a écrit la chaine de caractère « charset= » ?

Tout ce qu'on a, c'est une structure textuelle indéfinie et nous intéresse la chaine de caractère « charset= » pour pouvoir lancer une commande cut après. Mais la commande cut accepte des caractères singuliers et pas un groupe de caractères, donc il faut utiliser une variable ! Le caractère doit être non ambigu pour la commande cut. Ex. @ ou le "pipe", mais encore mieux #.

On va remplacer la chaine de caractères « charset= » par ce caractère là pour qu’il soit non ambigu. Pour ce faire, il faut utiliser une nouvelle commande : la commande sed. Il s'agit d'un éditeur de la ligne de commande: il peut rechercher et remplacer la chaine de caractères « charset= » par "pipe" : |

Sed –e “s/charset=/\|/” (pour déspécialiser, parce que c’est un operateur des expressions régulières)

Sed –e “s/charset=/\|/” | cut –d|

Mais "pipe" sert pour la direction de flux donc ce n’est pas un bon choix. Il faut indiquer qui est un caractère et le déspécialiser:

Sed –e “s/charset=/\|/” | cut –d“|” –f2

ou

Sed –e “s/charset=/\|/” | cut –d\| –f2

Le terminal donne comme résultat: iso-8859-1” />

Mais on ne veut pas la chaine de caractères «  ” /> ». Pour l'éliminer, on peut utiliser la commande cut et le caractère « ” » comme délimitateur ou effacer ce qui reste en le remplaçant par rien :

Sed –e “s/\.*$// ”

. = n’importe quel caractère sauf le retour à la ligne

$ représente la fin d’une chaine / ligne

a* (a, aa, aaa…)

On a maintenant tous les instruments pour ajouter notre quatrième colonne!