Encodeur Base32768

Au lieu d'empiler cinq ou six bits dans un symbole ASCII comme Base32 et Base64, Base32768 choisit chaque caractère dans un répertoire de 32768 points de code sûrs du plan multilingue de base et transporte quinze bits de charge par caractère. Cela donne environ 93.75 pour cent d'efficacité lorsque le résultat est stocké ou transmis en UTF-16, bien plus dense que Base64 sur le même fil. Cette capacité implémente de bout en bout le profil qntm Base32768 : le mode encode lit votre chaîne en clair comme octets UTF-8 et émet un résultat Base32768 ; le mode decode valide chaque symbole face à l'alphabet primaire de quinze bits et à l'alphabet secondaire de remplissage de sept bits, puis retrouve le texte UTF-8 d'origine.

Comment Base32768 regroupe quinze bits en caractères BMP sûrs

Base32768 traite l'entrée comme un flux continu de bits d'octets bruts. Pour le texte, cette capacité convertit d'abord votre chaîne en UTF-8 afin que les caractères multi-octets restent portables entre langues et plateformes. Les bits sont pris du plus significatif au moins.

Tous les quinze bits accumulés sélectionnent un index dans un répertoire primaire de 32768 entrées bâti sur des plages fermées de points de code Unicode assignés, non de contrôle et sans blanc, dans le plan multilingue de base. Lorsque le reste final n'est pas un bloc complet de quinze bits, l'encodeur remplit avec des uns et termine par un symbole primaire ou par un symbole secondaire de remplissage de sept bits tiré d'un alphabet séparé de 128 entrées.

Le décodage inverse la carte : chaque caractère apporte quinze ou sept bits, des octets complets sont émis dès que huit bits s'accumulent, et les bits de remplissage résiduels doivent encore être tous des uns. Un caractère secondaire de remplissage avant la position finale est aussi rejeté, car ce motif n'apparaît jamais dans un encodage légal.

Face à Base64, vous échangez un alphabet purement ASCII contre une bien meilleure densité sous UTF-16 ; face à Base65536, vous restez dans le BMP et chaque caractère est une seule unité de code UTF-16.

Ce que vous envoyez et ce que vous recevez

Envoyez un champ chaîne obligatoire nommé text et un champ optionnel mode égal à encode ou decode. Lorsque mode est omis, encode est la valeur par défaut et une seule charge utile reste utile. Le mode encode traite text comme contenu UTF-8 en clair et renvoie une chaîne result dans les alphabets Base32768.

Le mode decode traite text comme Base32768, valide chaque symbole et renvoie la chaîne UTF-8 récupérée dans result. Les échecs de validation ne consomment pas le solde prépayé. Les contrôles classiques incluent l'encodage de Hello en un court bloc Base32768 de trois caractères, l'encodage de la phrase hello world vers la chaîne de référence connue du format, et le décodage de cette chaîne vers la charge utile d'origine de onze octets.

Où Base32768 apparaît dans le travail réel

Les systèmes qui stockent des blobs binaires dans des colonnes texte UTF-16 ont souvent besoin d'un empaquetage plus dense que ce que Base64 offre sans quitter le BMP. Les équipes déjà standardisées sur la suite qntm d'encodages denses utilisent Base32768 lorsque le canal est natif UTF-16 et Base2048 ou Base65536 lorsque d'autres contraintes s'appliquent. Les bureaux d'assistance collent des chaînes opaques depuis des tickets et exigent une validation stricte de l'alphabet sans accepter des symboles pourris qui produiraient une charge erronée.

Les auteurs de cours qui enseignent la densité d'encodage sous différentes formes Unicode veulent une page dédiée à Base32768 plutôt que de l'enterrer sous une landing générique Base64, car l'intention de recherche, les règles d'alphabet et les chiffres d'efficacité diffèrent. Si vous avez besoin de Base32 RFC 4648 pour des secrets TOTP, de Base64 sûr pour URL ou de densité basE91 sous UTF-8, traitez-les comme des intentions de recherche et des landings distinctes plutôt que de surcharger cette page d'encodeur Base32768.