Windows "Regional Options" locale (8bit vs 16bit character sets)

Question

I have a Java application that reads in an Encrypted text file. The text file was Encrypted using JCE 1.2.1 and Encrypted on a Windows system with the locale set to English(US). The Encryption uses Sun's version of the DES encryption algorithm.
This app reads in the Encrypted text file and Decrypts it and processes it's information.
This works fine on Windows systems if the Regional Options control panel is set to a region that uses 8bit character sets:
- English
- Italian
- Spanish
- French
But, if the locale is set to 16bit character set regions, the text file cannot be read and parsed. Such regions include:
- Russian
- Greek
- English (Hong Kong)
At this point, I think I have two options, but I would love to hear about more:
- Edit the Encrypting/Decrypting code (or the parsing code - parses through a comma deliminated file) so that the file that is Encrypted and Decrypted can handle either an 8bit or 16bit character sets
(Don't know how to do this)
or
- Programatically change the locale of Windows machines to English(US) at application start-up and then change it back to the previous locale setting on application shut-down
(Don't know how to do this either)
I'd appreciate any help. I'm not sure if this is an International issue or an JCE issue.
Thanks in advance

Answer 1

I found an answer to the problem I was having.
The culprit were two special characters that the client was using in the encrypted text to distinguish between different fields and to distinguish carriage returns (� and �). The non Latin alphabet languages didn't know what to do with those characters so they substituted there own characters, thus breaking the parsing logic which was hard coded to look for � and �.
The problem also was related to the fact that the JCE works with byte[] arrays. FileInputStreams (which deal with byte[] arrays) seem to convert the special characters to new characters in non Lating languages to match what was going on in the JCE logic.
The easiest fix I could come up with, was to include a new properties file to be read by a separate FileInputStream. This properties text file contained just two characters (��). When I loaded in this new properties file via a FileInputStream, the two characters (��) in the properties file magically change to match the currently active alphabet (or didn't change at all if the computer was using a Latin alphabet).
By checking the new properties file to see what the characters had changed to (if they had), I was able to know what to use to parse the encrypted data. And as such, regardless of what language the computer was set to, the encrypted data is now parsed correctly, as I took out the hard coding that looked specifically for the characters � and � and instead rewrote the code so it now uses the characters from the properties file (or whatever characters they change to) for parsing the content data.
I hope others find this useful.