Mojibake: Cómo Solucionar el Texto Corrupto (Caracteres Raros)

Seguro que te ha pasado. Abres un archivo de texto, una página web, un correo electrónico, o miras datos en una base de datos y… ¡sorpresa! En lugar del texto que esperabas, te encuentras con una sopa de caracteres raros, símbolos extraños, acentos convertidos en parejas de letras sin sentido, o esos infames rombos negros con un signo de interrogación dentro (�). Algo parecido a esto:

El próximo miércoles nos vemos.
Donde dije digo digo Diego � Qué lío!

Si esta visión te resulta familiar, lo más probable es que estés frente a un caso de Mojibake. Es un término japonés que se ha adoptado internacionalmente para describir precisamente este fenómeno: la aparición de texto corrupto o ilegible cuando un software intenta mostrar datos de texto usando una codificación de caracteres incorrecta.

No te preocupes, no es que el archivo esté poseído ni que tu ordenador se haya vuelto loco (normalmente). Es un problema técnico con una causa clara y, lo más importante, tiene solución.

En este artículo, vamos a ir directos al grano:

1. Entenderemos rápidamente por qué ocurre este lío de codificaciones.

2. Veremos cómo diagnosticar cuál es el problema exacto en tu caso.

3. Y lo fundamental: aprenderemos cómo arreglar ese texto para que vuelva a ser legible y cómo prevenir que el Mojibake vuelva a aparecer.

Así que, si estás listo para dejar de ver símbolos raros y recuperar tu texto, ¡sigue leyendo!

Entendiendo el Origen: ¿Por Qué Aparece el Mojibake?

Vale, ya sabemos identificar el Mojibake, pero ¿cuál es el culpable técnico? La raíz del problema es, en realidad, bastante simple: es un desajuste entre «idiomas digitales».

Imagina que guardas un mensaje escribiéndolo en español, pero luego alguien intenta leerlo como si estuviera escrito en chino. El resultado será incomprensible, ¿verdad? Con los ordenadores pasa algo similar. El texto que vemos en pantalla no se guarda tal cual; se convierte en una secuencia de bytes (números) siguiendo unas reglas específicas. Esas reglas son lo que llamamos codificación de caracteres. Define cómo convertir cada carácter (‘A’, ‘ñ’, ‘€’, ‘😂’) en uno o más bytes, y viceversa.

(Si quieres profundizar más en qué son exactamente Unicode, UTF-8 y otras codificaciones, puedes echar un vistazo a nuestros artículos sobre Unicode y UTF-8)

El Mojibake ocurre cuando el texto se guarda (se codifica) usando una regla (una codificación), pero luego se lee (se decodifica) usando una regla diferente e incompatible. Ahí es donde las cosas se tuercen y aparecen los errores de codificación de caracteres.

Veamos los escenarios más comunes de este Qué es Mojibake en la práctica:

1. Texto en UTF-8 leído como ISO-8859-1 o Windows-1252:

   • UTF-8 es la codificación estándar hoy en día. Para caracteres como ‘ñ’, ‘á’, ‘é’, ‘€’, etc., usa dos bytes.

   • Codificaciones antiguas como ISO-8859-1 (Latin-1) o Windows-1252 esperan un solo byte para los caracteres que soportan.

   • Cuando un programa que espera Windows-1252 se topa con los dos bytes que UTF-8 usa para ‘ñ’ (que son C3 y B1 en hexadecimal), los interpreta individualmente. El byte C3 en Windows-1252 corresponde a ‘Ã’ y el byte B1 corresponde a ‘±’. ¡Y voilà! En lugar de ‘ñ’, ves Ã±. Este es un patrón súper común para los problemas con acentos y ñ. Es un claro síntoma de UTF-8 Mojibake interpretado como una codificación de 8 bits simple.

2. Texto en Windows-1252 (u otra ANSI/ISO) leído como UTF-8:

   • Aquí la situación es inversa. Tienes un texto guardado con una codificación antigua de 8 bits, como Windows-1252. 📌 Si quieres saber más sobre esta codificación concreta, lee nuestro artículo: Entendiendo la codificación Windows-1252.

   • Un programa moderno que espera UTF-8 intenta interpretar esos bytes. UTF-8 tiene reglas estrictas sobre qué secuencias de bytes son válidas. Muchos bytes individuales usados en Windows-1252 para caracteres especiales (como el byte E1 para ‘á’ o F1 para ‘ñ’) no son válidos como inicio de una secuencia UTF-8 o son secuencias incompletas.

   • Cuando UTF-8 se topa con estos bytes «ilegales», no sabe qué hacer y normalmente muestra el carácter de reemplazo: el famoso rombo negro con interrogación �. Ver muchos � suele indicar Mojibake Windows-1252 (o similar) leído como UTF-8.

