EisFuX: PCRE-Versionen, UTF-8

Beitrag lesen

(Hallo|Hi(ho)|Tag) Kurt,

Es geht um folgenden regulären Ausdruck der Bestandteil eines Suchscriptes ist:

// $par1: entweder leer oder "\b"
// $par2: entweder "u" oder "ui"

preg_match("=\b.{0,100}($par1$search_word$par1).{0,100}\b=s$par2", $search_string, $hit_result);

Unter PHP4 (vor dem Serverumzug) funktionierte dies noch.
Jetzt mit PHP5 nicht mehr.

Welche PHP-4- und -5-Version genau?

http://php.net/www.php.net/manual/en/pcre.installation.php

Und was bedeutet "nicht funktionieren"?
Gabs 'ne Fehlermeldung?
Bleibt $hit_result leer?

Änder ich die Zeile aber statisch in folgende, so klappt es auch unter PHP5:
preg_match("=\b.{0,100}(".$par1.$search_word.$par1.").{0,100}\b=sui", $search_string, $hit_result);

Mein Problem liegt also vermutlich an dem $par2.

... oder|und an $search_word, welches du ohne Anpassung in den RegEx einklinkst.

Hast du schon mal von preg_quote() gehört?

Ich hoffe ihr versteht, was ich mein und könnt mir weiterhelfen.

Ohne den Inhalt von $search_word zu sehen, kann man nur Vermutungen anstellen.

Die PCRE-Extension hat in Version 7.3 ihre Meinung darüber geändert, was eine valide UTF-8-Bytesequenz ist:

Validity of UTF-8 strings

When you set the PCRE_UTF8 flag, the strings  passed  as  patterns  and
       subjects are (by default) checked for validity on entry to the relevant
       functions. From release 7.3 of PCRE, the check is according  the  rules
       of  RFC  3629, which are themselves derived from the Unicode specifica-
       tion. Earlier releases of PCRE followed the rules of  RFC  2279,  which
       allows  the  full range of 31-bit values (0 to 0x7FFFFFFF). The current
       check allows only values in the range U+0 to U+10FFFF, excluding U+D800
       to U+DFFF.

Interessant für dich könnte auch noch folgender Abschnitt sein:

6. The character escapes \b, \B, \d, \D, \s, \S, \w, and  \W  correctly
      test  characters of any code value, but the characters that PCRE recog-
      nizes as digits, spaces, or word characters  remain  the  same  set  as
      before, all with values less than 256. This remains true even when PCRE
      includes Unicode property support, because to do otherwise  would  slow
      down  PCRE in many common cases. If you really want to test for a wider
      sense of, say, "digit", you must use Unicode  property  tests  such  as
      \p{Nd}.  Note  that  this  also applies to \b, because it is defined in
      terms of \w and \W.

Kurz: \b ist untauglich, wenn es um UTF-8 geht.

MffG
EisFuX