RE: ISO-8859-1 and meta-tags, etc

Charles McCathieNevile <charlesn@sunrise.srl.rmit.edu.au> wrote:

> >>If I put an HTTP-EQUIV Content-type into a web page then (as I understand
> >>it) I don't need to rely on the person who runs the server setting it up
> >>to give the correct content-type for all my pages.

In some servers, it might be possible.  But (as I understand it) most
servers don't do so, and as Lynn pointed out, it's not a general solution.
For example, if the resource is plain text, where to put an HTTP-EQUIV
Content-type?

> In addition, I produce HTML material to be run from a CD-ROM as files  
> - there is no server to program, so the HTTP-EQUIV is the only mechanism 
> available.

I have heard (and done) this kind of discussion quite number of times -
I know both have advantages and disadvantages.  That's why XML has
introduced encoding declaration.  But putting the HTTP-EQUIV into your
HTML document doesn't mean that you don't have to label your HTTP
header correctly.

"David Norris" <kg9ae@geocities.com> wrote:

> Well, kind of.  They might get double hits for every one of your files.
> (Browser bug or feature? Hmmm.  I can only guess that the browser switches
> accept languages on the second request.  I am not really clear on why there
> is a second request.  IE does this, I know.  I am not sure how Nav handles
> other charsets.)  Once to read the file and realize the server sent the
> wrong header, and, the second to retrieve it using the equivalent header.

To display the document correctly, browsers have to know the character
encoding of the document.  If the proper character encoding information
is provided via HTTP header, browsers are able to know how to display
the document *before* parsing the document.  But if the character
encoding information is only available via HTTP-EQUIV, browsers have
to parse the document to know that information, then try to display
the document again.  That's one of the disadvantages of HTTP-EQUIV.

Charles:
> A related question is how to specify the Language of a document - as I 
> understand it it is possible to use an HTTP-EQUIV to 'fake' a server 
> response, but I can't recall what it is (Content-language: en ???) Does 
> anybody know?

In HTTP, you're right, you can use the "Content-Language" header.
In HTML, you may use the LANG attribute, something like the following:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
      "http://www.w3.org/TR/REC-html40/strict.dtd">
  <HTML lang="en">
  <HEAD>
    ....


David:
> Also, some servers (Such as Apache) support multilingual webs.  With this
> configuration, index.html would be the server's default language page (often
> English), index.html.fr would be the default page for browsers with FR
> (French) as the primary accept language, index.html.es would be the default
> for browsers with ES (Spanish) set as the primary accept language, etc.
> This, of course, depends on proper configuration of the server.  In effect,
> a French browser that requests http://someserver/index.html would seamlessly
> be served http://someserver/index.html.fr with a properly configured server.
> Pages without translations would use the default language version of the
> page.

W3C's Web server is configured to do so.  For example, try the press release
of XSL 1.0 Working Draft [1].  Our server will send the document either in
English, Dutch, German, Swedish or Japanese, depends on your language
request.

[1] http://www.w3.org/Press/1998/XSL-WD

In Apache, this language negotiation can be used to label the document
correctly.  The following example shows how to associate the specific
charset parameter with the specific language.

  <Files ~ "\.html\.ja$">
  ForceType 'text/html; charset=ISO-2022-JP'
  </Files>


Regards,
-- 
Masayasu Ishikawa / mimasa@w3.org
W3C - World Wide Web Consortium

Received on Wednesday, 2 September 1998 02:23:38 UTC