Ajax のプログラムを書いていて日本語の文字が化ける対策をとったのは 1 月程前である。
サーバからテキストデータを読み取ると文字が化ける。
原因は文字コードの指定が無いからである。
RFC2616 によると指定が無い場合には ISO-8859-1 と見なされる。これはいわゆるラテン文字集合である。化ける訳である。
現在では UTF-8 がインターネット標準になってしまっており、筆者は 2002 年頃から全てのテキストを UTF-8 で書いている。Mac OSX を買ったのもひとえに UTF-8 環境の良さからである。
しかし Ajax でテキストデータを読み取るときに文字化けするのは困りものである。そこでサーバに手を加えて HTTP ヘッダのレベルで UTF-8 を文字コードとして指定した。つまり
Content-Type: text/plain; charset=utf-8のように、text コンテンツには(plain でなくても) charset を明示的に指定したのである。これでデフォルトの文字コードが UTF-8 になるのだと思っていた。Ajax 問題は解決した。しかし....
今日気がついた。古いページが文字化けしているのである。
古いページは EUC コードで書かれ、 HTML テキストのヘッダに
<meta http-equiv="Content-Type" content="text/html; charset=x-euc-jp">が添えられていた。これまではちゃんとこれで文字化けせずに表示されていたのである。ところが文字化けしている。HTTP ヘッダの変更と関係があることは明らかである。
HTTP ヘッダの指定と、HTML ドキュメントのメタでの指定とどちらが優先されるのか? 筆者はメタでの指定が優先されるのは自明の事であると考えていた。だってえ... HTTP ヘッダの指定はサーバー全体のドキュメントの文字コードを問題にしており、それでは困る事があるから、各ページ毎に文字コードを指定できるようにしているんでしょ。
神崎さんの解説のなかで優先順位の問題が触れられている*。(神崎さんの解説はありがたいですねぇ。本を読むのは面倒だから屢々お世話になります。)
神崎さんに導かれて http://www.w3.org/TR/html4/charset.html#h-5.2.2 を見ると確かに
To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest):
1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
3. The charset attribute set on an element that designates an external resource.