The Glade 4.0

Just out of curiosity, for any Korean or Japanese speakers...

It appears that the Korean unicode character mapping puts the won symbol in the same address (0x5c) that contains the backslash (reverse solidus) in English unicode. Japanese unicode does the same thing with the yen symbol. So, say not so hypothetically that you're trying to configure an email client to check mail on a domain's Exchange server, you can't just type in domain\username, because you wind up with domain(won)username or domain(yen)username.

Considering that \ is also the separator in typing paths (like c:\windows\system32 and whatnot) this is bound to come up fairly regularly right? I've read that Windows has no problem interpreting the won character as being a valid path separator, but apparently when being sent off to an Exchange server there's no such luck.

Short of flipping back and forth between language inputs (or just plain conceding to using English to play nice with the Exchange server), there's just no way to create a backslash, is there? Communicating between two systems using different unicode sets appears to be problematic, to say the least.

More info for the deeply geeky:
http://blogs.msdn.com/michkap/archive/2 ... 69941.aspx

I'm a little confused, here. The Unicode encoding for Won and Yen are *not* the same as for backslash. It's only when you're not using Unicode that the Japanese and Korean code pages use the 0x5c for Won/Yen.

But I'm not sure where the problem is. As long as you point the email client at "domain[0x5c]user", it shouldn't really matter whether the client displays that as a \, ¥, or ₩. It might look a little funny (at least to non-Korean/Japanese users), but it should be functional.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.

Yeah, I think that's what I thought I understood Kinda learning on the fly here... 0x5c is a reverse solidus, period, in any functional sense, right? On codepage 949 (Korean), 5C may be Won, and codepage 932 (Japanese), it's Yen. Those are just differences in glyphs, though. It should act like a backslash does regardless. But it's not doing that. I would have thought it was just user error and that (person I was trying to help) was just entering a typo in her login credentials. But, using the Outlook client, where she must specify domain\username and password, she couldn't authenticate, but then using the same credentials in a web client that doesn't require the domain specification, she logged in fine. I dunno, I was stumped, going to call the mail server admin tomorrow and see what they see when she tries to authenticate via the client app.

Well, the NT-based Windows APIs are all Unicode-aware. Individual applications may or may not be, but I would assume that both Outlook and Exchange server are Unicode-aware applications as well. So if your user is actually entering a Yen/Won char at the keyboard, my guess would be that it's producing the unicode encoding for it (instead of 0x5c), which won't work as a path delimiter.

In that case, I really don't know what to suggest other than to have them use something like the character map application to grab the 0x5C backslash character (however it may appear with their locale settings and font sets) and paste it into the Outlook configuration. Kind of a pain, but you should only have to do it once.

Incidentally, does this Exchange server service more than one NT domain? Because otherwise it should select the default domain when none is specified during authentication. Or at least my Exchange server does. YMMV. But that could be another way to side-step the problem.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.