Codificación de binario a texto

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) Este artículo posiblemente contiene investigación original .Por favor, mejórelo verificando las afirmaciones realizadas y agregando citas en línea . Las afirmaciones que consistan únicamente en investigaciones originales deben eliminarse. ( Abril de 2010 )( Aprenda cómo y cuándo eliminar este mensaje ) Este artículo necesita citas adicionales para su verificación .Por favor, ayude a mejorar este artículo añadiendo citas de fuentes confiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Codificación de binario a texto» – noticias  · periódicos  · libros  · académico  · JSTOR ( Diciembre 2012 )( Aprenda cómo y cuándo eliminar este mensaje ) ( Aprenda cómo y cuándo eliminar este mensaje )

Una codificación de binario a texto es una codificación de datos en texto simple . Más precisamente, es una codificación de datos binarios en una secuencia de caracteres imprimibles . Estas codificaciones son necesarias para la transmisión de datos cuando el canal de comunicación no permite datos binarios (como correo electrónico o NNTP ) o no es de 8 bits limpio . La documentación de PGP ( RFC  4880) utiliza el término " armadura ASCII " para la codificación de binario a texto cuando se hace referencia a Base64 .

La necesidad básica de una codificación de binario a texto surge de la necesidad de comunicar datos binarios arbitrarios a través de protocolos de comunicación preexistentes que fueron diseñados para transmitir únicamente texto legible por humanos en idioma inglés . Esos protocolos de comunicación pueden ser seguros sólo en 7 bits (y, dentro de ese límite, evitar ciertos códigos de control ASCII), y pueden requerir saltos de línea en ciertos intervalos máximos, y pueden no mantener espacios en blanco . Por lo tanto, sólo los 94 caracteres ASCII imprimibles son "seguros" para utilizarlos para transmitir datos.

El estándar de codificación de texto ASCII utiliza 7 bits para codificar caracteres. Con esto es posible codificar 128 (es decir, 2 ⁷ ) valores únicos (0–127) para representar los caracteres alfabéticos, numéricos y de puntuación que se usan comúnmente en inglés , además de una selección de caracteres de control que no representan caracteres imprimibles. Por ejemplo, la letra mayúscula A se representa en 7 bits como 100 0001 ₂ , 0x41 (101 ₈ ) , el numeral 2 es 011 0010 ₂ 0x32 (62 ₈ ), el carácter } es 111 1101 ₂ 0x7D (175 ₈ ), y el carácter de control RETURN es 000 1101 ₂ 0x0D (15 ₈ ).

En cambio, la mayoría de los ordenadores almacenan los datos en la memoria organizados en bytes de ocho bits . Los archivos que contienen código ejecutable por máquina y datos no textuales suelen contener los 256 valores posibles de bytes de ocho bits. Muchos programas informáticos empezaron a depender de esta distinción entre texto de siete bits y datos binarios de ocho bits , y no funcionaban correctamente si aparecían caracteres no ASCII en datos que se esperaba que incluyeran solo texto ASCII. Por ejemplo, si no se conserva el valor del octavo bit, el programa podría interpretar un valor de byte superior a 127 como una señal que le indica que debe realizar alguna función.

Sin embargo, a menudo es deseable poder enviar datos no textuales a través de sistemas basados ​​en texto, como cuando se adjunta un archivo de imagen a un mensaje de correo electrónico. Para lograr esto, los datos se codifican de alguna manera, de modo que los datos de ocho bits se codifican en caracteres ASCII de siete bits (generalmente utilizando solo caracteres alfanuméricos y de puntuación, los caracteres imprimibles ASCII). Una vez que llegan sanos y salvos a su destino, se decodifican nuevamente a su formato de ocho bits. Este proceso se conoce como codificación de binario a texto. Muchos programas realizan esta conversión para permitir el transporte de datos, como PGP y GNU Privacy Guard .

Los métodos de codificación de binario a texto también se utilizan como mecanismo para codificar texto simple . Por ejemplo:

• Algunos sistemas tienen un conjunto de caracteres más limitado que pueden manejar; no sólo no son limpios a nivel de 8 bits , sino que algunos ni siquiera pueden manejar todos los caracteres ASCII imprimibles.
• Otros sistemas tienen límites en la cantidad de caracteres que pueden aparecer entre saltos de línea, como el límite de "1000 caracteres por línea" de algunos programas de Protocolo simple de transferencia de correo , según lo permite el RFC  2821.
• Otros añaden encabezados o trailers al texto.
• Algunos protocolos poco valorados pero que aún se utilizan utilizan señalización en banda , lo que provoca confusión si aparecen patrones específicos en el mensaje. El más conocido es la cadena "From" (incluido el espacio final) al principio de una línea, que se utiliza para separar los mensajes de correo en el formato de archivo mbox .

