No hay funciones multibyte 'preg' disponibles en PHP, ¿eso significa que las funciones preg predeterminadas son todas seguras mb? No se pudo encontrar ninguna mención en la documentación de php.¿Son seguras las preg_functions de PHP multibyte?
PCRE puede soportar UTF-8 y otras codificaciones Unicode, pero tiene que ser especificado en tiempo de compilación. Desde el man page for PCRE 8.0:
La implementación actual de PCRE corresponde aproximadamente con Perl 5.10, incluyendo soporte para UTF-8 cuerdas codificados y Unicode propiedades categoría general. Sin embargo, la compatibilidad con UTF-8 y Unicode debe estar explícitamente habilitada; no es el predeterminado. Las tablas Unicode corresponden a la versión 5.1 de Unicode.
PHP actualmente utiliza PCRE 7.9; su sistema puede tener una versión anterior.
Al echar un vistazo al PCRE lib que viene con PHP 5.2, parece que está configurado para admitir propiedades Unicode y UTF-8. Lo mismo para el 5.3 branch.
Estoy usando PHP 5.3.0 que incluye PCRE Versión 7.9, revisé el archivo PCRE config.h que incluye la definición UTF8, por lo que parece que los preg_funcs son seguro. ¡Muchas gracias por la información! – Spoonface
¿Existe alguna forma rápida de determinar qué versión de PCRE está usando una instalación PHP existente? Mi servidor, por ejemplo, ejecuta PHP 5.5, pero ¿cómo puedo saber con qué biblioteca PCRE se compiló? – thatidiotguy
No, no lo son. Ver la pregunta preg_match and UTF-8 in PHP por ejemplo.
Para aclarar, el 'PREG_OFFSET_CAPTURE' produce compensaciones de bytes en lugar de caracteres. Es coherente con el manejo de cadenas en PHP, pero puede ser bastante confuso. –
No, usted necesitará utilizar el multibyte string functions como mb_ereg
Sin embargo, son la versión de múltiples bytes de las funciones POSIX 'ereg', que no son exactamente las mismas que las funciones' preg' de PCRE. – mercator
Ben S eres mi héroe :) Solo quería purificar textos y dejar äöüß dentro del texto. preg_replace nunca hizo esto correctamente, ¡pero mb_ereg sí! – Nibbels
, siempre y cuando use el modificador/u, ELLOS SON MÚLTIPLES SEGUROS, siempre que la codificación multibyte sea UTF-8. el motor/u no admite ninguna otra codificación que UTF-8 – hanshenrik
pcre admite utf8 fuera de la caja, consulte la documentación para el modificador 'u'.
Ilustración (\ xc3 \ XA4 es la codificación UTF-8 para la letra alemana "A")
echo preg_replace('~\w~', '@', "a\xC3\xA4b");
Esto se hace eco "@@ ¤ @" porque "\ xc3" y "\ XA4" fueron tratados como símbolos distintos
echo preg_replace('~\w~u', '@', "a\xC3\xA4b");
(nótese la 'U') impresiones "@@@" porque "\ xc3 \ XA4" fueron tratadas como una sola letra.
¿De verdad? Hmm, no soy demasiado hábil con las cadenas de expresiones regulares, si no te importa, ¿podría publicar algo de mi código preg_ para ver lo que piensas? – Spoonface
ideal para usted modificador, no lo sabía –
Algunos de mis más complicadas funciones preg:
(1a) validar nombre de usuario como alfanumérico + subrayado:
preg_match('/^[A-Za-z][A-Za-z0-9]*(?:_[A-Za-z0-9]+)*$/',$username)
(1b) posible alternativa UTF:
preg_match('/^[A-Za-z][A-Za-z0-9]*(?:_[A-Za-z0-9]+)*$/u',$username)
(2a) validar el correo electrónico:
preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ix",$email))
(2b) posibles alternativas UTF:
preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ixu",$email))
(3a) normalizar las nuevas líneas:
preg_replace("/(\n){2,}/","\n\n",$str);
(3b) UTF posible alternativa:
preg_replace("/(\n){2,}/u","\n\n",$str);
interés thse cambios se ven bien?
bien entonces, aplausos por la información – Spoonface
Creo que su expresión regular de correo electrónico permitirá '..' en cualquier lugar de la dirección de correo electrónico, que es algo que necesita aserciones para evitar. –
Estoy 90% seguro de que las funciones subyacentes de C son, pero eso no significa que las versiones de PHP son, supongo ... –