plain text files with Unicode characters are mis-rendered

[gjanee]

Bug description:

I'll be honest with you, I'm not entirely sure this is a Dryad bug. Still, it's problematic behavior. A plain text file that is part of a deposit (e.g., a README.txt) that is viewed on the Dryad website is not rendered properly by the web browser if the file contains Unicode characters, even if the file is UTF-8 encoded. This appears to be because the MIME type Dryad sends back is just text/plain, not text/plain;encoding=UTF-8. I can see that Dryad doesn't necessarily know what the charater encoding is, and so can't necessarily claim that the encoding is UTF-8. And I'm a little mystified as to why web browsers (at least, both Safari and Firefox on Macos Catalina) don't assume UTF-8 if no encoding is specified, but rather assume ASCII.

Steps to reproduce:

Take a look at 10.25349/D99W4T, say, the README.txt file in the May 17 version. You'll see something like "1A-18 double" where the A has a bar over it and the dash is actually an endash. It should be "1x18 double" where the x is a Unicode multiplication sign.

**Expected behavior: **

Such files are rendered as being UTF-8 encoded.

[sfisher]

This is an interesting issue. The files are served by Merritt from S3 presigned URLs. Maybe there is something they could add for defaulting to UTF-8 when presigning URLs on AWS.

[sfisher]

It appears that these files are now opening as attachments rather than rendering in-page as part of the transition away from Merritt. I tried in Firefox, Chrome and Safari on MacOS and they all simply download or download and open with the system viewer in the case of Safari (which I'm guessing is a Mac setting).

I believe they look ok, though maybe I missed something and didn't look at every character.

I added #2993 which relates to this and previews for now.