Saltar al contenido Navegación Ir a buscar

Actualizaciones ocasionales en inglés, mayormente sobre programación, ocasionalmente de fútbol.

UTF-8

Antes o después tendría que acabar por escribir sobre el tema. Más si consideramos la de horas perdidas tratando de buscar una solución alternativa1.

Pongamonos en antecedentes: no es la primera vez que alguien comenta que en tal o cual herramienta de gestión de contenidos – Textpattern incluido, por supuesto – le aparecen unos caracteres extraños con cirulitos, arrobas y más cosas raras que justo están donde deberían los acentos y las tildes de las eñes.

Esos caracteres extraños son, sencillamente, el resultado de mostrar un documento guardado como utf-8 con un juego de caracteres distinto – probablemente iso-8859-1, que es el más común por estos lares.

El problema puede estar en dicho sistema de publicación, o puede que dicho sistema de publicación haya abordado el problema del modo más lógico2 y haya decidido emplear como codificación, para todo el mundo mundial utf-8. ¿Por qué?. Simplemente porque es la única solución a los problemas de todos, de una vez.

Desde ese momento, el problema pasa al usuario responsable del hosting: si empleas un sistema que requiere el uso de utf-8 – cualquiera que tenga cierta vocación internacional lo hará – tu servidor debe indicar claramente que el contenido emplea ese juego de caracteres.
Como ya hemos comentado anteriormente2 no debería resultar excesivamente complejo añadir la línea necesaria a un simple .htaccess, de no ser por la – también mencionada3 – manía de los proveedores nacionales de hosting de emplear por defecto iso-8859-1 – lo cual no es del todo descabellado – y no permitir que se sobre-escriba dicha regla; (es más, si la seguridad de tu hosting se basa en la imposibilidad de sobre-escribir las configuraciones del servidor, mal empezamos).

Existe un excelente artículo de Sam Ruby al respecto: Iñtërnâtiônàlizætiøn – exacto, el mismo que aloja en su web el wiki de Atom y la mitad del equipo de desarrollo del Feed Validator – que ha vuelto a poner en evidencia ciertas pretendidamente maravillosas novedades, precisamente por lo mismo: carencia de soporte para utf-8.

Hace bastante tiempo que lo tengo claro: igual que a mi me gusta que los anglo parlantes consideren que hay quien no escribe en inglés, habrá quienes escriban en otros juegos de caracteres – mencionaremos el cirílico, por no hablar de las variantes del chino – a quienes les gustará saber que nosotros también les consideramos a ellos.

La solución utf-8 es la única que se sabe es válida para todos los casos. De hecho, es la codificación de Typepad – y nadie va a enseñar, a estas alturas, a programar a Ben Trott – y de un cliente RPC de lo más decentito que he podido probar: ecto.

Y no hay otra posible. Ni mejor. Y en esto acepto apuestas.

Que lo de la globalización tiene estas cosas.

1 Character encodings.

2 i18n.

3 Atom en IETF.

