Child Item

Accents in plain txt files incorrectly displayed

I saved some accented and umlauted characters in a plain txt file using mac with UTF-8 encoding under a dropbox folder, and when opening it using dropbox in a browser or on an ios dropbox app, the acccented characters are incorrectly displyed, i.e. ignroed or replaced with something wierd. Conversely when I saved a plain txt file with accents using ios dropbox app, the plain text file opens in Mac Textedit with incorrect accents. Is there a way to set the plain text file so that accents and umlauts are interepreted correctly on both my Mac and dropbox app/online viewing through a browser?

Find more posts tagged with

Web

File Access

Preview

Developer

Closed - Not for right now

New

Comments

Jane

Hey @babablablabla, as this matter will need some hands-on troubleshooting (& because it may need to be further reviewed by a specialized team member), I’ve made sure to reach out to you directly via email on my end. Whenever you have some spare time, please have a look at your inbox for my email & we’ll take it from there.

I’ll be awaiting your next message in order to best address your question & thanks for reaching out for assistance on our Community!

DiversityStudio

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 & and < into <

Dropbox can you advise has this been fixed?

Walter

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!

DiversityStudio

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 & and > as > 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 & 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].

Walter

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!

DiversityStudio

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

Walter

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

Looking forward to your reply!

DiversityStudio

Hi,

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

Thank you.

Jamie

Walter

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.

billyjoker

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.