-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No title or URL found in TYPE_LINK; exception str() failed #52
Comments
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 |
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) content: reserved: |
and when the "link" (if you can call it that) is tapped, the internal wechat browser is opened and goes to URL: |
seems it got this appid value from the appid attribute of appmsg |
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 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 |
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.
The text was updated successfully, but these errors were encountered: