‘And actually, single quotes can be curly on your browser, you can see that right here’ (these should be curly-looking).
If you just type into DU yourself as I'm sure you know, you NEVER see curly quotes. You can get them in Word, you can get them in articles online, but there are NO 'curly quote' keys on your keyboard. They're created on the fly by software like Word, as you type. "Smart Quotes" they call it.
Anyways, character set describes the translations from hex representations (what is really stored on disk) to and from the 'characters', as we see them. It is a 'mapping' system, if you will. The means by which characters are converted to hex values is called "encoding". Every character set has its own "encoding" scheme associated.
The "font" otoh handles the actual presentation step, which takes the character it's been provided and makes it look like it does (and a bewildering array of other, non-obvious things about how the characters and words look, it would trip most people out to learn just HOW MUCH the font choice actually DOES in practice).
Anyways, this is not a font question, it's a character set translation issue. All four of these characters have their own distinct hex values behind the scenes. Or in some cases, they do not have one!
The “single, open, curly quote” is the Unicode character LEFT SINGLE QUOTATION MARK, U+2018. is the Unicode character LEFT SINGLE QUOTATION MARK, U+2018.
In UTF‑8, U+2018 is encoded as E2 80 98 (hex).
In ISO‑8859‑1, there is no defined character at U+2018, and curly quotes are not part of the ISO‑8859‑1 repertoire, so it does not have a valid single‑byte hex value there.
Curly quotes can clearly be saved to the database okay because I can save the above (without preview or edit) and you will see the versions I saved (with curly quotes in various spots). So the issue is not with saving to/storing in the DB. DB is probably using UTF-8 which is default for mysql.
However, at some step in the process where DU app server plucks your (saved) post content from the DB and presents it to you for a continued edit in the preview/edit form, the hex value of CURLY version that was saved in the DB is not properly interpreted anymore and you get garbage instead. That's why you can SEE the bad characters in the edit window at that point. At this point, local browser setting are irrelevant, font choices are irrelevant, because the data was F'd before it even hit your computer at all. It came out of DU's server wrong 
Make sense, at least somewhat?
Edit history
= new reply since forum marked as read