» Blog

2010
Jul
10

Comment détecter l'encodage d'un fichier ?

C’est une question délicate qui a méritée quelques recherches et une longue réflexion de ma part. Étonnamment, la réponse n’est pas triviale. Pour situer rapidement le contexte, l’idée était de détecter en PHP le charset d’un fichier afin de le manipuler proprement. Delphiki, auteur du site www.u-sub.net, souhaitait effectuer des statistiques, des ajustements et des conversions automatiques dans plusieurs formats et normes des sous-titres qu’il propose.

Réponse

Détecter l’encodage d'un fichier en fonction du contenu est impossible. La fonction PHP mb_detect_encoding() et la commande file -i d'Unix font toutes les deux une supposition. L'avantage de file -i par rapport à la fonction PHP est que l'ordre de détection des charsets a déjà été pensé. Ainsi, le charset détecté est le plus souvent le bon. Si on arrive à déterminer comment les charsets doivent être ordonnés, on peut reproduire le même comportement en PHP à l'aide de la fonction mb_detect_order().

On ne peut pas deviner quel est le charset d'un fichier simplement parce qu'une même représentation binaire d'un caractère en machine peut correspondre à deux caractères différents suivant le charset. Comment alors dire qu'un charset est plus correct qu'un autre ?

Explications par des exemples

Exemple n°1

Prenons par exemple, le ANSI et l'UTF8.

J'ai un fichier que j'ai enregistré avec mon éditeur de texte avec un charset ANSI. Mon script peut très bien dire qu'il s'agit d'un fichier UTF8 sans BOM. Effectivement pour lui, tous les caractères du fichier correspondent au charset UTF8 sans BOM même si le fichier n'a pas été enregistré réellement dans ce format. Il fait une supposition. Il ne peut pas faire autrement ! Cette information n'est pas présente dans les méta-données du fichier.

On peut effectivement affiner cette supposition. Il suffit de regarder si tous les caractères appartiennent au charset ANSI avant de vérifier l'UTF8. Ça fonctionne dans ce cas simplement parque l'UTF8 est un dérivé de l'ANSI.

Exemple n°2

