Pourquoi base128 n'est-il pas utilisé? [fermé]

90

Pourquoi est-ce que seule base64 au lieu de base128 est utilisée pour transmettre des données binaires sur le Web? Le jeu de caractères ASCII a 128 caractères qui en théorie pourraient représenter la base 128, mais seule base64 mais pas base128 est utilisée dans la plupart des cas.

Gmadar
la source
60
Pourquoi pas même la base 256?
Gumbo
22
Je pense que le but est d'avoir des caractères imprimables (bien qu'il y en ait aussi plus de 64 ...)
Felix Kling
29
Je pense que la base 128 nous appartenait il y a quelque temps. L'équipe affectée à la base de garde 64 tient toujours.
Ritch Melton
5
pourquoi cette question est-elle spécifique à javascript? cela est également vrai pour la plupart des autres langues utilisées sur le Web, n'est-ce pas?
Benedikt Waldvogel
5
@KenRockot: Je vois que vous reconnaissez que certains de vos caractères 15 bits seraient encodés sur 3 octets. Votre codage base-2048 signifie emballer 11 bits dans 2 octets, ce qui fait 5,5 bits par octets - un demi-bit de moins que la base 64.
maaartinus

Réponses:

105

Le problème est qu'au moins 32 caractères du jeu de caractères ASCII sont des «caractères de contrôle» qui peuvent être interprétés par le terminal récepteur. Par exemple, il y a le caractère BEL (cloche) qui fait sonner le terminal récepteur. Il y a les caractères SOT (Start Of Transmission) et EOT (End Of Transmission) qui exécutent exactement ce que leurs noms impliquent. Et n'oubliez pas les caractères CR et LF, qui peuvent avoir des significations spéciales dans la façon dont les structures de données sont sérialisées / aplaties dans un flux.

Adobe a créé le codage Base85 pour utiliser plus de caractères dans le jeu de caractères ASCII, mais AFAIK est protégé par des brevets.

pepoluan
la source
7
Base91 semble être une bonne option open source: base91.sourceforge.net
Jorge Cevallos
2
Cela vaut la peine de considérer qu'une puissance de 2 s'adapte plus facilement aux données d'octets et que l'encodage est plus simple. Ensuite, il y a la portabilité; chaque langue a un encodage base64 et / ou un décodage base64.
Lodewijk
5
Re Base85 et Adobe : la réponse pourrait être rendue plus utile si elle citait les numéros de brevet et l'année de délivrance. Si les brevets posent un problème, il y a toujours btoa, qui date de 1990, n'est pas grevé de brevets, et ceux-ci seraient certainement expirés de toute façon.
agc
65

Parce que certains de ces 128 caractères ne sont pas imprimables (principalement ceux qui sont sous le point de code 0x20). Par conséquent, ils ne peuvent pas être transmis de manière fiable sous forme de chaîne sur le fil. Et, si vous dépassez le point de code 128, vous pouvez avoir des problèmes d'encodage en raison des différents encodages utilisés dans les systèmes.

driis
la source
8
Base94 existe ici dans github, il utilise les 94 caractères ASCII imprimables: gist.github.com/iso2022jp/4054241
intrepidis
15

Comme déjà indiqué dans les autres réponses, le point clé est de réduire le jeu de caractères aux caractères imprimables . Un schéma de codage plus efficace est basE91 car il utilise un jeu de caractères plus grand et évite toujours les caractères de contrôle / d'espacement dans la plage ASCII basse. La page Web contient une belle comparaison de l' efficacité de l'encodage binaire vs base64 vs basE91 .

Une fois, j'ai nettoyé l'implémentation Java. Si les gens sont intéressés, je pourrais le pousser sur GitHub.

Mise à jour : il est maintenant sur GitHub .

Benedikt Waldvogel
la source
Je serais intéressé par la version java
Michael Deardeuff
2
Je l'ai poussé
Benedikt Waldvogel
12

Que les 32 premiers caractères soient des caractères de contrôle n'a absolument aucune pertinence, car vous n'avez pas à les utiliser pour obtenir 128 caractères. Nous avons le choix entre 256 caractères et seuls les 32 premiers sont des caractères de contrôle. Cela laisse 192 caractères, et donc 128 est tout à fait possible sans utiliser de caractères de contrôle.

Voici la raison: ce doit être quelque chose qui aura la même apparence et que vous pouvez copier et coller, peu importe où. Pour cela, il doit y avoir des caractères qui seront affichés de la même manière sur n'importe quel forum, chat, e-mail, etc. Cela signifie que nous ne pouvons pas utiliser de caractères, qu'un client de forum / chat / e-mail peut généralement utiliser pour le formatage ou le non-respect. Il doit également s'agir de caractères identiques, quels que soient la police, la langue et les paramètres régionaux.

C'est la raison!

