caten una ventana de xtermEn informática , el texto simple es un término impreciso para los datos (por ejemplo, el contenido de un archivo) que representan solo caracteres de material legible, pero no su representación gráfica ni otros objetos ( números de punto flotante , imágenes, etc.). También puede incluir un número limitado de caracteres de "espacio en blanco" que afectan la disposición simple del texto, como espacios, saltos de línea o caracteres de tabulación. El texto simple es diferente del texto formateado , donde se incluye información de estilo; del texto estructurado, donde se identifican partes estructurales del documento, como párrafos, secciones y similares; y de los archivos binarios en los que algunas partes deben interpretarse como objetos binarios (números enteros codificados, números reales, imágenes, etc.).
El término se utiliza a veces de forma bastante vaga, para referirse a archivos que contienen solo contenido "legible" (o simplemente archivos que no contienen nada que el hablante no prefiera). Por ejemplo, esto podría excluir cualquier indicación de fuentes o diseño (como marcado, Markdown o incluso tabulaciones); caracteres como comillas, espacios indivisibles, guiones suaves, rayas largas y/o ligaduras; u otras cosas.
En principio, el texto sin formato puede estar en cualquier codificación , pero en ocasiones el término se interpreta como ASCII . A medida que las codificaciones basadas en Unicode , como UTF-8 y UTF-16, se vuelven más comunes, es posible que ese uso esté disminuyendo.
El texto sin formato también se utiliza a veces sólo para excluir archivos "binarios": aquellos en los que al menos algunas partes del archivo no se pueden interpretar correctamente a través de la codificación de caracteres vigente. Por ejemplo, un archivo o cadena que consta de "hola" (en cualquier codificación), seguido de 4 bytes que expresan un entero binario que no es un carácter, es un archivo binario. La conversión de un archivo de texto sin formato a una codificación de caracteres diferente no cambia el significado del texto, siempre que se utilice la codificación de caracteres correcta. Sin embargo, la conversión de un archivo binario a un formato diferente puede alterar la interpretación de los datos no textuales.
Según el estándar Unicode: [1]
Sin embargo, según otras definiciones, los archivos que contienen marcado u otros metadatos generalmente se consideran texto sin formato, siempre que el marcado también esté en un formato directamente legible para humanos (como en HTML, XML, etc.). Por lo tanto, las representaciones como SGML, RTF, HTML, XML, marcado wiki y TeX, así como casi todos los archivos de código fuente de lenguajes de programación, se consideran texto sin formato. El contenido particular es irrelevante para determinar si un archivo es texto sin formato. Por ejemplo, un archivo SVG puede expresar dibujos o incluso gráficos de mapa de bits, pero sigue siendo texto sin formato.
El uso de texto simple en lugar de archivos binarios permite que los archivos sobrevivan mucho mejor "en la naturaleza", en parte al hacerlos en gran medida inmunes a las incompatibilidades de la arquitectura informática. Por ejemplo, se pueden evitar todos los problemas de endianidad (con codificaciones como UCS-2 en lugar de UTF-8, la endianidad importa, pero de manera uniforme para cada carácter, en lugar de para subconjuntos potencialmente desconocidos de él).
El objetivo de utilizar texto simple en la actualidad es principalmente la independencia de los programas que requieren su propia codificación o formato de archivo especial . Los archivos de texto simple se pueden abrir, leer y editar con editores de texto y utilidades omnipresentes.
Una interfaz de línea de comandos permite a las personas dar comandos en texto simple y obtener una respuesta, normalmente también en texto simple.
Muchos otros programas de computadora también son capaces de procesar o crear texto simple, como innumerables programas en DOS , Windows , Mac OS clásico y Unix y sus afines; así como navegadores web (algunos navegadores como Lynx y el Line Mode Browser producen solo texto simple para mostrar) y otros lectores de texto electrónico .
Los archivos de texto sin formato son casi universales en programación; un archivo de código fuente que contiene instrucciones en un lenguaje de programación es casi siempre un archivo de texto sin formato. El texto sin formato también se usa comúnmente para archivos de configuración , que se leen para buscar configuraciones guardadas al iniciar un programa.
En muchos correos electrónicos se utiliza texto simple .
Un comentario , un archivo " .txt " o un registro TXT generalmente contienen solo texto simple (sin formato) destinado a ser leído por humanos.
El mejor formato para almacenar conocimiento de forma persistente es el texto simple, en lugar de algún formato binario . [2]
Antes de principios de los años 1960, las computadoras se utilizaban principalmente para procesar números, más que para procesar texto, y la memoria era extremadamente cara. Las computadoras a menudo asignaban solo 6 bits para cada carácter, lo que permitía solo 64 caracteres; asignar códigos para AZ, az y 0-9 dejaría solo 2 códigos: ni de lejos suficientes. La mayoría de las computadoras optaron por no admitir letras minúsculas. Por lo tanto, los primeros proyectos de texto como el Index Thomisticus de Roberto Busa , el Brown Corpus y otros tuvieron que recurrir a convenciones como escribir un asterisco antes de las letras que en realidad debían ser mayúsculas.
Fred Brooks de IBM defendió firmemente la adopción de bytes de 8 bits, porque algún día la gente podría querer procesar texto, y ganó. Aunque IBM utilizó EBCDIC , la mayoría del texto a partir de entonces pasó a codificarse en ASCII , utilizando valores de 0 a 31 para caracteres de control (no imprimibles) y valores de 32 a 127 para caracteres gráficos como letras, dígitos y puntuación. La mayoría de las máquinas almacenaban caracteres en 8 bits en lugar de 7, ignorando el bit restante o utilizándolo como suma de comprobación .
La casi ubicuidad del ASCII fue de gran ayuda, pero no logró resolver los problemas internacionales y lingüísticos. El signo de dólar ("$") no era tan útil en Inglaterra, y los caracteres acentuados utilizados en español, francés, alemán, portugués, italiano y muchos otros idiomas no estaban disponibles en ASCII (sin mencionar los caracteres utilizados en griego, ruso y la mayoría de los idiomas orientales). Muchas personas, empresas y países definieron caracteres adicionales según fuera necesario, a menudo reasignando caracteres de control o utilizando valores en el rango de 128 a 255. El uso de valores superiores a 128 entra en conflicto con el uso del octavo bit como suma de comprobación, pero el uso de la suma de comprobación se fue extinguiendo gradualmente.
Estos caracteres adicionales se codificaban de forma diferente en distintos países, lo que hacía que los textos fueran imposibles de decodificar sin averiguar las reglas del creador. Por ejemplo, un navegador podría mostrar ¬A en lugar de ` si intentara interpretar un conjunto de caracteres como otro. La Organización Internacional de Normalización ( ISO ) desarrolló con el tiempo varias páginas de códigos bajo la norma ISO 8859 para dar cabida a varios idiomas. La primera de ellas ( ISO 8859-1 ) también se conoce como "Latin-1" y cubre las necesidades de la mayoría (no todas) de los idiomas europeos que utilizan caracteres basados en el latín (no había suficiente espacio para cubrirlos todos). La ISO 2022 proporcionó entonces convenciones para "cambiar" entre diferentes conjuntos de caracteres en mitad de un archivo. Muchas otras organizaciones desarrollaron variaciones de estas, y durante muchos años los ordenadores Windows y Macintosh utilizaron variaciones incompatibles.
La situación de la codificación de texto se volvió cada vez más compleja, lo que llevó a la ISO y al Consorcio Unicode a realizar esfuerzos para desarrollar una codificación de caracteres única y unificada que pudiera cubrir todos los idiomas conocidos (o al menos todos los que se conocen actualmente). Después de algunos conflictos, [ cita requerida ] estos esfuerzos se unificaron. Unicode actualmente permite 1.114.112 valores de código y asigna códigos que cubren casi todos los sistemas de escritura de texto modernos, así como muchos de los históricos y para muchos caracteres no lingüísticos, como dingbats de imprenta , símbolos matemáticos, etc.
El texto se considera texto simple independientemente de su codificación. Para comprenderlo o procesarlo correctamente, el receptor debe saber (o ser capaz de averiguar) qué codificación se utilizó; sin embargo, no necesita saber nada sobre la arquitectura informática que se utilizó ni sobre las estructuras binarias definidas por el programa (si lo hay) que creó los datos.
Quizás la forma más común de indicar explícitamente la codificación específica de texto sin formato es con un tipo MIME . Para correo electrónico y HTTP , el tipo MIME predeterminado es " text/plain ": texto sin formato sin marcado. Otro tipo MIME que se usa a menudo tanto en correo electrónico como en HTTP es " text/html ; charset=UTF-8": texto sin formato representado mediante la codificación de caracteres UTF-8 con marcado HTML. Otro tipo MIME común es "application/json": texto sin formato representado mediante la codificación de caracteres UTF-8 con marcado JSON .
Cuando se recibe un documento sin ninguna indicación explícita de la codificación de caracteres, algunas aplicaciones utilizan la detección de juegos de caracteres para intentar adivinar qué codificación se utilizó.
ASCII reserva los primeros 32 códigos (números decimales 0–31) para caracteres de control conocidos como el "conjunto C0": códigos que originalmente no estaban destinados a representar información imprimible, sino más bien a controlar dispositivos (como impresoras ) que utilizan ASCII, o a proporcionar metainformación sobre flujos de datos como los almacenados en cinta magnética. Incluyen caracteres comunes como el carácter de nueva línea y el carácter de tabulación .
En los conjuntos de caracteres de 8 bits, como Latin-1 y otros conjuntos ISO 8859 , los primeros 32 caracteres de la "mitad superior" (128 a 159) también son códigos de control, conocidos como el "conjunto C1". Rara vez se utilizan directamente; cuando aparecen en documentos que aparentemente están en una codificación ISO 8859, sus posiciones de código generalmente se refieren a los caracteres en esa posición en una codificación propietaria y específica del sistema, como Windows-1252 o Mac OS Roman , que utilizan los códigos para proporcionar caracteres gráficos adicionales.
Unicode define caracteres de control adicionales, incluidos caracteres de anulación de dirección de texto bidireccional (usados para marcar explícitamente la escritura de derecha a izquierda dentro de la escritura de izquierda a derecha y viceversa) y selectores de variación para seleccionar formas alternativas de ideogramas CJK , emoji y otros caracteres.