Issue 28: Broken Away & N/A message - text/x-aolrtf; charset="iso-8859-1"
Status:  Fixed
Owner:
Closed:  Jan 2008
Reported by jadest...@gmail.com, Dec 9, 2007
 Posted by guest at 2006-05-16 21:47:18

Contacts using ICQ5.06 build 2495 display a crippeld away & N/A message. For
example:
Idle $MINUTES minutes - text/x-aolrtf; charset="iso-8859-1";
$AWAY_MESSAGE

Is this a client (Gajim 0.10 in my case) or pyICQ issue? My transport is
icq2.swissjabber.ch (pyICQt svn-r196)

Other contacts clients display:
Idle $MINUTES minutes - $AWAY_MESSAGE

Inte

Posted by jadestorm at 2006-05-17 02:11:23

that's bizarre!  I mean the text/x-aolrtf part can definitely be my fault in
some way

but $AWAY_MESSAGE?  there's no way that's coming from my stuff  =/

... unless you simply mean that that's the person's away message  ;D  in that
case, nevermind

I don't suppose you have logs of this do you?  (debugging logs from pyicq)  I
have yet to be able to duplicate this

Posted by guest at 2006-05-17 06:27:04

the person's away message ... you got it ;)

I don't have any logs of this. /me just use this transport. I had a look at the
XML-dump, but couldn't find anything which belongs to this odd behaviour.

If you want, you can get the ICQ# of the contacts I've these problems with.
Beside you can write 

Inte - kral at jabber dot org

Posted by jadestorm at 2006-05-17 19:05:12

FYI to self:
[2, 6, 0, 0, 35L, '\x0894909954\x00\x00\x00\x08
\x00\x01\x00\x02\x00p\x00\x0c\x00%\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00\t\x00

\x00\x00\x00\x00\x00H\x19\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0

0\x00\x00\x00\x00\x00\n\x00\x04\x00\x00\x00\x00\x00\x04\x00\x02\x00\x0b\x00\x06\

x00\x04\x10\x01\x00\x01\x00\x0f\x00\x04\x00\x00\xbf\xbe\x00\x1d\x00\x14\x00\x01\

x01\x10\xb42\\%4=A\x13r\x90\x9d\xc0\xe7:qs\x00\x03\x00\x04Dj\xb2\xfd\x00\x03\x00

#text/x-aolrtf;
charset="iso-8859-1"\x00\x04\x00q<html><body>Der Benutzer
ist zu
rzeit abwesend.<br/>Sie k\xc3\xb6nnen ihm/ihr eine Nachricht
hinterlassen.</body
></html>']



To all others, this is definitely something my code appears to be screwing up. 
Thank you for the sample users btw!  =)

Posted by guest at 2006-05-17 22:43:45

You're welcome.

I'm happy to see, if an ordinary user (/me) could help you.

Posted by bronger at 2007-02-06 08:44:27

I had to write the following workaround function for my Jabber client
(Gajim) in
order to cope with this:

def fix_aol_message(message):
	aol_marker = 'text/x-aolrtf; charset="iso-8859-1": '
	aol_marker_position = message.find(aol_marker)
	if aol_marker_position != -1:
		return message[:aol_marker_position] +\
		    message[aol_marker_position+len(aol_marker):]\
		    .encode("iso-8859-15").decode("utf-8")
	else:
		return message

The stange thing is the iso-8859-15.  Either this is hardcoded in the transport
or it is the default encoding on the Linux box running it -- I can't find out.

Posted by bronger at 2007-02-06 08:44:52

I had to write the following workaround function for my Jabber client
(Gajim) in
order to cope with this:

def fix_aol_message(message):
	aol_marker = 'text/x-aolrtf; charset="iso-8859-1": '
	aol_marker_position = message.find(aol_marker)
	if aol_marker_position != -1:
		return message[:aol_marker_position] +\
		    message[aol_marker_position+len(aol_marker):]\
		    .encode("iso-8859-15").decode("utf-8")
	else:
		return message

The stange thing is the iso-8859-15.  Either this is hardcoded in the transport
or it is the default encoding on the Linux box running it -- I can't find out.

Posted by bronger at 2007-02-06 09:24:22

I had to write the following workaround function for my Jabber client
(Gajim) in
order to cope with this:

def fix_aol_message(message):
	aol_marker = 'text/x-aolrtf; charset="iso-8859-1": '
	aol_marker_position = message.find(aol_marker)
	if aol_marker_position != -1:
		return message[:aol_marker_position] +\
		    message[aol_marker_position+len(aol_marker):]\
		    .encode("iso-8859-15").decode("utf-8")
	else:
		return message

The stange thing is the iso-8859-15.  Either this is hardcoded in the transport
or it is the default encoding on the Linux box running it -- I can't find out.


Jan 12, 2008
Project Member #1 volk...@gmail.com
This may be fixed by the latest "don't crash on weird encoding" patches.
Status: Fixed