Hi,
hm - interesting :). The problem is that I still believe that it is one
of Licqs main shortcoming that the user has do decide manually which
character set to use. To solve this problem once and for all I had a
look at the gaim source code (which obviously is able to automatically
decide which character set to use). Interestingly, when the user sends
the Supports-UTF-8-Flag the correct encoding doesn't seem to be "UTF-8"
but "UCS-2BE". The problem with this encoding is that it can contain
bytewise zeros (I think) - and this is the point where of course things
like strdup or strlen stop working.
I think it would be the best solution to have the licq backend do the
work again. Plugins should deliver all information in UTF-8 or something
like that to the backend and it will do an intelligent character set
conversations (or if a preferred encoding is set for the specific user
it will use this encoding).
This would require some more building alterations but would finally make
encoding work the way it should - reliable and independent from GUI plugins.
I'd like to start with such a work in the backend if this doesn't
interfere with some plans you have :)
Regards,
Joachim
Jon Keating schrieb:
On 9/22/06, Joachim Staib <[EMAIL PROTECTED]> wrote:
I'm currently trying to improve character set handling in icqnd and
realized that functions like icqSendMessage also do some encoding stuff.
So what's the encoding I have to deliver icqSendMessage a string to? In
the qt-gui the function UserSendMsgEvent::sendButton() also seems to
encode the string. and what does gTranslator.NToRN do :)?
The encoding in the daemon is not really supported anymore, it is up
to the individual plugins to do this. The console plugin and RMS do
not do that, so as work around the daemon encoding stuff is still
present. But, it is better that the plugins send the message to the
daemon in the encoding that the user has set for that specific user.
NToRN changes \n to \r\n, which was required and probably still is for
Windows to show new lines correctly.
Jon
