> 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
