Les,
Ok, it's making a little more sense now. Thanks.
Just to be crystal clear, what is the *right* way to get a String from the
value of decrypted in testBlockOperations? The unit test compares the byte
arrays to assert true, but never converts the decrypted value back to a
string:
assertTrue(Arrays.equals(plaintext, decrypted.getBytes()));
The following almost works, but strips all spaces and leaves garbage at the
end:
System.out.println(new
SimpleByteSource(Base64.decode(decrypted.getBytes())).toString());
Thanks,
Tauren
On Tue, Apr 5, 2011 at 7:20 PM, Les Hazlewood <lhazlew...@apache.org> wrote:
> > appkey and result1 are UTF-8-encoded Strings of base64-encoded byte
> > arrays: i.e. there are two levels of encoding going on here - one for
> > base64 and another encoding for the String itself. When you call
> > String#getBytes(), the JDK will return the bytes of that string using
> > the platform's default encoding character set. Shiro instead
> > explicitly uses UTF-8 for guaranteed behavior.
>
> To clarify this a bit more, think of it this way:
>
> Base64 really encodes (converts) byte arrays of any type into byte
> arrays with a limited byte alphabet. It is really a byte array ->
> byte array mechanism. That's encoding level 1.
>
> Once an encoding has been done, the resulting byte array output is
> guaranteed to representable in a simple character set. But Java needs
> to know the character set to use. So this is the byte array -->
> String mechanism. That's encoding level 2.
>
> Shiro uses UTF-8 for this 2nd level to guarantee the same behavior no
> matter what JVM it is deployed in. If you call aString.getBytes(),
> you bypass Shiro's mechanism and use whatever the platform's default
> character set is, which is likely to be incorrect.
>
> I hope that makes more sense!
>
> --
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and
> Training:
> http://www.katasoft.com
>
