Accents in plain txt files incorrectly displayed

I too am having the same issue, it was a file in plain text .txt format with passwords which broke because special characters were being changed to HTML entities like & into &amp; and < into &lt;

Dropbox can you advise has this been fixed?

Hi DiversityStudio; welcome to the Community.

Just to make sure we're troubleshooting the right thing here, could you elaborate on the issue you described providing screenshots of how the mentioned file looks like on our website and how it looks like when downloaded and opened locally on your device(s)?

Thanks a bunch!

Hi Walter,

Yes I can elaborate, we created some plain text files .txt for passwords and when viewed on phone app or local desktop the special characters are correct but when viewed on a web browsers some characters are being rendered as their HTML entities for instance & as &amp; and > as &gt; which when we copy the password to be used to login somewhere it is wrong because of the changed characters

Screenshot on desktop/app all OK

 [IMAGE LINK IS BROKEN AND CANNOT BE DISPLAYED]. 

Screenshot on Dropbox in web browser

 [IMAGE LINK IS BROKEN AND CANNOT BE DISPLAYED]. 

Notice &amp; and not just &

Also looking at the source HTML it has been changed to HTML entities, does this help you to shed some light? I was hoping plain text files should not be formatted and just outputted as plain text only.

Also this was OK for weeks as I have been copying from a web browser view and it was only yesterday this happened.

 [IMAGE LINK IS BROKEN AND CANNOT BE DISPLAYED]. 

I see now, thanks for your swift response and extensive description DiversityStudio; it definitely helps paint a better picture of the matter at hand.

For the time being, as we work on this, I'd recommend downloading the file and access it locally to copy the text you need. I know it's not optimal, but it should do the trick for now.

Moving on to your concern, it seems like there's an issue with how the text is encoded when previewed on our website (assuming the wrong encoding). Can you let me know for how long has this been working fine and what browsers you've tested it on? 

While at it, does it persist after clearing your browser's cache and/on or an incognito window with no extension or plugin running and can you replicate it with new files following the same procedure? 

Let me know what you find and we'll take it from there! 

Hi Walter,

I have been accessing locally. To answer your further questions...

It has been working since we created the password .txt files so end of January 2020, it errored yesterday when we came to paste in a password and got login errors.

I have hard refreshed my browser, emptied the cache and still persists with error.

Error also in Incognito tab.

Tested on Chrome, Safari and Firefox, error persists, it seems to be encoded on the server side before hitting any client.

Does this help?

thanks,

Jamie

Thanks for your effort and cooperation so far Jamie. 

At this point, may I reach out to the email address that's linked to your profile here on our Community so I can have a look into this with all of my tools at our disposal?

If need be, I'll also escalate it to an expert from our team to investigate further. 

On a closing note, I was just about to ask your name but you beat me to it; I guess we're in sync, Jamie -- no pun intended :grin:

Looking forward to your reply! 

Hi,

Yes please reach out to my email address, look forward to any enlightment on this!

Thank you.

Jamie

I just sent you a brief message to look into this Jamie.

Whenever you get the chance, please take a look at your inbox and we'll take it from there.

It was the same for me, and i could solve it by changing the codification type with Notepad++, choosing "Code with UTF-8" makes the trick.