为什么base64编码Java代码这样做

Question

So I'm trying to understand base64 encoding better and I came across this implementation on wikipedia

private static String base64Encode(byte[] in)       {
        StringBuffer out = new StringBuffer((in.length * 4) / 3);
        int b;
        for (int i = 0; i < in.length; i += 3)  {
            b = (in[i] & 0xFC) >> 2;
            out.append(codes.charAt(b));
            b = (in[i] & 0x03) << 4;
            if (i + 1 < in.length)      {
                b |= (in[i + 1] & 0xF0) >> 4;
                out.append(codes.charAt(b));
                b = (in[i + 1] & 0x0F) << 2;
                if (i + 2 < in.length)  {
                    b |= (in[i + 2] & 0xC0) >> 6;
                    out.append(codes.charAt(b));
                    b = in[i + 2] & 0x3F;
                    out.append(codes.charAt(b));
                } else  {
                    out.append(codes.charAt(b));
                    out.append('=');
                }
            } else      {
                out.append(codes.charAt(b));
                out.append("==");
            }
        }

        return out.toString();
    }

And I'm following along and I get to the line:

b = (in[i] & 0xFC) >> 2;

and I don't get it...why would you bitwise and 252 to a number then shift it right 2 ...wouldn't it be the same if you just shifted the byte itself without doing the bitwise operation? example:

b = in[i] >> 2; 

Say my in[i] was the letter e ...represented as 101 or in binary 01100101 . If I shift that 2 to the right I get 011001 or 25 . If I bitwise & it I get

01100101
11111100
--------
01100100

but then the shift is going to chop off the last 2 anyway...so why bother doing it?

Can somebody clarify for me please. Thanks.

Answer 1

IN in[i] >> 2 , in[i] is converted to an int first. If it was a negative byte (with the high bit set) it will be converted to a negative int (with the now-highest 24 bits set as well).

In (in[i] & 0xFC) >> 2 , in[i] is converted to an int as above, and then & 0xFC makes sure the extra bits are all reset to 0.

You're partially right, in that (in[i] & 0xFF) >> 2 would give the same result. & 0xFF is a common way to convert a byte to a non-negative int in the range 0 to 255.

The only way to know for sure why the original developer used 0xFC , and not 0xFF , is to ask them - but I speculate that it's to make it more obvious which bits are being used.