ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Base64 wiki: info, historia y vídeos

videos internet

salud  Base64 


Protocolo Privacy-Enhanced Electronic Correo electrónico (PEM)


La primera aplicación famosa de la codificación Base sesenta y cuatro para transmisiones electrónicas de datos fue el protocolo Privacy-enhanced Electronic Correo electrónico (PEM), propuesto por el RFC novecientos ochenta y nueve en mil novecientos ochenta y siete. PEM define un esquema de caracteres imprimibles que utiliza Base sesenta y cuatro para convertir una secuencia arbitraria de octetos en un formato que puede ser expresado en líneas cortas de caracteres de seis bits, como las precisas en protocolos de transmisión como SMTP.


La versión actual de PEM (concretada en el RFC mil cuatrocientos veintiuno) utiliza un abecedario de sesenta y cuatro caracteres consistente en los caracteres en mayúscula y minúscula del abecedario latino (A-Z, a-z), los numerales (0-nueve) y los símbolos '+' y '/'. El símbolo '=' se utiliza como un sufijo singular. La especificación original (RFC novecientos ochenta y nueve) utiliza además de esto el carácter '*' para definir la parte codificada mas no cifrada del flujo de salida.


Para convertir datos en una codificación PEM imprimible, el primer byte se ubica en los ocho bits más significativos de un búfer de veinticuatro bits, el próximo en los ocho de en medio y el tercero en los de menor peso. Si hay menos de tres bytes por codificar, el resto del búfer se rellena con ceros. En este punto, el búfer se emplea de manera que se marchan extrayendo seis bits desde la parte más significativa para ser utilizados como índice en la cadena: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", de manera que el carácter indicado va a ser la salida.


Este proceso se repite con los datos sobrantes hasta el momento en que queden menos de 4 octetos. Si quedan 3, se procesan de forma normal, al paso que si quedan menos de tres bytes (veinticuatro bits), la entrada se rellenará con ceros por la derecha para formar un múltiplo de seis bits.


Después de codificar los datos, si en el paso precedente quedaban dos octetos por codificar, entonces se agrega el carácter '=' al final de la salida; si solo quedaba un octeto, se concadenarán 2 caracteres '='. Esto informa al descodificador de que los bits a 0 que se hayan añadido de relleno no deben ser parte de los datos reconstruidos.


PEM precisa que todas y cada una de las líneas codificadas estén formadas precisamente por sesenta y cuatro caracteres imprimibles, con la salvedad de la última, que puede contener menos. Las líneas van a estar acotadas por caracteres de espacio en blanco conforme con las convenciones concretas de la plataforma.

Multipurpose Internet Correo Extensions

La especificación MIME (Multipurpouse Internet Correo electrónico Extensions) definida en el RFC dos mil cuarenta y cinco, describe base64 como uno de los sistemas de codificación de binario a texto. El base64 de MIME se fundamenta en la versión de PEM que se describe en el RFC 1421: utiliza exactamente el mismo abecedario de sesenta y cuatro caracteres y exactamente el mismo mecanismo de codificación, del mismo modo que utiliza el símbolo '=' para indicar el relleno final, como se describe en el RFC mil quinientos veintiuno.


MIME no detalla un tamaño fijo para las líneas codificadas en base64, mas sí precisa un tamaño máximo de setenta y seis caracteres. Además de esto, específica que cualquier carácter que no pertenezca al abecedario habrá de ser ignorado por los decodificadores, si bien muchas implementaciones emplean los caracteres CR/LF (retorno de carro y salto de línea) para definir las líneas codificadas. De este modo, el tamaño real de los datos codificados de conformidad con MIME acostumbra a ser de un ciento cuarenta por ciento del tamaño original.


UTF-siete, descrito en el RFC dos mil ciento cincuenta y dos, introdujo un sistema llamado Modified Base64 (Base64 Cambiado). Este esquema de codificación se utiliza para codificar UTF-dieciseis como caracteres ASCII para ser utilizados en transmisiones de siete bits como en SMTP. Es una variación del base64 utilizado en MIME.


