Base64 le calcul de la longueur?

4 * n /3 donne unpadded longueur.

Et arrondi au plus proche multiple de 4 pour le rembourrage, et que 4 est une puissance de 2 pouvez utiliser les opérations logiques bit à bit.

((4 * n /3) + 3) & ~3

Entiers

En général, nous ne voulons pas utiliser de doubles, parce que nous ne voulons pas utiliser la virgule flottante ops, les erreurs d'arrondi etc. Ils sont tout simplement pas nécessaires.

Pour cela, il est une bonne idée de se rappeler comment effectuer le plafond de la division: ceil(x /y) en double peut être écrite comme (x + y - 1) /y (tout en évitant les nombres négatifs, mais méfiez-vous de débordement).

Lisible

Si vous allez pour des raisons de lisibilité, vous pouvez bien sûr également au programme comme ceci (exemple en Java, C vous pouvez utiliser de macro, bien sûr):

public static int ceilDiv(int x, int y) {
    return (x + y - 1) / y;
}

public static int paddedBase64(int n) {
    int blocks = ceilDiv(n, 3);
    return blocks * 4;
}

public static int unpaddedBase64(int n) {
    int bits = 8 * n;
    return ceilDiv(bits, 6);
}

//test only
public static void main(String[] args) {
    for (int n = 0; n < 21; n++) {
        System.out.println("Base 64 padded: " + paddedBase64(n));
        System.out.println("Base 64 unpadded: " + unpaddedBase64(n));
    }
}

Inline

Collier de

Nous savons que nous avons besoin de 4 caractères des blocs à la fois pour chacun des 3 octets (ou moins). Alors la formule devient (pour x = n et y = 3):

blocks = (bytes + 3 - 1) /3
chars = blocks * 4

ou de façon combinée:

chars = ((bytes + 3 - 1) /3) * 4

votre compilateur d'optimiser le 3 - 1, il suffit donc de le laisser comme cela pour maintenir la lisibilité.

Unpadded

Moins commun, c'est la unpadded variante, et pour cela nous rappeler que chacun de nous avons besoin d'un personnage pour chaque 6 bits, arrondie:

bits = bytes * 8
chars = (bits + 6 - 1) /6

ou de façon combinée:

chars = (bytes * 8 + 6 - 1) /6

on peut cependant encore diviser par deux (si on veut):

chars = (bytes * 4 + 3 - 1) /3

Illisible

Dans le cas où vous n'avez pas confiance en votre compilateur de faire la finale des optimisations pour vous (ou si vous voulez prendre vos collègues):

Collier de

((n + 2) /3) << 2

Unpadded

((n << 2) | 2) /3

---

Voilà, deux façons logiques de calcul, et nous n'avons pas besoin branches, bit-ops ou modulo ops - à moins que nous voulons vraiment.

Notes:

• Évidemment, vous pouvez avoir besoin d'ajouter 1 pour les calculs d'inclure une terminaison null byte.
• Mime, vous pouvez avoir besoin de prendre soin de possible de terminaison de ligne personnages et ces (chercher d'autres réponses pour que).

Voici une fonction pour calculer la taille d'origine d'un encodé en Base 64 fichier comme une Chaîne de caractères dans la base de connaissances:

private Double calcBase64SizeInKBytes(String base64String) {
    Double result = -1.0;
    if(StringUtils.isNotEmpty(base64String)) {
        Integer padding = 0;
        if(base64String.endsWith("==")) {
            padding = 2;
        }
        else {
            if (base64String.endsWith("=")) padding = 1;
        }
        result = (Math.ceil(base64String.length() /4) * 3 ) - padding;
    }
    return result /1000;
}

Alors que tout le monde est à débattre de formules algébriques, je préfère suffit d'utiliser BASE64 lui-même à me dire:

$ echo "Including padding, a base64 string requires four bytes for every three-byte chunk of the original string, including any partial chunks. One or two bytes extra at the end of the string will still get converted to four bytes in the base64 string when padding is added. Unless you have a very specific use, it is best to add the padding, usually an equals character. I added an extra byte for a null character in C, because ASCII strings without this are a little dangerous and you'd need to carry the string length separately."| wc -c

525

$ echo "Including padding, a base64 string requires four bytes for every three-byte chunk of the original string, including any partial chunks. One or two bytes extra at the end of the string will still get converted to four bytes in the base64 string when padding is added. Unless you have a very specific use, it is best to add the padding, usually an equals character. I added an extra byte for a null character in C, because ASCII strings without this are a little dangerous and you'd need to carry the string length separately." | base64 | wc -c

710

Il semble donc que la formule de 3 octets étant représenté par 4 base64 personnages semble correcte.

Dans windows - j'ai voulu estimer la taille de mime64 de la taille de la mémoire tampon, mais tous les précis de la formule de calcul n'a pas de travail pour moi - enfin j'ai fini avec la formule approximative comme ceci:

Mine64 chaîne répartition de la taille (approximative)
= (((4 * ((binaire, taille de la mémoire tampon) + 1)) /3) + 1)

Dernière, +1 - il est utilisé pour ascii-zéro - dernier caractère doit allouée pour stocker zéro de fin - mais pourquoi "binaire, taille de la mémoire tampon" est de + 1, je crois qu'il y a quelques mime64 caractère de fin ? Ou peut-être que c'est quelque problème d'alignement.

Si il y a quelqu'un qui s'intéresse à atteindre l' @Pedro Silva solution en JS, j'ai juste porté cette même solution pour elle:

const getBase64Size = (base64) => {
  let padding = base64.length
    ? getBase64Padding(base64)
    : 0
  return ((Math.ceil(base64.length /4) * 3 ) - padding) /1000
}

const getBase64Padding = (base64) => {
  return endsWith(base64, '==')
    ? 2
    : 1
}

const endsWith = (str, end) => {
  let charsFromEnd = end.length
  let extractedEnd = str.slice(-charsFromEnd)
  return extractedEnd === end
}