Confidare Weblog

En principio, es buena la idea de los patrones \w y \W en las expresiones regulares PCRE de PHP. Según la documentación, el patrón \w debe calzar con cualquier carácter de “palabra” (esto es, letras, dígitos y la barra inferior “_”), considerando el locale actual. Cito:

Un caracter de “palabra” es cualquier letra o dígito, o el caracter de subrayado, esto quiere decir, cualquier caracter que pueda ser parte de una “palabra” en Perl. La definición de letras y dígitos es controlada por las tablas de caracteres de PCRE, y puede variar si se están efectuando coincidencias específicas a localidades. Por ejemplo, en la localidad “fr” (Francia), algunos códigos de caracteres mayores a 128 son usados para letras con acentos, y éstas coinciden con \w.

Esta última característica haría que, por ejemplo, la función preg_replace fuera idónea para sanitizar datos ingresados por el usuario; por ejemplo, podríamos reemplazar fácilmente cualquier carácter “extraño” por un espacio mediante un simple:

preg_replace(’/\W/’, ‘ ‘, $q)

La gracia sería que no reemplazara los caracteres acentuados, ni a nuestra querida letra “Ñ”. Según la documentación, todo lo que habría que hacer para lograrlo es asegurarse de que el locale esté ajustado al valor correcto. Sin embargo, miren este caso de prueba:

< ?php
echo setlocale(LC_ALL, ‘es_CL.UTF-8′) . “\n”;
echo preg_replace(’/\W/u’, ‘ ‘, ‘año’) . “\n”;

La salida es:

$ php -f test.php
es_CL.UTF-8
a o

De manera que la “ñ” no es considerada un carácter de “palabra”. ¡Bien, PHP! En devnetwork.net un tipo llegó a probar todo el juego ASCII para finalmente concluir de que el locale es ignorado por las funciones PCRE de PHP.

Ah, por supuesto. ¿Tiene que haber otra manera de lograrlo, no? Claro que no es tan elegante:

preg_replace(’/[^A-Za-z0-9áéíóúÁÉÍÓÚñÑ_]/’, ‘ ‘, $q);

En tardes como ésta puedo llegar a entender a los php-haters.

Actualización: Gracias a Roberto dimos con una mejor alternativa para evitar este “bug”. Mira en los comentarios para más detalles.

Nada más quería advertir a quienes pasen por aquí que acabo de perder media hora tratando de descubrir por qué el lenguaje del calendario dynarch de la aplicación Symfony en que estoy trabajando volvió a cambiarse de español a inglés, con los consiguientes errores a la hora de almacenar las fechas en la base de datos (por el formato).

Resulta que, por alguna razón (ahí está el misterio), —y a pesar de que mi default_culture está en “es” en el archivo settings.yml— a la hora de incluir los archivos JS del calendario Symfony se encontraba con que la “cultura” del usuario era “en” en lugar de “es”. Después de varios cabezazos y por pura prueba y error, descubrí que el problema residía en la sesión. En la sesión simplemente la cultura había quedado como “en”.

Así que, bastó con borrar las cookies involucradas (gracias a San Web Developer Toolbar) para resolver el problema.

¿Cómo llegó a meterse esa cookie venenosa ahí? Ahora que lo pienso, a la otra aplicación en la que estoy trabajando no le he configurado aún el default_culture, de manera que de ahí debe venir la contaminación. Increíblemente, la reflexión que tuve que hacer para escribir este post me ayudó a encontrar la raíz del problema. ¡Gracias por su ayuda!

Este año finalmente decidí a hacerme el tiempo de preparar algunos trabajos para el Encuentro Linux, luego de dos años de puras intenciones. Dos de los tres trabajos que presenté fueron seleccionados, así que me fue bastante bien.

El 8° Encuentro se realizó en la Universidad de Tarapacá de Arica entre el 12 y 14 de octubre y contó con la asistencia de unas 300 personas (al ojo), principalmente estudiantes.

Todo fue tan rápido que ni siquiera había tenido tiempo de escribir al respecto. Les dejo algunas fotos del Encuentro.

Habiendo adquirido una consola Atari 2600 Junior (¡ah…! ¡la nostalgia!) a través de un conocido portal de remates en Internet, me apresuré en completar la transacción para que el vendedor me la enviara cuanto antes (de Talca). Cuando finalmente obtuve el número de flete de Tur Bus, fui directamente a la página de seguimiento de carga de su web), ingresé el numerito, presioné “Realizar seguimiento” y el resultado fue:

La situación del paquete era “PENDIENTE ENTREGA”. ¿Y qué significa eso? O sea, claramente se indica que falta entregar el paquete, pero ¿a quién? ¿al bus que lo va a transportar? ¿a la oficina de Valparaíso? ¿a mi? ¿a alguien más que esté en el camino?

En vano busqué en la web el significado de dicho código. Miré la sección de “Datos útiles”, busqué en otras páginas, incluso usé google para ello, pero nada.

Lo único que pude hacer, resignadamente, fue telefonear a la oficina de Valparaíso para preguntar por el estado del paquete. Entonces escuché a una operadora teclear el código (quizá en la misma página en la cual lo había hecho yo minutos antes) y decirme con voz gangosa “su paquete está acá, tiene que venir a buscarlo”.

De manera que Tur Bus invierte en un sistema para hacer el seguimiento de los paquetes de carga que transporta, el cual, a pesar de su aparente sencillez, tiene un costo no despreciable. Sin embargo, en su construcción se olvida un pequeño detalle: un simple glosario de los estados posibles de un paquete (cuyo compañero perfecto sería un diagrama de estados); ese sí es un costo despreciable, pero por no haber detectado dicha necesidad, seguramente por la sencilla razón de no haber visto la aplicación desde la perspectiva del usuario, su utilidad es nula en el caso de clientes como yo, que no la hemos utilizado más que un par de veces.

Habría enviado un comentario al encargado de la mantención de la aplicación, pero no encontré como contactarlo.

El siguiente es un extracto de un aviso de trabajo publicado por una empresa de informática santiaguina:

Requisitos:
- Conocimiento de J2EE avanzado, JSP
- Conocimiento MySQL

¿Soy sólo yo, o claramente hay una inconsistencia en los requisitos?

Hablando de usabilidad, un ejemplo de mensaje de error confuso (Office 2003):

Perdón, pero… si digo “sí”, ¿estoy aceptando continuar o estoy aceptando esperar?

No costaba nada poner dos botones “Esperar” y “Continuar”, pero de lo poco que he programado en Visual Basic, sé que crear un diálogo con alternativas “sí/no” significa menos trabajo que crear uno con etiquetas genéricas, así que, esta dificultad para el usuario debe ser producto sólo de la flojera de los programadores de Office…