Detecta si PCRE se construyó sin los --enable-unicode-properties o --enable-utf8 switches de configuración

Tengo una biblioteca de PHP que usa varias expresiones regulares con las expresiones \P para cadenas multibyte, p. Ej.Detecta si PCRE se construyó sin los --enable-unicode-properties o --enable-utf8 switches de configuración

((((?:\P{M}\p{M}*)+?)|(\'[^\']*\')|(\"[^\"]*\"))!)?\$?([a-z]{1,3})\$?(\d+)

Aunque esto funciona en la mayoría de las compilaciones, he tenido algunos informes de que la expresión regular devuelve un error.

dependiendo de la plataforma de funcionamiento, los mensajes de error de PCRE son:

Compilación falló: PCRE no soporta \ L, \ l, \ N, \ P, \ p, \ T, \ u, o \ X en el offset n

Compilación falló: soporte para \ P, \ p, y \ X no se ha compilado en el desplazamiento n

Sé que probablemente pueda probar una expresión regular al comienzo de mi código que usa \P, y atrapar un error devuelto, luego usar esa respuesta para establecer una bandera de compatibilidad y proporcionar una expresión regular degradada (no UTF-8) sin el \P dentro del cuerpo principal de mi código basado en ese indicador de compatibilidad.

Me preguntaba si había alguna manera más simple de identificar si PCRE se había construido sin los conmutadores de configuración --enable-unicode-properties o --enable-utf8. PHP proporciona acceso a la constante PCRE_VERSION, pero eso no ayudará a identificar si la compatibilidad con \P está habilitada o no.

Fuente

2010-12-22 Mark Baker

Me pregunto si 'PREG_BAD_UTF8_OFFSET' se definiría si no compiló con soporte para utf8. Verifique si existe esa constante ('defined ('PREG_BAD_UTF8_OFFSET');') en las plataformas en las que no se compiló. Si no lo tiene, ahí está su cheque. Si lo hace, siempre se puede analizar 'phpinfo()', pero eso no va a ser barato ... – ircmaxell

phpinfo() en realidad no proporciona esa información ... Ya lo he comprobado. Haré una nueva versión de PCRE en uno de mis servidores de prueba y reconstruiré PHP contra eso para ver si PREG_BAD_UTF8_OFFSET está definido, eso proporcionaría una alternativa más limpia a mi repliegue si pudiera simplemente probar una constante definida. –

Bueno, dado que PCRE es compilado por PHP, ¿no debería ser una opción de configuración para PHP? (es decir, ¿no debería aparecer en la línea 'configure' de Phpinfo)? Sin embargo, podría estar equivocado ... – ircmaxell

Aparte de probarlo, creo que la única manera de hacerlo es utilizar la herramienta de línea de pcretest mando, con los (las opciones de tiempo de compilación) -C opción:

bash-4.1.5$ pcretest -C 
    No UTF-8 support 
    No Unicode properties support 
    Newline sequence is LF 
    \R matches all Unicode newlines 
    Internal link size = 2 
    POSIX malloc threshold = 10 
    Default match limit = 10000000 
    Default recursion depth limit = 10000000 
    Match recursion uses stack

Fuente

2010-12-22 13:47:32 netcoder

no ayudará desde PCRE es más distribuída con PHP (y por lo tanto puede usar una compilación diferente de la que está instalada en el servidor, si está instalada en el servidor) ... Por ejemplo, en uno de mis sistemas PCRE es la versión 6.6, pero la versión PCRE de PHP es 8.02 ... – ircmaxell

Lamentablemente cierto, PHP puede use su propia PCRE, o una PCRE del servidor, dependiendo de cómo fue construida. –

Si bien los comentarios sugieren que la comprobación de PREG_BAD_UTF8_ERROR la fuente PHP http://lxr.php.net/xref/PHP_5_6/ext/pcre/php_pcre.c#141 sugiere que esta constante siempre está disponible si PCRE sí lo está. De hecho, parece que --enable-unicode-properties es un conmutador PCRE lib y simplemente no está expuesto por PHP. Lo único que puedo imaginar es ejecutar una expresión regular simple una vez con advertencia supressed ...

Fuente

2016-02-01 07:42:27 chx

Detecta si PCRE se construyó sin los --enable-unicode-properties o --enable-utf8 switches de configuración

Respuesta

Cuestiones relacionadas