Lección de historia: ¿Qué es un archivo .txt? Por qué los textos antiguos muestran caracteres extraños

¿Qué es un archivo .txt?

Abre un .txt en cualquier editor y solo ves caracteres: letras, cifras, signos de puntuación, espacios y saltos de línea. Ese es todo el formato. No hay encabezado, ni fuente, ni negrita ni cursiva, ni tamaño de página, ni registro del idioma del texto. Lo que el archivo contiene de verdad es una serie de bytes (números del 0 al 255), y el programa que lo abre tiene que decidir qué carácter representa cada número. La extensión “.txt” solo le dice a Windows qué programa ofrecer; no dice nada sobre cómo leer los bytes. Por eso el texto sin formato es uno de los formatos más portables que se han creado, y también uno de los más fáciles de leer mal.

¿Por qué mi archivo .txt muestra caracteres extraños?

Porque el programa que lee el archivo usa una codificación de caracteres distinta de la del programa que lo escribió. La misma letra puede guardarse como bytes diferentes: é es el byte único E9 en Windows-1252, la página de códigos que Microsoft describe como la habitual para inglés y otros idiomas de Europa occidental, pero los dos bytes C3 A9 en UTF-8. Si abres un archivo UTF-8 como Windows-1252, cada é se convierte en é. El apóstrofo tipográfico ’ (E2 80 99 en UTF-8) se convierte en ’. Un archivo UTF-8 que empieza con una marca de orden de bytes (BOM, se explica más abajo) comienza con . En sentido contrario, al abrir como UTF-8 un archivo Windows-1252, el byte E9 suelto no es UTF-8 válido y el programa muestra el carácter de reemplazo �.

Los archivos de la era DOS fallan de otro modo. En el IBM PC original, el mismo byte podía ser otro carácter más: en la página de códigos 437, el juego de caracteres de DOS, el byte 82 es é y los cinco bytes C9 CD CD CD BB dibujan el borde superior de un recuadro (╔═══╗). Windows los lee como página de códigos 1252 y muestra ‚ y ÉÍÍÍ», así que la palabra café sale como caf‚ y el recuadro del banner de un README se convierte en letras.

Ningún programa acierta siempre por sí solo. En 2007, Raymond Chen, de Microsoft, mostró el dilema del Bloc de notas con un archivo de dos bytes, D0 AE. Leído como Windows-1252 son los caracteres Ю; leído como UTF-8 es la letra cirílica Ю; leído como UTF-16 (dos bytes por carácter) es una única sílaba del hangul coreano, distinta según el orden de bytes. Señaló que las cuatro lecturas son verosímiles. Sin etiqueta dentro del archivo, “extraño” es simplemente el aspecto de una suposición equivocada.

1963: ASCII da un número a 128 caracteres

Para que el texto sin formato pudiera ser un archivo, los caracteres necesitaban números en los que las distintas máquinas estuvieran de acuerdo. La American Standards Association creó en agosto de 1960 un subcomité para los juegos de caracteres codificados y, el 17 de junio de 1963, aprobó la norma X3.4-1963, el American Standard Code for Information Interchange: ASCII. Era un código de 7 bits con 128 valores para caracteres de control, cifras, signos de puntuación y el alfabeto inglés. La edición de 1963 era a sabiendas incompleta, con buena parte de la tabla sin asignar. Un aviso de 1967 sobre la revisión aprobada el 7 de julio de 1967, X3.4-1967, decía que la mayoría de los participantes en el proyecto ASCII la consideraba la primera culminación real del código básico de 7 bits.

Siete bits no encajan bien en un byte. Uno de los primeros documentos que dicen qué hacer es la RFC 20, escrita por Vint Cerf en octubre de 1969 para la primera ARPANET, la red de investigación que precedió a Internet. Proponía “ASCII estándar de 7 bits incrustado en un byte de 8 bits cuyo bit de mayor peso es siempre 0”. Ese octavo bit sin usar es donde empiezan los problemas: cuando un byte puede guardar 256 valores, los otros 128 quedan libres para que cualquiera los asigne.

CR, LF o ambos: cómo termina una línea