El abecé de Base64 Cambiado consiste en el abecé de base64 utilizado en MIME, mas no emplea el carácter '='. UTF-siete se pretendió utilizar para las cabeceras de los correos (definido en RFC dos mil cuarenta y siete), y el carácter '=' se reserva en este contexto como carácter de escape para codificación Quoted-Printable. Base sesenta y cuatro Cambiado sencillamente omite el relleno y acaba de forma inmediata tras el último dígito BASE64 que contiene bits útiles (dejando los 0-cuatro bits no utilizados del último dígito base64).


OpenPGP, descrito en el RFC dos mil cuatrocientos cuarenta, emplea la codificación Radix-sesenta y cuatro, asimismo famosa como ASCII Armor. Radix-sesenta y cuatro es idéntico a base64 de MIME, salvo en que agrega una suma de verificación CRC de veinticuatro bits. Esta suma se calcula sobre los datos de entrada, ya antes de codificar, y más tarde se codifica con exactamente el mismo base64 para ser concatenada a la codificación resultante.


En el protocolo P10 de servidor-servidor utilizado por el diablo IRCIRCu y software compatible, se utiliza una versión de Base sesenta y cuatro para codificar los datos numéricos de cliente/servidor y de las direcciones IP binarias. Estos datos numéricos de la comunicación entre el usuario y el servidor tienen tamaños fijos, con un número preciso de dígitos base64, con lo que no se precisa rellenar. Las direcciones IP binarias tienen bits a 0 por el inicio para hacerlas encajar. El símbolo utilizado es algo diferente al utilizado en el abecedario de MIME, usando " en vez de "+/" para eludir enfrentamientos con otras unas partes del protocolo que utilizan el carácter '+' interiormente como indicador de establecimiento de modos.


RFC tres mil quinientos cuarenta y ocho (Las codificaciones Base16, Base32 y Base64) es un documento informal (no-normativo) que trata de aunar las especificaciones RFC mil cuatrocientos veintiuno y RFC dos mil cuarenta y cinco de base64, codificaciones con alfabetos alternativos y las codificaciones extrañamente utilizadas Base32 y Base16.


RFC tres mil quinientos cuarenta y ocho prohíbe a las implementaciones agregar caracteres no alfabéticos y establece que los descodificadores deben rehusar datos que contengan caracteres no alfabéticos; todo esto si no están contemplados en una especificación que se refiera a esta o bien que, en cualquier caso, la requiera.


Este RFC hace obsoleto al RFC tres mil quinientos cuarenta y ocho y se refiere al mismo tema:

Este documento describe las codificaciones base sesenta y cuatro, base treinta y dos y base dieciseis utilizadas generalmente y trata cuestiones como el empleo de saltos de línea, rellenos, empleo de caracteres no alfabéticos en los datos codificados y la utilización de otros alfabetos y codificaciones preceptivas.

Una cita de Thomas Hobbes perteneciente a la obra Leviathan:

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

se codifica en base64 como sigue:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

En la cita de arriba el valor codificado de Man es TWFu. Codificadas en ASCII, las letras: M, a y n son guardadas como los bytes setenta y siete, noventa y siete y ciento diez, o sea, un millón mil ciento uno, un millón cien uno, un millón ciento mil ciento diez en base dos.


Ahora esos 3 bytes se unen y tenemos el búfer de veinticuatro bits, que va a ser 010011010110000101101110. Este número se transformará a su valor Base sesenta y cuatro, que puede hacerse tomando bloques de seis bits al unísono (seis bits forman como máximo sesenta y cuatro valores diferentes en binario: veintiseis). Ahora, cogiendo cada vez seis bits del búfer, tenemos cuatro números (veinticuatro = seis x cuatro), que entonces son transformados a su pertinente valor en Base sesenta y cuatro.

