Journal Reconnaissance d'encodage avec Utrac

Posté par  .
Étiquettes : aucune
0
3
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  . Évalué à 1.

    • [^] # Re: je suis pas sur de comprendre

      Posté par  . É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  . Évalué à 2.

      recode apporte quoi par rapport a iconv ?
  • # Equivalent en java

    Posté par  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  . É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  . É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  (site Web personnel) . É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 ;)
  • # Comment ça marche ?

    Posté par  (site Web personnel) . É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  (site Web personnel) . É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 :)
  • # noms de fichiers

    Posté par  (site Web personnel) . É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  . É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.

Suivre le flux des commentaires

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