le codage base64 qui n'utilise pas de “+/=” (plus ou égale à) caractères?

J'ai besoin de coder une chaîne d'environ 1000 caractères qui peut être n'importe quelle valeur d'un octet (00 à FF). Je ne veux pas utiliser Hex parce que c'est pas assez dense. le problème avec base64 ce que je comprends c'est qu'il comprend + /et = qui sont des personnages que je ne peux pas tolérer dans mon application.

Des suggestions?

En fait, ce n'est pas un problème avec base64, c'est un problème avec votre application.
Comme @JeremyP dit. Si votre demande ne peut pas tolérer + / et =, alors vous devez être très, très inquiets.

OriginalL'auteur Peter Kellner | 2010-12-09

  1. 2

    Que Ciaran dit, base64 n'est pas très difficile à mettre en œuvre - mais vous voudrez peut-être avoir un coup d'oeil pour les bibliothèques qui vous permettent de spécifier un ensemble personnalisé de caractères à utiliser. Je suis assez sûr qu'il ya beaucoup là-bas, mais vous n'avez pas spécifié de quelle plate-forme vous en avez besoin pour.

    Fondamentalement, vous avez juste besoin de 65 caractères ASCII qui sont acceptable, de préférence, en plus des sauts de ligne.

    Comment est-ce accepté de répondre, elle n'offre aucune solution.

    OriginalL'auteur Jon Skeet

  2. 10

    Choisissez votre remplacement. Envisager d'autres variantes: base64 Variante de la table à partir de Wikipedia.

    Tout en base64 d'encodeurs/décodeurs sont triviales, remplacement remplacement peut être fait dans un simple pré/post-traitement de l'étape de existant base64 encode/décode les fonctions (à l'intérieur des wrappers) -- pas besoin de ré-inventer la roue (entièrement). Ou, mieux encore, comme M. Skeet points, trouver une bibliothèque existante avec suffisamment de souplesse.

    Si vous n'avez pas d'alternative appropriée "drôle" de personnages au choix (peut-être tous les autres personnages ne sont pas valides en laissant seulement la 62 caractères alphanumériques au choix), vous pouvez toujours utiliser un caractère d'échappement pour un très léger (~3/64?) l'augmentation de la taille. Par exemple, 0 (A) doit être codé comme "AA", 62 (+) serait codé comme "AB" et 63 (/) serait codé en "AC". Ce qui pourrait être fait, comme une pré/post-étape si vous ne voulez pas écrire votre propre encodeur/décodeur à partir du sol-up. L'inconvénient de cette approche est que le ratio de caractères de sortie octets d'entrée n'est pas fixe.

    OriginalL'auteur

  3. 8

    Base58Check est une option. Il commence à devenir quelque chose d'un standard de facto dans cryptocurrency adresses.

    Améliorations de base sur Base64:

    • Uniquement des caractères alphanumériques [0-9a-zA-Z]
    • Aucun des caractères semblables: 0OIl /0OIl
    • Pas de ponctuation pour déclencher le retour à la ligne ou de saut de ligne dans les documents et e-mails
    • Pouvez également sélectionner l'intégralité de la valeur avec un simple double clic en raison de l'absence de signes de ponctuation.

    La Adresse Bitcoin Utilitaire est un exemple de mise en œuvre; adaptées pour les Bitcoins.

    Remarque: Une nouvelle norme de facto peut ne pas être suffisant pour vos besoins. Il est difficile de savoir si le Base58Check méthode de codage permettra de formaliser à travers les protocoles actuels.

    J'ai voulu un encodage comme ça pendant une demi-décennie, je souhaite que j'étais au courant de ça plus tôt.
    Et voici un prêt à aller de mise en œuvre de Base58 en c# gist.github.com/dotnetchris/8e99ef70a6fcb3bd445ef1f3505f7087

    OriginalL'auteur LateralFractal

  4. 6

    Si c'est juste un de ces personnages qui vous dérange, et vous pouvez trouver quelques autres personnages afin de les utiliser à la place, alors comment sur la mise en œuvre de votre propre base64 module? Ce n'est pas tout ce que difficile.

    OriginalL'auteur Ciaran Keating

  5. 1

    Sûr. Pourquoi ne pas écrire votre propre Base64 encodeur/décodeur, mais de remplacer ces caractères dans votre algorithme. Bien sûr, il ne sera pas en mesure d'être décodé par un décodeur, mais si ce n'est pas un problème, alors whyt s'en soucier. Mais, il vaut mieux avoir au moins 3 caractères autres que SONT utilisable dans votre application afin de représenter l' +/et =s'...

    En supposant qu'aucun rembourrage (normalement =) est requis, seulement deux caractères non alphanumériques sont nécessaires.
    Oui, mais je ne suis pas sûr que c'est une hypothèse que vous voulez faire...à Moins qu'il SAIT pour sûr que ses données de longueur TOUJOURS être le même, et alors que doesen "résolvez le problème pour les futures mises à jour quand il ajoute un nouveau champ ou de quelque chose, et tout d'un coup tous ses B64 code des pauses, et il doesen" savoir pourquoi...

    OriginalL'auteur LarryF

  6. 1

    Vous pouvez utiliser Base32 à la place. Moins dense que Base64, mais élimine les caractères indésirables complètement.

    Base32 utilise encore =, il ne peut pas l'utiliser... Mais, il pourrait subst que pour un autre char, ont seulement à vous soucier de 1, au lieu de 3...
    Le rembourrage peut être omis si la longueur peut être détecté dans une autre manière, ne peut-il pas?

    OriginalL'auteur sharptooth