|
From: Chris N. <pu...@po...> - 2001-03-26 22:08:02
|
At 23:52 +0200 2001.03.26, Stefan Strigler wrote:
>portald doesn't seem to work with RDF containing german Umlauts (=FC,=F6=
,=E4
>etc.)
>
>XML::Parser just stops with en error, if it encounters such a character.
>(Well in fact, he just does this, if the encoding isn't set right in the
>RDF-file). So I added the following:
>
>$p->parse($d, ProtocolEncoding =3D> 'ISO-8859-1') or
> portaldLog("$bid did not parse properly");
The fact that $p->parse($d) fails means the document is broken. If Slash
created that document, then the way to fix it is to include "encoding =3D=
>
'ISO-8859-1'" in the newrdf function in slashd. In Slash 2.0, this is
handled by "rdfencoding" in the vars table.
>This seems to fix the problem for the first step, but now, if I got it
>right, the resulting data is encoded in UTF-8 and therefore doesn't
Nope. UTF-8 is the default. ISO-8859-1 is not UTF-8, but Latin-1.
>display right in the browser. I only get very ugly symbols but not the
>umlauts (in fact, these should be html-encoded, but this is another
>problem, I can easily deal with).
Nope, the encoding of the RDF really has nothing to do with how it is
displayed. "=FC" will look bad on most browsers, because chances are you=
r
HTML document is set to only display ASCII characters, and even if it is
not, most clients won't display it properly. The answer is to do as you
suggest: convert the data to the proper HTML entities.
When you put data into Slash, in a story etc., you should use the HTML
entities. The only problem with this is in the daily mailer, which (I
think) would just put the HTML entities in verbatim. It's on my list of
things to look at.
--=20
Chris Nandor pu...@po... http://pudge.net/
Open Source Development Network pu...@os... http://osdn.com/
|