Una de las cosas que repito mucho en mi charla de Entendiendo Unicode es que "siempre, siempre, siempre, hay que procesar los textos estando en Unicode, no en bytes, porque se pueden obtener resultados inesperados".
Acabo de encontrar un caso de estos. Lo interesante es que es un caso que no había visto nunca.
Estoy agregando a mi programa Encuentro un nuevo backend: BACUA. Bueno, ya casi está (gracias a la ayuda de Gonzalo Martinez), el tema es que había una página que tenía problemas de Unicode. Me puse a investigar, y resulta que el problema es que se estaba decodificando con el encoding incorrecto.
Se intentaba decodificar con UTF-8, pero como fallaba, se decodificaba con otra cosa, y algunas palabras quedaban mal.
Empecé a ver en detalle, y resulta que la página está toda bien codificada en UTF-8, excepto una parte. La linea "molesta" es esta:
<h5 class="sinopsis_cat">Los Ludomatic, banda de m\xc3\xbasica infantil exitosa en los a\xc3\xb1os 80, se re\xc3\xbane luego de veinte a\xc3\xb1os para ver que sus vidas no son como lo hab\xc3\xadan imaginado tiempo atr\xc3\xa1s. Toni, Becca, Marco, Lupe y Ren\xc3 ...</h5><br/>\r\n'
Como pueden ver, está toda casi bien, en utf8... por ejemplo, dice "Los Ludomatic, banda de música", y ahí vemos que la "ú" está bien codificada en utf8 como 0xC3 0xBA. El problema está al final, en el último nombre. Seguramente debía decir "Toni, Becca, Marco, Lupe y René", pero está cortado (con el agregado de los tres puntos, para indicar continuación).
Y está cortado mal.
Obviamente, si los que generaron la página hubiesen procesado el texto como Unicode, se hubiese cortado antes de la é o después de la é. Pero no, lo manejaron como bytes, donde la é codificada como utf8 es 0xC3 0xA9. Y por mala suerte el corte cayó en el medio de esos dos bytes. Y quedó el 0xC3 suelto, que no es utf8 válido.
Y bueno. Eso. Recuerden: Siempre hay que procesar los textos como Unicode.
