W3C home > Mailing lists > Public > www-validator@w3.org > July 2001

Re: charset parameter

From: Martin Duerst <duerst@w3.org>
Date: Fri, 27 Jul 2001 11:42:55 +0900
Message-Id: <>
To: Terje Bless <link@pobox.com>, Nick Kew <nick@webthing.com>
Cc: W3C Validator <www-validator@w3.org>
At 11:36 01/07/26 +0200, Terje Bless wrote:
>On 26.07.01 at 09:08, Nick Kew <nick@webthing.com> wrote:
> >Surely that at least is clear: [HTTP] takes precedence over [META]?
>Nope. HTTP 1.1 doesn't mention META, and HTML just sez it's supposed to be
>read by _servers_ to initialize the HTTP header... :-(

Sorry, this is wrong. Please everybody read
http://www.w3.org/TR/REC-html40/charset.html#h-5.2 !

> >>Or what this means for the case when the charset in the HTTP header is
> >>there by inference (as a default, not explicitly)...
> >
> >But *ML rules don't apply to HTTP, so whence the conclusion that
> >*anything* is implicit (as opposed to absent) in the headers?
>The lack of a "charset" parameter on the HTTP 1.1 "Content-Type" header
>field means that you should assume it is there with a value of "ISO-889-1"
>according to the HTTP 1.1 RFC. HTML doesn't specify a default (it actually
>discourages it). But if HTTP overrides META, and the HTTP charset is only
>there by default, does HTTP's default still override an explicitly inserted

By widespread current practice, as well as by the HTML 4 Rec, NO.

>That is, if the META sez EUC-JP and HTTP implicitly defines ISO-8859-1 (by
>being absent), does that really mean that we should use ISO-8859-1 (which
>the user obviously does _not_ want) over EUC-JP (which s/he _does_ want)?

Yes. The validator currently goes for EUC-JP, and that's the right thing.

> >>or "I'm sorry, but I was unable to determine the Character Encoding based
> >>on available information. Please make your Character Encoding explicit in
> >>the HTTP headers".
> >
> >Except if HTTP happens to be FTP or file upload, and there is no header...
>Or a fragment pasted into the form (not finished yet)... Or...
>It must be dealt with, but these are sufficiantly fringe cases that we can
>add exceptions for those. I think... :-)

Yes, these must be treated differently. I think the right thing to do,
for both fragment and file upload, is:

- Take the explicit selection in the popup menu as if it were the transport
   information (e.g. HTTP).
- For the rest, do as currently.

Regards,   Martin.
Received on Friday, 27 July 2001 22:57:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:58:23 UTC