¿Por qué una transcripción exportada muestra caracteres raros en el iPhone?

Es un tipo de fallo concreto y desconcertante: la transcripción se ve perfectamente normal en la app, se exporta sin ningún error, y luego un nombre en ucraniano o una palabra en hebreo sale al otro lado como una fila de signos de interrogación o casillas vacías en cuanto se abre en otro sitio — un portátil con Windows, un programa antiguo, la importación de una hoja de cálculo. Nada de eso parece una errata o un fallo de reconocimiento. Parece que el archivo se rompió por el camino, que es una sospecha razonable y casi nunca lo que ha ocurrido en realidad.

Qué es en realidad un archivo de texto, por dentro

Un archivo de texto plano no lleva ninguna etiqueta dentro que diga qué alfabeto representan sus bytes. Es solo una secuencia de bytes, y cada programa que lo abre tiene que suponer una correspondencia entre esos bytes y las letras y símbolos que te muestra — una codificación de caracteres. Si acierta con esa suposición, el archivo se lee tal cual se escribió. Si se equivoca, el programa no se está inventando nada: está mostrando fielmente el carácter equivocado en cada byte donde su suposición y la codificación real del archivo no coinciden.

Casi todo lo escrito para iPhone, Mac, Android o la web moderna hace la misma suposición: UTF-8, una única codificación capaz de representar cualquier escritura que un iPhone pueda transcribir — hebreo, el cirílico del ucraniano y el ruso, caracteres chinos, el silabario y los kanji japoneses, el hangul coreano, y cualquier letra acentuada del francés, el español o el portugués. Es lo más parecido que tiene el texto hoy a un estándar universal, precisamente por lo que este problema es ahora mucho más raro de lo que era, y también por lo que sorprende las pocas veces que aparece.

Por qué se rompen solo algunas palabras

La pista de que esto es un desajuste de codificación y no un error de transcripción está en qué caracteres sobreviven. Las letras normales, los números y la puntuación corriente se representan igual en UTF-8 y en casi cualquier codificación antigua que todavía se use — esa coincidencia es deliberada, viene de hace décadas, y es la razón de que una frase en español sin tildes pase intacta por casi cualquier programa que suponga mal la codificación. Son precisamente los caracteres en los que esas codificaciones no coinciden — una é o una ñ, y cualquier escritura no latina — los que salen como un signo de interrogación, una casilla o una fila de símbolos sin relación con el original. Si toda la transcripción sale ilegible de principio a fin, el problema está en otra parte; si solo se rompen las tildes y las palabras en otro alfabeto mientras el resto se lee bien, ese patrón es la firma concreta de un desajuste de codificación.

Así se distingue también de un reconocedor que simplemente se equivoca con una palabra. Una palabra mal transcrita sigue siendo una palabra real y plausible — el reconocedor oyó algo y escribió su mejor suposición, equivocada pero coherente. Un carácter roto no es ninguna suposición: no tiene relación con lo que se dijo, aparece siempre exactamente igual de roto cada vez que se repite esa secuencia de bytes, y es una propiedad de lo que está mostrando el archivo, no de lo que la app escribió realmente en él.

Dónde sigue apareciendo esto, ahora que UTF-8 es el estándar en casi todas partes

Las apps modernas de uso general casi nunca provocan esto solo con abrir un archivo de texto — Notas, Mail, Mensajes, un navegador o un procesador de textos en un teléfono u ordenador actual leen UTF-8 correctamente sin que hagas nada. Donde una suposición equivocada todavía aparece es más bien al entrar en una herramienta más concreta: el cuadro de "importar archivo de texto" de una hoja de cálculo que ofrece elegir codificación y por defecto trae una regional en vez de UTF-8, o un script o programa antiguo construido asumiendo una codificación de un solo byte, solo para el alfabeto latino, porque quien lo escribió nunca esperó que la entrada llevara nada más. La transcripción en sí no tuvo la culpa en ninguno de los dos casos — el desajuste ocurre justo en la puerta concreta por la que pasó.

Arreglar la copia concreta que lo muestra

La transcripción original, la que sigue guardada en la app que la generó, no se ve afectada por nada de esto — solo esa copia exportada, leída por ese programa que supuso mal, se muestra incorrectamente. Eso apunta directo a la solución: volver a abrir el archivo y decirle explícitamente al programa qué codificación usar, donde ofrezca esa opción. Un editor de texto con un comando de "volver a abrir con codificación", o el asistente de importación de una hoja de cálculo con un desplegable de codificación, permiten elegir UTF-8 directamente en vez de aceptar lo que el programa supuso por defecto. Si la herramienta no ofrece ninguna opción de ese tipo, volver a exportar desde el origen y pegar el texto directamente en el destino, en vez de abrir el archivo guardado, evita la suposición por completo — pegar traslada los caracteres reales, sin ninguna interpretación del archivo de por medio.

Cómo lo gestiona Voice Studio

Tanto la exportación en TXT como en JSON escriben texto plano en UTF-8, la misma codificación que ya asume prácticamente cualquier herramienta actual de iOS, Mac, Android o la web al abrir un archivo — una transcripción en hebreo, ucraniano, chino, japonés, coreano o en francés o español con tildes se abre correctamente en la inmensa mayoría de los sitios donde es probable que acabe. Si un destino concreto sigue mostrando los caracteres equivocados, eso es un hecho sobre lo que está leyendo el archivo ahí, no sobre lo que se escribió en él — decirle a ese programa que lea el archivo como UTF-8, donde te deje elegirlo, es lo que realmente lo soluciona. Nada de este fallo de visualización al abrirlo afecta a la transcripción que sigue en la app, que se queda exactamente como se transcribió.

Preguntas frecuentes

¿Significa esto que la transcripción se equivocó con la palabra?

No. Una palabra mal transcrita sigue siendo una palabra real, solo que la equivocada. Los caracteres rotos — signos de interrogación, casillas o símbolos sin relación con el original — son un programa leyendo el archivo con la codificación equivocada, un problema completamente distinto al de que el reconocedor oyera mal algo.

¿Por qué se rompen solo algunas letras y no toda la transcripción?

Las letras normales, los números y la puntuación corriente se representan igual en UTF-8 y en casi cualquier codificación antigua, así que se leen bien sin importar cuál suponga un programa. Son precisamente las letras con tilde y las escrituras no latinas — donde las codificaciones no coinciden — las que salen mal.

¿Está dañada mi transcripción si veo esto?

No. La transcripción dentro de la app no se ve afectada — esto le pasa a una copia exportada concreta, en el programa que la abrió con la suposición equivocada. Volver a exportarla o reabrir esa copia con la codificación puesta en UTF-8 lo arregla.

¿Cómo arreglo una transcripción que ya muestra caracteres rotos?

Vuelve a abrirla en un programa que te deje elegir la codificación explícitamente y elige UTF-8, si esa opción existe. Si no existe, vuelve a exportar la transcripción desde la app y pega el texto directamente en el destino en vez de abrir el archivo guardado.