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 en banda .
Hasta principios de los años 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 asumían 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 en costes de transmisión de datos. En ordenadores y enlaces de datos que utilizaban bytes de 8 bits , esto dejaba el bit superior de cada byte libre para su uso como 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 habituales 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 solo caracteres ASCII de 7 bits . Algunas de estas codificaciones son uuencoding , Ascii85 , SREC , BinHex , kermit y Base64 de MIME . Los sistemas basados en EBCDIC no pueden manejar todos los caracteres utilizados en datos UUencoded. Sin embargo, la codificación base64 no tiene este problema.
Históricamente, se han utilizado varios medios para transferir mensajes, algunos de los cuales solo admiten datos de 7 bits, por lo que un mensaje de 8 bits tenía muchas posibilidades de ser ilegible durante la transmisión en el siglo XX. Pero algunas implementaciones realmente no se preocupaban por desalentar formalmente los datos de 8 bits y permitían que pasaran bytes con valores altos. Se dice que estas implementaciones son de 8 bits limpios. En general, se dice que un protocolo de comunicaciones es de 8 bits limpio 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 en dichos enlaces de comunicación de "7 bits". Requieren específicamente el uso del conjunto de caracteres ASCII "transmitido como un byte de 8 bits con el bit de orden superior puesto a cero" y algunos de ellos [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 a principios de los años 1990), la mayoría de los mensajes de correo electrónico eran texto simple en el conjunto de caracteres US-ASCII de 7 bits. [2]
La definición de SMTP del RFC 788, al igual que su predecesor, el 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]
Más tarde, se redefinió el formato de los mensajes de correo electrónico para admitir mensajes que no sean completamente texto US-ASCII (mensajes de texto en 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 que "NNTP opera sobre cualquier canal de flujo de datos bidireccional confiable de 8 bits de ancho" y cambia el conjunto de caracteres para los comandos a UTF-8. Sin embargo, RFC 5536 [8] aún limita el conjunto de caracteres a ASCII, incluida la codificación MIME de RFC 2047 [9] y RFC 2231 [10] de datos que no sean ASCII.
La comunidad de Internet generalmente agrega características por extensión , lo que permite la comunicación en ambas direcciones entre máquinas actualizadas y máquinas que aún no se han actualizado, en lugar de declarar que el software heredado que anteriormente cumplía con los estándares estaba "roto" e insistir en que todo el software en todo el mundo se actualizara al último estándar. A mediados de la década de 1990, la gente [ ¿quién? ] se opuso a "solo enviar 8 bits (a los servidores SMTP RFC 821)", quizás debido a la percepción de que "solo enviar 8 bits" es una declaración implícita de que ISO 8859-1 se convertirá en la nueva "codificación estándar", obligando a todos en el mundo a usar el mismo conjunto de caracteres . [¿ investigación original? ] En cambio, la forma recomendada de aprovechar los enlaces limpios de 8 bits entre máquinas es usar 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 quoted-printable , "conversión QP") requerida por RFC 6152. Esta actitud de "solo enviar 8" de hecho no causa problemas en la práctica, ya que prácticamente todos los servidores de correo electrónico modernos son de 8 bits limpios. [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 por transparencia).
SMTP, tal como se define en RFC 821, limita el envío de correo de Internet a caracteres US-ASCII.
Las extensiones multipropósito de correo de Internet, o
MIME
, redefinen el formato de los mensajes.