Recientemente migramos a la version 2.7 de Guaraní. También actualizamos a la versión 2.7 el portal web Guaraní 3W (El código fuente PHP)
El error que se nos presenta es que cuando algún alumno entra y quiere actualizar sus datos censales en las listas desplegables las cadenas de texto que tienen acento no se muestran (Por ejemplo se visualiza la respuesta “NO” pero no se ve la opción “SÍ” solo el campo en blanco, en el adjunto se ve mejor)
Nuestra instalación de G3W:
Debian 7.0 Wheezy
PHP 5.4.4
ODBC 2.2.14p2-5
Informix client: 4.10.UC1DE
DB: Informix 9.21 sobre Windows Server 2003
Al parecer el problema se da entre Informix y ODBC por diferencias en los charsets del cliente y de la base de datos. Mirando la base de datos con “select * from sysmaster:sysdbslocale” resulta que la base de datos del Guaraní está en “en_US.1252”
El odbc.ini tiene etos valores de charset para cliente y DB:
DB_LOCALE=en_us.1252
CLIENT_LOCALE=en_us.8859-1
Las mismas variables están seteadas para Apache.
¿Alguien podría orientarnos dónde puede estar el problema?
El problema ocurrió al actualizar a 2.7. Lo extraño es que los campos desaparecen por completo, la opción está pero es una cadena vacía.
Gracias por tu respuesta. Podrías ser más específico con el tema de los templates, porque nosotros no tocamos nada de los templates. Solamente descomprimimos el paquete del Guarani 3W y modificamos paramatros.inc. Nada más por eso me extraña que nos ocurra este problema.
Si.
el punto es de encoding pero de los archivos.
vos tenes guardado en el disco de tu máquina una archivo que contiene una “á”. Lo que realmente tenes es un ascii(160) que el sistema lo interpreta de acuerdo al encoding que haya. El sistema operativo puede tener uno distinto. El php otro.
El consejo es modificar esos acentos que van a html por los códigos html, en este ejemplo á por á
Con ello no tendras problema con ningun juego de caracteres.
Sí, era un problema de codificación pero no de los templates. Las opciones que salen en las listas desplegables aparecen en el archivo www/a_alumnos/formularioDatosCensales.php, allí estaban las opciones con acento y las cambié a códigos de HTML.
Lo mismo no entiendo por qué no se veía en absoluto la cadena, cuando el problema era con un solo caracter. Generalmente cuando hay problemas de codificación se muestra el caracter acentuado con un código extraño. En este caso el código HTML producido contenía dentro del un pero con una cadena vacía. Así que problema de codificación de HTML no es.
Sigo pensando que el problema debe ocurrir en alguna parte del proceso de creación de los templates de Smarty. Alguna función debe estar “saneando” los strings que no le gustan y suprime por completo la cadena de texto.
Alguien en la sala que pueda dar una pista al respecto?
vos tenes un problema con el PHP 5.4.4.
la funcion htmlspecialchars cambia el encoding por defecto que tenía.
el guarani esta hecho para iso-8859-1 que es lo que tenía antes la funcion php.
en php5.4 se cambia a utf-8 con lo cual deberás modificar todas las apariciones de htmlspecialchars agregándole el encoding (que es el tercer argumento).
Sí, es cierto, desde la versión 5.4.0 la versión por defecto del encoding que produce la función htmlspecialchars es UTF-8, lo que es raro es que la cadena que se produce está vacía, incluso cuando se muestra el código fuente la cadena de texto sencillamente no existe. No se trata de que se produce un string en UTF-8 y luego en el header de la página se declara el encodign como ISO-8859-1 y por lo tanto el browser lo parsea mal.
El "vaciamiento " de las cadenas con caracteres no ingleses debe estar en otra parte. Por otro lado si el encoding es importante, debería haber una parámetro a nivel de Guaraní para especificar qué encoding se va a usar. No me parece muy correcto que digamos tener que “hardcodear” el encoding.
Si el string de entrada contiene una secuencia de unidad de código no válida en el parámetro encoding dado, se devolverá un string vacío, a menos que cualquiera de las banderas ENT_IGNORE o ENT_SUBSTITUTE estén establecidas.
$ file charset.php
charset.php: PHP script, UTF-8 Unicode text
Se guardó en UTF-8 el script de prueba charset.php con el código que me pasaste.
Lo mismo el script no genera los headers HTML donde se especifica el encoding que tiene que interpretar el navegador. Por eso creo que cuando lo fuerzo a UTF8 desde las opciones del navegador la primera aparición de la cadena “está” se ve bien, con sus acentos y todo y la segunda no sé por qué no se ve bien. Sospecho que vuelve a codificar UTF-8 en UTF-8 y por eso se ve mal, no sé, son solo conjeturas.
Lo mismo la cita que me pasas de la página de PHP lo aclara bien, sobre el tema de las cadenas vacías que es lo que está pasando.
De cualquier forma creo que la gente e Guaraní debería tener en cuenta este detalle y hacer la instalación independiente del charset. Se podría verificar de forma dinámica la versión de php de la instalación y setear la variable del charset de acuerdo a dicha verificación.
