Re: Accept-Charset support
On Sun, 8 Dec 1996, Keld J&o/rn Simonsen wrote:
> Koen Holtman writes:
> > But skimming the UTF-8 specification, I gather that UTF-8 is an encoding
> > mechanism, not a character set.
> Well, no. UTF8 is an encoding of characters. It implies the character
> repertoire of ISO 10646. So it is a charset in MIME sense, including
> the specific character definitions of 10646.
If that is taken seriously, then "Accept-Charset: utf-8" cannot be used
to just send information about what character encoding a client can
decode. It implies that (at least when sent in the encoding of utf-8)
all characters from the 10646 repertoire are acceptable.
It seems predictable that e.g. "Accept-Charset: koi8-r,iso-8859-1,utf-8"
will be used to indicate "documents containing characters which are
also in koi8-r and latin-1 characters are acceptable in utf-8 encoding",
because there is currently no better way to express that (other than
maybe with language tags, which has other problems already mentioned:
e.g. transliteration/transcription, languages that do not imply exactly
one character repertoire).
If such interpretation of "utf-8", i.e. effectively using it like another
Content-Transfer-Encoding or C-E, becomes widespread, the fact that "utf-8"
implies the full 10646 repertoire will be totally lost.
This is of course not specific to HTTP or the Web, protocols without
negotiation like mail need charset labelling. A simple MIME compliant
MUA should have sufficient information from message headers to dispatch
to the appropriate viewer. In the pre-UTF era this was reliably possible
e.g. with metamail (given the correct charset parameter and availability of
appropriate codepage). With messages labelled "utf-8", heuristics have to