Journal Reconnaissance d'encodage avec Utrac

Posté par calandoa le 03 décembre 2004 à 13:24.

Étiquettes : aucune

déc.

2004

Bonjour!

J'ai le plaisir de vous annoncer la sortie d'Utrac version 0.2. Il s'agit d'une bibliothèque et d'un utilitaire en ligne de commande dont la principale utilité est la reconnaissance automatique de jeux de caractères :

http://tech.alliancemca.net/utrac/(...)

Bien que le projet soit encore assez jeune, l'utilitaire marche déjà relativement bien. Pour la bibliothèque, il faudrait un peu plus de débugage et que j'écrive une doc et tutoriel pour l'API. Il y a bien une doc qui existe en doxygen, mais elle date de la version 0.1 et elle n'est pas encore mise à jour...

Les jeux de caractères supportés sont la série des iso, des cp (windows et dos), des Mac et l'utf-8. On peut très facilement en ajouter d'autres, à conditions qu'ils soient dérivés de l'ascii et mono-octets. La reconnaissance marche en général plutôt bien, même si il y a des problèmes avec des encodages proches (latin1, 2, 3 par ex)

Sinon, la liste des autres fonctionnalités :
- reconnaissance automatique des fins de lignes.
- prise en charge de la localisation (langage et système) pour une meilleur reconnaissance.
- tri du texte pour extraire les caractères étendus
- conversion (avec spécification de l'encodage en entrée)

Si vous avez des questions ou remarques, n'hésitez pas!

# je suis pas sur de comprendre

Posté par jraf le 03 décembre 2004 à 14:29. Évalué à 1.

ca apporte quoi de plus que "file" et/ou "recode" ?

http://packages.debian.org/stable/text/recode(...)
et
http://packages.debian.org/stable/utils/file(...)
- [^] # Re: je suis pas sur de comprendre
  
  Posté par calandoa le 03 décembre 2004 à 15:00. Évalué à 5.
  
  Par rapport à recode, ça fait de la reconnaissance, et par rapport à file, ça fait, en plus de la conversion, de la vraie reconnaissance, car file se limite aux possibilités Ascii / utf-8 / iso / non-iso qu'il gère d'ailleurs assez mal...
  
  Par rapport aux 2, il s'agit aussi d'une bibliothèque que l'on peut intégrer dans n'importe quel programme.
- [^] # Re: je suis pas sur de comprendre
  
  Posté par M le 03 décembre 2004 à 22:25. Évalué à 2.
  
  recode apporte quoi par rapport a iconv ?
# Equivalent en java

Posté par lampapiertramol (site web personnel) le 03 décembre 2004 à 14:33. Évalué à 3.

Juste histoire de raconter ma vie:

Je viens de découvrir cpdetector qui est un équivalent d'Ultrac en java http://cpdetector.sourceforge.net/(...)

Je compte bientôt m'en servir et serais intéressé par des témoignages d'utilisateurs (ça marche bien ?) ou par des projets similaires (toujours en java).
- [^] # Re: Equivalent en java
  
  Posté par allcolor (site web personnel) le 04 décembre 2004 à 10:49. Évalué à 2.
  
  J'ai voulu l'utiliser.... et bien ça fonctionne pas bien. Du moins, j'ai été incapable de lui faire reconnaître du 'iso-8859-15', il s'obstine à le reconnaître comme un charset BIGkekchose... (donc japonais ou chinois)... par contre l'utf-8 est ok.
  
  Pour moi, ce truc ne fonctionne pas, en tout les cas, pas comme ça devrait.
# à propos de codage...

Posté par Juke (site web personnel) le 03 décembre 2004 à 16:06. Évalué à 0.

Quel codage dois je utiliser pour que cette page s'affiche correctement ?
http://sonodis.fr/test/php/page.php?id=13&prod=S61815(...)

Merci de votre aide,

Julien
- [^] # Re: à propos de codage...
  
  Posté par calandoa le 03 décembre 2004 à 17:07. Évalué à 3.
  
  Chez moi ça s'affiche correctement... mais je suppose qu'il s'agit des apostrophes qui passent mal? c'est un problème assez courant : les encodages cp1252 (windows) et iso-8859-1 (unix) sont identiques, exeptés pour les caractères 0x80 à 0x9F (caractères de controles inutilisés sous iso-8859-x, différents symboles rajoutés sous cp1252, comme l'euro).
  
  Beaucoup de pages indiquent donc à tort "iso-8859-1" alors qu'il s'agit de cp1252, étant donné qu'elles utilisent des caractères compris entre 0x80 à 0x9F. Il s'agit ici du guillement simple fermant, utilisé assez stupidement comme apostrophe (c'est une pratique malheuresement très courante chez les windowsiens).
  - [^] # Re: à propos de codage...
    
    Posté par Juke (site web personnel) le 04 décembre 2004 à 00:18. Évalué à 1.
    
    merci de tes explications, entre temps j'avais resolu le problème.
    
    J'ai des problèmes à causes des charset pour passer de MAC -> windows -> serveur apache.
# Proposition comme ca:

Posté par Ph Husson (site web personnel) le 03 décembre 2004 à 17:28. Évalué à 3.

Fais toi recenser par freshmeat et n'oublie pas d'y inscrire les mises a jours.
(Etant packageur de la plupart des paquets de la distrib que j'utilise faut que j'ai un moyen simple de surveiller, alors freshmeat powa :)
# Probleme?

Posté par Ph Husson (site web personnel) le 03 décembre 2004 à 17:35. Évalué à 3.

Ta lib a l'air super et je compte l'utiliser mais un truc me chagrine:
Il n'y a a aucun endroit mention de la version 0.2 gros oublie de ta part?
Disponible seulement sur cvs/svn/arch/jesaispasquoid'autre?
- [^] # Re: Probleme?
  
  Posté par calandoa le 03 décembre 2004 à 20:00. Évalué à 4.
  
  Effectivement! J'ai mis à jour le site au boulot, et en interne cela marchait, mais maintenant de chez moi, ça pointe sur l'ancienne version! Et on est vendredi soir... y a l'admin qui va m'entendre lundi! :^)
  
  J'ai récupéré la version à jour que j'ai mis sur mon site perso :
  http://calandoa.free.fr/web/utrac(...)
  
  Il s'agit en fait d'une lib qu'on a développée pour être intégrée à un autre logiciel, et on a décidé d'en faire un projet en GPL vu que la reconnaissance de charsets est un thème peu abordé par l'ensemble des LL.
  
  La lib est par contre assez peu débugué (particulièrement la progress bar pour laquelle je me défausse de toute responsabilité quant aux segfaults qu'elle pourrait aléatoirement provoquer :^). Je suis en ce moment sur un autre développement, donc le débugage va se faire à petit rythme... Il y a par contre un petit tutoriel qu'il faudrait que j'écrive rapidement.
  
  Désolé pour le mauvais lien...
# Parser de commandes

Posté par olympien le 03 décembre 2004 à 23:01. Évalué à 1.

Je regardais vite fait le source, étant jeune débutant en C.

Pour le parser du main (option d'utilisation, arguments, ...), ne faudrait-il pas utliser getopt ?

http://www.opengroup.org/onlinepubs/007908799/xsh/getopt.html(...)

Ca faciliterait grandement la tâche !
- [^] # Re: Parser de commandes
  
  Posté par calandoa le 04 décembre 2004 à 00:54. Évalué à 3.
  
  Le problème de getopt(), c'est que la fonction ne parse pas les options longues ("--arg"). Il y a bien getopt_long() qui existe, mais c'est uniquement compatible gnu. Utrac devant être porté sous windows, on se tape donc le parsage des argv à la main (mais bon, c'est pas si compliqué...).
# faudrait maj le site !

Posté par TImaniac (site web personnel) le 04 décembre 2004 à 11:50. Évalué à -2.

Petit détail : c'est cool d'annoncer la sortie de la version 0.2 mais sur ton site seule la version 0.1 est dispo ;)
- [^] # Re: faudrait maj le site !
  
  Posté par Pascal Terjan (site web personnel) le 04 décembre 2004 à 12:00. Évalué à 4.
  
  Faudrait lire les commentaires au dessus.
# Comment ça marche ?

Posté par Thomas Cataldo (site web personnel) le 04 décembre 2004 à 18:28. Évalué à 3.

La dernière fois que j'ai eu des problèmes de jeux de caractère, je me suis posé la question "Est il possible de déterminer de manière fiable l'encoding des caractères dans un fichier texte", et la réponse que j'ai trouvé c'est "tu peux seulement savoir si c'est de l'unicode ou pas, pour le reste c'est très pifométrique et doit se baser sur des stats/dictionnaires/poudre verte.".

Un autre signe qui me fait penser que ça ne peut pas marcher c'est que la pluspart des api sérieuse devant traiter du texte exigent de connaître par avance l'encoding du texte (sous peine de retomber par défaut à l'encoding du système) : je pense à XML (encoding UTF-8 par défaut si non précisé), je pense à java pour lequel toutes les méthodes contruisant des String à partir de byte[] demandent un encoding (celles qui ne demandent pas l'encoding sont deprecated), je pense à la glib, etc.

Je m'interresse à la question car la dans le cadre d'un projet, une application web recevait des fichiers zip et devait les décompresser. Et la specification zip datant de l'époque "tout ascii", le champ des zip contenant le nom des fichiers est du type "tableau de char". L'encoding n'est précisé nulle part. Les utilisateurs de base étant fans des accents et autre ponctuation dans les noms de fichiers, j'ai découvert que je n'arrivait pas à décompresser un zip de manière fiable (restitution correcte des noms de fichiers).

D'ou ma question, paske la reconnaissance d'encodage me semble être un but innacessible, sur lequel pas mal de gens se sont cassés les dents ou on renoncés.
- [^] # Re: Comment ça marche ?
  
  Posté par Pascal Terjan (site web personnel) le 04 décembre 2004 à 18:55. Évalué à 3.
  
  Pour l'ASCII et l'Unicode, c'est facile.
  
  Pour le reste je procéderais d'abord par élimination. Certains caractères sont inutilisés snas les différents charset, tu peux donc déjà te dire que ce n'est pas celui là si tu les rencontres.
  
  Ensuite les caractères qui différent ne sont souvent pas du même type (minuscule/majuscule/ponctuation/...) donc tu dois pouvoir déterminer une probabilité que ca apparaisse la ou ca apparait. On peut aussi ajouter un dictionnaire, et entre un mot qui existe et un qui n'existe pas, préférer celui qui existe. Dans la mesure ou c'est une probabilité ce n'est certainement pas fiable à 100%. Je ne pense d'ailleurs pas qu'on puisse trouver une méthode sure.
  
  Je n'ai pas été voir donc je ne sais pas si c'est comme celà qu'ils font ou si ils ont trouvé une super technique révolutionnaire et fiable :)
  - [^] # Re: Comment ça marche ?
    
    Posté par Pascal Terjan (site web personnel) le 04 décembre 2004 à 18:59. Évalué à 3.
    
    Bon, finalement j'ai été voir http://tech.alliancemca.net/utrac/other_doc/uu.html(...) ca explique tout (et c'est en français en plus). J'étais pas trop loin :-)
# noms de fichiers

Posté par ccomb (site web personnel) le 06 décembre 2004 à 01:17. Évalué à 2.

Est-ce que ça peut marcher pour des textes aussi courts que des noms de fichiers ? (je subodore que non)
- [^] # Re: noms de fichiers
  
  Posté par gnujsa le 06 décembre 2004 à 10:35. Évalué à 3.
  
  $ ls -d /home/gnujsa/Desktop/TÃ©lÃ©chargements/ | utrac -p DEBUG ut_utils.c:205: ut_load_stdin to debug!!! UTF-8 $ touch "héhé, vive l'iso-8859-1" $ ls héhé\,\ vive\ l\'iso-8859-1 | utrac -p DEBUG ut_utils.c:205: ut_load_stdin to debug!!! ISO-8859-1 $ ls héhé\,\ vive\ l\'iso-8859-1 | utrac -t UTF-8 2> /dev/null hÃ©hÃ©, vive l'iso-8859-1
  
  je subodore que oui :)
  
  Bravo et merci à calandoa pour cet outil trés pratique.
  - [^] # Re: noms de fichiers
    
    Posté par Grégory SCHMITT le 06 décembre 2004 à 11:09. Évalué à 2.
    
    On peut également utiliser xxd dans ce cadre:
    
    /bin/ls "nomdufichier" | xxd
    
    Si c'est de l'Unicde, les caractères acentués apparaissent avec c3 en préfixe (exemple: é se dit e9 en ISO8859-1, c3a9 en UTF-8).
  - [^] # Re: noms de fichiers
    
    Posté par ccomb (site web personnel) le 06 décembre 2004 à 14:24. Évalué à 2.
    
    Dans ce cas c'est un outil qui peut être très utile pour des gens qui migrent de l'iso vers l'utf-8, j'avais fait un minuscule script python à l'époque, ce serait interessant de rajouter la détection automatique de l'encodage :
    http://ccomb.free.fr/wiki/wakka.php?wiki=UtfConvert(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.