Gracias Alex, estamos trabajando con estos enlaces. Cómo vamos con retraso en el desarrollo, vamos a seguir por el camino del ccsid en el select.
A ver qué sale. Un saludo Javier Mora El mié., 28 oct. 2020 10:29, Alex Martínez <[email protected]> escribió: > Hola de nuevo > > tampoco voy muy sobrado de tiempo pero mírate este enlace, por ejemplo, > aunque el desarrollador de php igual lo conoce > > el caso es que mbstring no viene por defecto configurado en php y ayuda en > las conversiones de caracteres > > https://www.php.net/manual/es/mbstring.installation.php > > > https://stackoverflow.com/questions/1605760/how-to-best-configure-php-to-handle-a-utf-8-website > > > > El mié., 28 oct. 2020 a las 8:55, datil400 (<[email protected]>) > escribió: > >> 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. > > ____________________________________________________ > Ú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.
