Non US characters in login and email generation

Question

I have a design problem that I would like to check if anyone else has found a good solution to.
Once you leave the safe shores of the United States your users start having names that includes all kinds of funny characters. In the good old days this problem was resolved by the fact that the HR system only handled 7 bit US ascii characters but today you are likely to have to face an HR system that supports unicode or at least some kind of character set that includes lots of non US ascii characters. I just ran some stats on my current enterprise population and it seems like about 5% of the users have names containing "strangeness".
These strange characters causes big problems if you aren't allowed to include non US ascii characters in logins, email addresses and other generated fields. Exactly what a "strange character" is varies. RFC 5322 takes a quite liberal view towards special characters but explicitly disallows non US letters.
The simplistic solution is to drop any character that isn't a US ascii letter. This works if the problem is names like "O'Malley" as the "'" really shouldn't be part of the user login and probably not part of an email address either(can be debated). This solution breaks down when you get to Germany or Scandinavia where your users that are called "Örjan Åhs" may not appreciate an email address of rjan.hs@your_company.com.
What you would like to do is to convert "Örjan Åhs" to either "Orjan Ahs" or (possible) "Oerjan Aohs" but I haven't been able to find any java lab that does that conversion for you.
Anyone that has run into this problem before and solved it?
I wonder how certain characters in this post will be rendered on computers in different parts of the world :)
/Martin, who long ago converted his last name (Swedish) to be 7 bit ascii compliant

Answer 1

Thanks Daniel
The code above drops any non US ascii characters which is fine in some situations but doesn't work for me as that would result in (amongst other issues) unacceptable email addresses.
Example: The user "Jörgen Åhs" gets the email [email protected] (using drop strategy), what is needed is [email protected]
The solution to this problem is to write a transform function and as we have about 80 non US ascii characters in character set we are using this mapping can quite easily be externalized to a configuration file.
Good point about the preferred name. I have not seen this specific problem in my current system but it is very common in certain parts of the world i.e. people with Chinese heritage in south east Asia often have a Chinese legal name and a western name that they actually use in day to day interactions. If you base the email address of their name in HR much screaming ensures. The same thing should actually happen in the US as you are supposed to enter the name on your social security card into the HR system but that seems largely to be ignored.