[JDEV] Non english messages problem (solution)
wil at home
wil at dready.org
Sun Apr 8 17:21:32 CDT 2001
You have a valid point that it places a lot of effort on the client side to
do charset conversion. However, that is the most complete solution, simply
because it puts the power at the users hands.
If the conversion is done on the ICQ transport, e.g.
Hackee has 2 friends, A and B. A uses linux with koi8-r encoding, while B
uses Windows with cp1251 encoding. If the preferred encoding is set to
cp1251, and Hackee receives a message from A, the ICQ transport would
convert the raw bytes from ICQ, treating it like it was cp1251, and the end
result would be wrong. How is Hackee gonna reverse engineer it, switch the
encoding for the ICQ agent and tell A to resend?
Another way would be to associate each user with a preferred encoding, that
sort of solves the problem, but still could be frustrating if the sender
decides to switch OS :)
----- Original Message -----
From: "Alexander Tsvyashchenko" <ndl at ndl.unicyb.kiev.ua>
To: <jdev at jabber.org>
Cc: <icq-dev at jabber.org>
Sent: Monday, April 09, 2001 4:26 AM
Subject: Re: [JDEV] Non english messages problem (solution)
> Hello, "wil at home" <wil at dready.org>!
> AFAIK ICQ doesn't support encoding information.
> But I think Hackee is right proposing "right click on the ICQ agent, and
set preferred encoding".
> For first, it seems in most cases user will know encoding for all
incoming/outgoing messages from ICQ (for example, all russian/ukrainian
users use cp1251 encoding in ICQ messages).
> For second: how are You imaging process of "setting encoding
individually for every message"? ICQ transport receives an ICQ message for
me. ICQ transport should convert it to unicode and send to the client. How
can it know what encoding incoming message has? I see only one realistic way
to handle this: set assumed encoding for ICQ transport by user for all
messages. Of course, second way is to encode this message just as sequence
of bytes and send to client to let client handle encoding of this message.
Then Your proposition (setting encoding for every message individually) will
work, but as I understand this way will break general idea of jabber:
equality of handling of all messages by client without relation to the
> With outgoing messages situation is simplier (it's possible to add extra
tag to the message with desired outgoing encoding), but this also will
somewhat break uniformity of handling messages.
> So I think that setting assumed encoding for ICQ transport for all
incoming/outgoing messages is the best and the easiest way. There is only
one problem: is anyone going to implement this?
> Good luck! Alexander.
> On Mon, 9 Apr 2001 01:39:07 +0800
> "wil at home" <wil at dready.org> wrote:
> WAH> We have encountered similar problems with non i18n aware
> WAH> interoperability between applications who use different encodings.
> WAH> I don't know much about the ICQ protocol, maybe someone could point
> WAH> it does send encoding information. Working on the assumption that
> WAH> not support it, then messages would of course be treated as iso8859-1
> WAH> rather most apps will not even care, these days we're luckier because
> WAH> programmers don't strip the 8th bit of a characters).
> WAH> Hackee brought out an interesting workaround, which is to do allow
> WAH> to select the encoding at the application level, since you can't do
> WAH> the protocol level due to missing encoding information. However, I
> WAH> with him to "right click on the ICQ agent, and set preferred
> WAH> should be done at individual message level, that is when viewing /
> WAH> a message, you select the encoding that this message should be viewed
> WAH> converted to for sending.
> WAH> This is similar to the browsers / email clients. When a html page
> WAH> contain the encoding tag, IE would use the default encoding, but user
> WAH> override the encoding using the "View->Encoding" menu.
> WAH> wil
> jdev mailing list
> jdev at jabber.org
More information about the JDev