I’‘ve just installed system WildFire for Windows. I’‘m connected to it the module for ICQ. The Database is used internal. I’'ve used some programs-clients for an exchange of messages such as Psi, Spark, Pandion. At all one problem is observed: at sending messages inside of jabber-system with the Russian text everything is all right. If to send the message on another icq - too everything is all right with Russian. But in the answer from other people I receive abracadabra instead of the Russian text. If to send the message on ICQ in Russian and back to the person in a local network where costs WildFire, too everything is all right. What output from this situation can be?
I’‘ve just installed system WildFire for Windows. I’‘m connected to it the module for ICQ. The Database is used internal. I’'ve used some programs-clients for an exchange of messages such as Psi, Spark, Pandion. At all one problem is observed: at sending messages inside of jabber-system with the Russian text everything is all right. If to send the message on another icq - too everything is all right with Russian. But in the answer from other people I receive abracadabra instead of the Russian text. If to send the message on ICQ in Russian and back to the person in a local network where costs WildFire, too everything is all right. What output from this situation can be?
Thanx.
Hahaha, I love that term abracadabra for what the text comes out as. =) That’‘s awesome. I think I’'ll use that from now on.
Anyway, on to more serious note, ICQ charsets are nuts. I think I’‘ll post in my wiki about them at some point, but the gist of it is, ICQ can do either unicode or a custom charset. The problem is that the charset is completely arbitrary and depends solely on the client to “pick the right one”. So lets say I’‘m here in america and I’'m set to iso-8859-1 and I actually make use of some of the characters that would matter. Your ICQ client is set to russian and you get abracadabra (or something else equally bizarre). You would actually have had to have YOUR client set to iso-8859-1 to properly read my message. The whole concept makes me ill and falls under the “everyone should use unicode” statement. =)
Anyway, that said, at best what I can provide is an ability to set your local icq encoding. This encoding will be set in stone across all users of your server, but unfortunately that’‘s about the best one can hope for. =/ I’'ve created an issue for this: GATE-82
I actually tried that with PyICQt at one point. The reg form returned comes in two formats… x data form and not. The non x data form response part is, unfortunately, restricted to only specific keys, of which encoding is not one. Only some clients care. x data forms are theoretically open season, and what good clients should be using, but i vaguely recall reading that they, too, were supposed to be limited to a particular list of fields.
So what then? I had actually considered writing a JEP that used ad hoc commands to do user prefs. I envisioned it being something that would act like Psi does vcards, for example. When you log in via Psi, you pull your vcard from the server. If none is found, a dialog pops up telling you to fill out your vcard info. Anyway, this is something I’'ve been meaning to do for a while now.
My client would support that in the registration form :). I don’‘t think you’'re restricted in that form, otherwise what would be the point of doing that instead of those predefined fields?
However, adding an ad-hoc command would work fine, too. You’‘re definitely not restricted at all there, and you don’'t need to write a XEP about it.
My client would support that in the registration form :). I don’‘t think you’'re restricted in that form, otherwise what would be the point of doing that instead of those predefined fields?
However, adding an ad-hoc command would work fine, too. You’‘re definitely not restricted at all there, and you don’'t need to write a XEP about it.
It’‘s not that I have to. =) It’‘s more that I’‘d like to. It really does seem to be a “best practices” type of thing. I wouldn’‘t want to see 8 million implementations of the same idea. And thanks, I forgot they are XEP’'s now!
It’‘s possible the client I was using is what was being dippy about restricting the fields in the x data form. Hrm… let me think about this. I mean regardless I need somewhere to store the info. Don’'t currently have a place in the db.
It’‘s possible the client I was using is what was being dippy about restricting the fields in the x data form. Hrm… let me think about this. I mean regardless I need somewhere to store the info. Don’'t currently have a place in the db.
Well, couldn’'t you simply add a field? The point of betas is that things can still change.
It’‘s possible the client I was using is what was being dippy about restricting the fields in the x data form. Hrm… let me think about this. I mean regardless I need somewhere to store the info. Don’'t currently have a place in the db.
Well, couldn’'t you simply add a field? The point of betas is that things can still change.
Sure, but I want to spend some time thinking about what else might come along like that. I mean I don’‘t want to just keep making the registration table ‘‘wider and wider’’ so to speak. I think I may be better off creating a new table that maps the registration ID to various fields. It could contain “preferences” so to speak. Basically what I’‘m getting at is I don’‘t want to just add a new field to the existing table and later go "man, I shouldn’'t have done that"… want to give it some “future” thought. =)
You could add generic key/value-columns in their own table there (foreign key to the registration table, string key, string value). That’'s as extensible as possible (you could even store whole XML data structures as a value).
Is there anything I could do about this? I looked in the svn and I didn’‘t see any setDefaultEncoding method anywhere I suppose that this might be a flag or setting in joscar somewhere, but I didn’‘t find it. I’'ve only seen clases like ImEncodingParams etc… Or maybe you wanted to adjust the strings outside joscar?
This is in fact the last thing I want fixed before I enforce using this plugin in our company (some messages probably arrive in codepage 1250…outgoing messages from Miranda IM/Unicode seem to be OK).
As it turns out, a helpful user =D has written the code for this already… there’‘s another thread that should still be on the front page that’'s related to this.