Hola Alex, no entiendo muy bien tu pregunta.
isql lo estamos utilizando sólo como herramienta para verificar conexiones y resultados devueltos para compararlos con lo obtenido en PHP. Después de muchas horas buscando y probando (llevamos dos días dos personas) no damos con la tecla. Hemos revisado lo siguiente: 1. Todos los archivos .php están creadas con la página de códigos utf-8 (sin BOM) 2. Se ha incluido en la cabecera del html <meta charset="utf-8" /> 3. No podemos tocar la configuración del servidor Apache porque hay más webs involucradas. Creemos que está configurado para utf-8 4. La conexión ODBC desde Linux está configurada y funciona: con isql y odbc_connect de PHP 5. En la configuración de la conexión ODBC hemos incluido CCSID = 1208 6. En la extracción de datos desde PHP utilizamos la función utf8_decode(). 7. El trabajo abre conexión con el IBM i y arranca un trabajo QZADSSINIT con CCSID 1145 En las pruebas con isql siempre hemos conseguido obtener las eñes y vocales acentuadas correctamente. En el PHP, cuando extraemos un campo con una eñe o vocal acentuada y incluimos en el html, salta un error 503 del servidor. Como curiosidad, si en el select hacemos un CAST (nombre_campo AS VARCHAR(30) CCSID 1208) AS nombre, el PHP no falla y tampoco aparece el error 503 de http, pero los caracteres eñes y vocales acentuadas no aparecen con el símbolo correcto. En fin, que no tenemos mucha más experiencia en esto. No sabemos si realmente el parámetro CCSID = 1208 de la conexión funciona. No sabemos qué tipo de conversión se está haciendo. No sabemos cómo depurar PHP para intentar atrapar el carácter o "lo que sea" que éste provocando el error 503. Estamos en punto muerto. Saludos, Javier Mora El mar., 27 oct. 2020 a las 17:11, Alex Martínez (<[email protected]>) escribió: > ¿y el archivo que acceder por isql está creado con CCSID 1145 ? > > El mar., 27 oct. 2020 a las 15:49, datil400 (<[email protected]>) > escribió: > >> No es nuestro caso: QCCSID = 1145 >> >> Gracias >> >> El mar., 27 oct. 2020 a las 12:50, Alex Martínez (<[email protected]>) >> escribió: >> >>> Si tienes el valor de sistemas QCCSID con 65535 tienes un problema ¿es >>> vuestro caso? >>> >>> >>> El mar., 27 oct. 2020 a las 11:00, datil400 (<[email protected]>) >>> escribió: >>> >>>> Hola Alex, >>>> >>>> tenemos configuradas dos conexiones: una con SSL y la otra SIN SSL (por >>>> descartar problemas de puertos, certificados, etc.). Estamos casi seguros >>>> que la conexión ODBC está bien configurada. Tomo nota para ver también logs >>>> de http y las opcione de debug. >>>> >>>> Buscando y haciendo pruebas, hemos encontrado que puede estar >>>> relacionado con el CCSID. Si en la consulta SELECT hacemos un CAST con >>>> CCSID(1208) ya no falla la conexión, pero aparecen todas las eñes y acentos >>>> con símbolos raros. Sin embargo, la misma consulta SELECT en isql (CON/SIN >>>> el CCSID) devuelve los resultados correctamente. >>>> >>>> Hemos comprobado también que el meta charset del html sea UTF-8, pero >>>> no conseguimos recuperar correctamente las vocales acentuadas o las eñes. >>>> >>>> ¿Qué se nos escapa? ¿Es un tema de servidor Apache? ¿Es un tema de PHP? >>>> ¿Será el HTML? >>>> >>>> Seguimos buscando. >>>> >>>> Gracias por tu ayuda Alex. >>>> >>>> Javier Mora >>>> >>>> El mar., 27 oct. 2020 a las 10:36, Alex Martínez (<[email protected]>) >>>> escribió: >>>> >>>>> >>>>> Hola >>>>> >>>>> Asegurate que en la pruebas con isql se utiliza SSL >>>>> >>>>> En el servidor revisad las anotaciones del los trabajo QZDASOINIT >>>>> >>>>> Y en el servidor HTTP ¿no tienes ninguna anotación en el logs? >>>>> >>>>> y habilita las opciones de debug de php.ini >>>>> >>>>> El mar., 27 oct. 2020 a las 9:07, datil400 (<[email protected]>) >>>>> escribió: >>>>> >>>>>> Hola a tod@s, >>>>>> >>>>>> estamos desarrollando un aplicativo en PHP que extrae información del >>>>>> IBM i. Se ha desarrollado desde un servidor Windows y funciona >>>>>> correctamente, pero cuando lo trasladamos a Linux empiezan los problemas. >>>>>> >>>>>> En Linux tenemos instalado tanto el driver como la conexión ODBC >>>>>> necesaria, así como los certificados para SSL. Sabemos que está todo bien >>>>>> configurado porque cuando abrimos una conexión con 'isql' y realizamos >>>>>> una >>>>>> petición SQL obtenemos el resultado esperado. >>>>>> >>>>>> La conexión en PHP la realizamos con la siguiente función: >>>>>> >>>>>> function conexionAS400() >>>>>> { >>>>>> global $dsn_as400; >>>>>> global $username_as400; >>>>>> global $password_as400; >>>>>> $as400 = odbc_connect($dsn_as400, $username_as400, $password_as400, >>>>>> SQL_CUR_USE_ODBC); >>>>>> return $as400; >>>>>> } >>>>>> >>>>>> donde $dsn_as400 contiene el nombre de la conexión ODBC. >>>>>> >>>>>> El resultado es un error 503 del servidor HTTP, pero no sabemos cómo >>>>>> averiguar el error que está generando el intento de conexión. >>>>>> >>>>>> En el IBM i comprobamos que se abre una conexión en el puerto 9471, >>>>>> pero hasta ahí llegamos. >>>>>> >>>>>> ¿Alguna sugerencia o idea que nos ayude a descubrir qué pasa? >>>>>> >>>>>> Gracias a todos por vuestros comentarios. >>>>>> >>>>>> Javier Mora >>>>>> ____________________________________________________ >>>>>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>>>>> Forum.Help400 © Publicaciones Help400, S.L. >>>>> >>>>> ____________________________________________________ >>>>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>>>> Forum.Help400 © Publicaciones Help400, S.L. >>>> >>>> ____________________________________________________ >>>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>>> Forum.Help400 © Publicaciones Help400, S.L. >>> >>> ____________________________________________________ >>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 © Publicaciones Help400, S.L. >> >> ____________________________________________________ >> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >> Forum.Help400 © Publicaciones Help400, S.L. > > ____________________________________________________ > Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) > Forum.Help400 © Publicaciones Help400, S.L.
____________________________________________________ �nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 � Publicaciones Help400, S.L.
