j'ai un petit souci à soumettre aux neurones de jussieu,
Je travaille avec perl 5.8.1 et je voudrais chercher dans une liste de
noms ceux qui commencent par une lettre majuscule.
Je recherche donc m/[A-Z].*/ mais cela ne repère pas les mots commençant
par AE (E dans l'A majuscule).
Si vous avez une idée (faire joujou avec l'encodage par exemple), je
vous en serais gré.
À (at) Mon, 21 Mar 2005 18:28:53 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
les tris,
Il a l'air d'y avoir Unicode::Collate pour résoudre le problème.
C'est bien cela qui est un problème (potentiel).
Auparavant, un programmeur pouvait utiliser les opérateur Perl 'lt', 'gt', 'le', 'ge' et 'cmp' pour faire des comparaisons de chaînes. S'il souhaitait que ces comparaisons dépendent du 'locale' courant, il lui suffisait d'inclure un 'use locale;' au début du script et toutes ses comparaisons tenaient automagiquement compte de la langue courante... Ce n'est plus le cas lorsqu'on utilise Unicode.
En fait, on passe d'un monde où l'information était considérée implicitement sans langue (locale 'C') ou avec une langue précise (le 'locale' courant) à un monde où l'information est possiblement multi-lingue. On passe d'une prise en compte implicite d'une (et une seule) langue à une prise en compte explicite des langues.
[... des explications sur les mécanismes Unicode...]
Pour le dire autrement, Unicode supprime les problèmes de locale LC_CTYPE en intégrant l'information de locale dans le caractère lui-même, et les autres catégories de locales sont très indépendantes de LC_CTYPE.
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La question est : comment définit-on un ordre cohérent (de textes) si ces textes sont potentiellement dans toutes les langues ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 21 Mar 2005 18:28:53 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit wrote in message <r7is3k991o.fsf@iena.enstimac.fr>:
les tris,
Il a l'air d'y avoir Unicode::Collate pour résoudre le problème.
C'est bien cela qui est un problème (potentiel).
Auparavant, un programmeur pouvait utiliser les opérateur Perl 'lt', 'gt',
'le', 'ge' et 'cmp' pour faire des comparaisons de chaînes. S'il souhaitait
que ces comparaisons dépendent du 'locale' courant, il lui suffisait d'inclure
un 'use locale;' au début du script et toutes ses comparaisons tenaient
automagiquement compte de la langue courante... Ce n'est plus le cas lorsqu'on
utilise Unicode.
En fait, on passe d'un monde où l'information était considérée implicitement
sans langue (locale 'C') ou avec une langue précise (le 'locale' courant) à un
monde où l'information est possiblement multi-lingue. On passe d'une prise en
compte implicite d'une (et une seule) langue à une prise en compte explicite
des langues.
[... des explications sur les mécanismes Unicode...]
Pour le dire autrement, Unicode supprime les problèmes de locale LC_CTYPE en
intégrant l'information de locale dans le caractère lui-même, et les autres
catégories de locales sont très indépendantes de LC_CTYPE.
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La
question est : comment définit-on un ordre cohérent (de textes) si ces textes
sont potentiellement dans toutes les langues ?
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 21 Mar 2005 18:28:53 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
les tris,
Il a l'air d'y avoir Unicode::Collate pour résoudre le problème.
C'est bien cela qui est un problème (potentiel).
Auparavant, un programmeur pouvait utiliser les opérateur Perl 'lt', 'gt', 'le', 'ge' et 'cmp' pour faire des comparaisons de chaînes. S'il souhaitait que ces comparaisons dépendent du 'locale' courant, il lui suffisait d'inclure un 'use locale;' au début du script et toutes ses comparaisons tenaient automagiquement compte de la langue courante... Ce n'est plus le cas lorsqu'on utilise Unicode.
En fait, on passe d'un monde où l'information était considérée implicitement sans langue (locale 'C') ou avec une langue précise (le 'locale' courant) à un monde où l'information est possiblement multi-lingue. On passe d'une prise en compte implicite d'une (et une seule) langue à une prise en compte explicite des langues.
[... des explications sur les mécanismes Unicode...]
Pour le dire autrement, Unicode supprime les problèmes de locale LC_CTYPE en intégrant l'information de locale dans le caractère lui-même, et les autres catégories de locales sont très indépendantes de LC_CTYPE.
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La question est : comment définit-on un ordre cohérent (de textes) si ces textes sont potentiellement dans toutes les langues ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Nicolas George
Paul Gaborit wrote in message :
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La question est : comment définit-on un ordre cohérent (de textes) si ces textes sont potentiellement dans toutes les langues ?
Dans ce paragraphe, je ne parlais pas de l'ordre, mais des catégories de caractères et des correspondances minuscules-majuscules.
Paul Gaborit wrote in message <r7eke795n3.fsf@iena.enstimac.fr>:
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La
question est : comment définit-on un ordre cohérent (de textes) si ces textes
sont potentiellement dans toutes les langues ?
Dans ce paragraphe, je ne parlais pas de l'ordre, mais des catégories de
caractères et des correspondances minuscules-majuscules.
De mon point de vue, Unicode ne supprime pas le problème, il le révèle. La question est : comment définit-on un ordre cohérent (de textes) si ces textes sont potentiellement dans toutes les langues ?
Dans ce paragraphe, je ne parlais pas de l'ordre, mais des catégories de caractères et des correspondances minuscules-majuscules.
