Codificador Base32768

Base32768 es una codificación de binario a texto pensada para canales que ya hablan UTF-16: cadenas JavaScript, String de Java, APIs anchas de Windows y muchas bases de datos con NVARCHAR. En lugar de empaquetar cinco o seis bits en un símbolo ASCII como Base32 y Base64, Base32768 elige cada carácter de un repertorio de 32768 puntos de código seguros del Plano Multilingüe Básico y transporta quince bits de carga por carácter. Eso rinde cerca del 93.75 por ciento de eficiencia al almacenar o transmitir el resultado como UTF-16, mucho más denso que Base64 en el mismo cable. Esta capacidad implementa de extremo a extremo el perfil qntm Base32768: el modo encode lee su cadena en claro como bytes UTF-8 y emite un resultado Base32768; el modo decode valida cada símbolo frente al alfabeto primario de quince bits y al secundario de relleno de siete bits, y recupera el texto UTF-8 original.

Cómo Base32768 empaqueta quince bits en caracteres BMP seguros

Base32768 trata la entrada como un flujo continuo de bits de bytes en bruto. Para texto, esta capacidad convierte primero su cadena con UTF-8 para que los caracteres multibyte sigan siendo portátiles entre idiomas y plataformas. Los bits se toman del más significativo al menos.

Cada quince bits acumulados seleccionan un índice en un repertorio primario de 32768 entradas construido con rangos cerrados de puntos de código Unicode asignados, no de control y sin espacio en blanco del Plano Multilingüe Básico. Esos rangos evitan a propósito caracteres que rompen la normalización Unicode, confunden la dirección del texto o parecen formato, de modo que la cadena codificada es segura al pegarse en la mayoría de APIs limpias de Unicode.

Cuando el resto final no es un bloque completo de quince bits, el codificador rellena con unos y termina con un símbolo primario o con un símbolo secundario de relleno de siete bits de un alfabeto aparte de 128 entradas. La decodificación invierte el mapa: cada carácter aporta quince o siete bits, se emiten bytes completos en cuanto se acumulan ocho bits y los bits residuales de relleno deben seguir siendo todos unos.

También se rechaza un carácter secundario de relleno antes de la posición final, porque ese patrón nunca aparece en una codificación válida. Frente a Base64, usted cambia un alfabeto solo ASCII por mucha más densidad bajo UTF-16; frente a Base65536, permanece en el BMP y cada carácter es una sola unidad de código UTF-16.

Dónde aparece Base32768 en el trabajo real

Los sistemas que guardan blobs binarios en columnas de texto UTF-16 suelen necesitar un empaquetado más denso del que Base64 ofrece sin salir del BMP. Los equipos ya estandarizados en la suite qntm de codificaciones densas usan Base32768 cuando el canal es nativo UTF-16 y Base2048 o Base65536 cuando aplican otras restricciones. Los escritorios de soporte pegan cadenas opacas desde tickets y necesitan validación estricta del alfabeto sin aceptar símbolos basura que producirían una carga incorrecta.

Quienes enseñan densidad de codificación bajo distintas formas Unicode quieren una página dedicada a Base32768 en lugar de enterrarla bajo un landing genérico de Base64, porque la intención de búsqueda, las reglas del alfabeto y las cifras de eficiencia difieren. Si necesita Base32 RFC 4648 para secretos TOTP, Base64 seguro para URL o densidad basE91 bajo UTF-8, trátelos como intenciones de búsqueda y landings aparte en lugar de sobrecargar esta página de codificador Base32768.