J'ai du mal à comprendre et surtout à résoudre un problème tout bête.
Je cherche à parser un texte à la recherche d'expressions présentes dans
une base. Ce que font les tonnes des trucs à la autolink.
Mais, si tout va bien dans mes tests hors SQL, si tout va bien sur la
pluparts des mots et expressions, ça foire avec les quotes.
Ceci place des % entre les expressions ($exp) trouvées dans la base MySQL :
preg_replace ( "#(\W)(" . preg_quote ( $exp ) . ")(\W)#Ui" ,
'${1}%${2}%${3}' , $texte , $max );
Si, au sein du script php, je cherche "aujourd'hui", ça ne fonctionne pas.
Normal, le problème est que le texte original transforme les ' en ' (je
ne le contrôle pas).
Donc, toujours au sein du script, je cherche "aujourd'hui" et là, ça
fonctionne.
Par contre, quand j'utilise la sortie MySQL, ça ne fonctionne plus. J'ai
beau faire un str_replace("'","'",$texte) ou un
str_replace("'","'",$exp), ça ne fonctionne pas du moment que $exp vient
de la base de données.
Pourtant, quand je fais un echo du $exp sorti de la base et que je fais
un copier/coller dans le script, ça fonctionne.
Tout est censé être en utf-8 et j'ai même insisté avec un
set_charset('utf8') pour la connexion MySQL.
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas parlé, c'est que je trouvais le caractère « # » peu lisible comme délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore une fois la lisibilité est quelque chose de subjectif. Mais ici, il n'est pas question que de lisibilité : tu as un « # » dans la chaîne elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ? Bon, eh bien je n'en sais rien.
version texte : 3c703e61756a6f7572642623383231373b6875693c2f703e0a
"<p>aujourd’hui</p>"
Ah, je comprends mieux pourquoi toutes les versions marchaient, quels que soient les iconv() effectués ! Il n'y a que de l'ASCII ici, et c'est juste à l'affichage que tu montres une apostrophe...
Mais pourquoi cette entité n'apparait nulle part (dans le code) ?
Ça, c'est à toi de nous le dire car tu es le seul à l'avoir, le code. Sans infos supplémentaires, j'ai même cru que c'était bien dans le code et que tu avais oublié de faire « View > Source » sur la page HTML.
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que
j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas
parlé, c'est que je trouvais le caractère « # » peu lisible comme
délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore
une fois la lisibilité est quelque chose de subjectif. Mais ici, il
n'est pas question que de lisibilité : tu as un « # » dans la chaîne
elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ?
Bon, eh bien je n'en sais rien.
version texte : 3c703e61756a6f7572642623383231373b6875693c2f703e0a
"<p>aujourd’hui</p>"
Ah, je comprends mieux pourquoi toutes les versions marchaient, quels
que soient les iconv() effectués ! Il n'y a que de l'ASCII ici, et c'est
juste à l'affichage que tu montres une apostrophe...
Mais pourquoi cette entité n'apparait nulle part (dans le code) ?
Ça, c'est à toi de nous le dire car tu es le seul à l'avoir, le code.
Sans infos supplémentaires, j'ai même cru que c'était bien dans le code
et que tu avais oublié de faire « View > Source » sur la page HTML.
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas parlé, c'est que je trouvais le caractère « # » peu lisible comme délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore une fois la lisibilité est quelque chose de subjectif. Mais ici, il n'est pas question que de lisibilité : tu as un « # » dans la chaîne elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ? Bon, eh bien je n'en sais rien.
version texte : 3c703e61756a6f7572642623383231373b6875693c2f703e0a
"<p>aujourd’hui</p>"
Ah, je comprends mieux pourquoi toutes les versions marchaient, quels que soient les iconv() effectués ! Il n'y a que de l'ASCII ici, et c'est juste à l'affichage que tu montres une apostrophe...
Mais pourquoi cette entité n'apparait nulle part (dans le code) ?
Ça, c'est à toi de nous le dire car tu es le seul à l'avoir, le code. Sans infos supplémentaires, j'ai même cru que c'était bien dans le code et que tu avais oublié de faire « View > Source » sur la page HTML.
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas parlé, c'est que je trouvais le caractère « # » peu lisible comme délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore une fois la lisibilité est quelque chose de subjectif. Mais ici, il n'est pas question que de lisibilité : tu as un « # » dans la chaîne elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ? Bon, eh bien je n'en sais rien.
Ç'aurait effectivement pu être la bonne solution, pas évidente à trouver. En fait, je viens à l'instant de voir une erreur que j'avais faite. Comme je ne peux pas modifier ce qui vient de $texte, j'ai voulu modifier ce qui provenait de la base. Et là, je ne comprenais vraiment pas pourquoi ça ne fonctionnait pas. Et puis avec ta très bonne idée du binhex, ça devenait plus facile à voir. Je faisais (depuis tes infos sur cet étrange ’) : str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;. Donc maintenant ça fonctionne !
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que
j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas
parlé, c'est que je trouvais le caractère « # » peu lisible comme
délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore
une fois la lisibilité est quelque chose de subjectif. Mais ici, il
n'est pas question que de lisibilité : tu as un « # » dans la chaîne
elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ?
Bon, eh bien je n'en sais rien.
Ç'aurait effectivement pu être la bonne solution, pas évidente à trouver.
En fait, je viens à l'instant de voir une erreur que j'avais faite.
Comme je ne peux pas modifier ce qui vient de $texte, j'ai voulu
modifier ce qui provenait de la base. Et là, je ne comprenais vraiment
pas pourquoi ça ne fonctionnait pas. Et puis avec ta très bonne idée du
binhex, ça devenait plus facile à voir.
Je faisais (depuis tes infos sur cet étrange ’) :
str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;.
Donc maintenant ça fonctionne !
Bon sang, mais c'est bien sûr ! Parmi toutes les modifications que j'aurais faites à ta ligne de code, il y en a une dont je n'ai pas parlé, c'est que je trouvais le caractère « # » peu lisible comme délimiteur d'expression rationnelle ; je n'en ai pas parlé car encore une fois la lisibilité est quelque chose de subjectif. Mais ici, il n'est pas question que de lisibilité : tu as un « # » dans la chaîne elle-même ! Ah, sauf que tu dis que tu le passes bien en paramètre ? Bon, eh bien je n'en sais rien.
Ç'aurait effectivement pu être la bonne solution, pas évidente à trouver. En fait, je viens à l'instant de voir une erreur que j'avais faite. Comme je ne peux pas modifier ce qui vient de $texte, j'ai voulu modifier ce qui provenait de la base. Et là, je ne comprenais vraiment pas pourquoi ça ne fonctionnait pas. Et puis avec ta très bonne idée du binhex, ça devenait plus facile à voir. Je faisais (depuis tes infos sur cet étrange ’) : str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;. Donc maintenant ça fonctionne !
Merci beaucoup pour ton aide.
Olivier Miakinen
Le 18/10/2009 21:01, Olivier Masson a écrit :
[...] Je faisais (depuis tes infos sur cet étrange ’) : str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;. Donc maintenant ça fonctionne !
D'autant plus béta que dans <4ad89fed$0$10119$ tu avais bien écrit : <cit.> Pour finir, j'ai essayé un str_replace("'","’",$exp), ce qui a bien remplacé le ' par un ’... </cit.> ... ce qui fait que je n'ai pas pu le corriger ici.
Merci beaucoup pour ton aide.
Avec plaisir.
-- Olivier Miakinen
Le 18/10/2009 21:01, Olivier Masson a écrit :
[...]
Je faisais (depuis tes infos sur cet étrange ’) :
str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;.
Donc maintenant ça fonctionne !
D'autant plus béta que dans <4ad89fed$0$10119$426a74cc@news.free.fr>
tu avais bien écrit :
<cit.>
Pour finir, j'ai essayé un
str_replace("'","’",$exp), ce qui a bien remplacé le ' par un ’...
</cit.>
... ce qui fait que je n'ai pas pu le corriger ici.
[...] Je faisais (depuis tes infos sur cet étrange ’) : str_replace("'", "’",$exp);
Ben oui, c'est béta hein :) Il manquait juste le ;. Donc maintenant ça fonctionne !
D'autant plus béta que dans <4ad89fed$0$10119$ tu avais bien écrit : <cit.> Pour finir, j'ai essayé un str_replace("'","’",$exp), ce qui a bien remplacé le ' par un ’... </cit.> ... ce qui fait que je n'ai pas pu le corriger ici.
Merci beaucoup pour ton aide.
Avec plaisir.
-- Olivier Miakinen
Olivier Masson
Olivier Miakinen a écrit :
En attendant ta republication, quelques remarques quand même :
Le 16/10/2009 15:40, Olivier Masson a écrit :
Ceci place des % entre les expressions ($exp) trouvées dans la base MySQL : preg_replace ( "#(W)(" . preg_quote ( $exp ) . ")(W)#Ui" , '${1}%${2}%${3}' , $texte , $max );
Tout d'abord, si les expressions $exp sont censées toujours commencer et finir par un caractère « de mot », alors une assertion « limite de mot » est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est, cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec (W).
En fait, ça ne fonctionne pas avec /b car il n'isole pas "isoloir" dans "l'isoloir".
Olivier Miakinen a écrit :
En attendant ta republication, quelques remarques quand même :
Le 16/10/2009 15:40, Olivier Masson a écrit :
Ceci place des % entre les expressions ($exp) trouvées dans la base MySQL :
preg_replace ( "#(W)(" . preg_quote ( $exp ) . ")(W)#Ui" ,
'${1}%${2}%${3}' , $texte , $max );
Tout d'abord, si les expressions $exp sont censées toujours commencer et
finir par un caractère « de mot », alors une assertion « limite de mot »
est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est,
cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec
(W).
En attendant ta republication, quelques remarques quand même :
Le 16/10/2009 15:40, Olivier Masson a écrit :
Ceci place des % entre les expressions ($exp) trouvées dans la base MySQL : preg_replace ( "#(W)(" . preg_quote ( $exp ) . ")(W)#Ui" , '${1}%${2}%${3}' , $texte , $max );
Tout d'abord, si les expressions $exp sont censées toujours commencer et finir par un caractère « de mot », alors une assertion « limite de mot » est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est, cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec (W).
Tout d'abord, si les expressions $exp sont censées toujours commencer et finir par un caractère « de mot », alors une assertion « limite de mot » est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est, cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec (W).
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça marche -- conformément à la doc.
Tout d'abord, si les expressions $exp sont censées toujours commencer et
finir par un caractère « de mot », alors une assertion « limite de mot »
est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est,
cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec
(W).
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche
pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça
marche -- conformément à la doc.
Tout d'abord, si les expressions $exp sont censées toujours commencer et finir par un caractère « de mot », alors une assertion « limite de mot » est plus facile à lire qu'un (W) repris dans un ${1}. Qui plus est, cela fonctionnera même en début de chaîne, ce qui n'est pas le cas avec (W).
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça marche -- conformément à la doc.
-- Olivier Miakinen
Olivier Masson
Olivier Miakinen a écrit :
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça marche -- conformément à la doc.
Je retire, jma trompé ! C'est plus tordu : sur mon serveur en local, tout fonctionne. Par contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je l'ai cru mais à cause de l'accent.
Donc l'exemple avec l'isoloir, on oublie, j'ai fait n'importe quoi. Par contre, sur le serveur Amen, "étude" n'était pas trouvé. J'ai donc comparé avec bin2hex mais cette fois, le problème ne venait pas des chaines. C'est bel et bien le preg-replace qui ne fonctionnait pas.
Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a pas loupé : j'y ai encore une fois eu le droit. Tout fonctionne avec W.
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un serveur linux à moi.
Olivier Miakinen a écrit :
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche
pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça
marche -- conformément à la doc.
Je retire, jma trompé !
C'est plus tordu : sur mon serveur en local, tout fonctionne. Par
contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est
pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je
l'ai cru mais à cause de l'accent.
Donc l'exemple avec l'isoloir, on oublie, j'ai fait n'importe quoi.
Par contre, sur le serveur Amen, "étude" n'était pas trouvé.
J'ai donc comparé avec bin2hex mais cette fois, le problème ne venait
pas des chaines.
C'est bel et bien le preg-replace qui ne fonctionnait pas.
Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a
pas loupé : j'y ai encore une fois eu le droit.
Tout fonctionne avec W.
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un
serveur linux à moi.
Hein ? Alors « ' » fait partie de W, « i » de w, mais le b ne matche pas au milieu de « 'i » ??? Je viens de faire des tests, et pour moi ça marche -- conformément à la doc.
Je retire, jma trompé ! C'est plus tordu : sur mon serveur en local, tout fonctionne. Par contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je l'ai cru mais à cause de l'accent.
Donc l'exemple avec l'isoloir, on oublie, j'ai fait n'importe quoi. Par contre, sur le serveur Amen, "étude" n'était pas trouvé. J'ai donc comparé avec bin2hex mais cette fois, le problème ne venait pas des chaines. C'est bel et bien le preg-replace qui ne fonctionnait pas.
Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a pas loupé : j'y ai encore une fois eu le droit. Tout fonctionne avec W.
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un serveur linux à moi.
Olivier Miakinen
Le 24/10/2009 21:12, Olivier Masson a écrit :
Je retire, jma trompé ! C'est plus tordu : sur mon serveur en local, tout fonctionne. Par contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je l'ai cru mais à cause de l'accent.
[...] sur le serveur Amen, "étude" n'était pas trouvé.
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison, en utilisant problablement une locale "C" alors qu'en local tu dois être en français. Tu dois avoir parfois des comportements assez inattendus sur ton serveur local.
[...] Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a pas loupé : j'y ai encore une fois eu le droit. Tout fonctionne avec W.
Oui, mais ça ne marchera pas dans tous les cas. Par exemple, si tu cherches « change » il le trouvera dans « échange », et si tu cherches « coup » il le trouvera dans « découpât ».
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un serveur linux à moi.
La raison est très simple. Avec une locale française, « é » et « â » font partie de w alors qu'avec la locale "C" ils font partie de W.
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est pas une lettre » (quelle que soit la langue) :
Je retire, jma trompé !
C'est plus tordu : sur mon serveur en local, tout fonctionne. Par
contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est
pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je
l'ai cru mais à cause de l'accent.
[...] sur le serveur Amen, "étude" n'était pas trouvé.
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison,
en utilisant problablement une locale "C" alors qu'en local tu dois être
en français. Tu dois avoir parfois des comportements assez inattendus
sur ton serveur local.
[...]
Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a
pas loupé : j'y ai encore une fois eu le droit.
Tout fonctionne avec W.
Oui, mais ça ne marchera pas dans tous les cas. Par exemple, si tu
cherches « change » il le trouvera dans « échange », et si tu cherches
« coup » il le trouvera dans « découpât ».
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un
serveur linux à moi.
La raison est très simple. Avec une locale française, « é » et « â »
font partie de w alors qu'avec la locale "C" ils font partie de W.
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des
assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est
pas une lettre » (quelle que soit la langue) :
Je retire, jma trompé ! C'est plus tordu : sur mon serveur en local, tout fonctionne. Par contre, sur un serveur Amen (oui, je sais, c'est mauvais, mais ce n'est pas le mien), ça ne fonctionne pas. Pas à cause de l'apostrophe comme je l'ai cru mais à cause de l'accent.
[...] sur le serveur Amen, "étude" n'était pas trouvé.
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison, en utilisant problablement une locale "C" alors qu'en local tu dois être en français. Tu dois avoir parfois des comportements assez inattendus sur ton serveur local.
[...] Je t'avais dit que j'avais déjà rencontré des problèmes avec b. Ça n'a pas loupé : j'y ai encore une fois eu le droit. Tout fonctionne avec W.
Oui, mais ça ne marchera pas dans tous les cas. Par exemple, si tu cherches « change » il le trouvera dans « échange », et si tu cherches « coup » il le trouvera dans « découpât ».
Par contre pourquoi, ça, aucune idée. Pas eu le tps de tester sur un serveur linux à moi.
La raison est très simple. Avec une locale française, « é » et « â » font partie de w alors qu'avec la locale "C" ils font partie de W.
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est pas une lettre » (quelle que soit la langue) :
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison,
Ah merde !
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est pas une lettre » (quelle que soit la langue) :
Ouah ! Bon, je n'ai pas encore testé mais chapeau ! Je n'avais jamais vu P. Tu devrais faire un conf sur unicode à Paris Web ? :)
Je craignais qu'une limite de mot et ce qui est ou n'est pas un mot pouvait être gênant car je n'ai jamais trouvé (cherché ?) de définitions exactes de ces classes.
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la solution, que j'ai eu l'extrême gentillesse de partager avec le peuple ! Mais bon, merci qd même beaucoup ;)
Olivier Miakinen a écrit :
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison,
Ah merde !
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des
assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est
pas une lettre » (quelle que soit la langue) :
Ouah ! Bon, je n'ai pas encore testé mais chapeau !
Je n'avais jamais vu P.
Tu devrais faire un conf sur unicode à Paris Web ? :)
Je craignais qu'une limite de mot et ce qui est ou n'est pas un mot
pouvait être gênant car je n'ai jamais trouvé (cherché ?) de définitions
exactes de ces classes.
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la
solution, que j'ai eu l'extrême gentillesse de partager avec le peuple !
Mais bon, merci qd même beaucoup ;)
Bon sang mais c'est bien sûr ! Et pour le coup c'est Amen qui a raison,
Ah merde !
Du coup, puisque tes chaînes sont en UTF-8 je te suggère d'utiliser des assertions, avec la propriété Unicode P{L} ou PL qui signifie « n'est pas une lettre » (quelle que soit la langue) :
Ouah ! Bon, je n'ai pas encore testé mais chapeau ! Je n'avais jamais vu P. Tu devrais faire un conf sur unicode à Paris Web ? :)
Je craignais qu'une limite de mot et ce qui est ou n'est pas un mot pouvait être gênant car je n'ai jamais trouvé (cherché ?) de définitions exactes de ces classes.
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la solution, que j'ai eu l'extrême gentillesse de partager avec le peuple ! Mais bon, merci qd même beaucoup ;)
Olivier Miakinen
Le 26/10/2009 17:08, Olivier Masson a écrit :
... c'est Amen qui a raison,
Ah merde !
Non, Amen. Enfin... tu le prononces comme tu veux.
Je n'avais jamais vu P.
Problablement parce que tu ne connaissais pas non plus l'option /u (PCRE8). Attention, l'un ne va pas sans l'autre !
<cit. http://fr2.php.net/manual/fr/reference.pcre.pattern.modifiers.php> u (PCRE8)
Cette option désactive[sic] les fonctionnalités additionnelles de PCRE qui ne sont pas compatibles avec Perl. Les chaînes sont traitées comme des chaînes UTF-8. Cette option est disponible en PHP 4.1.0 et plus récent sur plate-forme Unix et en PHP 4.2.3 et plus récent sur plate-forme Windows. </cit.>
En version originale, sans les coquilles de traduction :
<cit. http://fr2.php.net/manual/en/reference.pcre.pattern.modifiers.php> u (PCRE8)
This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5. </cit.>
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la solution, que j'ai eu l'extrême gentillesse de partager avec le peuple !
:-D
Le 26/10/2009 17:08, Olivier Masson a écrit :
... c'est Amen qui a raison,
Ah merde !
Non, Amen. Enfin... tu le prononces comme tu veux.
Je n'avais jamais vu P.
Problablement parce que tu ne connaissais pas non plus l'option /u
(PCRE8). Attention, l'un ne va pas sans l'autre !
<cit. http://fr2.php.net/manual/fr/reference.pcre.pattern.modifiers.php>
u (PCRE8)
Cette option désactive[sic] les fonctionnalités additionnelles de PCRE
qui ne sont pas compatibles avec Perl. Les chaînes sont traitées comme
des chaînes UTF-8. Cette option est disponible en PHP 4.1.0 et plus
récent sur plate-forme Unix et en PHP 4.2.3 et plus récent sur
plate-forme Windows.
</cit.>
En version originale, sans les coquilles de traduction :
<cit. http://fr2.php.net/manual/en/reference.pcre.pattern.modifiers.php>
u (PCRE8)
This modifier turns on additional functionality of PCRE that is
incompatible with Perl. Pattern strings are treated as UTF-8. This
modifier is available from PHP 4.1.0 or greater on Unix and from
PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since
PHP 4.3.5.
</cit.>
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la
solution, que j'ai eu l'extrême gentillesse de partager avec le peuple !
Non, Amen. Enfin... tu le prononces comme tu veux.
Je n'avais jamais vu P.
Problablement parce que tu ne connaissais pas non plus l'option /u (PCRE8). Attention, l'un ne va pas sans l'autre !
<cit. http://fr2.php.net/manual/fr/reference.pcre.pattern.modifiers.php> u (PCRE8)
Cette option désactive[sic] les fonctionnalités additionnelles de PCRE qui ne sont pas compatibles avec Perl. Les chaînes sont traitées comme des chaînes UTF-8. Cette option est disponible en PHP 4.1.0 et plus récent sur plate-forme Unix et en PHP 4.2.3 et plus récent sur plate-forme Windows. </cit.>
En version originale, sans les coquilles de traduction :
<cit. http://fr2.php.net/manual/en/reference.pcre.pattern.modifiers.php> u (PCRE8)
This modifier turns on additional functionality of PCRE that is incompatible with Perl. Pattern strings are treated as UTF-8. This modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5. </cit.>
Bon, je ne te remercie pas parce que c'est un peu moi qui t'ai donné la solution, que j'ai eu l'extrême gentillesse de partager avec le peuple !
:-D
Olivier Masson
Olivier Miakinen a écrit :
En version originale, sans les coquilles de traduction :
!!! C'est précisément ce que je ne comprenais pas ! Je ne voyais pas trop à quoi ils faisaient allusion, mais je trouvais ça dommage de désactiver des fonctions en passant en utf-8...
Olivier Miakinen a écrit :
En version originale, sans les coquilles de traduction :
!!!
C'est précisément ce que je ne comprenais pas !
Je ne voyais pas trop à quoi ils faisaient allusion, mais je trouvais ça
dommage de désactiver des fonctions en passant en utf-8...
En version originale, sans les coquilles de traduction :
!!! C'est précisément ce que je ne comprenais pas ! Je ne voyais pas trop à quoi ils faisaient allusion, mais je trouvais ça dommage de désactiver des fonctions en passant en utf-8...
