La limpieza de 8 bits es un atributo de los sistemas informáticos , canales de comunicación y otros dispositivos y software que procesan codificaciones de caracteres de 8 bits sin tratar ningún byte como un código de control dentro de banda .
Hasta principios de la década de 1990, muchos programas y canales de transmisión de datos estaban orientados a caracteres y trataban algunos caracteres, por ejemplo, ETX , como caracteres de control . Otros asumieron un flujo de caracteres de siete bits, con valores entre 0 y 127; por ejemplo, el estándar ASCII utilizaba sólo siete bits por carácter, evitando una representación de 8 bits para ahorrar costes de transmisión de datos. En computadoras y enlaces de datos que utilizan bytes de 8 bits, esto dejaba el bit superior de cada byte libre para su uso como bit de paridad , bit de bandera o bit de control de metadatos. Los sistemas de 7 bits y los enlaces de datos no pueden manejar directamente códigos de caracteres más complejos que son comunes en países de habla no inglesa con alfabetos más grandes .
Los archivos binarios de octetos no se pueden transmitir directamente a través de canales de datos de 7 bits. Para solucionar este problema, se han ideado codificaciones de binario a texto que utilizan sólo caracteres ASCII de 7 bits . Algunas de estas codificaciones son uuencoding , Ascii85 , SREC , BinHex , kermit y MIME 's Base64 . Los sistemas basados en EBCDIC no pueden manejar todos los caracteres utilizados en datos codificados en UU. Sin embargo, la codificación base64 no tiene este problema.
Históricamente, se utilizaban varios medios para transferir mensajes, algunos de ellos sólo admitían datos de 7 bits, por lo que un mensaje de 8 bits tenía muchas posibilidades de ser confuso durante la transmisión en el siglo XX. Pero a algunas implementaciones realmente no les importaba desalentar formalmente los datos de 8 bits y permitían el paso de bytes con conjuntos de bits altos. Se dice que estas implementaciones son limpias de 8 bits. En general, se dice que un protocolo de comunicaciones es limpio de 8 bits si pasa correctamente por el bit alto de cada byte en el proceso de comunicación.
Muchos de los primeros estándares de protocolos de comunicaciones , como RFC 780, 788, 821, 2821, 5321 (para SMTP ), RFC 977 (para NNTP ) y RFC 1056, fueron diseñados para funcionar con enlaces de comunicación de "7 bits". Requieren específicamente el uso de un juego de caracteres ASCII "transmitido como un byte de 8 bits con el bit de orden superior puesto a cero" y algunos de estos [1] restringen explícitamente todos los datos a caracteres de 7 bits.
Durante las primeras décadas de las redes de correo electrónico (1971 hasta principios de la década de 1990), la mayoría de los mensajes de correo electrónico eran texto sin formato en el conjunto de caracteres US-ASCII de 7 bits. [2]
La definición RFC 788 de SMTP, al igual que su predecesor RFC 780, limita el correo de Internet a líneas (1000 caracteres o menos) de caracteres US-ASCII de 7 bits. [3] [4] [5] [6]
Posteriormente, se redefinió el formato de los mensajes de correo electrónico para admitir mensajes que no sean exclusivamente texto US-ASCII (mensajes de texto con conjuntos de caracteres distintos de US-ASCII y mensajes que no sean de texto, como audio e imágenes). [6] El campo de encabezado Content-Transfer-Encoding=binary [a] requiere un transporte limpio de 8 bits.
RFC 3977 [7] especifica "NNTP opera sobre cualquier canal de flujo de datos bidireccional confiable de 8 bits de ancho". y cambia el juego de caracteres para los comandos a UTF-8. Sin embargo, RFC 5536 [8] todavía limita el juego de caracteres a ASCII, incluida la codificación MIME RFC 2047 [9] y RFC 2231 [10] de datos que no son ASCII.
La comunidad de Internet generalmente agrega características por extensión , permitiendo la comunicación en ambas direcciones entre máquinas actualizadas y máquinas aún no actualizadas, en lugar de declarar que el software heredado que anteriormente cumplía con los estándares está "roto" e insistir en que todo el software en todo el mundo se actualice a la última versión. estándar. A mediados de los años 1990, la gente [ ¿quién? ] se opuso a "simplemente enviar 8 bits (a servidores SMTP RFC 821)", tal vez debido a la percepción de que "simplemente enviar 8 bits" es una declaración implícita de que ISO 8859-1 se convertirá en la nueva "codificación estándar", lo que obliga a todos en el mundo para utilizar el mismo conjunto de caracteres . [ ¿investigacion original? ] En su lugar, la forma recomendada de aprovechar los enlaces limpios de 8 bits entre máquinas es utilizar la extensión ESMTP ( RFC 1869) 8BITMIME [11] [12] para los cuerpos de los mensajes y la extensión SMTP SMTPUTF8 [13] para los encabezados de los mensajes. A pesar de esto, algunos agentes de transferencia de correo , en particular Exim y qmail , retransmiten correo a servidores que no anuncian 8BITMIME sin realizar la conversión a MIME de 7 bits (normalmente "conversión QP" imprimible entre comillas ) requerida por RFC 6152. Esto "sólo -send-8" en realidad no causa problemas en la práctica, ya que prácticamente todos los servidores de correo electrónico modernos están limpios en 8 bits. [14]
La longitud total máxima de una línea de texto, incluido el <CRLF>, es de 1000 caracteres (pero sin contar el punto inicial duplicado para transparencia).
SMTP, tal como se define en RFC 821, limita el envío de correo de Internet a caracteres US-ASCII.
Extensiones multipropósito de correo de Internet, o
MIME
, redefine el formato de los mensajes