Texto de entradaManASCII7797110Bits010011010110000101101110Índice1922546Resultado en Base64TWFu

Por tanto, tres bytes sin codificar (en un caso así, caracteres ASCII) entran y cuatro caracteres ASCII codificados brotan como resultado.


La tabla de índice Base64:

ValorCaracterValorCaracterValorCaracterValorCaracter0A16Q32g48w1B17R33h49x2C18S34i50y3D19T35j51z4E20U36k5205F21V37l5316G22W38m5427H23X39n5538I24Y40o5649J25Z41p57510K26a42q58611L27b43r59712M28c44s60813N29d45t61914O30e46u62+15P31f47v63/


Ilustración del marcado de relleno conforme acortamos la entrada:

La entrada finaliza con: any carnal pleasure. La salida acaba con: YW55IGNhcm5hbCBwbGVhc3VyZS4=La entrada acaba con: any carnal pleasure La salida acaba con: YW55IGNhcm5hbCBwbGVhc3VyZQ==La entrada concluye con: any carnal pleasur La salida finaliza con: YW55IGNhcm5hbCBwbGVhc3VyLa entrada acaba con: any carnal pleasu La salida acaba con: YW55IGNhcm5hbCBwbGVhc3U=La entrada concluye con: any carnal pleas La salida acaba con: YW55IGNhcm5hbCBwbGVhcw==

La codificación Base64 puede ser útil cuando el tamaño de la información de identificación utilizada en un ambiente HTTP es bastante grande. El framework de base de datos para objetos persistentes llamado Hibernate para el lenguaje de programación Java utiliza Base64 para codificar una ID única parcialmente grande (normalmente UUIDs de ciento veintiocho bits) en una cadena de texto para ser utilizada como factor HTTP en los formularios o bien en el modo perfecto de transmisión GET. Asimismo, gran cantidad de aplicaciones precisan codificar datos binarios de manera que puedan ser introducidos en las URL, como en los campos ocultos de los formularios. Base64 resulta conveniente para estos propósitos puesto que aparte de convertirlos en una cadena compacta, oculta la naturaleza de los datos ante posibles observadores.


El empleo de un codificador de URL sobre Base64 estándar, no obstante, no resulta conveniente puesto que va a traducir los caracteres '+' y '/' en las secuencias singulares en hexadecimal por ciento XX ('+' = ' por ciento 2B' y '/' = ' por ciento 2F'). Si más tarde se emplea para almacenaje en base de datos o bien entre sistemas heterogéneos, generarán un enfrentamiento en el carácter ' por ciento ' generado por el codificador de URL (debido a que este carácter es utilizado en ANSI SQL como comodín).


Por esta razón hay un Base64 Cambiado para URL, donde no se utiliza el carácter '=' de marcado de relleno, y los caracteres '+' y '/' del Base64 estándar son reemplazados por '-' y '_' respectivamente, de forma que ya no se precisa emplear codificadores de URL. Además de esto, no tiene impacto en el tamaño de la codificación, dejándola íntegra para empleo en base de datos relacionales, formularios web y también identificadores de objetos por norma general.


Otra variación, llamada Base64 Cambiado para expresiones regulares, utiliza "!-" en vez de "*-" para substituir el "+/" del Base64 estándar, debido a que, tanto '+' como '*' son caracteres reservados para las expresiones regulares (cabe destacar que el " utilizado en la variación IRCu explicada arriba no va a funcionar en este contexto).


También hay otras variaciones que emplean "_-" o bien "._" cuando la cadena codificada será utilizada como identificador válido para programas, o bien ".-" cuando se utiliza para los tokens de XML (Nmtoken), o bien aun "_:" para ser utilizada en un los identificadores más restrictivos de XML (Name).


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 

Está aquí: Inicio > [ INTERNET ] > ıllı Base64 wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas