Encoding problems with special characters

[y-young]

Hi, When using mega.py to upload files, I encountered some encoding problems: Some files with special filename(emoji, special character, etc) will cause unusual phenomenon, the filenames are misinterpreted on MEGA Android client and MEGASync

For example, the ✦ character will be displayed as &, ６０(full-width number) as garbage characters, and some appear to be BLANK on Android client(decoding failure, I guess) Furthermore, these files cannot be synced with MEGASync(it just can't see them, I think)

However, these filenames can be displayed normally on MEGA Web; And if uploaded with MEGA official clients, everything is fine So I'm wondering whether there's something different in encoding between mega.py and official clients, as is stated in the api doc(https://github.com/meganz/sdk/blob/develop/doc/source/internals.rst):

As JSON is not binary clean, all non-ASCII data has to be encoded. For binary data, the MEGA API uses a variation of base-64 with the characters -_ used instead of +/ and the trailing = stripped (where necessary, the actual payload length is heuristically inferred after decoding, e.g. by stripping trailing NULL bytes). Unicode text has to be encoded as UTF-8.

I also found that:

• In web client, these files can cause filename conflicts with normally uploaded files
• If you rename the files in web client or copy from one place to another, then it comes back to normal(this process fixes the wrong encoding, I think)
• These files can be downloaded with correct filename with web client and mega.py

PS: As for version 1.0.8 this issue still exists.

Thanks for your work!

[knowledgeorange]

Can't you try to upload them without the emojies in their names? Maybe its in the Mega servers code and you can't edit that...

[y-young]

Can't you try to upload them without the emojies in their names? Maybe its in the Mega servers code and you can't edit that...

That's the final option. The point is that these files can be handled properly using Mega official client, so I doubt that the API implementation is somewhat different from the official SDK, and it would be better if we can fix it.