Hola Alex, gracias por tus aportaciones. Nuestro problema con todo este tinglado en la falta de experiencia y conocimiento sobre el tema. Está mi compañero que es el desarrollador del aplicativo PHP, está la empresa que comparte con nosotros la gestión y mantenimiento de toda nuestra infraestructura y estoy yo que soy el especialista (si se puede decir así) del IBM i.
Cuando digo "que no podemos tocar" es un símil de "no sabemos hacerlo y podemos romper algo". Te contesto a tus preguntas: 1. La vista con la que estamos haciendo las pruebas apunta a una tabla con CCSID 1145. El trabajo que se abre en QZDASSINIT también tiene CCSID 1145. 2. Durante toda una mañana nuestra empresa colaboradora estuvo buscando en los logs de Apache, pero como no teníamos muy claro que buscábamos tampoco encontramos ninguna pista. Aquí asumimos que el servidor Apache está configurado para utf-8. 3. Tenemos claro que el meta charset afecta al html final servidor y a efectos del cliente (cómo se visualiza en el navegador). 4. Hemos estado buscando ejemplos e información sobre el php.ini a ver qué encontramos para compararlo con el nuestro. Tampoco sabemos qué es "mbstring" ¿algún ejemplo? Después de mi último correo hemos realizado, de nuevo, algunas pruebas. El problema es que hemos probado tantas cosas que estamos en un punto que no tenemos claro si lo hemos probado todo. Tengo mis dudas de que el parámetro CCSID de la conexión ODBC esté teniendo efecto (o tampoco entendemos su función). Yo entiendo que tiene que estar convirtiendo todos los datos char/varchar al CCSID indicado en la petición de PHP. Digo que no tiene efecto porque después de una petición similar a esta: SELECT CAST( campo VARCHAR(30) CCSID 1208) AS nombre FROM CENTROS y eliminar del PHP el utf8-decode() sobre ese campo, los datos parecen que se recuperan correctamente. Si quitamos el CAST+CCSID y sin ningún utf8_decode()/encode() todo vuelve a fallar. Yo creo que hemos utilizado incorrectamente estas funciones. De momento estamos tirando por este camino. Se nos acaba el tiempo. Una vez más, gracias. Javier Mora El mié., 28 oct. 2020 a las 7:43, Alex Martínez (<[email protected]>) escribió: > Hola Javier > > No hice correctamente la pregunta.... y se escapó el "enviar". Me refería > a si has comprobado con un DSPFD el CCSID de los archivos ¿es 1145? > > Para un error 503 lo primero que revisaría son los logs de apache y no > entiendo que no se pueda tocar la configuración de apache, ya que puedes > tener múltiples configuraciones para host virtuales. > > Y sobre los puntos que comentas, aunque se haya configurado utf-8 en las > cabeceras de html esto solo afecta al código estático de las páginas > ¿correcto? > > No comentas nada de php.ini ¿tambien está configurado para utf-8 ? y no > entiendo porqué utilizas utf8_decode() si tienes configurado mbstring de > php para trabajar con utf-8 ¿o no? > > Creo que no me dejo nada > > Salu2 > > El mar., 27 oct. 2020 a las 18:05, datil400 (<[email protected]>) > escribió: > >> 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. > > ____________________________________________________ > Ú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.