3. El caso del «Doble UTF-8» (o doble codificación):

   • Este es un poco más retorcido. Ocurre cuando texto que ya está correctamente codificado en UTF-8 es tratado erróneamente como si estuviera en otra codificación (ej. ISO-8859-1) y luego se vuelve a codificar a UTF-8.

   • Por ejemplo, la ‘ñ’ (UTF-8: C3 B1) se interpreta erróneamente como los dos caracteres ‘Ã’ y ‘±’ (ISO-8859-1). Luego, estos dos caracteres se codifican de nuevo a UTF-8. ‘Ã’ se convierte en C3 83 y ‘±’ se convierte en C2 B1. El resultado final para la ‘ñ’ original es C3 83 C2 B1, que se mostrará como ÃƒÂ±. Si ves este tipo de patrones (á, Ã¢â€šÂ¬ para ‘€’, etc.), probablemente estés ante un caso de doble codificación.

Entender estos patrones es clave para el siguiente paso: el diagnóstico.

Paso 1: Diagnóstico – ¿Qué Codificación Está Causando el Problema?

Muy bien, tenemos el texto corrupto delante. El objetivo ahora es detectar la codificación de texto original (la correcta) y la codificación que se está usando incorrectamente para leerlo. No siempre es fácil, pero con un poco de investigación, podemos llegar a una conclusión bastante fiable.

Aquí van las técnicas que suelo usar, de más simple a más potente:

1. Inspección Visual (Buscando Patrones):

   • Lo primero es observar detenidamente los símbolos extraños en el archivo o texto. ¿Recuerdas los patrones que vimos en la sección anterior?

     • ¿Ves muchos Ã±, Ã¡, Ã©, Â¿, â‚¬ (para ‘€’)? Esto grita: «¡Probablemente soy UTF-8 siendo leído como Windows-1252 o ISO-8859-1!». Es el caso más común con textos en español y otros idiomas europeos.

     • ¿Ves muchos rombos negros con interrogación �? Esto suele indicar lo contrario: «¡Probablemente soy texto en una codificación antigua (como Windows-1252 o ISO-8859-1) leído como UTF-8!». UTF-8 es estricto y marca lo que no entiende.

     • ¿Ves cosas más raras como ÃƒÂ±, ÃƒÂ¡, Ã¢â€šÂ¬? ¡Ajá! Posiblemente sea el doble UTF-8. Texto que ya era UTF-8, malinterpretado y recodificado a UTF-8.

   • Fíjate bien. A veces, solo unos pocos caracteres están mal, lo que te da pistas sobre qué idioma o símbolos específicos están causando problemas.

2. Uso de Editores de Texto Avanzados:

   • Herramientas como Notepad++ (Windows), Visual Studio Code (multiplataforma), Sublime Text (multiplataforma) o BBEdit (macOS) son tus mejores amigas aquí.

   • Abrir el archivo: Muchos de estos editores intentan autodetectar la codificación al abrir un archivo. Fíjate en la barra de estado inferior, a menudo indica la codificación detectada (ej., «UTF-8», «Windows-1252»).

   • Cambiar la interpretación (sin guardar): La función clave es la que permite reabrir o reinterpretar el archivo con una codificación diferente. Suele estar en menús como «Codificación», «Archivo» > «Reabrir con codificación» o similar. Prueba a seleccionar las sospechosas habituales (UTF-8, Windows-1252, ISO-8859-1, a veces variantes como ISO-8859-15) y mira si el texto se arregla visualmente en el editor. ¡Importante! Solo estás cambiando cómo lo ves, no has arreglado el archivo todavía.

1. Comandos de Terminal (Linux/macOS/WSL):

   • Si trabajas en un entorno tipo Unix, el comando file es muy útil. Ejecuta:

   file -i tu_archivo_sospechoso.txt

   • La salida te dará información sobre el tipo de archivo y, a menudo, intentará adivinar la codificación (charset). Ejemplo: tu_archivo_sospechoso.txt: text/plain; charset=iso-8859-1. ¡Ojo! file no es infalible, pero da una buena pista inicial.