Prenons maintenant deux charsets totalement différent mais recouvrant le même nombre de représentation de caractères : 2 (c'est pour illustrer). Dans le premier, le caractère E est codé en 0000 et dans le second 0001. La seconde lettre est le X. Comment déterminer quel est le charset utilisé pour ce fichier ? Bon courage.

Charset n°1
Représentation binaireLettre
0000E
0001X
Charset n°2
Représentation binaireLettre
0000X
0001E

Prenons ce contenu binaire d'un fichier quelconque : 00000001

C'est seulement après conversion avec la table de caractère du charset que le texte apparait graphiquement ; et c'est seulement à ce moment là que le lecteur peut dire s'il a du sens ou pas.

Après conversion avec le charset 1, on obtient EX.
Après conversion avec le charset 2, on obtient XE.

Avec le second charset, le contenu ne veut plus rien dire mais pourtant les représentations binaires des deux caractères étaient valides pour le charset2.

Comment s'en sortent les systèmes d'exploitations ?

Maintenant qu'on voit le fond du problème, comment font les OS s'ils n'ont pas l'information ? Il s'appuie simplement sur la localisation de l'utilisateur. Inutile de chercher une correspondance avec un charset chinois si l'utilisateur est français. L'OS fait une hypothèse.

Pour insister sur le fait que cette notion est un joyeux bordel. Concaténons, par exemple, deux fichiers UTF8 avec BOM, on se retrouve avec des bytes de déclaration de l'encodage au milieu du fichier résultat... C'est bêtement ce que fait la commande COPY sous Windows. Quelque part, ça revient à dire que le même fichier est encodé de deux manières différentes (la même pour cet exemple, mais pas forcément). Bref ; et comme chaque OS gère ça à sa sauce...

Conclusion

Que devrais-faire, selon moi, une classe confrontée à ce problème ? Laisser le choix au développeur de préciser le charset des fichiers qu'il manipule pour conserver le sens du texte. A défaut, choisir un charset compatible avec l'ensemble des caractères du fichiers pour faire le traitement souhaité et tant pis pour le développeur si le texte ne veut plus rien dire...

A lire aussi :

Notes :


2010
Apr
19

Koyöt Team

Page d'accueil du site de la Koyöt Team J'aime tout ce qui touche à l'informatique. Vous ne serez pas surpris d'apprendre que cela recouvre également le jeu vidéo. Ainsi, je joue régulièrement à Team Fortress 2.

J'ai d'ailleurs une team. Il s'agit des Koyöt. Nous n'avions jusqu'alors pas réellement de site pour nous organiser. C'est maintenant chose faite. La partie publique est pour le moment plutôt légère mais comporte de nombreuses jokes que je vous laisse découvrir. La partie privée constitue un espace réservé aux membres de notre équipe. Elle permet de gérer les membres, les différentes line-up et les nombreux événements auxquels nous participons. Cette année, nous nous inscrivons dans un tournoi officiel : la ligue.

Pour information, ce site est une application web de taille moyenne (~ 70 pages) réalisée avec Atom, Xml, Xhtml, CSS, PHP, MySQL et sans Framework.


2010
Feb
4

Concours WinGineer

Du 10 décembre 2009 au 13 mars 2010, le groupe ESIEA organise son concours WinGineer. Ne souhaitant pas rejoindre cette école, je me suis inscrit début janvier dans la poule libre. Les lots se composent en effet de frais d'inscription totalement ou partiellement offert. A l'heure où j'écris ces lignes, je suis 14ème sur 310 participants.

Chaque candidat dispose d'un tank qui évolue sur une carte boisée. L'idée est de ramasser plus d'étoiles que ses adversaires et de survivre jusqu'à la fin du temps réglementaire. Pour le programmeur, le principe consiste à développer deux IA : celle qui gère le tank et celle qui gère ses missiles. J'ai donc appris sur le tas NetLogo qui est le langage utilisé. Mon pseudonyme est elementaire et comme vous le voyez dans la vidéo ci-dessous extraite d'un match, je défonce tout !


2009
Nov
13

Mozilla Developer Center et sa technologie XUL

Comme je vous l'avais annoncé dans mon billet précédent, je vais vous parler d'une technologie de la fondation Mozilla que j'ai récemment expérimenté. Il s'agit de XUL. C'est un langage de description d'interfaces graphiques fondé sur XML et créé dans le cadre du projet Mozilla. Je me suis récemment familiariser avec cette technologie afin de développer ma première extension Firefox. En effet, une partie de la version 3 de ce navigateur et toute la version 4 exploite la technologie XUL. Pour vulgariser le concept, je dirais que c'est un mélange de XML pour représenter les interfaces (boutons, listes, textes...) et de Javascript pour les dynamiser.

Cette technologie est agréable à utiliser et repose sur des normes et des principes clairs. Elle est légère et fonctionne indépendamment du système d'exploitation. Ce que j'aime dans la conception, c'est qu'elle est événementielle. En d'autres termes, le code source est organisé selon un principe simple : tel action correspond tel évènement. Tout n'est malheureusement pas aussi parfait. Le MDC qui est le wiki officiel pour apprendre la technologie est une vraie horreur à utiliser. Je ne vous parlerai pas de la version française qui n'est traduite que partiellement mais seulement de la version anglaise. Il manque des références entières sur certains composants graphiques et certains services. Un service, c'est une sorte de code embarqué qui fournit un accès complet à un concept de l'OS : le système de fichier par exemple. Les méthodes et leurs paramètres ne sont pas toujours documentés. Je crois que le pire sur ce wiki, officiel je le rappelle, c'est obsolescence du contenu. Quelle galère pour développer pour FF 3.5 quand tout ce qui est écrit correspond au mieux à FF 3 ! Je ne parlerai pas non plus dans ce billet de son concurrent XulFr.org qui héberge un tutoriel en date de 2007.

Je sais que les SSII à développer leurs logiciels avec cette technologie sont peu nombreuses. Je plains sincèrement les équipes d'ingénieurs informatiques de Renault F1 Team ou celles du site LeMonde.fr par exemple qui chaque jour doivent se plonger dans ce fameux wiki. Depuis, je me pose une question. Comment la fondation Mozilla peut-elle gâcher l'avenir d'une technologie si prometteuse ?


2009
Oct
28

Ouverture du site

Après une bonne semaine de développement, je me permets de mettre mon site en ligne. L'ensemble du contenu que je souhaitais mettre pour l'ouverture est présent. Comme vous pouvez le remarquer, ma ligne éditoriale se décompose en deux sections distinctes : labs et blog.

Dans la première rubrique, vous retrouverez tous mes travaux sur la toile qui mérite qu'on en parle. Voici les 4 premiers :

Dans la seconde rubrique, à l'image d'un blog, j'y posterai des billets d'humeurs. Je compte en réaliser un prochainement sur la technologie XUL de Mozilla.

Ce site web n'est pas figé et va évoluer au fur et à mesure en se dotant de nouveau contenu dans un premier temps et en s'améliorant ergonomiquement, graphiquement et techniquement dans un second temps. J'ai comme projet d'ajouter des flux XML par exemple.