Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème d'expressions régulières

12 réponses
Avatar
Angel Anta
Salut tout le monde,

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é.

;A.A;

10 réponses

1 2
Avatar
Nicolas George
Angel Anta wrote in message <d1eruj$1ird$:
Je recherche donc m/[A-Z].*/ mais cela ne repère pas les mots commençant
par AE (E dans l'A majuscule).


Utiliser [:upper:] ou p{IsUpper}.

Si vous avez une idée (faire joujou avec l'encodage par exemple), je
vous en serais gré.


En perl 5.8, la bonne manière de procéder est de faire en sorte que la
chaîne traitée soit une chaîne Unicode (utilisation de binmode $fh,
":encoding(xxx)" si ça vient d'un fichier par exemple).

Avatar
Le TeXnicien de surface

Salut tout le monde,

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).


Avec m/[[:upper:]].*/ j'ai cru comprendre que ça tenait compte de la
localisation mais c'est SGDG.

jeqça

--
Le TeXnicien de surface

Avatar
Angel Anta
Avatar
Paul Gaborit
À (at) Fri, 18 Mar 2005 15:36:57 +0000 (UTC),
Nicolas George <nicolas$ écrivait (wrote):
Angel Anta wrote in message <d1eruj$1ird$:
Je recherche donc m/[A-Z].*/ mais cela ne repère pas les mots commençant
par AE (E dans l'A majuscule).


Utiliser [:upper:] ou p{IsUpper}.

Si vous avez une idée (faire joujou avec l'encodage par exemple), je
vous en serais gré.


En perl 5.8, la bonne manière de procéder est de faire en sorte que la
chaîne traitée soit une chaîne Unicode (utilisation de binmode $fh,
":encoding(xxx)" si ça vient d'un fichier par exemple).


Je crois, sans l'avoir vérifier, que le résultat dépendra tout de même du
'locale' courant. Les majuscules d'une langue ne sont pas obligatoirement
celles d'une autre langue.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>


Avatar
Nicolas George
Le TeXnicien de surface wrote in message
<423b0d02$0$19361$:
Avec m/[[:upper:]].*/ j'ai cru comprendre que ça tenait compte de la
localisation mais c'est SGDG.


[:upper:], comme le reste de perl, tient compte de la localisation si (1)
use locale est en action, (2) setlocale a été appelé et (3) la chaîne sur
laquelle on l'utilise est une chaîne d'octets. Ça marche à peu près, mais
c'est peu extensible et peu robuste.

[:upper:], comme le reste de perl, utilise les bases de données Unicode s'il
est utilisé sur des chaînes Unicode.

Personnellement, quand on a des considérations de ce genre
(majuscules/minuscules, respect des caractères accentués), de toujours
travailler avec des chaînes Unicode, et de faire les conversions le plus tôt
possible en entrée, et le plus tard possible en sortie.

Avatar
Nicolas George
Paul Gaborit wrote in message :
Je crois, sans l'avoir vérifier, que le résultat dépendra tout de même du
'locale' courant. Les majuscules d'une langue ne sont pas obligatoirement
celles d'une autre langue.


Unicode, normalement, attribue deux caractères distincts quand il y a des
distinctions de ce genre à faire. D'ailleur, perlunicode(1) dit « Things to
do with locales (Lithuanian, Turkish, Azeri) do not work since Perl does not
understand the concept of Unicode locales. »

Avatar
Paul Gaborit
À (at) Fri, 18 Mar 2005 18:18:37 +0000 (UTC),
Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Je crois, sans l'avoir vérifier, que le résultat dépendra tout de même du
'locale' courant. Les majuscules d'une langue ne sont pas obligatoirement
celles d'une autre langue.


Unicode, normalement, attribue deux caractères distincts quand il y a des
distinctions de ce genre à faire. D'ailleur, perlunicode(1) dit « Things to
do with locales (Lithuanian, Turkish, Azeri) do not work since Perl does not
understand the concept of Unicode locales. »


Donc, si on travaille sans unicode, il faut faire attention aux 'locale'.

Et si on travaille avec unicode, on ne peut pas (encore) faire attention aux
'locale' correctement...

C'est pas très fun tout ça ;-)

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>


Avatar
Nicolas George
Paul Gaborit wrote in message :
Et si on travaille avec unicode, on ne peut pas (encore) faire attention aux
'locale' correctement...


Mais le standard Unicode est fait de telle sorte que ce n'est presque jamais
un problème. Et surtout, c'est uniquement pour les caractères, ça ne change
rien aux autres catégories de locales.

Avatar
Paul Gaborit
À (at) Mon, 21 Mar 2005 15:09:52 +0000 (UTC),
Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit wrote in message :
Et si on travaille avec unicode, on ne peut pas (encore) faire attention aux
'locale' correctement...


Mais le standard Unicode est fait de telle sorte que ce n'est presque jamais
un problème. Et surtout, c'est uniquement pour les caractères, ça ne change
rien aux autres catégories de locales.


Les 'locale' agissent tout de même sur beaucoup de paramètres liés aux
caractères : les tris, la définition des classes de caractères, les opérations
de transformation de ces mêmes classes (uc, lc, ucfirst par exemple), etc.

Si les 'locale' (en fait celles de certaines langues) ne sont pas encore bien
gérées par Perl en Unicode, ça peut poser problème... La migration vers
Unicode est une nécessité (une fatalité diront les grincheux) qui fera encore
couler beaucoup d'encre et surtout phosphorer les programmeurs !

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>


Avatar
Nicolas George
Paul Gaborit wrote in message :
les tris,


Il a l'air d'y avoir Unicode::Collate pour résoudre le problème.

la définition des classes de caractères,


Pour ça, il n'y a rien à faire en Unicode : chaque caractère a une classe
par définition ; s'il y a plusieurs classes, Unicode définit différents
caractères.

les opérations
de transformation de ces mêmes classes (uc, lc, ucfirst par exemple), etc.


Là aussi, c'est moins pertinent. Il faut bien voir que les classes de
caractères et les correspondances minuscules/majuscules, ce n'est pas
réellement une question d'usage local, mais avant tout d'encodage : 0xE0
peut vouloir dire LATIN SMALL LETTER A WITH GRAVE ou bien CYRILLIC CAPITAL
LETTER YU selon les cas, et dans un cas sa minuscule est lui-même et sa
majuscule est 0xC0, et dans l'autre cas la minuscule est 0xC0 (tiens, ça
retombe sur le même) et la majuscule lui-même.

Pour ça, Unicode supprime complètement le problème : chaque code correspond
à un seul caractère, et à ce caractère correspond un jeu de propriétés
(catégorie, correspondance minuscule-majuscule) qui n'a pas à dépendre de la
locale : dans une locale différente, on utilise un caractère différent et
c'est tout.

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.

1 2