2. Herramientas Online (¡Con Precaución!):

   • Existen páginas web que intentan detectar la codificación de un texto que pegues. Busca «online charset detector» o similar.

   • ¡¡ADVERTENCIA DE PRIVACIDAD!! Nunca pegues información sensible, confidencial o privada en estas herramientas online. Úsalas solo para textos genéricos o fragmentos que no contengan datos personales o críticos.

La Técnica del Detective: Prueba y Error Informada

Basándote en los patrones visuales y las pistas de las herramientas, haz pruebas lógicas:

• Si ves Ã±, tu hipótesis principal es «Original UTF-8, leído como Windows-1252». Intenta reabrir como UTF-8.

• Si ves �, tu hipótesis es «Original Windows-1252 (o similar), leído como UTF-8». Intenta reabrir como Windows-1252 o ISO-8859-1.

Una vez que consigas que el texto se vea bien en tu editor cambiando la interpretación, ¡has encontrado las codificaciones involucradas! Ahora estás listo para el siguiente paso: aplicar la solución permanente.

¡Excelente! Ya hemos jugado a los detectives y tenemos una buena idea de qué codificaciones están causando el estropicio. Ahora viene la parte satisfactoria: solucionar el Mojibake y recuperar nuestro texto legible.

Aquí tienes la redacción de la cuarta sección:

Paso 2: Solución – Cómo Arreglar Texto con Mojibake

Una vez que has conseguido visualizar correctamente el texto en tu editor (o tienes una fuerte sospecha de cuál era la codificación original), tienes dos caminos principales para arreglar el desaguisado. La elección depende de si solo necesitas ver o copiar el texto correctamente una vez, o si quieres arreglar el archivo de forma permanente.

Solución A: Reinterpretar/Recargar con la Codificación Correcta (Arreglo Temporal o para Copiar)

Este método utiliza la misma función que empleamos en el diagnóstico: la opción de tu editor de texto, navegador o herramienta para cambiar la codificación con la que interpreta el contenido.

• Cómo: Vuelve al menú «Codificación», «Ver» > «Codificación de texto», «Archivo» > «Reabrir con codificación», o similar, y selecciona la codificación original correcta que identificaste en el paso anterior (ej., si veías ñ, probablemente selecciones UTF-8 aquí; si veías �, quizás selecciones Windows-1252).

• Resultado: El texto debería mostrarse correctamente en pantalla de inmediato.

• Cuándo usarlo: Perfecto si solo necesitas leer la información, copiar y pegar el texto corregido en otro lugar, o si no tienes permiso para modificar el archivo original.

• Limitación: Normalmente, esto no cambia el archivo en sí. Si cierras y vuelves a abrir el archivo, el problema probablemente reaparecerá a menos que el programa recuerde tu preferencia (lo cual no siempre pasa).

Solución B: Convertir el Archivo Permanentemente (Arreglo Definitivo)

Este es el camino si quieres arreglar el archivo con Mojibake de una vez por todas. El objetivo final suele ser convertir el archivo a UTF-8, que es el estándar moderno y más compatible.

¡¡MUY IMPORTANTE!! Antes de convertir cualquier archivo, ¡haz siempre una COPIA DE SEGURIDAD del original! Si algo sale mal en la conversión, tendrás el archivo original para intentarlo de nuevo.

Aquí tienes cómo hacerlo:

1. Usando Editores de Texto Avanzados (Método Recomendado):

   • Abre el archivo original en tu editor (Notepad++, VSCode, Sublime Text, etc.).

   • Primero, usa la función de reinterpretar (Solución A) para asegurarte de que el editor está leyendo el archivo con la codificación original correcta y ves el texto bien. ¡Este paso es crucial!

   • Una vez que el texto se vea bien, busca la opción «Guardar como…» o, idealmente, una opción específica como «Convertir a UTF-8» (o la codificación que desees, pero UTF-8 es lo más recomendable).

   • Al guardar, asegúrate de que en las opciones de guardado o en el menú de codificación esté seleccionado UTF-8 como la codificación de destino.

   • Guarda el archivo (puedes sobrescribir el original si hiciste copia de seguridad, o guardarlo con un nombre nuevo).

1. Usando Herramientas de Línea de Comandos (Avanzado):

   • Si te manejas con la terminal (Linux, macOS, WSL), la utilidad iconv es tu aliada. Permite convertir entre codificaciones.

   • La sintaxis básica es: iconv -f <CODIFICACION_ORIGINAL> -t <CODIFICACION_DESTINO> archivo_entrada.txt > archivo_salida.txt

   • Ejemplo: Para convertir un archivo que sabes que está en Windows-1252 a UTF-8:

   iconv -f WINDOWS-1252 -t UTF-8 archivo_mojibake.txt > archivo_corregido_utf8.txt

   (Los nombres exactos de las codificaciones para iconv pueden variar ligeramente según el sistema, usa iconv -l para ver la lista).

2. Librerías en Lenguajes de Programación:

   • Si eres desarrollador, lenguajes como Python, PHP, Java, etc., tienen funciones integradas o librerías para leer archivos especificando una codificación y escribirlos especificando otra. Esto es útil para procesos automáticos o scripts.

El Objetivo: Convertir a UTF-8

Salvo casos muy específicos, la meta debería ser tener tus archivos de texto en UTF-8. Es la codificación más universal, soporta todos los caracteres Unicode y es el estándar de facto en la web y en muchos sistemas modernos.

Una vez convertido el archivo, ábrelo de nuevo para verificar que se ve correctamente y que tu editor lo reconoce como UTF-8. ¡Problema resuelto! Pero… ¿cómo evitamos que vuelva a pasar? Eso lo vemos en el siguiente paso.

¡Perfecto! Arreglar el Mojibake está bien, pero evitar que aparezca en primer lugar es mucho mejor. Como dicen, más vale prevenir que curar. Vamos a ver cómo configurar tus herramientas y sistemas para mantener a raya esos caracteres corruptos.

Aquí tienes la redacción de la quinta sección:

Paso 3: Prevención – Configurar Sistemas para Evitar Futuros Mojibakes

Ya has limpiado el desastre, ¡genial! Ahora, el objetivo es asegurar la consistencia para que el Mojibake no vuelva a llamar a tu puerta. La estrategia más robusta y recomendada en el mundo moderno es adoptar UTF-8 como estándar en todas las etapas de tu flujo de trabajo donde se maneje texto.

Aquí tienes los puntos clave que debes revisar y configurar para usar UTF-8 por defecto:

1. Tu Editor de Código / IDE:

   • Busca en las preferencias o configuración de tu editor (VSCode, Sublime Text, Notepad++, Atom, PhpStorm, etc.) la opción para establecer la codificación de guardado predeterminada.

   • Selecciona UTF-8 (a veces aparece como «UTF-8 with BOM» o «UTF-8 without BOM». Generalmente, UTF-8 sin BOM es preferible, especialmente para desarrollo web).

   • Esto asegura que cualquier archivo nuevo que crees se guarde automáticamente en UTF-8.

1. Servidor Web (Apache, Nginx, etc.):

   • El servidor web debe decirle al navegador qué codificación está usando para enviar el contenido HTML. Esto se hace a través de la cabecera HTTP Content-Type.

   • Asegúrate de que tu servidor esté configurado para enviar Content-Type: text/html; charset=UTF-8 (o el tipo MIME apropiado para otros contenidos de texto como CSS, JS).

   • La configuración varía según el servidor (ej. AddDefaultCharset UTF-8 en Apache, charset utf-8; en Nginx dentro del bloque http, server o location). Consulta la documentación de tu servidor.

2. Documentos HTML:

   • Incluso si el servidor envía la cabecera correcta, es una buena práctica fundamental declarar la codificación dentro del propio HTML. Esto ayuda si el archivo se guarda localmente o si la cabecera HTTP se pierde.

   • La forma estándar en HTML5 es incluir esta etiqueta <meta> lo más arriba posible dentro de la sección <head>:

   <meta charset="UTF-8">

   • ¿Qué codificación usar en HTML5? Sin duda, UTF-8.

3. Bases de Datos (MySQL, PostgreSQL, SQL Server, etc.):

   • Este es un punto crítico y a menudo olvidado. Debes asegurarte de que la base de datos, las tablas específicas y las columnas de texto (VARCHAR, TEXT, etc.) estén definidas para usar UTF-8 (o una variante como utf8mb4 en MySQL, que es necesaria para emojis y caracteres suplementarios).

   • Además, la conexión entre tu aplicación (PHP, Python, Java…) y la base de datos también debe establecerse explícitamente en UTF-8 (ej. SET NAMES ‘utf8mb4’ en MySQL después de conectar).

   • Consulta la documentación de tu SGBD y del conector/librería que uses en tu aplicación para la configuración correcta de la codificación de la base de datos.

