Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
regex et espace "spécial" (Non-Breaking Space)
49 views
Skip to first unread message
Une Bévue
Jan 31, 2017, 11:16:12 AM1/31/17
to
Bonjour ,
si dans une chaine de caractères j'ai un "Non-Breaking Space" (" ")
("c2a0" en UTF-8 codé Hex) il n'est pas vu comme un caractère espace
"\s" en regex.
c'est "normal" docteur ?
si dans une chaine de caractères j'ai un "Non-Breaking Space" (" ")
("c2a0" en UTF-8 codé Hex) il n'est pas vu comme un caractère espace
"\s" en regex.
c'est "normal" docteur ?
Olivier Miakinen
Jan 31, 2017, 11:40:48 AM1/31/17
to
Bonjour,
Il faudrait voir si tu utilises des regexp exotiques, mais par exemple
dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
(11), FF (12) et space (32). C'est donc tout à fait normal.
Cela exclut donc l'espace normale insécable U+00A0, mais aussi les
caractères Line Separator (U+2028) et Paragraph Separator (U+2029)
reconnus dans JavaScript comme fins de lignes, et bien sûr toutes
les autres espaces sécables ou insécables, à commencer par les
espaces sans chasse ZWSP (U+200B) et ZWNBSP/BOM (U+FEFF).
Attention, si tu veux ajouter ce caractère dans une regexp en PHP,
à ne pas oublier l'option /u (PCRE_UTF8).
--
Olivier Miakinen
dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
(11), FF (12) et space (32). C'est donc tout à fait normal.
Cela exclut donc l'espace normale insécable U+00A0, mais aussi les
caractères Line Separator (U+2028) et Paragraph Separator (U+2029)
reconnus dans JavaScript comme fins de lignes, et bien sûr toutes
les autres espaces sécables ou insécables, à commencer par les
espaces sans chasse ZWSP (U+200B) et ZWNBSP/BOM (U+FEFF).
Attention, si tu veux ajouter ce caractère dans une regexp en PHP,
à ne pas oublier l'option /u (PCRE_UTF8).
--
Olivier Miakinen
Une Bévue
Feb 1, 2017, 3:11:23 AM2/1/17
to
Le 31/01/2017 à 17:40, Olivier Miakinen a écrit :
> Il faudrait voir si tu utilises des regexp exotiques, mais par exemple
> dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
> (11), FF (12) et space (32). C'est donc tout à fait normal.
>
> Cela exclut donc l'espace normale insécable U+00A0, mais aussi les
> caractères Line Separator (U+2028) et Paragraph Separator (U+2029)
> reconnus dans JavaScript comme fins de lignes, et bien sûr toutes
> les autres espaces sécables ou insécables, à commencer par les
> espaces sans chasse ZWSP (U+200B) et ZWNBSP/BOM (U+FEFF).
>
> Attention, si tu veux ajouter ce caractère dans une regexp en PHP,
> à ne pas oublier l'option /u (PCRE_UTF8).
Bon, merci beaucoup pour cette claire explication.
> Il faudrait voir si tu utilises des regexp exotiques, mais par exemple
> dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
> (11), FF (12) et space (32). C'est donc tout à fait normal.
>
> Cela exclut donc l'espace normale insécable U+00A0, mais aussi les
> caractères Line Separator (U+2028) et Paragraph Separator (U+2029)
> reconnus dans JavaScript comme fins de lignes, et bien sûr toutes
> les autres espaces sécables ou insécables, à commencer par les
> espaces sans chasse ZWSP (U+200B) et ZWNBSP/BOM (U+FEFF).
>
> Attention, si tu veux ajouter ce caractère dans une regexp en PHP,
> à ne pas oublier l'option /u (PCRE_UTF8).
C'est donc normal, mais particulièrement génant.
Je n'utilise pas de regex "exotiques", il y a que je souhaite supprimer,
dans certains cas, ded espaces et que less "non breaking spaces" sont
récalcitrants.
Bien sûr j'ai trouvé la parade.
Olivier Miakinen
Feb 2, 2017, 6:54:21 AM2/2/17
to
Le 01/02/2017 09:11, Une Bévue m'a répondu :
tous ceux qui ont codé des regexp pour l'ASCII ou le Latin1, et
qui par hasard se retrouveraient avec une chaîne en UTF-8. Cela
pourrait même être une source potentielle de grosse faille de
sécurité.
> Je n'utilise pas de regex "exotiques", il y a que je souhaite supprimer,
> dans certains cas, des espaces et que les "non breaking spaces" sont
> récalcitrants.
Sans vouloir te faire peur outre mesure, le fait que tu utilises
un \s sans savoir *exactement* quels caractères cela recouvre me
fait penser que peut-être tu pourrais avoir de telles failles de
sécurité dans ton code. Bien sûr cela ne concerne pas que \s et \S
mais aussi \w et \W, \d et \D, \b et \B... j'en oublie peut-être.
Donc, à moins de savoir exactement ce que tel raccourci recouvre
et d'être d'accord avec ça, il pourrait être plus sage d'utiliser
des regexp plus basiques, par exemple [ \t\n] au lieu de \s, ou la
même chose en y ajoutant l'espace insécable.
> Bien sûr j'ai trouvé la parade.
Ok. Tous ceux qui étaient intéressés par ton problème sont ravis
que tu l'aies trouvée (quoique peut-être un peu déçus que tu la
gardes secrète). ;-)
--
Olivier Miakinen
>
>> Il faudrait voir si tu utilises des regexp exotiques, mais par exemple
>> dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
>> (11), FF (12) et space (32). C'est donc tout à fait normal.
>>
>> [...]
>> Il faudrait voir si tu utilises des regexp exotiques, mais par exemple
>> dans PCRE cela inclut uniquement les caractères HT (9), LF (10), VT
>> (11), FF (12) et space (32). C'est donc tout à fait normal.
>>
>
> Bon, merci beaucoup pour cette claire explication.
> C'est donc normal, mais particulièrement génant.
Peut-être pour toi, mais l'inverse serait encore plus gênant pour
> Bon, merci beaucoup pour cette claire explication.
> C'est donc normal, mais particulièrement génant.
tous ceux qui ont codé des regexp pour l'ASCII ou le Latin1, et
qui par hasard se retrouveraient avec une chaîne en UTF-8. Cela
pourrait même être une source potentielle de grosse faille de
sécurité.
> Je n'utilise pas de regex "exotiques", il y a que je souhaite supprimer,
> récalcitrants.
Sans vouloir te faire peur outre mesure, le fait que tu utilises
un \s sans savoir *exactement* quels caractères cela recouvre me
fait penser que peut-être tu pourrais avoir de telles failles de
sécurité dans ton code. Bien sûr cela ne concerne pas que \s et \S
mais aussi \w et \W, \d et \D, \b et \B... j'en oublie peut-être.
Donc, à moins de savoir exactement ce que tel raccourci recouvre
et d'être d'accord avec ça, il pourrait être plus sage d'utiliser
des regexp plus basiques, par exemple [ \t\n] au lieu de \s, ou la
même chose en y ajoutant l'espace insécable.
> Bien sûr j'ai trouvé la parade.
que tu l'aies trouvée (quoique peut-être un peu déçus que tu la
gardes secrète). ;-)
--
Olivier Miakinen
Une Bévue
Feb 3, 2017, 12:48:57 AM2/3/17
to
Le 02/02/2017 à 12:54, Olivier Miakinen a écrit :
> Donc, à moins de savoir exactement ce que tel raccourci recouvre
> et d'être d'accord avec ça, il pourrait être plus sage d'utiliser
> des regexp plus basiques, par exemple [ \t\n] au lieu de \s, ou la
> même chose en y ajoutant l'espace insécable.
ok, bien sûr.
> Donc, à moins de savoir exactement ce que tel raccourci recouvre
> et d'être d'accord avec ça, il pourrait être plus sage d'utiliser
> des regexp plus basiques, par exemple [ \t\n] au lieu de \s, ou la
> même chose en y ajoutant l'espace insécable.
>> Bien sûr j'ai trouvé la parade.
> Ok. Tous ceux qui étaient intéressés par ton problème sont ravis
> que tu l'aies trouvée (quoique peut-être un peu déçus que tu la
> gardes secrète). ;-)
[ \t\n] (au lieu de \s)
ben tout simplement j'ajoute, dans cette liste, le caractère , en
utf-8 :
[ \t\n]
ça ne se voit pas mais là il est en tête, avant l'espace ordinaire...
Olivier Miakinen
Feb 3, 2017, 5:17:44 AM2/3/17
to
Le 03/02/2017 06:49, Une Bévue a écrit :
>
> rien de secret à ça, plus haut tu as listé :
> [ \t\n] (au lieu de \s)
> ben tout simplement j'ajoute, dans cette liste, le caractère , en
> utf-8 :
>
> [ \t\n]
>
> ça ne se voit pas mais là il est en tête, avant l'espace ordinaire...
Ok, c'est parfait. Je rappelle pour ceux qui nous lisent que, si c'est
>
> rien de secret à ça, plus haut tu as listé :
> [ \t\n] (au lieu de \s)
> ben tout simplement j'ajoute, dans cette liste, le caractère , en
> utf-8 :
>
> [ \t\n]
>
> ça ne se voit pas mais là il est en tête, avant l'espace ordinaire...
en PHP qui par défaut suppose un jeu de caractères mono-octet, il est
indispensable de ne pas oublier l'option /u (PCRE_UTF8). Sinon, seront
acceptés dans la regexp des bouts de tous les caractères compris entre
U+00A0 et U+00BF (par exemple les guillemets « ») dont le code UTF-8
commence par C2, mais aussi un bout du caractère /à/ dont le code UTF-8
se termine par A0, et plein d'autres.
--
Olivier Miakinen
0 new messages