La limpieza de 8 bits es un atributo de los sistemas informáticos , los canales de comunicación y otros dispositivos y software que manejancorrectamente las codificaciones de caracteres de 8 bits . Dicha codificación incluye laserie ISO 8859 y la codificación UTF-8 de Unicode .
Historia
Hasta principios de la década de 1990, muchos programas y canales de transmisión de datos estaban orientados a los caracteres y trataban a algunos , como 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 usó solo siete bits por carácter, evitando una representación de 8 bits para ahorrar en costos de transmisión de datos. En computadoras y enlaces de datos que utilizan bytes de 8 bits, esto deja 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 solo 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.
Limpieza SMTP y NNTP de 8 bits
Históricamente, se utilizaron varios medios para transferir mensajes, algunos de ellos solo admitían datos de 7 bits, por lo que un mensaje de 8 bits tenía muchas posibilidades de ser distorsionado durante la transmisión en el siglo XX. Pero algunas implementaciones realmente no se preocuparon por desalentar formalmente los datos de 8 bits y permitieron que pasaran bytes de conjuntos de bits altos. Se dice que tales implementaciones son limpias de 8 bits. En general, se dice que un protocolo de comunicaciones está 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 protocolo de comunicaciones , como RFC 780 , 788 , 821 , 2821 , 5321 (para SMTP ), RFC 977 (para NNTP ) y RFC 1056 , fueron diseñados para funcionar sobre estos enlaces de comunicación de "7 bits". Requieren específicamente el uso del 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 juego de caracteres US-ASCII de 7 bits. [2]
La Definición RFC 788 de SMTP, como 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]
Más tarde, el formato de los mensajes de correo electrónico se redefinió para admitir mensajes que no son enteramente texto US-ASCII (mensajes de texto en conjuntos de caracteres que no sean US-ASCII, y mensajes que no son de texto, como audio e imágenes). [6]
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, incluyendo RFC 2047 [9] y RFC 2231 [10] Codificación MIME de datos no ASCII.
La comunidad de Internet generalmente agrega funciones por extensión , lo que permite la comunicación en ambas direcciones entre las máquinas actualizadas y las 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 la década de 1990, la gente [ ¿quién? ] se opuso a "enviar 8 bits (a RFC 821 SMTP servers) ", quizás debido a la percepción de que" solo envíe 8 bits "es una declaración implícita de que ISO 8859-1 se convierte en la nueva" codificación estándar ", lo que obliga a todos en el mundo a utilizar el mismo conjunto de caracteres . [ Original ¿investigación? ] En cambio, la forma recomendada de aprovechar los enlaces limpios de 8 bits entre máquinas es utilizar el ESMTP ( RFC 1869 ) Extensión 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 , especialmente Exim y qmail , retransmiten el correo a servidores que no anuncian 8BITMIME sin realizar la conversión a MIME de 7 bits (normalmente entre comillas imprimibles , "conversión QP") requerida por RFC 6152 . Esta actitud de "solo enviar 8" no causa problemas en la práctica, ya que prácticamente todos los servidores de correo electrónico modernos están limpios de 8 bits. [14]
Ver también
- 32 bits limpio
- MIME § Codificación de transferencia de contenido
- Telnet § datos de 8 bits
Referencias
- ^ RFC 780 : Apéndice A, RFC 788 : 4.5.2., RFC 821 : Apéndice B, RFC 1056 : 4.
- ^ John Beck. "Correo electrónico explicado" . 2011.
- ^ Jonathan B. Postel (noviembre de 1981). "4.5.3. TAMAÑOS". PROTOCOLO DE TRANSFERENCIA DE CORREO SIMPLE . doi : 10.17487 / RFC0788 . RFC 788 .
La longitud total máxima de una línea de texto, incluido el
, es de 1000 caracteres (pero sin contar el punto inicial duplicado para la transparencia). - ^ G. Vaudreuil (febrero de 1993). "2. El problema". Transición del correo de Internet de Just-Send-8 a 8bit-SMTP / MIME . doi : 10.17487 / RFC1428 . RFC 1428 .
SMTP como se define en RFC 821 limita el envío de correo de Internet a caracteres US-ASCII.
- ^ Dan Sugalski. "Correo electrónico con archivos adjuntos" . "El diario de Perl". Verano de 1999. "Cuando el correo se estandarizó allá por 1982 con RFC822, ... Los únicos límites puestos en el cuerpo eran el juego de caracteres (ASCII de 7 bits) y la longitud máxima de línea (1000 caracteres)".
- ^ a b N. Freed; N. Borenstein (noviembre de 1996). "Resumen". Extensiones multipropósito de correo de Internet (MIME) Parte uno: formato de los cuerpos de mensajes de Internet . doi : 10.17487 / RFC2045 . RFC 2045 .
Extensiones multipropósito de correo de Internet, o MIME , redefine el formato de los mensajes
- ^ C. Feather (octubre de 2006). Protocolo de transferencia de noticias por red (NNTP) . doi : 10.17487 / RFC3977 . RFC 3977 .
- ^ C. Lindsey; D. Kohn (noviembre de 2009). K. Murchison (ed.). Formato del artículo de Netnews . doi : 10.17487 / RFC5536 . RFC 5536 .
- ^ K. Moore (noviembre de 1996). MIME (Extensiones multipropósito de correo de Internet) Tercera parte: Extensiones de encabezado de mensaje para texto no ASCII . doi : 10.17487 / RFC2047 . RFC 2047 .
- ^ N. Freed; K. Moore (noviembre de 1997). Valor de parámetro MIME y extensiones de palabras codificadas: juegos de caracteres, idiomas y continuaciones . doi : 10.17487 / RFC2231 . RFC 2231 .
- ^ Theodore Ts'o ; Keith Moore ; Mark Crispin (12 de septiembre de 1994). "Transmisión de 8 bits en NNTP" . Lista de correo IETF -SMTP . Archivado desde el original el 20 de marzo de 2012 . Consultado el 3 de abril de 2010 .
- ^ "Preguntas frecuentes de comp.mail.mime, parte 3 '¿Qué es ESMTP y cómo afecta a MIME? ' " . Preguntas frecuentes de Usenet . 8 de agosto de 1997. Archivado desde el original el 18 de enero de 2012 . Consultado el 3 de abril de 2010 .
- ^ J. Yao; W. Mao (febrero de 2012). Extensión SMTP para correo electrónico internacionalizado . doi : 10.17487 / RFC8531 . RFC 8531 .
- ^ "La extensión 8BITMIME" .