Esto es lo que pasa cuando tienes entornos que no son homogéneos y cada aplicación se encuentra ubicada en distintas márgenes de un "río virtual", en una ribera las más antiguas soportando por defecto el viejo ISO-8859-1 y en la otra, un poco más actualizadas a los tiempos modernos, las que incluyen el soporte de UTF-8.En un mundo ideal, donde todos los servidores y las estaciones de trabajo se actualizan a la par, contemplando los últimos cambios tecnológicos, obtendremos con el uso de UFT-8 la posibilidad de trabajar con cualquier tipo de "caracteres especiales", incluyendo los famosos "tildes" (que abundan en nuestro castellano) sin tener que usar "codificaciones html" para representarlos.
¿Quién no sufrió tener que escribir "día" y "año" para representar "día" y "año"?
En el mundo real, obviamente, sucede todo lo contrario: tu estación de trabajo puede estar con la última versión de tu sistema operativo y aplicativos, y todas ellas usarán desde hace pocos años por defecto el juego de caracteres UTF-8...
PERO... como es lógico y habitual, los servidores no se acostumbran a actualizar a la par de la tecnología (al menos no completamente de cero), puesto que si brindan servicios (que generalmente son siempre críticos) actualizar completamente un software de base o sus aplicativos sin una justificación fundamentada sería arriesgarse a que algo pudiera dejar de funcionar.
Eso lleva a que es completamente habitual encontrar que existen diferencias en las versiones de software entre desarrolladores y sus propios servidores, lo cual hay que tener en cuenta que al editar un archivo con formato ISO que incluye tildes y caracteres especiales escritos sin usar codificación html y grabarlos en una herramienta que use UTF-8 genera la pérdida completa de los mismos.
Existen muchas alternativas para paliar estos problemas:
- Usar utilidades que tomen archivos en formatos ISO y los transformen en formato UTF, con la única contra de que no se podrá aplicar si los servidores son antiguos y desconocen el nuevo formato,
- Migrar los servidores y las aplicaciones para unificar el formato de caracteres, pero raramente este tipo de problemas es razón suficiente para poner en riesgo toda una instalación de servidores (web, base de datos, servidores de aplicación, etc).
- Codificar internamente todos los caracteres especiales (tildes, símbolos, etc) con su correspondiente representación en "código html", lo cual si no encontramos un editor que nos ayude a trabajar de forma transparente con ellos, nos obliga a hacerlo "a mano", con todos los caracteres. La otra contra posible es que si mañana se unifica todo a formato UTF, perderíamos la posibilidad de usar libremente cualquier caracter, lo que deberíamos entonces buscar algo que lo traduzca al nuevo formato.
- Cambiar a todas las aplicaciones que usan por defecto UTF-8 al antiguo ISO-8859-1 para que nuestros archivos en este último formato no pierdan todos los caracteres especiales.
Esta última es la opción generalmente más elegida.
En el caso concreto de EclipseHace mucho tiempo que el
IDE Eclipse (el cual uso para
desarrollar con PHP5) usa por defecto UTF-8, y en su momento he tenido varios problemas para cambiar "completamente" todos los lugares donde hace referencia a este juego de caracteres (sí, en más de un lado):
- En la "configuración general" con qué formato editas los archivos.
- El formato con el cual se graba el archivo.
Todavía no me cierra porqué se podría querer editar en un formato y grabarlo en otro, pero bueno, alguien tal vez lo pueda necesitar.
A pesar de estos cambios, los caracteres se seguían perdiendo. También hay que cambiar en:
- Configuración -> Content Type, y para cada tipo de archivo donde diga "Default Encoding":
Por ejemplo, tenía en mi configuración por defecto:
- Java prefs = "ISO-8859-1"
- Javascripts = "US-ASCII"
- XML = "UTF8"
- DTD = "UTF8"
La mayoría dice UTF8, pero...
- HTML = "vacío"
- PHP Source File = "vacío"
Que asumo se debería tomar "alguna configuración general", pero al haberlas -creo- cambiado todas, les agregué el valor "ISO-8859-1".
Hasta ahora no volví a perder ningún tilde.
ResumiendoTodo esto no sucedería si todos los aplicativos trabajaran con el mismo juego de caracteres, en particular UTF-8, el cual permite insertar caracteres especiales de forma directa y no a través de un código particular que después será traducido por el navegador de turno.
También, según como codifiques los caracteres, tienes distintos tipos de problemas:
- Si en ISO usas literalmente los caracteres especiales, en UTF se pierden (quedan convertido en "basura").
- Si en ISO usas los "códigos html" que corresponden con los caracteres especiales no se pierden al pasar a UTF, pero en algún momento deberás cambiarlos a caracter literal para poder sacarle provecho al formato.
- Que no solo depende del editor de turno que formato usa, también del servidor.
Y que en Eclipse hay muchos lados para cambiar esta configuración, lo cual debo recordar para volver atrás en algún momento futuro.
Un detalle sobre PHP6 y UTFEn
muchos lados se comenta como "la panacea " que la nueva versión de PHP, la versión 6,
será 100% compatible con UTF-8 (sus funciones, el manejo de información de salida y entrada, etc), lo cual siempre me dio la impresión de algo menor (habiendo tantas otras cosas del lenguaje que se podrían agregar,
como los namespaces). También me había sorprendido que decían que el trabajo era "una obra titánica" por la cantidad de código que tenían que modificar para incorporar ese soporte...
...pero luego de vivir este tipo de problemas y saber que hace mucho tiempo todas las aplicaciones recientes lo usan, y que de aquí en más se soluciona cualquier problema de caracteres (por lo que tengo entendido podríamos escribir directamente en japonés y debería soportarlo sin más)...
... ahora comprendí cuan grave y necesario es (aunque sigo pensando -de terco que soy-
que "namespaces" debería estar en esta versión).
