j'ai un tableau avec des valeurs accentuées : action accéder acculer
Que je voudrais trier par ordre alpha en ignorant les accent (accéder devant donc être en 1er)
Comment faire ?
S'assurer d'avoir un Perl 5.8 au moins, et utiliser Unicode::Collate.
Paul Gaborit
À (at) Thu, 01 Jun 2006 18:37:41 +0200, paul POULAIN écrivait (wrote):
j'ai un tableau avec des valeurs accentuées : action accéder acculer
Que je voudrais trier par ordre alpha en ignorant les accent (accéder d evant donc être en 1er)
Comment faire ?
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
------------------------------------------------------------ # pour utiliser les 'locale' use locale; # pour le pouvoir utiliser LC_COLLATE et setlocale use POSIX qw(locale_h); # pour choisir le français (le print est là pour vérifier que ça ma rche) print "locale:", setlocale(LC_COLLATE, "fr_FR"), "n";
# le tri print "@{[sort 'action', 'accéder', 'acculer']}n"; ------------------------------------------------------------
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 01 Jun 2006 18:37:41 +0200,
paul POULAIN <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
j'ai un tableau avec des valeurs accentuées :
action
accéder
acculer
Que je voudrais trier par ordre alpha en ignorant les accent (accéder d evant
donc être en 1er)
Comment faire ?
Si vous êtes sur un système bien élevé, vous pouvez utiliser les
'locale' :
------------------------------------------------------------
# pour utiliser les 'locale'
use locale;
# pour le pouvoir utiliser LC_COLLATE et setlocale
use POSIX qw(locale_h);
# pour choisir le français (le print est là pour vérifier que ça ma rche)
print "locale:", setlocale(LC_COLLATE, "fr_FR"), "n";
# le tri
print "@{[sort 'action', 'accéder', 'acculer']}n";
------------------------------------------------------------
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 01 Jun 2006 18:37:41 +0200, paul POULAIN écrivait (wrote):
j'ai un tableau avec des valeurs accentuées : action accéder acculer
Que je voudrais trier par ordre alpha en ignorant les accent (accéder d evant donc être en 1er)
Comment faire ?
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
------------------------------------------------------------ # pour utiliser les 'locale' use locale; # pour le pouvoir utiliser LC_COLLATE et setlocale use POSIX qw(locale_h); # pour choisir le français (le print est là pour vérifier que ça ma rche) print "locale:", setlocale(LC_COLLATE, "fr_FR"), "n";
# le tri print "@{[sort 'action', 'accéder', 'acculer']}n"; ------------------------------------------------------------
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Paul Gaborit wrote in message :
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
Franchement bof. Les locales, c'est une interface vraiment foireuse, conçue pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour. Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de provoquer de bugs intempestifs, autant s'en servir.
Paul Gaborit wrote in message <r7r728iyvb.fsf@vaugirard.enstimac.fr>:
Si vous êtes sur un système bien élevé, vous pouvez utiliser les
'locale' :
Franchement bof. Les locales, c'est une interface vraiment foireuse, conçue
pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour.
Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de
provoquer de bugs intempestifs, autant s'en servir.
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
Franchement bof. Les locales, c'est une interface vraiment foireuse, conçue pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour. Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de provoquer de bugs intempestifs, autant s'en servir.
Paul Gaborit
À (at) Thu, 1 Jun 2006 17:53:34 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
Franchement bof.
Je vous comprends ;-)
Les locales, c'est une interface vraiment foireuse, conçue pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour.
C'est sûr que les 'locale' ne sont pas la panacée (et de très loin). Mais ça a l'avantage d'exister depuis longtemps. C'est une forme d'i18n minimaliste. De plus, ça permet de continuer à utiliser les fonctions standards ('cmp' par exemple). Il n'y a donc pas à modifier le code existant (avec tous les avantages mais aussi les inconvénients/risques que ça comporte).
Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de provoquer de bugs intempestifs, autant s'en servir.
Pour les versions avant 5.8, les 'locale' sont la solution la plus simple.
À partir de 5.8 (et même 5.8.4 ou 5.8.5), c'est sûr que Unicode::Collate (et autres modules) offrent des fonctionnalités bien plus complètes. Mais cela nécessite quasiment obligatoirement une adaptation du code existant.
La route vers l'i18n est longue. Nous ne sommes pas au bout !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 1 Jun 2006 17:53:34 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit wrote in message <r7r728iyvb.fsf@vaugirard.enstimac.fr>:
Si vous êtes sur un système bien élevé, vous pouvez utiliser les
'locale' :
Franchement bof.
Je vous comprends ;-)
Les locales, c'est une interface vraiment foireuse, conçue
pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour.
C'est sûr que les 'locale' ne sont pas la panacée (et de très
loin). Mais ça a l'avantage d'exister depuis longtemps. C'est une
forme d'i18n minimaliste. De plus, ça permet de continuer à utiliser
les fonctions standards ('cmp' par exemple). Il n'y a donc pas à
modifier le code existant (avec tous les avantages mais aussi les
inconvénients/risques que ça comporte).
Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de
provoquer de bugs intempestifs, autant s'en servir.
Pour les versions avant 5.8, les 'locale' sont la solution la plus
simple.
À partir de 5.8 (et même 5.8.4 ou 5.8.5), c'est sûr que
Unicode::Collate (et autres modules) offrent des fonctionnalités bien
plus complètes. Mais cela nécessite quasiment obligatoirement une
adaptation du code existant.
La route vers l'i18n est longue. Nous ne sommes pas au bout !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 1 Jun 2006 17:53:34 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Si vous êtes sur un système bien élevé, vous pouvez utiliser les 'locale' :
Franchement bof.
Je vous comprends ;-)
Les locales, c'est une interface vraiment foireuse, conçue pour faire marcher en i18n des trucs qui ne sont vraiment pas prévus pour.
C'est sûr que les 'locale' ne sont pas la panacée (et de très loin). Mais ça a l'avantage d'exister depuis longtemps. C'est une forme d'i18n minimaliste. De plus, ça permet de continuer à utiliser les fonctions standards ('cmp' par exemple). Il n'y a donc pas à modifier le code existant (avec tous les avantages mais aussi les inconvénients/risques que ça comporte).
Perl à partir de 5.8 a une interface bien conçue et qui ne risque pas de provoquer de bugs intempestifs, autant s'en servir.
Pour les versions avant 5.8, les 'locale' sont la solution la plus simple.
À partir de 5.8 (et même 5.8.4 ou 5.8.5), c'est sûr que Unicode::Collate (et autres modules) offrent des fonctionnalités bien plus complètes. Mais cela nécessite quasiment obligatoirement une adaptation du code existant.
La route vers l'i18n est longue. Nous ne sommes pas au bout !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Paul Gaborit wrote in message :
De plus, ça permet de continuer à utiliser les fonctions standards ('cmp' par exemple). Il n'y a donc pas à modifier le code existant (avec tous les avantages mais aussi les inconvénients/risques que ça comporte).
Justement, je trouve que les risques sont très largement supérieurs aux avantages.
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur numérique des lexèmes flottants, il utilise la libc.
Résultat :
# let pi = 3.14159;; val pi : float = 3.0
et derrière, des résultats complètement aberrants.
Paul Gaborit wrote in message <r7pshseyti.fsf@vaugirard.enstimac.fr>:
De plus, ça permet de continuer à utiliser
les fonctions standards ('cmp' par exemple). Il n'y a donc pas à
modifier le code existant (avec tous les avantages mais aussi les
inconvénients/risques que ça comporte).
Justement, je trouve que les risques sont très largement supérieurs aux
avantages.
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk
dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur
numérique des lexèmes flottants, il utilise la libc.
Résultat :
# let pi = 3.14159;;
val pi : float = 3.0
et derrière, des résultats complètement aberrants.
De plus, ça permet de continuer à utiliser les fonctions standards ('cmp' par exemple). Il n'y a donc pas à modifier le code existant (avec tous les avantages mais aussi les inconvénients/risques que ça comporte).
Justement, je trouve que les risques sont très largement supérieurs aux avantages.
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur numérique des lexèmes flottants, il utilise la libc.
Résultat :
# let pi = 3.14159;; val pi : float = 3.0
et derrière, des résultats complètement aberrants.
Paul Gaborit
À (at) Fri, 2 Jun 2006 10:57:47 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur numérique des lexèmes flottants, il utilise la libc. [...]
et derrière, des résultats complètement aberrants.
À une époque, le compilateur C de Sun souffrait d'un problème similaire : lorsqu'il lisait des valeurs numériques dans le source, il utilisait directement scanf ou sscanf dont le comportement dépendait évidemment des 'locale' (qui venaient d'être intégrés). Résultat :le séparateur décimal était le point (en en_US) ou la virgule (en fr_FR). C'était "fun" ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 2 Jun 2006 10:57:47 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk
dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur
numérique des lexèmes flottants, il utilise la libc.
[...]
et derrière, des résultats complètement aberrants.
À une époque, le compilateur C de Sun souffrait d'un problème
similaire : lorsqu'il lisait des valeurs numériques dans le source, il
utilisait directement scanf ou sscanf dont le comportement dépendait
évidemment des 'locale' (qui venaient d'être intégrés). Résultat :le
séparateur décimal était le point (en en_US) ou la virgule (en
fr_FR). C'était "fun" ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 2 Jun 2006 10:57:47 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
En particulier, je me rappelle avoir perdu des heures un jour avec LablGtk dans un toplevel Caml à cause du concours de circonstances suivant :
- LablGtk fait un gtk_init, qui fait un setlocale ;
- Caml utilise évidemment son propre lexer, mais pour évaluer la valeur numérique des lexèmes flottants, il utilise la libc. [...]
et derrière, des résultats complètement aberrants.
À une époque, le compilateur C de Sun souffrait d'un problème similaire : lorsqu'il lisait des valeurs numériques dans le source, il utilisait directement scanf ou sscanf dont le comportement dépendait évidemment des 'locale' (qui venaient d'être intégrés). Résultat :le séparateur décimal était le point (en en_US) ou la virgule (en fr_FR). C'était "fun" ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