Al utilizar una codificación de binario a texto en mensajes que ya son texto simple y luego decodificarlos en el otro extremo, se puede lograr que dichos sistemas parezcan completamente transparentes . A esto a veces se lo denomina "blindaje ASCII". Por ejemplo, el componente ViewState de ASP.NET utiliza codificación base64 para transmitir texto de forma segura a través de HTTP POST, con el fin de evitar colisiones de delimitadores .

La siguiente tabla compara las formas más utilizadas de codificación de binario a texto. La eficiencia que se indica es la relación entre la cantidad de bits en la entrada y la cantidad de bits en la salida codificada.

Codificación	Tipo de datos	Eficiencia	Implementaciones de lenguajes de programación	Comentarios
Ascii85	Arbitrario	80%	awk Archivado el 29 de diciembre de 2014 en Wayback Machine , C, C (2), C#, F#, Go, Java Perl, Python, Python (2)	Existen varias variantes de esta codificación, Base85 , btoa , etc.
Base32	Arbitrario	62,5%	ANSI C, Delphi, Go, Java, C#, F#, Python
Base36	Entero	~64%	bash, C , C++ , C# , Java , Perl , PHP , Python , Visual Basic, Swift y muchos otros	Utiliza los números arábigos del 0 al 9 y las letras latinas de la A a la Z (el alfabeto latino básico de la ISO ). Los sistemas de redirección de URL, como TinyURL o SnipURL/Snipr, suelen utilizarlos como identificadores alfanuméricos compactos.
Base45	Arbitrario	~67% (97% [a] )	¡Vamos, Python!	Definido en la especificación IETF RFC 9285 para incluir datos binarios de forma compacta en un código QR . [1]
Base56	Entero	—	PHP, Python, Go	Una variante de la codificación Base58 que elimina aún más los caracteres "1" y "o" minúscula para minimizar el riesgo de fraude y error humano. [2]
Base58	Entero	~73%	C, C++, Python, C#, Java	Similar a Base64, pero modificado para evitar caracteres no alfanuméricos (+ y /) y letras que podrían parecer ambiguas cuando se imprimen (0 – cero, I – i mayúscula, O – o mayúscula y l – L minúscula). Base58 se utiliza para representar direcciones de bitcoin . [ cita requerida ] Algunos sistemas de mensajería y redes sociales dividen líneas en cadenas no alfanuméricas. Esto se evita al no utilizar caracteres reservados para URI como +. Para SegWit , fue reemplazado por Bech32, vea a continuación.
Base62	Arbitrario	~74%	Óxido, pitón	Similar a Base64, pero contiene sólo caracteres alfanuméricos.
Base64	Arbitrario	75%	awk Archivado el 29 de diciembre de 2014 en Wayback Machine , C, C (2), Delphi, Go, Python, muchos otros	Una codificación temprana y aún popular, especificada por primera vez como parte del RFC  989 en 1987
Base85	Arbitrario	80%	C, Python, Python (2)	Versión revisada de Ascii85 .
Base91 [3]	Arbitrario	81%	Do# Fa#	Variante de ancho constante
base91 [4]	Arbitrario	81%	C, Java, PHP, ensamblaje 8086, AWK C#, F#, Rust	Variante de ancho variable
Base94 [5]	Arbitrario	82%	Python, C, óxido
Base122 [6]	Arbitrario	87,5%	JavaScript, Python, Java, Base125 Python y Javascript, Go, C
BaseXML [7]	Arbitrario	83,5%	C Python JavaScript
Playa32	Arbitrario	62,5 % + al menos 8 caracteres (etiqueta, separador, ECC de 6 caracteres )	C, C++, JavaScript , Go , Python, Haskell , Ruby y Rust	Especificación. [8] Se utiliza en Bitcoin y en la red Lightning . [9] La parte de datos está codificada como Base32 con la posibilidad de comprobar y corregir hasta 6 caracteres mal escritos utilizando el código BCH de 6 caracteres al final, que también comprueba/corrige la parte legible por humanos. La variante Bech32m tiene un cambio sutil que la hace más resistente a los cambios de longitud. [10]
BinHex	Arbitrario	75%	Perl, C, C (2)	MacOS clásico
Decimal	Entero	~42%	La mayoría de los idiomas	Generalmente es la representación predeterminada para entrada/salida desde/hacia humanos.
Hexadecimal (Base 16)	Arbitrario	50%	La mayoría de los idiomas	Existe en variantes en mayúsculas y minúsculas .
Intel HEX	Arbitrario	≲50%	Biblioteca C, C++	Generalmente se utiliza para programar chips de memoria flash EPROM y NOR.
MÍMICA	Arbitrario	Ver Quoted-printable y Base64	Ver Quoted-printable y Base64	Contenedor de codificación para formato similar al del correo electrónico
Codificación porcentual	Texto ( URI ), arbitrario (RFC1738)	~40% [b] (33–70% [c] )	C, Python y probablemente muchos otros
Citado-imprimible	Texto	~33–100% [d]	Probablemente muchos	Conserva los saltos de línea; corta líneas a los 76 caracteres
Registro S (Motorola hexadecimal)	Arbitrario	49,6%	Biblioteca C, C++	Generalmente se utiliza para programar chips de memoria flash EPROM y NOR . El 49,6 % supone 255 bytes binarios por registro.
Hexágono Tektronix	Arbitrario			Generalmente se utiliza para programar chips de memoria flash EPROM y NOR .
Esclerosis múltiple transmisible	Hexadecimal	~32%	Node.js (y CLI)	Se utiliza para transmitir transacciones de Blockchain a través de SMS utilizando UTF-16BE .
Codificación Uuen	Arbitrario	~60% ( hasta 70% )	Perl , C, Delphi, Java, Python y probablemente muchos otros.	Una codificación temprana desarrollada en 1980 para la copia de Unix a Unix . Reemplazada en gran medida por MIME y yEnc
Codificación Xx	Arbitrario	~75% (similar a Uuencoding)	C, Delfos	Propuesto (y usado ocasionalmente) como reemplazo de Uuencoding para evitar problemas de traducción de conjuntos de caracteres entre ASCII y los sistemas EBCDIC que podrían dañar los datos Uuencoded.
z85 (especificación ZeroMQ: 32/Z85)	Binario y ASCII	80% (similar a Ascii85/Base85)	C (original), C#, Dart, Erlang, Go, Lua, Ruby, Rust y otros	Especifica un subconjunto de ASCII similar a Ascii85 , omitiendo algunos caracteres que pueden causar errores en el programa ( ` \ " ' _ , ;). El formato cumple con la especificación ZeroMQ:32/Z85.
RFC  1751 ( S/CLAVE )	Arbitrario	33%	C, [11] Python	"Una convención para claves de 128 bits legibles por humanos ". Una serie de pequeñas palabras en inglés es más fácil de leer, recordar y escribir para los humanos que los sistemas de codificación decimal u otros sistemas de codificación de binario a texto. [12] Cada número de 64 bits se asigna a seis palabras cortas, de uno a cuatro caracteres cada una, de un diccionario público de 2048 palabras. [11]

