I set encoding to windows-1251, then users who use windows-1251 encoding as default in windows see my messages ok. But problem arises when i communicate with, for example, hebrew windows users.
The solution would be to send unicode ICQ messages, but if i set encoding to UTF-8 in ICQ transport preferences - some kind of squares come to remote users from me instead of letters.
It’s got nothing to do with Openfire, but rather the IM Gateway plugin. If you’d like to submit a patch for the IM Gateway plugin to improve upon this though, I’d love to include it!
The thing abot ICQ is… if I recall correctly I -am- sending unicode. Thing is, the target client has to indicate that it supports unicode. (this is the way of ICQ, you have to add a flag to say you support it. if you just up and send unicode to clients, most of them will balk) If there’s no unicode flag, we have to send based off the configured encoding. All things considered, ICQ has one of the ugliest language support implementations I’ve dealt with. =/
Oh, yes, I know there’s thing with the unicode support flag. But! This flag is set, as I can see, on the target computer - but messages are still sent there in non-unicode format.
So, it seems that this flag is not recognized correctly by ICQ gateway plugin, or something like that.
What flag are you talking about that you can “see”? I’m not referring to the one in the client preferences, but rather one that’s passed as part of the underlying ICQ communication. But, it very well be getting missed or lost or something or something else is going on. I’ve seen a couple ICQ clients actually set their non-unicode encoding to utf-8, which gets even more confusing. (the uncode flag != utf-8 encoding)
|I’ve sent two messages, one with “test” in latin, and second is “test” in cyrillic. Recipient says that he is seeing hebrew (it’s his default non-unicode encoding).