整数

通常我们不想使用双精度数，因为我们不想使用浮点运算，舍入错误等。他们只是没有必要。

为此，最好记住如何执行上限除法:双数的ceil(x / y)可以写成(x + y - 1) / y(同时避免负数，但要注意溢出)。

可读的

如果你追求可读性，你当然也可以像这样编程(例如在Java中，对于C你当然可以使用宏):

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));
    }
}

内联

垫

我们知道每3个字节(或更少)需要4个字符块。那么公式就变成了(对于x = n, y = 3)

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

或结合:

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

你的编译器会优化出3 - 1，所以就这样保持可读性。

填充物的

不太常见的是无填充的变体，为此我们记得每6位都需要一个字符，四舍五入:

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

或结合:

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

然而，我们仍然可以除以2(如果我们愿意的话):

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

不可读的

如果你不相信你的编译器会为你做最终的优化(或者如果你想让你的同事困惑):

垫

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

填充物的

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

---

所以我们有两种逻辑计算方式，我们不需要任何分支，位运算或模运算，除非我们真的想这样做。

注:

显然，您可能需要在计算中添加1以包含空终止字节。 对于Mime，您可能需要注意可能的行终止字符等(寻找其他答案)。

在我看来，正确的公式应该是:

n64 = 4 * (n / 3) + (n % 3 != 0 ? 4 : 0)

在windows中-我想估计mime64大小的缓冲区的大小，但所有精确的计算公式都不适合我-最后我得到了这样的近似公式:

Mine64字符串分配大小(近似) =((4 *((二进制缓冲区大小)+ 1))/ 3)+ 1)

所以最后+1 -它用于ascii- 0 -最后一个字符需要分配来存储零结束-但为什么“二进制缓冲区大小”是+1 -我怀疑有一些mime64终止字符?或者这可能是一些对齐问题。

我在其他回答中没有看到简化的公式。逻辑是覆盖的，但我想要一个最基本的形式为我的嵌入式使用:

  Unpadded = ((4 * n) + 2) / 3

  Padded = 4 * ((n + 2) / 3)

注意:当计算无填充计数时，我们四舍五入整数除法，即加上除数-1，在这种情况下是+2

简单的javascript实现

function sizeOfBase64String(base64String) {
    if (!base64String) return 0;
    const padding = (base64String.match(/(=*)$/) || [])[1].length;
    return 4 * Math.ceil((base64String.length / 3)) - padding;
}

我认为给出的答案忽略了原始问题的重点，即需要分配多少空间来适合长度为n字节的给定二进制字符串的base64编码。

答案是((n / 3) + 1) * 4 + 1

这包括填充和终止空字符。如果你在做整数运算，你可能不需要楼层调用。

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.