ABCD - versiones bases de datos

Para Windows

charset	Versión Cisis
ansi	16-60 bigisis ffi
utf8	16-60 ffi

Para Linux

charset	Versión Cisis
ansi	16-60 bigisis ffi
utf8	16-60 bigisis

Entonces, en el caso de las versiones 1660-ansi y 1660-utf8, que para simplificar llamaremos ansi y utf8, el charset se puede derivar de la versión. En el resto de los casos hay que especificar el charset.

Si esto es así, yo eliminaría la variable UNICODE y me quedaría solo con $cisis_ver y $charset. En código del config.php desarrollaríamos la lógica para generar $charset a partir de UNICODE. Veríamos que código incluir para asegurar la compatibilidad con las instalaciones ya existentes.

abcd.def

Se eliminaría el parámetro UNICODE y dejaríamos cisis_ver y charset. Podemos proveer un algoritmo para generar estas variables a partir en las instalaciones ya existentes

El parámetro MULTIPLE_DB_FORMATS no se si valga la pena mantenerlo. En lo único que ayuda es en evitar lecturas innecesarias del dr_path.def cuando todas las bases de datos usan la misma versión del Cisis. No se si este ahorro sea relevante.

dr_path.dat

Al dr_path.dat se le agregarían los parámetros $cisis_ver y charset y pueden desaparecer wxis_get y wxis_post.

Me parece mejor definir el request method tal como lo haces ahora en la versión 2.0, a través del config.php. Tal vez ese parámetro lo podamos agregar en el abcd.def

Yo creo que en esta forma todo quedaría más claro. El asunto sería desarrollar los algoritmos para asegurar la compatibilidad con el abcd.def y el dr_path.dat de las versiones anteriores.

HTML - Content-Type

Hay una tercera variable importante que viene del php.ini y se denomina default_charset que en algunos servidores viene como UTF-8 y en otros como ISO-8859-1. Si es UTF-8 entonces hay que incluir el comando 

     header('Content-Type: text/html; charset=iso-8859-1'); 

en el config.php del módulo central para aquellas instalaciones que trabajan con lenguajes latinos porque los mensajes del sistema están en iso-8859-1 y no en utf-8. Igual ocurre con las bases de datos que se han desarrollado usando 1660-ansi. Por eso es que a veces reportan que los caracteres aparecen distorsionados.

Este comando se debe incluir en el config.php porque todos los scripts lo leen al principio y ese debe ser el primer comando de la página generada. Entonces, se leería la variable default_charset del php.ini y según el charset definido para la base de datos generar el header correctamente. Esto tiene relación con el encoding de la página el cual debe coincidir con el charset de las bases de datos que debe ser igual al de los archivos y demás páginas que se muestran tanto en central como en OPAC-ABCC.

En wxis_llamar.php se agregó una rutina que convierte los datos de ANSI a UTF-8 según el charset de la base de datos. Aunque está prevista la conversión de UTF-8 a ANSI esta no se recomienda porque los resultados son inesperados.

       $cset=strtoupper($charset); 
       if (!isset( $charset_db)or $charset_db=="") $charset_db="ANSI";
       $cset_db=strtoupper($charset_db);
       if ($cset_db!=$cset){
          foreach ($contenido as $value) {
              if ($cset=="UTF-8" and $cset_db=="ISO-8859-1"){
                   $cont_cnv[]=utf8_encode($value);
              } else{
                    $cont_cnv[]=utf8_decode($value)
              } 
          }
          if (isset($cont_cnv) and count($cont_cnv)>0) $contenido=$cont_cnv;
       }
               

1. Se lee el charset de la página ($cset=strtoupper($charset))
2. Se lee el charset de la base de datos, $charset_db, (leído del dr_path.dat). Si no está definido se asume ANSI
3. Si el charset de la la base de datos no es igual al charset de la página se convierte la salida del wxis ($contenido) al charset de la página