Letters are transformed into unreadable characters if use devutations online drive as a data source
Letters are transformed into unreadable characters if use devutations online drive as a data source
Hello! I use the Russian version of RDM. If i use a local data source, the program works well. But if I use devutations online drive as a data source, the headers in the folder headers, some letters are transformed into unreadable characters. Gradually, when editing connections, they become more and more. If I export data to xml or rdm in the text there are bad characters. I attached a pdm file to the message. Folder names are duplicated. One folder with the correct name, another its clone but unreadable instead of some characters.
1.png
1.rdm
All Comments (7)
Hello,
I will log this bug.
Regards
David Hervieux
Your .rdm file contains many Russian characters but it looks like there is only one that doesn't render properly.
What character is missing exactly? Is it л?
If you edit the group and fix it does it get corrupted again?
Stéfane Lavergne
The given file is only an example. In my original file there are a lot of other folders with corrupted characters. There are broken symbols й, в, с, л. It seems that it does not depend on the symbol, in some folders they are normal, in some broken. These symbols appear only if I create connections using the devolutions online drive data source. Also, if I import a valid file into the devolutions online drive, it will break and corrupt characters will appear. Since the folder with broken characters is duplicated, I cannot rename it to the same folder, I get an error "You can't duplicate a filder with same name". If I rename to another name, there are no broken characters. If I transfer the connection from the folder with broken characters to a normal folder, then the old folder with broken characters is displayed correctly. If I try to delete it, then in the confirmation text of the deletion, I see that the characters are broken.
Thank you for the video. The behavior is very strange, we must have a "segment" of code that doesn't take unicode characters into account. Odd things is, some words contain both good & bad unicode characters. This one won't be easy to solve. Challenge accepted.
Stéfane Lavergne
It's been a while but we haven't been able to reproduce the issue internally. Is it still happening for you? What version are you currently running?
Best regards,
Stéfane Lavergne
Good news, apparently our QA team was able to reproduce the issue.
Stéfane Lavergne
Scratch that. The test was done with the "bad"/"already corrupt" export file you provided.
Stéfane Lavergne