Texto sin formato

Archivo de texto con porción de El lado humano de los animales por Royal Dixon, mostrado por el comando cat en una ventana xterm

En informática, texto sin formato es un término impreciso para datos (p. ej., contenidos de archivos) 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 "espacios en blanco" caracteres que afectan la disposición simple del texto, como espacios, saltos de línea o caracteres de tabulación (aunque los caracteres de tabulación pueden "significar" muchas cosas diferentes, por lo que difícilmente son "simples"). El texto sin formato es diferente del texto con formato, donde se incluye información de estilo; de texto estructurado, donde se identifican partes estructurales del documento como párrafos, secciones y similares; y de archivos binarios en los que algunas partes deben interpretarse como objetos binarios (enteros codificados, números reales, imágenes, etc.).

El término a veces se usa de manera bastante vaga, para referirse a archivos que contienen solo "legibles" contenido (o simplemente archivos sin nada que el hablante no prefiera). Por ejemplo, eso podría excluir cualquier indicación de fuentes o diseño (como marcado, descuento o incluso tabulaciones); caracteres como comillas, espacios de no separación, guiones suaves, guiones largos y/o ligaduras; u otras cosas.

En principio, el texto sin formato puede estar en cualquier codificación, pero en ocasiones se considera que el término implica ASCII. A medida que las codificaciones basadas en Unicode, como UTF-8 y UTF-16, se vuelven más comunes, ese uso puede reducirse.

El texto sin formato también se usa a veces solo para excluir archivos "binarios" archivos: aquellos en los que al menos algunas partes del archivo no pueden interpretarse correctamente mediante 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 número entero binario que no es solo un carácter(es), es un archivo binario, no texto sin formato ni siquiera para los usos comunes más imprecisos. Dicho de otra manera, traducir un archivo de texto sin formato a una codificación de caracteres que usa números completamente diferentes para representar caracteres no cambia el significado (siempre que sepa qué codificación está en uso), pero para archivos binarios, tal conversión sí cambiar el significado de al menos algunas partes del archivo.

Texto sin formato y texto enriquecido

Según el estándar Unicode:

• "El texto de texto es una secuencia pura de códigos de caracteres; texto sin cifrado simple es por lo tanto una secuencia de códigos de caracteres Unicode.
• En cambio, texto de estilo, también conocido como texto rico, es cualquier representación de texto que contenga texto plano más información agregada como un identificador de lenguaje, tamaño de fuente, color, enlaces de hipertexto, etc.
• SGML, RTF, HTML, XML y TeX son ejemplos de texto rico totalmente representado como flujos de texto simples, intercalando datos de texto plano con secuencias de caracteres que representan las estructuras de datos adicionales."

Sin embargo, de acuerdo con otras definiciones, los archivos que contienen marcado u otros metadatos generalmente se consideran texto sin formato, siempre que el marcado también esté en una forma directamente legible por 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 del lenguaje de programación, se consideran texto sin formato. El contenido particular es irrelevante para saber 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 sin formato 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, todos los problemas de Endianness pueden evitarse (con codificaciones como UCS-2 en lugar de UTF-8, endianness importa, pero uniformemente para cada carácter, en lugar de subconjuntos potencialmente desconocidos).

Uso

El propósito de usar texto sin formato hoy en día es principalmente la independencia de los programas que requieren su propia codificación o formato especial o formato de archivo. Los archivos de texto sin formato se pueden abrir, leer y editar con utilidades y editores de texto ubicuos.

Una interfaz de línea de comandos permite a las personas dar comandos en texto sin formato y obtener una respuesta, también normalmente en texto sin formato.

Muchos otros programas informáticos también son capaces de procesar o crear texto sin formato, como innumerables programas en DOS, Windows, Mac OS clásico y Unix y sus parientes; así como navegadores web (algunos navegadores como Lynx y el navegador de modo de línea producen solo texto sin formato para mostrar) y otros lectores de texto electrónico.

Los archivos de texto sin formato son casi universales en la 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 los archivos de configuración, que se leen para las configuraciones guardadas al inicio de un programa.

El texto sin formato se utiliza para muchos correos electrónicos.

Un comentario, un ".txt" archivo, o un registro TXT generalmente contiene solo texto sin formato (sin formato) destinado a que lo lean los humanos.