12/03/05 12:38 a.m.

  1. Yo no se si aporto un recurso demasiado trillado, pero quiero mencionar aquí la excelente introducción a Unicode de Joel on Software.

    Un saludo.
    Juanjo Navarro    12/03/05 01:23 a.m.    #
  2. Uy!, demasiado trillado dices ;-). Lo que escibe este hombre debe ser tratado casi como texto sacro.

    Ah!, la memoria y los años…
    kusor    12/03/05 01:38 a.m.    #
  3. Pues no acabo de ver dónde está el problema, quizás porque edito manualmente mi bitácora.

    ¿No sería más lógico que el CMS permitiese elegir el juego de caracteres seleccionado? Una vez seleccionado, lo indica en la cabecera y el navegador lo entenderá, o debiera.

    El problema tal vez esté cuando queremos migrar un texto de un juego a otro. En tal caso, ¿no es mejor mantener los antiguos con su juego y utilizar el utf-8 en los nuevos contenidos?

    Es decir, para mí el problema está en el navegador utilizado. K-MeleonCCF Nauscópico no tiene problema alguno para visualizar páginas en ruso, chino, indio o árabe (justo acabo de implementar un traductor árabe -> inglés, que subiré próximamente).

    Como tantas otras cosas, soy autodidacta, voy resolviendo/estudiando los problemas con la bitácora cuando se van planteando. Debería tener más apoyo teórico.

    Ah, tal vez la ventaja del UTF-8 resida en que en una misma página puedan aparecer textos en cirílico, chino y latino.

    Ilumina a este alumno tuyo.
    maty    12/03/05 09:17 p.m.    #
  4. Bueno, maty. En realidad el mayor problema es cuando hay una incompatibilidad entre lo que el CMS admite y lo que tu apache admite.

    Así, si tu CMS trabaja en modo UTF-8 y tu apache trabaja por defecto en iso-8859-1, pues habrá problemas de caracteres extraños.

    Otro problema relacionado es el de los literales propios del CMS (no los de los datos de la BBDD). Así, por ejemplo, Textpattern tiene los literales en castellano en UTF-8 (con esto quiero decir, los propios textos que emite el CMS como “Buscar”, etc). Aunque pongas el CMS en modo iso, y pongas el apache en modo iso y pongas la bbdd en modo iso, esos literales seguirán saliendo mal.
    Juanjo Navarro    13/03/05 08:57 p.m.    #
  5. Quiero hacer mi aporte a este tema de la internacionalización de los CMS, en particular del TXP.

    Yo soy uno de esos que andan quejándose por ahí porque el TXP, en la BBDD, no guarda las tildes como tildes ni las eñes como eñes…
    Por el contrario, TXP guarda esos caracteres con circulitos sobre una A, o arrobas o cosas raras...

    Yo me pregunto si en el caso del TXP es posible hacer lo siguiente:
    que TXP convierta cualquier tilde o eñe a su entidad HTML correspondiente.
    Por ejemplo, si ingreso una ’á’, me gustaría que TXP (si es que el ‘trabajo’ le corresponde a TXP) lo guarde (en la bbdd) como ‘& aacute ;’ (sin los espacios), o si escribo una ’ñ’ que lo guarde como & ntilde ;

    Alguno se preguntará: ”¿Y por qué no escribís tus artículos (o cualquier otro input en TXP, como “Site Name”) directamente con entidades HTML en vez de usar las tildes o las eñes, así ?”

    Lo he intentado en TXP.
    ¿Resultado?
    La primera vez que lo guarda, lo guarda bien en la BBDD. Obviamente, simplemente guarda la sucesión de caracteres que forman la entidad HTML -> & a a c u t e ; (sin espacios).

    Ahora bien, supongamos que quiero editar el artículo (o cualquier otro input, como el “Site Name” en TXP) en el que anteriormente había ingresado una entidad HTML.
    ¿Qué pasa?

    Por lo pronto, TXP no me devuelve las entidades HTML que yo había tipeado originalmente.
    Por ejemplo, si yo había tipeado ‘& aacute ;’ en un artículo y ahora quiero editar ese artículo, el TXP no me devuelve el artículo con las entidades HTML…
    Por el contrario, ¡me devuelve los caracteres especiales! Es decir, el ‘& aacute;’ en la BBDD, se convierte en ’á’ en el editor de artículos.

    ¿Cuál es el problema?

    Si vuelvo a guardar el artículo o cualquier otro input (que ya no tiene entidades HTML, sino que son tildes y eñes nuevamente) vuelve a guardarse como caracteres con circulitos, arrobas, cosas raras…

    En otras palabras, si quiero editar algo y no me tomo el trabajo de retipear todaslas entidades HTML, van a quedar “mal” grabadas en la BBDD.

    Yo no tengo problemas en escribir con entidades HTML, pero si TXP me va a estar cambiando cada entidad a tilde, y cada tilde a cosa rara, pues me voy a volver loco.

    Dios, no sé cómo explicarlo de otra manera, por eso no lo posteo en los foros de TXP, ya que si tanto me cuesta en español, no me quiero imaginar lo que me va a costar explicarlo en inglés. Y es muy problable que la mayor parte de la comunidad de TXP, que escribe sus sitios en ingles, no sepa de lo que le estoy hablando.

    Por último, creo que esta imagen es elocuente:

    http://www.midi-midi.com.ar/img/txp_page_title_google_results.gif
    Es una captura de pantalla de una búsqueda en Google, donde aparece el título de mi sitio (sitio administrado con TXP).

    Así es como Google lee las tildes y las eñes en páginas generadas por TXP

    Nadie quiere que su página aparezca indexada así en Google…

    Espero que la v.1.0 de TXP ofrezca una solución a este dilema de los caracteres.
    O por lo menos, sugerír cuál sería la solución del lado del servidor (es decir, qué regla hay que reescribir en Apache, qué hay que pedirle a nuestro querido hosting…).

    Kusor, por favor, si no se entiende lo que intento explicar, por favor, escribime e intentare ampliarlo.
    Agradezco tus iluminaciones diarias y vuelvo a felicitarte por integrarte al team de TXP. Saber que hay alguien que habla español en el equipo… me deja más tranquilo.
    Maniquí    17/03/05 08:52 p.m.    #
  6. Por cierto, mi hosting me acaba de informar que su servidor Apache está configurado como…

    ISO-8859-1

    Yo alguna vez tiré un “buscar y reemplazar” cualquier referencia a UTF-8 en TXP.
    Lo reemplacé todo por ISO-8859-1… los resultados realmente no fueron buenos…

    Prefiero ir convirtiendo todo a UTF-8…

    ¿Cómo hago para reconfigurar a UTF-8 mi virtual server con una simple línea desde el archivo .htaccess ?
    Maniquí    17/03/05 09:02 p.m.    #
  7. Guardar entidades HTML en la BBDD tiene el problema de que son entidades HTML y solo se entienden si estás trabajando con HTML. XML solo acepta 3 entidades que no sean numéricas, por ejemplo. Cualquier otra la tienes que definir tu en la DTD.
    Y si trabajas con datos que no sean HTML o XML, tu única opción es guardar el texto en UTF.
    Por cierto, no estoy de acuerdo con que UTF-8 sea la única opción válida, solo la más conveniente. UTF-16 es menos ambiguo que UTF-8, sin embargo, los carácteres normales en UTF-8 se codifican igual que en Latin1 o igual que en ASCII de toda la vida. Esa es la ventaja de UTF-8. Pero, si tu configuras tu navegador o servidor para usar UTF-16, tu texto en UTF-8 no se verá correctmente.

    Ah! y el hecho de que Ben Trott sea buen programador es ortogonal a que sepa que codificación escoger. Una cosa es escoger un algoritmo y otra un encoding. IMHO, claro.
    victor    18/03/05 06:34 p.m.    #
  8. (perdón por el off-topic)

    felicidades por tu aparición en terra1 (aunque deberías pedirles que corrigieran tu nombre… ;))

    [1] http://www.terra.es/tecnologia/articulo/html/tec12296.htm
    sergio    23/03/05 09:32 a.m.    #
  9. Maniquí, sigo pensando que TXP no tiene ningún problema con los caracteres. Yo tengo un TXP instalado y a mi me salen las páginas bien, en la bbdd me salen bien los caracteres y google lo indexa bien.

    Como ejemplo, busca en google “folcsonomías kusor.net” y verás como lo ha indexado perfecto.

    Se trata simplemente de que pongas el apache y la bbdd en modo UTF-8 y todo te funcionará perfecto.

    Un saludo.
    Juanjo Navarro    23/03/05 06:04 p.m.    #
  10. Juanjo Navarro, me alegro al saber que te funciona bien el TXP (eso significa que… ¡hay esperanzas!).

    Es más, veo que te aparecen bien los datos en la bbdd, así que toda mi teoría se va al c***jo.

    Seguramente, y como bien me iluminó Kusor, los caracteres se guardan “mal” (= de forma extraña) en mi bbdd por el tema de que mi hosting está configurado como iso-8859-1 y no como utf-8.

    (Y ahora que releo tu post, vos también sugerís la misma solución… :D )

    Voy a ver si desde el .htaccess puedo agregar una línea que me pasó Mr. Kusor y veremos qué es lo que sucede… (danger!)

    Gracias y saludos!
    Maniquí    29/03/05 09:00 p.m.    #
  11. Yo acabo de instalar Txp y estoy muy contento. He importado todos los post desde wordpress, que tenia con codificación iso-8859-1 y ahora se me ven interrogaciones en vez de tildes :(.
    superporcel    30/03/05 12:57 a.m.    #
  12. Pusiste “cirulitos” en vez de “circulitos” XDDD
    argie01    30/03/05 09:08 a.m.    #
  13. Sr. Kusor: me tomo el atrevimiento de solicitarle por la presente que cuando pueda le eche un ojo a esto: http://gattaca.com.ar/weblog/archivos/2005/04/06/iso-8859-1-vs-utf-8-la-batalla-continua/
    Muchas gracias.

    ¿Textpattern no maneja trackbacks?
    HighToro    08/04/05 02:38 a.m.    #