ASCII también codificó la mecánica del teletipo. Como explica Chen, el retorno de carro (CR) llevaba el cabezal de impresión de vuelta a la columna 0 sin avanzar el papel, y el avance de línea (LF) avanzaba el papel una línea sin mover el cabezal, de modo que empezar una línea nueva requería los dos. La edición de 1968 de ASCII, reproducida en la RFC 20, deja que LF signifique “Nueva línea”, pero añade que usarlo “requiere un acuerdo entre emisor y receptor de los datos”. Ese acuerdo nunca llegó del todo. La propia RFC 20 recoge que los primeros nodos de ARPANET discrepaban: SRI usaba un punto como carácter de fin de línea, mientras que UCLA usaba el retorno de carro.

CP/M, MS-DOS y Windows conservaron los dos caracteres, CRLF (los bytes 0D 0A). Unix se quedó con un solo LF (0A). El anuncio de Microsoft de 2018 sobre el nuevo comportamiento del Bloc de notas enumera las tres convenciones que ahora maneja: finales de línea de Unix/Linux (LF), de Macintosh (CR) y de Windows (CRLF). Hasta entonces, decía, el Bloc de notas solo mostraba bien los finales de línea de Windows, así que un archivo de texto creado en Unix o Linux se veía ilegible. La corrección llegó a las compilaciones Insider de Windows 10 en mayo de 2018.

1981: los otros 128 valores se van por su cuenta

El IBM PC llegó en 1981 con bytes de 8 bits y un estándar de 7 bits. David Bradley, uno de sus ingenieros, recordó después que el PC “usaba el juego de caracteres ASCII, un cambio radical para un producto de IBM” (los productos anteriores de IBM usaban EBCDIC) y que, con 128 huecos nuevos que llenar, el equipo los rellenó con letras de otros idiomas, gráficos de bloques y símbolos matemáticos y griegos. Dijo que le gustaba decir que el juego de caracteres se desarrolló en “una reunión de tres personas de cuatro horas”. El resultado es la página de códigos 437, que Microsoft llama la página OEM (DOS) habitual para inglés: su mitad superior contiene letras acentuadas, caracteres para dibujar líneas y símbolos.

Después Windows creó sus propias páginas de códigos. La documentación de Microsoft dice que la página 1252 de Windows se basó originalmente en un borrador del American National Standards Institute (ANSI) que acabó siendo ISO 8859-1, pero se implementó antes de que el estándar fuera definitivo y no es exactamente igual. Las páginas de códigos de Windows se siguen llamando comúnmente “páginas de códigos ANSI”, aunque son de Microsoft. Todas coinciden con ASCII en los valores 0 a 127 y discrepan a partir de ahí: el byte E9 es é en la página 1252, й en la página cirílica 1251 y ι en la griega 1253. El japonés y el chino usaban páginas de códigos de doble byte, en las que algunos bytes solo significan algo junto con el byte siguiente. Microsoft señala que ninguna página de códigos abarca todo lo que abarca Unicode.

1992: Unicode y un mantel de papel en un diner de Nueva Jersey

Unicode adoptó el enfoque contrario: un número para cada carácter, sin tener que manejar páginas de códigos. En su primera versión, de 1991 a 1995, era una codificación de 16 bits; desde Unicode 2.0, en julio de 1996, abarca el rango de U+0000 a U+10FFFF. Pero un número no es un archivo. Guardar valores de 16 bits directamente en archivos chocaba con el software Unix de la época, que dependía de bytes ASCII como el byte nulo y la barra, y en 1992 un comité de X/Open estudiaba una forma de guardar Unicode compatible con Unix.

Rob Pike, entonces en Bell Labs, escribió en 2003 que UTF-8 “fue diseñado, ante mis ojos, en un mantel de papel de un diner de Nueva Jersey una noche de septiembre o así de 1992”. Miembros del comité les habían pedido a él y a Ken Thompson que revisaran su propuesta. Los dos fueron a cenar, Thompson ideó el empaquetado de bits y después llamaron por teléfono al comité. Pike cuenta que Thompson escribió esa noche el código de empaquetado y desempaquetado, y que el viernes su sistema operativo, Plan 9, ya funcionaba solo con lo que se llamaría UTF-8. Archivos de correo que encontró su colega Russ Cox sitúan la propuesta a principios de septiembre de 1992.

