vendredi 03 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de calandoa :

Journal : Reconnaissance d'encodage avec Utrac

Posté par calandoa () le 03 décembre 2004
0
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!

> Lire le journal (22 commentaires, moyenne: 2,3).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

je suis pas sur de comprendre

Posté par jraf () le 03/12/2004 à 13:29. (lien). É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/12/2004 à 14:00. (lien). É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 Matthieu C () le 03/12/2004 à 21:25. (lien). Évalué à 2.

    recode apporte quoi par rapport a iconv ?

Equivalent en java

Posté par lampapiertramol (page perso, ) le 03/12/2004 à 13:33. (lien). É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 (Jabber id, page perso, ) le 04/12/2004 à 09:49. (lien). É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.

    --
    All those moments will be lost in time, like tears in rain.

à propos de codage...

Posté par Juke (Jabber id, page perso, ) le 03/12/2004 à 15:06. (lien). É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/12/2004 à 16:07. (lien). É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 (Jabber id, page perso, ) le 03/12/2004 à 23:18. (lien). É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 (Jabber id, ) le 03/12/2004 à 16:28. (lien). É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 :)

--
Ce messages est crypté par le système 42-rot13 pour plus de sécurité.

Probleme?

Posté par Ph Husson (Jabber id, ) le 03/12/2004 à 16:35. (lien). É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?

--
Ce messages est crypté par le système 42-rot13 pour plus de sécurité.

  • [^]Re: Probleme?

    Posté par calandoa () le 03/12/2004 à 19:00. (lien). É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 (page perso, ) le 03/12/2004 à 22:01. (lien). É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 03/12/2004 à 23:54. (lien). É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 (Jabber id, page perso, ) le 04/12/2004 à 10:50. (lien). É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 (Jabber id, page perso, ) le 04/12/2004 à 11:00. (lien). Évalué à 4.

    Faudrait lire les commentaires au dessus.

Comment ça marche ?

Posté par Thomas Cataldo (page perso, ) le 04/12/2004 à 17:28. (lien). É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 (Jabber id, page perso, ) le 04/12/2004 à 17:55. (lien). É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 ccomb (Jabber id, page perso, ) le 06/12/2004 à 00:17. (lien). É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/12/2004 à 09:35. (lien). É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/12/2004 à 10:09. (lien). É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).

      --
      R.I.P Chris Benoit, 1967-2007

    • [^]Re: noms de fichiers

      Posté par ccomb (Jabber id, page perso, ) le 06/12/2004 à 13:24. (lien). É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(...)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0981s (dont 0.0088 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !