Por qué tu asunto llega como =?UTF-8?B? y una ristra de letras
Publicado el 8/9/2026 · 3 min de lectura · Herramientas de archivos
Daniel Okonkwo — Desarrollador front-end y redactor de Tecnología en OneKitly
Rendimiento web · Formatos de archivo
Verificado con 3 fuentes
Un encabezado solo puede contener ASCII, lo que no deja sitio a la é, la ü, la ñ ni a la raya. El rodeo está definido en la RFC 2047: el texto se envuelve como =?charset?codificación?datos?=, donde la codificación es B para base64 o Q para una variante de quoted-printable en la que el espacio se vuelve un guion bajo. Así que Réunion — ordre du jour viaja como =?UTF-8?B?UsOpdW5pb24g4oCUIG9yZHJlIGR1IGpvdXI=?= o como =?UTF-8?Q?R=C3=A9union_=E2=80=94_ordre_du_jour?=, y ambos decodifican exactamente las mismas palabras. Los mensajes más antiguos usan =?ISO-8859-1?Q?R=E9union?= y decodifican igual de limpio. El cuerpo es un problema aparte con la misma forma: suele ir en quoted-printable, donde =C3=A9 es é y una línea que acaba en un signo igual desnudo continúa en la siguiente. Convierte el mensaje a texto plano y las dos capas caen a la vez, que es lo que hace un mensaje guardado buscable y citable en vez de algo que se descifra entornando los ojos.
Los encabezados de correo solo pueden llevar ASCII, así que un asunto acentuado se codifica antes de viajar. Se usan dos codificaciones, ambas empiezan por =?, y decodificarlas es toda la diferencia entre un mensaje legible y un muro de símbolos.
Por qué dos codificaciones, y cuál te toca
La Q deja en paz las letras corrientes y escapa solo lo imprescindible: un asunto casi todo en inglés con un acento sigue siendo casi legible en el archivo crudo. La B lo codifica todo, lo que resulta más corto cuando la mayoría de los caracteres no son ASCII — un asunto en griego o japonés es mucho más compacto en base64 que como ristra de escapes. Los programas eligen por encabezado, de ahí que un mismo mensaje lleve un asunto en Q y un nombre de remitente en B, y de ahí que haya que tratar ambos.
Para qué sirve el texto plano
Un mensaje reducido a texto lo busca cualquier herramienta de tu máquina, se cita sin arrastrar una maquetación y es lo bastante pequeño para guardarlo por millares. Es además la forma que sobrevive: un mensaje HTML de 2011 se ve distinto en cada lector aparecido desde entonces, mientras que su alternativa de texto se lee hoy igual que entonces. Casi todos los mensajes llevan ambas, y la de texto es la que nadie mira hasta que hace falta.
| En el archivo crudo | Decodificado |
|---|---|
| =?UTF-8?B?UsOpdW5pb24g4oCUIG9yZHJl…?= | Réunion — ordre du jour |
| =?UTF-8?Q?R=C3=A9union_=E2=80=94_ordre…?= | Réunion — ordre du jour |
| =?ISO-8859-1?Q?R=E9union?= | Réunion |
| Réunion (sin codificar) | Réunion — pasa tal cual |
Preguntas frecuentes
- Mi asunto sale «Réunion» en vez de «Réunion». ¿Qué es eso?
- El problema inverso: los bytes se decodificaron, pero con el juego de caracteres equivocado. é es el aspecto de los dos bytes de una é UTF-8 leídos como Latin-1. Suele venir de un programa que ignoró el juego declarado en el encabezado. Abrir el .eml original y dejar que la herramienta lea la declaración devuelve los caracteres correctos — el archivo nunca se dañó, solo se leyó mal.
- ¿La versión de texto pierde algo?
- La maquetación, las imágenes y el destino de los enlaces — un enlace se queda en sus palabras, no en su dirección, salvo que el remitente escribiera la dirección entera. Lo que conserva es todo lo que se dijo. Si necesitas también las direcciones, coge la conversión a HTML o lee el mensaje en el visor, donde los enlaces siguen siendo enlaces.
- ¿Puedo convertir un buzón entero de una vez?
- Divide primero el .mbox en archivos .eml individuales y convierte luego los que quieras. Esa vía en dos pasos es deliberada: un buzón suele ser mucho mayor que el puñado de mensajes que de verdad necesitas en texto, y dividir primero te deja elegir.
Artículos que podrían interesarte
Todas las guías →Herramientas relacionadas
Fuentes
¿Has detectado un error en este artículo?