El mejor formato para almacenar conocimiento de forma persistente es el texto sin formato, en lugar de algún formato binario.

Codificación

Codificaciones de caracteres

Antes de principios de la década de 1960, las computadoras se usaban principalmente para procesar números en lugar de texto, y la memoria era extremadamente costosa. Las computadoras a menudo asignaban solo 6 bits para cada carácter, lo que permitía solo 64 caracteres; la asignación de códigos para A-Z, a-z y 0-9 dejaría solo 2 códigos: ni mucho menos lo suficiente. 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 pretendían estar en mayúsculas.

Fred Brooks de IBM abogó firmemente por pasar a bytes de 8 bits, porque algún día la gente podría querer procesar texto; y ganó. Aunque IBM usó EBCDIC, la mayoría del texto a partir de ese momento se codificó en ASCII, usando 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 almacenan caracteres en 8 bits en lugar de 7, ignorando el bit restante o usándolo como suma de verificación.

La casi ubicuidad de ASCII fue de gran ayuda, pero no abordó las preocupaciones lingüísticas e internacionales. 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 y muchos otros idiomas no estaban disponibles en ASCII (sin mencionar los caracteres utilizado 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 usando 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 verificación, pero el uso de la suma de verificación se extinguió gradualmente..

Estos caracteres adicionales se codificaron de manera diferente en diferentes países, lo que hace que los textos sean imposibles de decodificar sin conocer las reglas del autor. Por ejemplo, un navegador puede mostrar ¬A en lugar de ` si intenta interpretar un conjunto de caracteres como otro. La Organización Internacional de Normalización (ISO) finalmente desarrolló varias páginas de códigos bajo ISO 8859, para adaptarse a varios idiomas. El primero de ellos (ISO 8859-1) también se conoce como "Latin-1" y cubre las necesidades de la mayoría de los idiomas europeos (no todos) que usan caracteres latinos (no había suficiente espacio para cubrirlos todos). ISO 2022 luego proporcionó convenciones para "cambiar" entre diferentes juegos de caracteres en medio del archivo. Muchas otras organizaciones desarrollaron variaciones de estos, y durante muchos años las computadoras Windows y Macintosh usaron variaciones incompatibles.

La situación de la codificación de texto se volvió cada vez más compleja, lo que llevó a que ISO y Unicode Consortium se esforzaran por 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 algún conflicto, 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 históricos, y para muchos caracteres no lingüísticos como dingbats de impresora, símbolos matemáticos, etc.

El texto se considera texto sin formato, independientemente de su codificación. Para comprenderlo o procesarlo correctamente, el destinatario debe saber (o ser capaz de averiguar) qué codificación se utilizó; sin embargo, no necesitan saber nada sobre la arquitectura de la computadora que se usó, o sobre las estructuras binarias definidas por cualquier 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 "texto/sin formato" -- texto sin formato sin marcado. Otro tipo de MIME que se usa a menudo tanto en correo electrónico como en HTTP es "text/html; juego de caracteres=UTF-8" -- texto sin formato representado usando la codificación de caracteres UTF-8 con marcado HTML. Otro tipo MIME común es "aplicación/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 juego de caracteres para intentar adivinar qué codificación se utilizó.

Códigos de control

ASCII reserva los primeros 32 códigos (números del 0 al 31 decimales) para los caracteres de control conocidos como el "conjunto C0": códigos originalmente destinados a no representar información imprimible, sino a dispositivos de control (como impresoras) que hacen uso de ASCII, o para proporcionar metainformación sobre flujos de datos como los almacenados en cinta magnética. Incluyen caracteres comunes como la nueva línea y el carácter de tabulación.

En conjuntos de caracteres de 8 bits como Latin-1 y los 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 usan 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 patentada específica del sistema, como Windows-1252 o Mac OS Roman, que usan los códigos para proporcionar en su lugar caracteres gráficos adicionales.

Unicode define caracteres de control adicionales, incluidos los caracteres de anulación de dirección de texto bidireccional (utilizados para marcar explícitamente la escritura de derecha a izquierda dentro de la escritura de izquierda a derecha y al revés) y selectores de variación para seleccionar formas alternativas de CJK ideografías, emoji y otros personajes.