>
Michael Kung wrote:
>Yes. Correct as
>
><META HTTP-EQUIV="Content-Type" CONTENT="text/html;
>charset=ISO-2022-JP">
>On Mar 25, 4:11pm, David Goldsmith wrote:
>>
>> Actually, I think this option is what Navigator assumes if there is no
>> MIME charset on the incoming data. If there is a MIME charset, Navigator
>> uses that and ignores the setting in the option menu.
Just to keep everybody completely informed, here is the full story.
The standard and official way to include information about the
document encoding is the HTTP header, according to HTTP 1.0.
This information is external to the document itself.
This will look something like:
HTTP/1.0 200 OK
Date: Tuesday, 26-Mar-96 11:23:54 GMT
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html; charset=ISO-2022-JP
<HTML><HEAD>
[rest of actual document deleted.]
In some cases, this is not possible (esp. there are unfortunately
some browsers that go crazy when they receive a MIME "charset"
parameter). To help out, the convention that the document encoding
is indicated with the META element inside the document itself
(hopefully before any "exotic" characters make understanding
of this information impossible) was introduced as a temporary
solution. This would then look like
<META HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-2022-JP">
as mentionned by Michael. In some browsers that don't
yet understand this syntax, and for cases where the MIME
"charset" is neither provided in the HTTP header nor as
a META element, the "document encoding" option (also
not very appropriatiely called "language encoding") is then
used on the browser side. If this is also not available or not set,
the HTTP default of ISO-8859-1 is used.
Regards, Martin.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:30 EDT