user3119289
la source
7
Les caractères de contrôle sont pertinents car à peu près tout le monde supposait déjà que cela devrait être aussi neutre que possible en termes de page de code / d'encodage. Cela vous limite nécessairement à l'ASCII (7 bits) qui est un sous-ensemble de la plupart des encodages pertinents. De plus, tout Internet n'est pas propre 8 bits, et une grande partie est de facto ASCII. Votre point mérite cependant d'être souligné.
Tim Seguine
7
Juste pour ajouter: ASCII ne définit que 128 caractères. Les caractères # 128 à # 255 ne sont pas définis en ASCII. Puisque la question fait explicitement référence à l'ASCII et non à "n'importe quel codage 8 bits", toutes les réponses se limitent aux 128 caractères de l'ensemble ASCII.
pepoluan
En utilisant le codage UTF-8 le plus courant comme exemple: les octets de 128 à 196 entraîneraient immédiatement des erreurs de décodage UTF8; des octets de 196 à 256 impliqueraient que l'octet suivant est également du même caractère, mais si l'octet suivant est inférieur à 128, cela entraînerait à nouveau des erreurs de décodage UTF8. Cependant, presque tous les langages sensibles au codage de caractères auraient la bibliothèque base64 prendre des chaînes base64 comme des chaînes UTF8-safe. La même chose ne peut pas être faite avec base128 car elle ne peut pas être encodée en tant que chaîne UTF8-safe.
SOFe
10

Base64 est courant car il résout une variété de problèmes (fonctionne presque partout où vous pouvez penser)

  • Vous n'avez pas à vous soucier de savoir si le transport est propre 8 bits ou non.

  • Tous les caractères de l'encodage sont imprimables. Vous pouvez les voir . Vous pouvez les copier et les coller . Vous pouvez les utiliser dans des URL (variantes particulières). etc.

  • Taille d'encodage fixe. Vous savez que les moctets peuvent toujours encoder en noctets.

  • Tout le monde en a entendu parler - il est largement pris en charge, de nombreuses bibliothèques, si faciles à interagir.

Base128 n'a pas tous ces avantages.

Il semble que ce soit 8 bits propre - mais rappelez-vous que base64 utilise 65 symboles. Sans un caractère hors bande, vous ne pouvez pas bénéficier d'une taille d'encodage fixe. Si vous utilisez un caractère hors bande, vous ne pouvez plus être propre 8 bits.

Ce n'est pas tout négatif cependant.

  • base128 est plus facile à encoder / décoder que base64 - il vous suffit d'utiliser des décalages et des masques. Peut être important pour les implémentations intégrées

  • base128 fait une utilisation légèrement plus efficace du transport que base64 en utilisant plus de bits disponibles.

Les gens font usage base128 - Je l' utilise pour quelque chose maintenant. Ce n'est tout simplement pas aussi courant.

John La Rooy
la source
Rappelez-vous également que les systèmes de messagerie / news et leurs semblables (et aussi XML) ne sont pas toujours gentils avec les 32 premiers points de code (considérez CR LF vs LF, par exemple), mais sinon votre réponse semble très bonne.
SamB
"que base64 utilise 65 symboles." => faute de frappe ou ai-je raté quelque chose?
Kikiwa
@Kikiwa, regardez cet exemple java sur wikipedia . Vérifiez la longueur de la CODESvariable.
John La Rooy
Oh oui, le caractère de remplissage '=' uniquement à la fin de la charge utile d'encodage, vous avez raison, merci.
Kikiwa
4

Pas sûr, mais je pense que les valeurs inférieures (représentant des codes de contrôle ou quelque chose) ne sont pas transférées de manière fiable en tant que texte / caractères dans les requêtes / réponses HTTP, et les valeurs supérieures à 127 peuvent être locales / codepage / tout ce qui est spécifique, donc il n'y en a pas 128 caractères différents susceptibles de fonctionner sur tous les navigateurs / plates-formes.

Esaj
la source
3

esaji a raison. Base64 est utilisé pour encoder des données binaires pour la transmission à l'aide d'un protocole qui n'attend que du texte. C'est juste dans l' entrée Wiki .

Russell Troywest
la source
2

Découvrez la classe PHP base128. Encodage et décodage avec le jeu de caractères ISO 8859-1.

GoogleCode Classe PHP Base128

seizu
la source
1
Je souhaite qu'il utilise utf-8 à la place ...
Janus Troelsen
1
Le codage de base n'a rien à voir avec les données sous-jacentes. Vous pouvez utiliser n'importe quel encodage de texte que vous souhaitez pour encoder votre texte / données. Ce qu'il veut dire, c'est que la table d'index Base ## utilise le jeu de caractères ASCII ISO 8859-1 comme traduction.
Tchad
1
Cela a quelque chose à voir avec les données sous-jacentes dès que vous essayez d' incorporer des données binaires codées en base dans du texte. Si ce texte est encodé dans un autre encodage, vous aurez des problèmes.
Stijn de Witt
Il n'y a pas de jeu de caractères "ISO 8859-1 ASCII". Le programme code les données en utilisant 128 caractères ISO 8859-1 imprimables différents. Il n'utilise en aucun cas l'ASCII , forme ou forme.
Nisse Engström