How does s9y think about HTML-Entities and charsets?

[jk]

Hi,
I read in the German forum people about people having trouble with umlauts broken on update. I'm planing a fresh install, so I'm not affected directly. However, I wonder, how s9y deals with non-ascii characters.

Some of my older entries (to be imported manually) contain HTML-Entities such as "ä", other have an ISO-8859-1 "ä" instead. Is this OK for s9y? How will s9y "export" this to the RSS/Atom-World? (I've seen many feeds with broken umlauts and I don't know whom to blame, feed reader or creater or both?)

If using iso-8859-1 or UTF-8 for editing entries, will s9y convert characters suitable for the client or just pass a "charset:utf-8" header? (Do I have to make sure the whole site uses the same character set now and ever or is there some helping magic involved?)

Thanks

Jan

[garvinhicking]

Hi!

Some of my older entries (to be imported manually) contain HTML-Entities such as "ä", other have an ISO-8859-1 "ä" instead. Is this OK for s9y? How will s9y "export" this to the RSS/Atom-World? (I've seen many feeds with broken umlauts and I don't know whom to blame, feed reader or creater or both?)

Using ä is deprecated in XHTML, if you properly declare the charset. So it might make W3C validation invalid, if you use those umlauts.

S9y however can deal with them properly, no matter if you use ä or ä. It will be exported to RSS like you entered it. s9y does not convert those characters.

s9y will avoid character conversion where possible (only when dealing with foreign input or output, conversion takes place). IT will pass character data through to the DB and the browser using the appropriate 'charset' headers or db connection parameters.

That means if you run your MySQL with UTf-8 and switch it to ISO-8859-1, s9y might show you garbaged data until you set the s9y configuration to use ISO-8859-1 as well.

So, yes, you need to make sure that whatever you use (ISO-8859-1 or UTF-8) it needs to be enforced at all places.

Best regards,
Garvin