UTF-8 guarda cada carácter en uno a cuatro bytes. Los 128 caracteres ASCII conservan su valor de un solo byte, y ningún byte de ningún otro carácter se parece a ASCII, de modo que un archivo ASCII puro ya es UTF-8 válido. Todo lo demás ocupa de dos a cuatro bytes, con bits iniciales que indican al lector la longitud de la secuencia: é pasa a ser C3 A9. La RFC 3629 de François Yergeau (noviembre de 2003) lo convirtió en estándar de Internet, y las preguntas frecuentes de Unicode lo llaman “la forma preferida para los archivos de texto Unicode”.

La BOM y por qué el Bloc de notas tenía que adivinar

UTF-16 guarda los caracteres en unidades de 16 bits, así que el lector también necesita saber el orden de bytes. La respuesta de Unicode es un carácter, U+FEFF, colocado al principio del archivo como firma: la marca de orden de bytes. En UTF-8 aparece como los bytes EF BB BF, y las preguntas frecuentes de Unicode son explícitas: ahí no tiene nada que ver con el orden de bytes, solo marca el archivo como UTF-8. Añaden que algunos programas no la esperan (la primera línea de un script de shell de Unix, que empieza por #!, es un ejemplo) y que un protocolo como las “convenciones de Microsoft para archivos .txt” puede exigirla. Así que un .txt puede empezar con BOM o no, y cuando no la tiene, el programa debe adivinar.

La entrada de 2007 de Chen sobre “el problema de la codificación de archivos del Bloc de notas” explica por qué adivinar nunca sale bien. Los archivos con BOM son fáciles. Sin ella, la mayoría de los archivos de texto en circulación eran ANSI de 8 bits, algunos archivos UTF-8 y UTF-16 tampoco tenían BOM, y cada regla que probó favorecía a un grupo y rompía otro. Su ejemplo: el comando cmd /u /c dir >results.txt escribe un archivo UTF-16 sin BOM.

Microsoft cambió el Bloc de notas en dos pasos. En 2018 aprendió los finales de línea de Unix y Mac. Después, en la compilación Insider 18298 de Windows 10, del 10 de diciembre de 2018, Microsoft añadió la opción de guardar en UTF-8 sin BOM, la hizo predeterminada para archivos nuevos y puso la codificación en la barra de estado, explicando que UTF-8 sin BOM es retrocompatible con ASCII y funciona mejor con la web, “donde UTF-8 se ha convertido en la codificación predeterminada”. El cambio llegó a todos con Windows 10 versión 1903, la actualización de mayo de 2019. Antes, un archivo nuevo del Bloc de notas usaba ANSI de forma predeterminada.

2007 y después: UTF-8 se apodera de la web

Google informó de que en diciembre de 2007 Unicode se convirtió por primera vez en la codificación más frecuente en las páginas web que indexaba, superando a ASCII y a las codificaciones de Europa occidental con diez días de diferencia entre una y otra. W3Techs informa ahora de UTF-8 en el 99,1 % de los sitios web cuya codificación puede identificar (noviembre de 2026). Es una estadística sobre sitios web. Los archivos de texto de discos antiguos nunca formaron parte de ese cambio, y nadie volvió atrás para recodificarlos.

Por qué los .txt de discos antiguos siguen saliendo ilegibles en 2026

El software actual da por hecho UTF-8, pero mucho texto se escribió antes: README de DOS, notas de los primeros Windows, exportaciones de programas que ya no funcionan, y correos o registros guardados como texto. Están en la página de códigos del PC que los creó, que dependía de su idioma y de su versión de Windows, y no llevan ninguna etiqueta. Si a eso se suman los finales de línea de otro sistema y algún archivo UTF-16 sin BOM, la misma extensión .txt esconde varios formatos sin relación. Muchos son archivos legacy de los que nadie puede preguntar al programa original.

Legacy File Converter incluye el texto sin formato (.txt) entre los documentos de su página Tipos de archivo compatibles y los convierte en tu propio PC con Windows a formatos modernos como DOCX, PDF, Markdown o HTML; no se sube nada. Después, compara las letras acentuadas, las comillas y los símbolos con el original, y conserva el archivo original. Para otros formatos que por debajo son sobre todo texto, mira la Lección de historia: ¿Qué es un archivo .csv?, donde la falta de una BOM hace tropezar a Excel, y la Lección de historia: ¿Qué es un archivo .rtf?.