Well...
I already mentioned this in a previous post, but I should have been more precise:
I have tested the getBytes() method on my string object retrieved with AIL method, using various charset names:
1/ In my CME application options, I put the following string for testing : "èé"
2/ I retrieve the string with ailFactory.getApplicationInfo().mOptions (note that important : when retrieved, it is ALREADY a String)
3/ I display the bytes of every char of my string, with a simple for block:
byte[] theBytes = myString.getBytes(charsetNameToTest);
for (byte eachByte : theBytes) {
LOGGER.debug("\nbyte = " + eachByte);
}
4/ the results for various charsets:
cp1252 => both 'è' and 'é' equal to '63'
UTF8 => both 'è' and 'é' have 3 bytes equal to '-17'/'-65'/'-67'
UTF16 => both 'è' and 'é' have 2 bytes equal to '-1'/'-3'
Indeed, I think that once the String is retrieved with AIL method, it's too late : the String is built, not correctly, not with the right encoding, and nothing you can do after can reverse what has been done.
When the JVM is cp1252, no problem : start is cp1252, end is cp1252, encoding is implicit. But when start and end have not the same encoding, it fails.
OK, I realize that the way I explained the thing, it seems to have no solution, but I still have a little hope that my analysis is wrong...