日本語の文字コード

外部文字符号化方式の問題では、
WWWサーバがtext/htmlのcharsetパラメタを設定するのが本来の姿です。

JIS・Shift_JIS・EUC(extensive unix code)

　日本語HTML文書は、JIS・Shift_JIS・EUC(extensive unix code)が使われています。どの字体コード化を選んでいるかは以下のように記載します： 

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=ISO-2022-JP">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=Shift_JIS">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=EUC-JP">

コードとIANA登録

　インタネット上で使うさまざまなコードは、IANA(Internet Assigned Numbers Authority)という組織が管理しています。ここで指定する文字コードも管理し ていて、 [ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets]に 一覧があります。

　よく、"charset=x-sjis"や "charset=x-euc-jp"を見かけますが、これらは、IANAには登録されていません。しかし、ブラウザによっては、これらは解釈するけどIANAに登録されているのを解釈しないというのもあります。Navigator 2.0などは、x-sjisは解釈するけど Shift_JISは解釈しません。

　漢字コード変換し、charset=iso-2022-jpを指定するのがどのブラウザでも見える方法です。これは、HEAD部分のトップに記載しておくべきです。これで、タイトルにも日本語を使うことができます。 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META http-equiv="content-type" content="text/html; charset=iso-2022-jp">
<TITLE>ISO-2022-JP版文書</TITLE>
<META name="keywords" content="ISO-2022-JP">
<LINK rev=made href="mailto:y.kato@personal.email.ne.jp">
</HEAD>
<BODY>

　文書全体のコメントは、 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!--==ここに文書についてのコメントを書くと解説されていますが、それはアスキー
文字の場合です。日本語などを記載するには、charset=iso-2022-jp指定後に書かな
ければならないので、下のように記載します。==-->
<HTML>
<HEAD>
<META http-equiv="content-type" content="text/html; charset=iso-2022-jp">
<TITLE>ISO-2022-JP版文書</TITLE>
<META name="keywords" content="ISO-2022-JP">
<LINK rev=made href="mailto:y.kato@personal.email.ne.jp">
</HEAD>
<!--================
日本語の場合、文書全体についてのコメントは文字指定の後のここに記載します。
=================-->
<BODY>

WWWサーバがtext/htmlのcharsetパラメタを設定するのが本来の姿です。

　しかしながら、外部文字符号化方式の問題では、WWWサーバがtext/htmlのcharsetパラメタを設定するのが本来の姿です。
<META http-equiv="content-type" content="text/html; charset=iso-2022-jp">
の意味と限界が述べられています。関連関連資料として ［xmlFAQのD.5］があります。

［HTML 2.x　日本語版］からの引用です。

6.外部文字コード化の問題

　テキスト文書の適切な解釈には文字コード化体系が分かっていなければなりません。しかし、現在のHTTPサーバーは Content-Typeヘッダーと適切なcharsetパラメーターを含んでいません。charsetパラメーターを受け取った時、認知されないメディア・タイプを宣言するブラウザが存続しつづけることでその気にさせられないとしても、これは悪い振る舞いです。表示代行手段の装備制作者は、利点がないとしても、ソフトウェアーをこのパラメーターに寛容にするように強く薦めます。適切なラベルは非常に望ましいのですが、それが無い場合の決定的な影響を最小にするために幾つかの予防的な尺度があります：

　文書が元のHTML文書にあるリンクからアクセスされた場合、リンクの意味（AやLINK）のある要素の属性リストに、特にlinkExtraAttributes実体に、CHARSET属性を加えます。その属性の値は、ハイパーリンクによって指し示されている資源によって使われている文字コード化体系の表示代行手段へのヒントになるものでなけらばなりません；それは資源のMIME charsetパラメーターの適切な値でなければなりません。

　どの文書に於いても、コード化体系の示唆を以下の様に文書頭部（ヘッダー）のできるだけはじめに含むことは可能です： 

    <META HTTP-EQUIV="Content-Type"
     CONTENT="text/html; charset=ISO-2022-JP">

　これは絶対安心といえるものではありませんが、メタ要素が解析される迄は少なくともただASCII文字のようにASCII値オクテットがあるだけ、といったコード化体系の場合はうまく働くでしょう。上記の様に信頼がおけないメタの代わりに、サーバーが文字コード化情報を得るのがよりいい方法であることに注意して下さい；より詳しいことや提案については[NICOL2]を参照下さい。

　定義にとって、文書資源から受け取る"charset"パラメーターが最も権威あるもので、次いで上で述べたようなメタ要素の内容による優先順位に続き、在るなら最後にアンカー（固定点）のCHARSETパラメーターです。 

[NICOL2] 
       G.T. Nicol, "MIME Header Supplemented File Type", 
       Work in Progress, EBT, October 1995.

資料