No title or URL found in TYPE_LINK; exception str() failed
ajburley opened this issue · comments
Due to #51, I modified "dump-html.py" to remove the try block and instead accept chatid directly from args. Not sure if this will actually work. Following this, I am getting another issue when running "dump-html.py". See below image:
WeChat version: 6.3.27
Not sure if this is due to the change I made (see #51) or some other reason.
You can also see that the contact name comes up with diamonds in the name, this is also due to my terminal not being able to render those special characters; see paragraph at the top of #51.
Changing the name is fine. This error might be due to some format change in wechat. I couldn't get this error myself, but it may help if you could print self.content_xml_ready before the assertion line.
I think I found the offending row, at least the first one. The row appears to be a sticker sent using "WeChatSticker". I will paste some values here; later I will add a screenshot of how it appears on the phone.
type = 49 (obviously)
createTime = 1404895676000 (this message was sent during 2014, so it's unlikely to be a format change, probably just a use-case you haven't seen before)
imgPath = THUMBNAIL_DIRPATH://th_033a654396173a9c05aabb14ccb859b4
status = 2
lvBuffer is a 38-byte blob with just { and then loads of zero bytes and then }
content:
<msg><appmsg appid="wx03ac32a3c1abfd1a" sdkver="0"><title></title><des>It's like me in my little tent :)</des><action>view</action><type>7</type><showtype>0</showtype><content></content><url></url><lowurl></lowurl><dataurl></dataurl><lowdataurl></lowdataurl><appattach><totallen>0</totallen><attachid></attachid><emoticonmd5></emoticonmd5><fileext></fileext></appattach><extinfo>{"mAnimationData":{"descs":{"zh_rcn":"It\u0027s like me in my little tent :)"},"titles":{"zh_tw":"温暖的港湾","zh_hk":"温暖的港湾","en":"Warm haven","zh_rcn":"温暖的港湾"},"mTitle":"温暖的港湾","mDesc":"It\u0027s like me in my little tent :)","newFlag":true,"mCreateDate":1386646361,"id":32,"mPrice":0,"mScreenOrientationType":2,"mIsFullScreenMode":false,"categoryId":7,"mFavoriteCount":2551426},"mIsBuiltIn":false,"mMinVerCodeNeed":1,"msg":"ok","code":0}</extinfo><androidsource>1</androidsource><thumburl></thumburl><mediatagname></mediatagname><messageaction><![CDATA[]]></messageaction><messageext><![CDATA[]]></messageext><emoticongift><packageflag>0</packageflag><packageid></packageid></emoticongift><emoticonshared><packageflag>0</packageflag><packageid></packageid></emoticonshared></appmsg></msg>
reserved:
~SEMI_XML~��.msg.appmsg.des�!It's like me in my little tent :)��.msg.appmsg.type��7��.msg.appmsg.showtype��0��.msg.appmsg.$sdkver��0�$.msg.appmsg.emoticongift.packageflag��0��.msg.appmsg.androidsource��1��.msg.appmsg.appattach.totallen��0��.msg.appmsg.$appid��wx03ac32a3c1abfd1a��.msg.appmsg.extinfo�Ƴ{"mAnimationData":{"descs":{"zh_rcn":"It\u0027s like me in my little tent :)"},"titles":{"zh_tw":"温暖的港湾","zh_hk":"温暖的港湾","en":"Warm haven","zh_rcn":"温暖的港湾"},"mTitle":"温暖的港湾","mDesc":"It\u0027s like me in my little tent :)","newFlag":true,"mCreateDate":1386646361,"id":32,"mPrice":0,"mScreenOrientationType":2,"mIsFullScreenMode":false,"categoryId":7,"mFavoriteCount":2551426},"mIsBuiltIn":false,"mMinVerCodeNeed":1,"msg":"ok","code":0}�&.msg.appmsg.emoticonshared.packageflag��0��.msg.appmsg.action��view
and when the "link" (if you can call it that) is tapped, the internal wechat browser is opened and goes to URL:
https://open.weixin.qq.com/sns/share_page?appid=wx03ac32a3c1abfd1a
seems it got this appid value from the appid attribute of appmsg
Here's what it looks like inside the app
Thanks for showing the details. I don't know how to properly render this type of message but I think we can just add a fallback to show the whole xml content when it cannot be properly parsed.
It seems you already return a fallback if the prefix is anything other than "URL:" Even "FILE:" is not supported, right? (even though it can be returned from msg.py)
The current logic in msg.py is to check for a URL, if that is missing then you look for a title. If the title is present then it is assumed this is a file. However I don't think this logic is correct. I have some messages which don't fit this pattern.
If the type = 49 in "message" table then there will be a corresponding row in table "AppMessage" (with same msgId), and if you check the "type" there you can find out more about it. Here is my rough investigation so far:
4 = Video
5 = URL link
6 = File (e.g. PDF)
7 = app link (the sticker mentioned above has this type)
1 = not sure, seems to be another type of URL link
2 = used by some other apps like MeituPic
3 = not sure, some sort of audio or video
19 = chat history
2000 = money transfer
2001 = no idea
We would need to do more investigation to isolate all the AppMessage types. But I think generally, the logic on when to return "FILE" is not correct currently and also "FILE" is not even supported by render.
I think it's better to return NOTIMPLEMENTED or similar (instead of FILE) if a URL is not found, and this will cause render to return fallback. We can log the whole content value if you like. What do you think?
I guess if a URL is present then it's probably a URL link so this part of the logic may be correct unless we can prove otherwise.
Now it will no longer throw an error but will use "NOTIMPLEMENTED". Would be good to implement the other subtype of TYPE=49 using the AppMessage table.