Los 95 códigos isprint del 32 al 126 se conocen como caracteres imprimibles ASCII .

Algunos formatos más antiguos y hoy en día poco comunes incluyen la codificación BOO, BTOA y USR.

La mayoría de estas codificaciones generan texto que contiene solo un subconjunto de todos los caracteres ASCII imprimibles: por ejemplo, la codificación base64 genera texto que solo contiene letras mayúsculas y minúsculas (A–Z, a–z), números (0–9) y los símbolos "+", "/" y "=".

Algunas de estas codificaciones (codificación imprimible entre comillas y codificación porcentual) se basan en un conjunto de caracteres permitidos y un único carácter de escape . Los caracteres permitidos no se modifican, mientras que todos los demás caracteres se convierten en una cadena que comienza con el carácter de escape. Este tipo de conversión permite que el texto resultante sea casi legible, ya que las letras y los dígitos son parte de los caracteres permitidos y, por lo tanto, se dejan como están en el texto codificado. Estas codificaciones producen la salida ASCII simple más corta para la entrada que es principalmente ASCII imprimible.

Algunas otras codificaciones ( base64 , uuencoding ) se basan en la asignación de todas las secuencias posibles de seis bits a diferentes caracteres imprimibles. Dado que hay más de 2 ⁶  = 64 caracteres imprimibles, esto es posible. Una secuencia dada de bytes se traduce viéndola como un flujo de bits, dividiendo este flujo en fragmentos de seis bits y generando la secuencia de caracteres correspondiente. Las diferentes codificaciones difieren en la asignación entre secuencias de bits y caracteres y en cómo se formatea el texto resultante.

Algunas codificaciones (la versión original de BinHex y la codificación recomendada para CipherSaber ) utilizan cuatro bits en lugar de seis, lo que hace que todas las secuencias posibles de 4 bits se asignen a los 16 dígitos hexadecimales estándar . El uso de 4 bits por carácter codificado genera una salida un 50 % más larga que la de base64, pero simplifica la codificación y la decodificación: expandir cada byte de la fuente de forma independiente a dos bytes codificados es más simple que expandir 3 bytes de la fuente a 4 bytes codificados en base64.

De los primeros 192 códigos de PETSCII , 164 tienen representaciones visibles cuando se citan: 5 (blanco), 17–20 y 28–31 (colores y controles del cursor), 32–90 (equivalente ascii), 91–127 (gráficos), 129 (naranja), 133–140 (teclas de función), 144–159 (colores y controles del cursor) y 160–192 (gráficos). ^[13] Esto teóricamente permite codificaciones, como base128, entre máquinas que hablan PETSCII.

• Código de shell alfanumérico
• Codificación de caracteres
• Compilando
• Formato de número de computadora
• Geocodificación
• Sistemas de numeración , ordenados por tipo de notación
• Código puny