Re: How to tell character encoding?

From:

"Mike Schilling" <mscottschilling@hotmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 2 Sep 2009 19:17:02 -0700

Message-ID:

<h7n8uv$hfe$1@news.eternal-september.org>

Arne Vajh?j wrote:

Mike Schilling wrote:

Arne Vajh?j wrote:

Steven Simpson wrote:

Tom Anderson wrote:

Steven Simpson wrote:

I think you're supposed to check HTTP before <meta>, at least
for
HTML: [...]
<http://www.w3.org/TR/html4/charset.html#h-5.2.2>

I tentatively consider that a bug in the spec - i'd prefer a
meta
tag to be able to override the protocol header. The reason being
that the server serving up some static content doesn't always
know
the charset it's in, but the person writing that content does.

I know what you mean, but I think I get what the spec is trying
to
do, i.e. allow the embedded setting to be overridden without
having
to alter the document, perhaps following a more general principle
that a container should be able to override its contents.

That may be the intention.

But given that:
* access to server config usually implies access to HTML files
* access to HTML files does not imply access to server config
then I agree with Tom that the opposite of current behavior
would be more useful.

If the sender has no idea of the encoding, it shouldn't put one
into
the content type; this allows the data to identify itself. If, on
the other hand, the sender is a program that knows damned well that
it just converted chars to UTF-8, it needs a way to say so,
overriding any text in the data which says that it began life as
ISO-8859-1.

Simple web servers serve usually files as BLOB's. They do not
convert any charset

Sure, but they're not the only HTTP clients (or servers.) Say I've
written a servlet that want to return some XML, which I've get in
memory as a DOM or a character string. In either case, it's
inconvenient to figure out whether it has an XML header or, if so,
what encoding that specifies. It's much simpler for me to serialize
it (or convert it) to UTF-8 and put that in the content-type.

On the other hand, I could (in theory) write a web server that accepts
lots of odd charsets for PUTs but saves everything as UTF-8, to be
nice to clients. It should reports content-type of UTF-8, and that
should override the <meta> tag.

And often they set a charset for text/html.

That's wrong. But the problem is the web server's claiming knowledge
it doesn't possess, not the spec.