4. Procesamiento de Formularios Web:

   • Asegúrate de que tus formularios HTML indiquen que aceptan UTF-8 (normalmente se hereda de la configuración de la página si usas <meta charset=»UTF-8″>).

   • En el backend (PHP, Python, Node.js, etc.), verifica que estás interpretando los datos recibidos del formulario como UTF-8 antes de procesarlos o guardarlos en la base de datos.

5. Lectura/Escritura de Archivos en Scripts:

   • Cuando escribas código (Python, PHP, Java, C#, etc.) que lea o escriba archivos de texto, especifica explícitamente la codificación UTF-8 en las funciones de apertura o manejo de archivos. No confíes en los valores predeterminados del sistema operativo, que pueden variar.

   • Ejemplo en Python 3: open(‘mi_archivo.txt’, ‘r’, encoding=’utf-8′) o open(‘mi_archivo.txt’, ‘w’, encoding=’utf-8′).

La Regla de Oro: UTF-8 en Todas Partes

Puede parecer repetitivo, pero la clave es esa: configura UTF-8 de forma consistente en tu editor, servidor, HTML, base de datos y código. Hacer esto desde el principio te ahorrará incontables horas de frustración depurando Mojibakes en el futuro.

¿Dónde Suele Esconderse el Mojibake?

El Mojibake es como un gremlin digital, puede aparecer en los lugares más inesperados si las codificaciones no están alineadas. Aquí te presento algunos de los escondites favoritos donde probablemente te lo encontrarás:

1. Archivos CSV (¡El Clásico Dolor de Cabeza con Excel!):

   • El Problema: Exportas datos de una base de datos o aplicación web (probablemente en UTF-8) a un archivo CSV. Luego, lo abres con Microsoft Excel (especialmente versiones algo antiguas) y… ¡zas! Todos los acentos, ‘ñ’ y símbolos especiales aparecen como Ã±, Ã¡, etc.

   • La Causa: Excel, históricamente, tendía a asumir codificaciones antiguas como Windows-1252 al abrir CSVs sin más. No interpretaba correctamente el UTF-8.

   • Pista: Si ves el patrón Ã seguido de otro carácter, es casi seguro un Mojibake en CSV por UTF-8 leído como ANSI/Windows-1252.

   • Solución Rápida: En lugar de hacer doble clic, usa la opción «Importar Datos» > «Desde Texto/CSV» en Excel. Durante el proceso de importación, te permitirá especificar la codificación del archivo original (selecciona «65001: Unicode (UTF-8)»).

2. Datos de Bases de Datos (Viejas Glorias o Migraciones):

   • El Problema: Recuperas datos de una base de datos (a través de una aplicación, un script o una herramienta de administración) y el texto aparece con � o patrones Ã±.

   • La Causa: Puede haber varios culpables:

     • La columna en la BBDD está definida con una codificación antigua (latin1, sql_latin1…) y contiene caracteres que no caben ahí (se guardaron ?).

     • La columna es UTF-8, pero la conexión entre tu aplicación y la BBDD no se estableció como UTF-8, causando una mala conversión al leer/escribir. (¡Este es muy común!).

     • Estás migrando datos de una BBDD antigua a una nueva y la conversión de codificación falló.

   • Pista: Mojibake en SQL a menudo implica revisar tanto la definición de las tablas (SHOW CREATE TABLE tu_tabla;) como la configuración de la conexión.

3. Contenido Copiado y Pegado (Mezclas Peligrosas):

   • El Problema: Copias texto de una página web, un PDF o un documento de Word y lo pegas en un editor de texto simple, un formulario web o tu código, y aparecen caracteres raros.

   • La Causa: El portapapeles a veces hace conversiones extrañas o el programa de origen usaba una codificación interna diferente a la del destino. Word, en particular, usa representaciones internas complejas.

   • Solución Rápida: Intenta usar «Pegado especial» > «Texto sin formato» si la opción existe. O pega primero en un editor simple configurado en UTF-8 y luego copia desde ahí.

4. Páginas Web y Contenido HTML:

   • El Problema: Abres una página web y ves Mojibake.

   • La Causa: Generalmente, es porque el servidor envió el HTML codificado en X (ej. UTF-8) pero olvidó declarar la codificación (ni cabecera Content-Type, ni <meta charset>), o la declaró incorrectamente. El navegador intenta adivinar y falla.

   • Pista: Si ves Mojibake en HTML, revisa el código fuente (Ctrl+U o Cmd+Opt+U) y busca la etiqueta <meta charset=»…»>. Asegúrate de que existe y es UTF-8. También comprueba las cabeceras HTTP con las herramientas de desarrollador del navegador (pestaña Red/Network).

5. Archivos de Subtítulos (.srt, .sub):

   • El Problema: Cargas un archivo de subtítulos en tu reproductor de vídeo y los diálogos con acentos o caracteres especiales se ven mal.

   • La Causa: Los archivos de subtítulos son archivos de texto plano y sufren los mismos problemas. Muchos se guardan erróneamente en ANSI/Windows-1252 cuando deberían estar en UTF-8.

   • Solución Rápida: Abre el archivo .srt en un editor avanzado, detecta la codificación original (probablemente Windows-1252 o similar) y conviértelo a UTF-8 (sin BOM) usando la Solución B que vimos antes.

6. Código Fuente y Archivos de Configuración Compartidos:

   • El Problema: Un compañero te pasa un script o un archivo de configuración, lo abres en tu sistema y los comentarios o cadenas de texto con caracteres especiales se ven mal.

   • La Causa: Diferencias en la configuración de codificación predeterminada entre los editores o sistemas operativos de los desarrolladores.

   • Solución: Acordar usar siempre UTF-8 y configurar los editores como vimos en la sección de prevención.

Estar atento a estos contextos te ayudará a diagnosticar y solucionar el Mojibake mucho más rápido. Recuerda siempre los patrones visuales y las causas probables que hemos comentado.

Kit de Supervivencia Rápido Contra el Mojibake

Te encuentras con texto corrupto. ¡Que no cunda el pánico! Sigue estos pasos rápidos para intentar solucionar el Mojibake:

1. OBSERVA (Identifica el Patrón):

   • ¿Ves Ã±, Ã¡, â‚¬? 👉 Sospecha: UTF-8 leído como Windows-1252/ISO-8859-1.

   • ¿Ves muchos �? 👉 Sospecha: Windows-1252/ISO-8859-1 leído como UTF-8.

   • ¿Ves ÃƒÂ±, Ã¢â€šÂ¬? 👉 Sospecha: Doble UTF-8.

2. INVESTIGA (Diagnostica las Codificaciones):

   • Usa un editor de texto avanzado (Notepad++, VSCode, etc.).

   • Prueba la función «Reabrir con codificación» o similar. Intenta con tus sospechosas (UTF-8, Windows-1252, ISO-8859-1) hasta que el texto se vea bien en pantalla.

   • Si estás en terminal, prueba file -i tu_archivo.txt para una pista.

3. ACTÚA (Aplica la Solución):

   • Opción Rápida (Ver/Copiar): Una vez que se ve bien en el editor (Paso 2), simplemente lee o copia el texto.

   • Opción Definitiva (Arreglar Archivo):

     • ¡HAZ COPIA DE SEGURIDAD!

     • Asegúrate de que el editor muestra el texto correctamente (interpretando con la codificación original correcta).

     • Usa «Guardar como…» o «Convertir a…» y selecciona explícitamente UTF-8 como codificación de destino.

     • Verifica el archivo guardado.

4. PREVÉN (Evita Futuros Problemas):

   • Configura tu editor para guardar en UTF-8 por defecto.

   • Asegura que tu servidor web envíe cabeceras Content-Type con charset=UTF-8.

   • Usa <meta charset=»UTF-8″> en tu HTML.

   • Define tus bases de datos, tablas y columnas en UTF-8 (o utf8mb4).

   • Establece la conexión a la BBDD en UTF-8.

   • Especifica UTF-8 al leer/escribir archivos en tus scripts.

   • Regla de oro: UTF-8 en todas partes.

Con estos pasos en mente, estarás mucho mejor equipado para enfrentarte y vencer al Mojibake la próxima vez que aparezca.

¿Te ha servido esta guía para luchar contra el Mojibake? ¿Tienes algún truco o herramienta adicional que uses? ¡Compártelo en los comentarios! Y si este kit de supervivencia te ha resultado útil, ¡ayúdanos a difundirlo!