as-tu essayé d'ajouter : use Encode qw(encode_utf8);
oui, oui, mais en fait c'est le module perl Encode::Gues qui ne vaut pas un clou, il n'arrive pas à faire la différence entre iso-8859-1 et utf-8 pourtant cette différence, je l'obtiens par une regex et de manière indubitable...
j'ai eu un peu le même problème avec php qui prétend décoder les encodages => bull shit ;-)
ce que je fais maintenant par ruby : - 2 regex l'une dit validAscci l'autre validUtf8
notes que pour ascii et utf-8 je n'ai plus rien à faire, car implicitement l'acii c'est de l'utf-8 (je décode l'encodage pour tout transcoder ce qui n'est pas en utf-!, en utf-8)
tout le reste je le met en iso-8859-1 (le plus probable sur le net car le plus utilisé) mais je ne m'arrête pas là.
ensuite avec un outil statistique (n-gram) je décode à la fois le langage et l'encodage, c'est nettement plus long qu'une simple regex, mais au moins pour french comme langue j'arrive à discriminer entre iso-8859-1 et MacRoman. (les é et è fréquents ne sont pas à la même position) en fait je fais un split avec é et è dans les deux encodages celui qui me retourne le plus d'éléments dans l'array est le bon encodage, si j'ai le même nombre je dis iso-8859-1...
autrement c'est impossible car les encodages 8bits (tous les iso et tous les macRoman-like) utilisent toute la table, enfin, il y a bien des trous, des caractères inutilisés dans un encodage et pas dans l'autre mais on ne peut discriminer là-dessus car ces trous correspondent à des caractères peu utilisés.
donc l'autre méthode (n-gram) qui détecte la langue et l'encodage simultanément marche comme ça : tu lui file un échantillon de texte dans une langue donnée et dans un encodage donné, elle balaie tous les couples language, encodage qui existent (donc c'est nécessairement limité à ce que tu lui a donné) et trouve le couple qui convient le mieux au texte sous test...
il faut quand même que la page en question contienne suffisamment de texte...
bon, qqfois il y a des erreurs d'encodage aussi, ça généralement c'est du cp-1252 (win;-) -- une bévue
kurtz le pirate <kurtzlepirate@yahoo.fr> wrote:
as-tu essayé d'ajouter :
use Encode qw(encode_utf8);
oui, oui, mais en fait c'est le module perl Encode::Gues qui ne vaut pas
un clou, il n'arrive pas à faire la différence entre iso-8859-1 et utf-8
pourtant cette différence, je l'obtiens par une regex et de manière
indubitable...
j'ai eu un peu le même problème avec php qui prétend décoder les
encodages => bull shit ;-)
ce que je fais maintenant par ruby :
- 2 regex l'une dit validAscci l'autre validUtf8
notes que pour ascii et utf-8 je n'ai plus rien à faire, car
implicitement l'acii c'est de l'utf-8 (je décode l'encodage pour tout
transcoder ce qui n'est pas en utf-!, en utf-8)
tout le reste je le met en iso-8859-1 (le plus probable sur le net car
le plus utilisé) mais je ne m'arrête pas là.
ensuite avec un outil statistique (n-gram) je décode à la fois le
langage et l'encodage, c'est nettement plus long qu'une simple regex,
mais au moins pour french comme langue j'arrive à discriminer entre
iso-8859-1 et MacRoman. (les é et è fréquents ne sont pas à la même
position) en fait je fais un split avec é et è dans les deux encodages
celui qui me retourne le plus d'éléments dans l'array est le bon
encodage, si j'ai le même nombre je dis iso-8859-1...
autrement c'est impossible car les encodages 8bits (tous les iso et tous
les macRoman-like) utilisent toute la table, enfin, il y a bien des
trous, des caractères inutilisés dans un encodage et pas dans l'autre
mais on ne peut discriminer là-dessus car ces trous correspondent à des
caractères peu utilisés.
donc l'autre méthode (n-gram) qui détecte la langue et l'encodage
simultanément marche comme ça :
tu lui file un échantillon de texte dans une langue donnée et dans un
encodage donné, elle balaie tous les couples language, encodage qui
existent (donc c'est nécessairement limité à ce que tu lui a donné) et
trouve le couple qui convient le mieux au texte sous test...
il faut quand même que la page en question contienne suffisamment de
texte...
bon, qqfois il y a des erreurs d'encodage aussi, ça généralement c'est
du cp-1252 (win;-)
--
une bévue
as-tu essayé d'ajouter : use Encode qw(encode_utf8);
oui, oui, mais en fait c'est le module perl Encode::Gues qui ne vaut pas un clou, il n'arrive pas à faire la différence entre iso-8859-1 et utf-8 pourtant cette différence, je l'obtiens par une regex et de manière indubitable...
j'ai eu un peu le même problème avec php qui prétend décoder les encodages => bull shit ;-)
ce que je fais maintenant par ruby : - 2 regex l'une dit validAscci l'autre validUtf8
notes que pour ascii et utf-8 je n'ai plus rien à faire, car implicitement l'acii c'est de l'utf-8 (je décode l'encodage pour tout transcoder ce qui n'est pas en utf-!, en utf-8)
tout le reste je le met en iso-8859-1 (le plus probable sur le net car le plus utilisé) mais je ne m'arrête pas là.
ensuite avec un outil statistique (n-gram) je décode à la fois le langage et l'encodage, c'est nettement plus long qu'une simple regex, mais au moins pour french comme langue j'arrive à discriminer entre iso-8859-1 et MacRoman. (les é et è fréquents ne sont pas à la même position) en fait je fais un split avec é et è dans les deux encodages celui qui me retourne le plus d'éléments dans l'array est le bon encodage, si j'ai le même nombre je dis iso-8859-1...
autrement c'est impossible car les encodages 8bits (tous les iso et tous les macRoman-like) utilisent toute la table, enfin, il y a bien des trous, des caractères inutilisés dans un encodage et pas dans l'autre mais on ne peut discriminer là-dessus car ces trous correspondent à des caractères peu utilisés.
donc l'autre méthode (n-gram) qui détecte la langue et l'encodage simultanément marche comme ça : tu lui file un échantillon de texte dans une langue donnée et dans un encodage donné, elle balaie tous les couples language, encodage qui existent (donc c'est nécessairement limité à ce que tu lui a donné) et trouve le couple qui convient le mieux au texte sous test...
il faut quand même que la page en question contienne suffisamment de texte...
bon, qqfois il y a des erreurs d'encodage aussi, ça généralement c'est du cp-1252 (win;-) -- une bévue
Vincent Lefevre
Dans l'article <1hcx1ir.1dwn7lp113kjyvN%, Laurent Pertois écrit:
Vincent Lefevre <vincent+ wrote:
En plus des modules Perl, lib-www installe des exécutables (qui sont des front-ends aux modules).
Pas exemple, sous Debian:
$ which HEAD /usr/bin/HEAD
Ca ok, mais ça ne me dit toujours pas ce qu'il installe sur un Mac OS X et où il l'installe...
Il l'installe dans le préfixe spécifié par l'utilisateur, e.g. /usr/local/bin.
S'il l'installe au même endroit, c'est embêtant, je suis d'accord.
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en priorité par rapport à /usr/bin/head.
Ca ok, mais ça ne me dit toujours pas ce qu'il installe sur un Mac OS X et où il l'installe...
Il l'installe dans le préfixe spécifié par l'utilisateur, e.g. /usr/local/bin.
C'est par défaut ?
S'il l'installe au même endroit, c'est embêtant, je suis d'accord.
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Ca ok, mais ça ne me dit toujours pas ce qu'il installe sur un Mac OS X
et où il l'installe...
Il l'installe dans le préfixe spécifié par l'utilisateur, e.g.
/usr/local/bin.
C'est par défaut ?
S'il l'installe au même endroit, c'est embêtant, je suis d'accord.
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en
priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ca ok, mais ça ne me dit toujours pas ce qu'il installe sur un Mac OS X et où il l'installe...
Il l'installe dans le préfixe spécifié par l'utilisateur, e.g. /usr/local/bin.
C'est par défaut ?
S'il l'installe au même endroit, c'est embêtant, je suis d'accord.
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Vincent Lefevre
Dans l'article <1hcxinb.1ko2a3feiq0xdN%, Laurent Pertois écrit:
Vincent Lefevre <vincent+ wrote:
Ca ok, mais ça ne me dit toujours pas ce qu'il installe sur un Mac OS X et où il l'installe...
Il l'installe dans le préfixe spécifié par l'utilisateur, e.g. /usr/local/bin.
[...] Additionally, Chris Owen sent a relevant bit from the finkproject.org that suggests the case insensitivity of HFS+ may have resulted in LWP (Perl's WWW library) overwriting /usr/bin/head with /usr/bin/HEAD. `which head' only gives me /usr/bin/head; however, Chris's advice was encouraging. As it turns out, there is also a HEAD (installed by libwww-perl) in /opt/local/bin, and I think that was the cause of the errors--the dp scripts were using the LWP HEAD instead of the BSD head. I moved /opt/local/bin/HEAD to a non-PATH directory, and *poof*, things started compiling fine. [...]
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
Il faudrait que le problème soit corrigé dans libwww-perl.
Pour les utilisateurs de DarwinPorts, une solution est d'avoir dans son $PATH dans l'ordre: /usr/local/bin /opt/local/bin /usr/bin. Le /usr/bin contient le "head" système. Pour ceux qui installent le port coreutils, on se retrouve avec un /opt/local/bin/ghead (pour GNU head), et il n'y a pas de conflit avec libwww-perl. Ensuite il suffit d'un lien symbolique /usr/local/bin/head pointant soit vers /opt/local/bin/ghead, soit vers /usr/bin/head.
De toute façon, j'ai un tel lien par défaut, afin que la commande head appelle /opt/local/bin/ghead et non /usr/bin/head, et idem pour les autres utilitaires des coreutils, à l'aide du script suivant:
#!/usr/bin/env zsh
mkdir -p -v /usr/local/{bin,share/man/man1}
for i in `port contents coreutils` do [[ $i == /opt/local/(bin|share/man/man1)/g* ]] && ln -s -v $i ${${i/opt/usr}//g//} done
[...]
Additionally, Chris Owen sent a relevant bit from the finkproject.org
that suggests the case insensitivity of HFS+ may have resulted in LWP
(Perl's WWW library) overwriting /usr/bin/head with /usr/bin/HEAD.
`which head' only gives me /usr/bin/head; however, Chris's advice was
encouraging. As it turns out, there is also a HEAD (installed by
libwww-perl) in /opt/local/bin, and I think that was the cause of the
errors--the dp scripts were using the LWP HEAD instead of the BSD
head. I moved /opt/local/bin/HEAD to a non-PATH directory, and
*poof*, things started compiling fine.
[...]
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en
priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
Il faudrait que le problème soit corrigé dans libwww-perl.
Pour les utilisateurs de DarwinPorts, une solution est d'avoir dans
son $PATH dans l'ordre: /usr/local/bin /opt/local/bin /usr/bin. Le
/usr/bin contient le "head" système. Pour ceux qui installent le
port coreutils, on se retrouve avec un /opt/local/bin/ghead (pour
GNU head), et il n'y a pas de conflit avec libwww-perl. Ensuite il
suffit d'un lien symbolique /usr/local/bin/head pointant soit vers
/opt/local/bin/ghead, soit vers /usr/bin/head.
De toute façon, j'ai un tel lien par défaut, afin que la commande
head appelle /opt/local/bin/ghead et non /usr/bin/head, et idem pour
les autres utilitaires des coreutils, à l'aide du script suivant:
#!/usr/bin/env zsh
mkdir -p -v /usr/local/{bin,share/man/man1}
for i in `port contents coreutils`
do
[[ $i == /opt/local/(bin|share/man/man1)/g* ]] &&
ln -s -v $i ${${i/opt/usr}//g//}
done
[...] Additionally, Chris Owen sent a relevant bit from the finkproject.org that suggests the case insensitivity of HFS+ may have resulted in LWP (Perl's WWW library) overwriting /usr/bin/head with /usr/bin/HEAD. `which head' only gives me /usr/bin/head; however, Chris's advice was encouraging. As it turns out, there is also a HEAD (installed by libwww-perl) in /opt/local/bin, and I think that was the cause of the errors--the dp scripts were using the LWP HEAD instead of the BSD head. I moved /opt/local/bin/HEAD to a non-PATH directory, and *poof*, things started compiling fine. [...]
Même /usr/local/bin est embêtant, car le HEAD va être utilisé en priorité par rapport à /usr/bin/head.
Faut formatter en HFS+ case-sensitive, alors :)
Il faudrait que le problème soit corrigé dans libwww-perl.
Pour les utilisateurs de DarwinPorts, une solution est d'avoir dans son $PATH dans l'ordre: /usr/local/bin /opt/local/bin /usr/bin. Le /usr/bin contient le "head" système. Pour ceux qui installent le port coreutils, on se retrouve avec un /opt/local/bin/ghead (pour GNU head), et il n'y a pas de conflit avec libwww-perl. Ensuite il suffit d'un lien symbolique /usr/local/bin/head pointant soit vers /opt/local/bin/ghead, soit vers /usr/bin/head.
De toute façon, j'ai un tel lien par défaut, afin que la commande head appelle /opt/local/bin/ghead et non /usr/bin/head, et idem pour les autres utilitaires des coreutils, à l'aide du script suivant:
#!/usr/bin/env zsh
mkdir -p -v /usr/local/{bin,share/man/man1}
for i in `port contents coreutils` do [[ $i == /opt/local/(bin|share/man/man1)/g* ]] && ln -s -v $i ${${i/opt/usr}//g//} done
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Pas testé, mais je cite un bout de mail:
Merci pour toutes les infos.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
