Magnus Hagander wrote:
> > Which is why I suggested using HTML entities instead of UTF8 chars which
> > are likely to get mangled.
>
> UTF8 works just fine,provided you actually encode your files in it.
> Entities is primarily a workaround for encodings that can't represent
> all characters.
>
> But if you don't deal with the files as utf8, then it'll certainly be
> a problem.
My point. These days I mostly use UTF8, but presumably the file got
mangled somewhere down the line. Remember that any decent email program
is supposed to recode the file according to the headers and the local
encoding of the reader -- and it works fine most of the time. But for
these kind of things it is bound to fail at some point, which is why I
prefer to avoid the UTF8. I mean, why use the unreliable solution when
the reliable one is just as easy?
> > It may look good to you, on your browser, but it looks broken on mine.
>
> Interesting. Since the codes are actually incorrect I'm not surprised.
> But just out of interest - what's your browser?
Epiphany -- Gecko-based Gnome browser. It is detecting the file as UTF8
(probably because the server says so) but it's showing the wrong chars
for the three names. If I change it to latin1, it shows something even
more bogus. (My guess is that it was utf8 originally and was passed
through a latin1->utf8 filter somewhere). If so, iconv -f utf8 -t
latin1 should end up with a valid utf8 file (silly, eh?)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.