Una codificación de binario a texto es la codificación de datos en texto sin formato . 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 no permite datos binarios (como correo electrónico o NNTP ) o no está limpio de 8 bits . 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 .
Descripción
El estándar de codificación de texto ASCII usa 128 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 códigos de control que no representan caracteres imprimibles. Por ejemplo, la letra A mayúscula es el carácter ASCII 65, el número 2 es ASCII 50, el carácter } es ASCII 125 y el retorno de carro de metacaracteres es ASCII 13. Los sistemas basados en ASCII utilizan siete bits para representar estos valores digitalmente.
Por el contrario, la mayoría de las computadoras almacenan datos en la memoria organizados en bytes de ocho bits . Los archivos que contienen código ejecutable por máquina y datos no textuales normalmente contienen los 256 valores posibles de bytes de ocho bits. Muchos programas de computadora llegaron a depender de esta distinción entre texto de siete bits y datos binarios de ocho bits , y no funcionarían correctamente si aparecieran caracteres no ASCII en datos que se esperaba que incluyan 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 bandera que le indica que realice 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 puede adjuntar 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 sólo caracteres alfanuméricos y de puntuación, los caracteres imprimibles ASCII ). Una vez que llega a salvo a su destino, se vuelve a decodificar a su forma de ocho bits. Este proceso se conoce como codificación binaria a texto. Muchos programas realizan esta conversión para permitir el transporte de datos, como PGP y GNU Privacy Guard (GPG).
Codificación de texto sin formato
Los métodos de codificación de binario a texto también se utilizan como mecanismo para codificar texto sin formato . Por ejemplo:
- Algunos sistemas tienen un conjunto de caracteres más limitado que pueden manejar; no solo no son limpios de 8 bits , algunos ni siquiera pueden manejar todos los caracteres ASCII imprimibles.
- Otros sistemas tienen límites en la cantidad de caracteres que pueden aparecer entre los saltos de línea , como el límite de "1000 caracteres por línea" de algunos programas de software SMTP , según lo permitido por RFC 2821 .
- Incluso otros agregan encabezados o avances al texto.
- Algunos protocolos mal considerados pero que aún se utilizan utilizan señalización en banda , lo que genera confusión si aparecen patrones específicos en el mensaje. La más conocida es la cadena "De" (incluido el espacio final) al comienzo de una línea que se utiliza para separar los mensajes de correo en el formato de archivo mbox .
Al usar una codificación de binario a texto en mensajes que ya son texto sin formato y luego decodificar en el otro extremo, se puede hacer que dichos sistemas parezcan completamente transparentes . Esto a veces se denomina "blindaje ASCII". Por ejemplo, el componente ViewState de ASP.NET usa codificación base64 para transmitir texto de forma segura a través de HTTP POST, a fin de evitar la colisión de delimitadores .
Estándares de codificación
La siguiente tabla compara las formas más utilizadas de codificaciones de binario a texto. La eficiencia indicada es la relación entre el número de bits en la entrada y el número de bits en la salida codificada.
Codificación | Tipo de datos | Eficiencia | Implementaciones de lenguajes de programación | Comentarios |
---|---|---|---|---|
ASCII | Arbitrario | 87,5% | La mayoría de los idiomas | |
Ascii85 | Arbitrario | 80% | awk , C , C (2) , C # , F # , Go , Java Perl , Python , Python (2) | Existen varias variantes de esta codificación, Base85 , btoa , etcétera. |
Base32 | Arbitrario | 62,5% | ANSI C , Java , Python | |
Base36 | Entero | ~ 64% | bash , C , C ++ , C # , Java , Perl , PHP , Python , Visual Basic , Swift , 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 ISO ). Usado comúnmente por sistemas de redirección de URL como TinyURL o SnipURL / Snipr como identificadores alfanuméricos compactos. |
Base58 | Entero | ~ 73% | C ++ , Python | Similar a Base64, pero modificado para evitar tanto caracteres no alfanuméricos (+ y /) como letras que pueden parecer ambiguas cuando se imprimen (0 - cero, I - i mayúscula, O - oy l mayúscula - L minúscula). Satoshi Nakamoto inventó el esquema de codificación base58 al crear bitcoin . [1] Algunos sistemas de mensajería y redes sociales se rompen en cadenas no alfanuméricas. Esto se evita al no usar caracteres reservados URI como +. Para segwit , fue reemplazado por Bech32, ver más abajo. |
Base62 | Similar a Base64, pero contiene solo caracteres alfanuméricos. | |||
Base64 | Arbitrario | 75% | awk , C , C (2) , Python , muchos otros | |
Base85 ( RFC 1924 ) | Arbitrario | 80% | C , Python Python (2) | Versión revisada de Ascii85 . |
Bech32 | 1 bit (mainnet o testnet) más de 3 a 40 bytes | no es un porcentaje simple ya que tiene un código de corrección de errores de 6 bytes | C, C ++, JavaScript, Go, Python, Haskell, Ruby, Rust | Especificación . Utilizado en Bitcoin y Lightning Network . [2] |
BinHex | Arbitrario | 75% | Perl , C , C (2) | MacOS clásico |
Decimal | Entero | ~ 42% | La mayoría de los idiomas | Por lo general, la representación predeterminada para la entrada / salida de / a humanos. |
Hexadecimal (Base16) | Arbitrario | 50% | La mayoría de los idiomas | Existe en variantes en mayúsculas y minúsculas |
Intel HEX | Arbitrario | ~ <50% | Biblioteca C , C ++ | Normalmente se utiliza para programar chips de memoria EPROM , NOR-Flash |
MÍMICA | Arbitrario | Consulte Quoted-printable y Base64 | Consulte Quoted-printable y Base64 | Contenedor de codificación para formateo similar al correo electrónico |
Formato de archivo de la tecnología MOS | Arbitrario | Normalmente se utiliza para programar chips de memoria EPROM , NOR-Flash . | ||
Codificación porcentual | Texto ( URI ), arbitrario ( RFC1738 ) | ~ 40% [a] (33-70% [b] ) | C , Python , probablemente muchos otros | |
Cotizado-imprimible | Texto | ~ 33-100% [c] | Probablemente muchos | Conserva los saltos de línea; corta líneas a 76 caracteres |
Registro S (Motorola hex) | Arbitrario | 49,6% | Biblioteca C , C ++ | Normalmente se utiliza para programar chips de memoria EPROM , NOR-Flash . 49,6% asume 255 bytes binarios por registro. |
Tektronix hex | Arbitrario | Normalmente se utiliza para programar chips de memoria EPROM , NOR-Flash . | ||
Uuencoding | Arbitrario | ~ 60% ( hasta 70% ) | Perl , C , Java , Python , probablemente muchos otros | En gran parte reemplazado por MIME y yEnc |
Xxencoding | Arbitrario | ~ 75% (similar a Uuencoding) | C | Propuesto (y utilizado ocasionalmente) como reemplazo de Uuencoding para evitar problemas de traducción de juegos de caracteres entre los sistemas ASCII y EBCDIC que podrían corromper los datos Uuencoded |
yEnc | Arbitrario, en su mayoría sin texto | ~ 98% | C | Incluye una suma de comprobación CRC |
RFC 1751 ( S / CLAVE ) | Arbitrario | 33% | C, [3] Python , ... | "Una convención para claves de 128 bits legibles por humanos ". Una serie de palabras pequeñas en inglés es más fácil de leer, recordar y escribir para los humanos que el decimal u otros sistemas de codificación de binario a texto. [4] 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. [3] |
Los códigos de 95 isprint 32 a 126 se conocen como caracteres imprimibles ASCII .
Algunos formatos más antiguos y poco comunes en la actualidad 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 imprimibles ASCII : 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 solo 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 forman 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 mapear todas las posibles secuencias de seis bits en diferentes caracteres imprimibles. Dado que hay más de 2 6 = 64 caracteres imprimibles, esto es posible. Una secuencia dada de bytes se traduce al verla como un flujo de bits, dividiendo este flujo en trozos de seis bits y generando la secuencia de caracteres correspondientes. Las diferentes codificaciones difieren en el mapeo 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, mapeando todas las secuencias posibles de 4 bits en los 16 dígitos hexadecimales estándar . El uso de 4 bits por carácter codificado conduce a una salida 50% más larga que base64, pero simplifica la codificación y decodificación; expandir cada byte en la fuente de forma independiente a dos bytes codificados es más simple que expandir 3 bytes de origen de base64 a 4 bytes codificados.
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 en 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). [5] En teoría, esto permite codificaciones, como base128, entre máquinas que hablan PETSCII.
Notas
- ^ Para datos arbitrarios; codifica los 189 caracteres no reservados con tres bytes y los 66 caracteres restantes con uno.
- ^ Para texto; solo codificando cada uno de los 18 caracteres reservados.
- ^ Un byte almacenado como = XX. Codificación de todos menos los 94 caracteres que no lo necesitan (incluido el espacio y la tabulación).
Referencias
- ^ "El esquema de codificación Base58" . Grupo de trabajo de ingeniería de Internet . 27 de noviembre de 2019. Archivado desde el original el 12 de agosto de 2020 . Consultado el 12 de agosto de 2020 .
Gracias a Satoshi Nakamoto por inventar el formato de codificación Base58
- ^ Rusty Russell ; et al. (15/10/2020). " Codificación de pago en el repositorio de Lightning RFC" .
- ^ a b RFC 1760 "El sistema de contraseña de un solo uso S / KEY".
- ^ RFC 1751 "Una convención para claves de 128 bits legibles por humanos"
- ^ http://sta.c64.org/cbm64pet.html y col.