stringtranslate.com

8 bits limpios

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 .

Historia

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.

Limpieza de 8 bits de SMTP y NNTP

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, se diseñaron para funcionar en 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", lo que obliga 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]

Véase también

Notas

  1. ^ El campo de encabezado Content-Transfer-Encoding=8BIT no designa limpieza de 8 bits, ya que CRLF tiene un significado especial.

Referencias

  1. ^ RFC  780: Apéndice A, RFC  788: 4.5.2., RFC  821: Apéndice B, RFC  1056: 4.
  2. ^ John Beck. "El correo electrónico explicado". 2011.
  3. ^ Jonathan B. Postel (noviembre de 1981). "4.5.3. TAMAÑOS". PROTOCOLO SIMPLE DE TRANSFERENCIA DE CORREO. doi : 10.17487/RFC0788 . RFC 788. 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).
  4. ^ 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, tal como se define en RFC 821, limita el envío de correo de Internet a caracteres US-ASCII.
  5. ^ Dan Sugalski. "Correo electrónico con archivos adjuntos". "The Perl Journal". Verano de 1999. "Cuando el correo se estandarizó en 1982 con RFC822, ... Los únicos límites impuestos al cuerpo del mensaje eran el conjunto de caracteres (ASCII de 7 bits) y la longitud máxima de línea (1000 caracteres)."
  6. ^ ab N. Freed; N. Borenstein (noviembre de 1996). "Abstracto". Extensiones multipropósito de correo de Internet (MIME), primera parte: formato de los cuerpos de los mensajes de Internet. doi : 10.17487/RFC2045 . RFC 2045. Las extensiones multipropósito de correo de Internet, o MIME , redefinen el formato de los mensajes.
  7. ^ C. Feather (octubre de 2006). Protocolo de transferencia de noticias en red (NNTP). doi : 10.17487/RFC3977 . RFC 3977.
  8. ^ C. Lindsey; D. Kohn (noviembre de 2009). K. Murchison (ed.). Formato de artículo de Netnews. doi : 10.17487/RFC5536 . RFC 5536.
  9. ^ K. Moore (noviembre de 1996). MIME (Multipurpose Internet Mail Extensions) Tercera parte: extensiones de encabezado de mensaje para texto no ASCII. doi : 10.17487/RFC2047 . RFC 2047.
  10. ^ N. Freed; K. Moore (noviembre de 1997). Valores de parámetros MIME y extensiones de palabras codificadas: conjuntos de caracteres, idiomas y continuaciones. doi : 10.17487/RFC2231 . RFC 2231.
  11. ^ 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 .
  12. ^ "comp.mail.mime FAQ, parte 3 '¿Qué es ESMTP y cómo afecta a MIME?'". Usenet FAQ . 8 de agosto de 1997. Archivado desde el original el 18 de enero de 2012 . Consultado el 3 de abril de 2010 .
  13. ^ J. Yao; W. Mao (febrero de 2012). Extensión SMTP para correo electrónico internacionalizado. doi : 10.17487/RFC8531 . RFC 8531.
  14. ^ "La extensión 8BITMIME".