HTMLの言語情報に関する覚え書き

言語情報とUnicode

言語情報は、HTMLの文書文字集合とし て採用されたUCS (ほぼUnicode) のためにある、という誤解がある。例 えば次のようなものである [加藤]。

[HTML 4.0の仕様原案には] HTML4で仕様可能な文 字セットについての解説もありますが、HTMLのレベルで言語指定タグをいれなければな らないそうです。Unicodeが文字コードレ ベルから言語指定を排除した尻ぬぐいを、HTMLがしなければならなくなったわけですね (苦笑)。

[引用者注] 原文は1998年5月2日現在のもの。リ ンクは原文どおり。

文字コードは通常、そのコードで符号化されたテキストの言語 が何であるかを表すことはしない。Unicodeに限らない。ASCIIでもJIS漢字でも、 また、HTML 2.0および3.2の文書文字集合 であるISO 8859-1でも同様である。ASCIIで符号化されたテキストは英語かも知れな いしローマ字表記の日本語かも知れない。JISコードで符号化されたテキストはアイヌ語か も知れないしロシア語かも知れないしラテン語かも知れない。文字 コードは言語を指定しない。

Unicodeが言語指定をしないからHTMLに言語情報が付加されたというのは、文字 コードに対する誤解に基づいた誤りであると言わざるを得ない。 「文字コードレベル」の「言語指定」なるものは、Unicodeに「排除」されたという以前に元々無い のである。むしろUnicodeは次の版(3.0) で「言語タグ」なる仕組みを取り入れようとしている(これの評価 はここでは行わない)。

別の意見として、Unicode/UCSのいわゆ る「日中韓統合漢字」の字体を区別するために言語 情報が必要だと言われることもある [石 川]。日本と中国では「骨」の字体が違うから言語情報で区別 しましょう、という話である。

これも少々ピントがずれている。日中韓統合漢字 の字体差を区別して表示することが必要だと仮定してみても、しか しそれを「言語」の指定で行うことはできないからである。言語で 字体が決まるとすると、統合されたコードポイントの文字の日本の 字体を使って中国語を表すことはできないということになる。

もし「統合漢字」の区別をしたければ (その必要性についてこ こでは論じない)、「日本語か中国語か」ではなく「日本の漢字か 中国の漢字か」(この区別の妥当性についてここでは論じない) の 情報が必要である。「必要なのはスクリプト情報である」[太田] ということになる。

なお、余談になるが、よく言われるUnicodeの「骨」に関して、中のカギが一画で書 ける字体を「中国の字体」と呼ぶのは誤りだという指摘がある [芝野]。

……ここで中国の字形とされる字形は、大正8年の文部省国語調 査室の「漢字整理案」(……) 及び昭和13年の国語審議会「漢字字 体整理案」に見える字体であり、この字体を中国の字体とするのは、 明らかに歴史及び伝統を無視している。なお、大正8年の国語調査 室「漢字整理案」に見える字体は、昭和初期に尋常小学校教科書で も用いられた。

HTMLの言語情報は、UCS/Unicodeとはあま り関係が無い。言語情報がUCSにおいて有 用であるならば、それはASCIIやJIS漢字においてもやはり有用であるはずだ(次節参照)。

言語情報と表示スタイル

次に、言語情報を表示スタイルの指定に使えるかどうかを検討 しよう。

HTMLとともに使われるスタイルシート 言語であるCSSのレベル2 [CSS2] では、HTML やXMLの言語情報の値によってスタイルを 変えることができる。これには疑似クラス「:lang()」 を使う。

よくあるウェブブラウザでは、強調句(EM要素)を斜体で表現することが多い。これは西 洋の文字で書かれた文書に対しては都合が良いが、仮名や漢字では 具合が悪い。そこで、言語情報を使って、強調句の内容が日本語 (LANG="ja")の場合は斜体にするのでなく下線を引く ようにしよう、と考えたとする。

しかしこれはいつでも上手くいくとは限らない。日本語はラテ ン文字(ローマ字)でも書かれ得るからである。英文の中にラテン文 字表記の日本語が出てきたら、その部分に関しては、ラテン文字で 書かれているにもかかわらず斜体ではなく下線で強調されることに なる。この場合「言語」によるスタイル指定ではうまくいかない。 「なに語であるか」ではなく、「どのような表記体系(script、用字系)であるか」の問題である。

また、上と同様に、言語情報で文字の書体を切り替えるのも、 一般には無理がある。日本語と英語とで別の書体を指定したとする。 こうすると、同じ文字(例えば「A」)であっても、日本語の表記に 用いるとき("Arigatô")と英語の表記に用いるとき("Apple")とで書体が違うことになる。開き直って 「それでいいじゃないか」と言うこともできるが、現在日本で行わ れている印刷の常識に照らして決して普通のやり方とは言えない。

一般に、その言語がなに語であるかと、どのような文字で書か れているかとは別のものである。言語の種類が分かれば用字系が分 かるというものではないし、逆に用字系から言語を特定できるわけ でもない。

例えば、モンゴル語はモンゴル文字でもキリル文字でも書かれ るし、トルコ語はアラビア文字で書くこともラテン文字で書くこと もできる。アイヌ語の表記には片仮名がよく用いられるから、「片 仮名だったら日本語だとみなす」という決め打ちはできない。ちな みに、現在策定作業が進められている「新JIS漢字」には、アイヌ語表記に使われる半濁点 付きの「ト」なども収められる予定である[JCS WG2]。

ついでに言えば、符号化文字集合(文字コード)の種類と言語の 種類とも一致しない。JIS漢字(JIS X 0208)は日本語を表記するのによく使われ るが、「有朋自遠方来、不亦楽乎」のよ うに古代中国の文章を符号化することもできる。

もっとも、言語情報をスタイル指定に利用することが常に上手 くいかないわけではない。例えば、ドイツ語の文章の中で、フラン ス語が現れる部分だけ目立たせたいというような場合には言語情報 が利用できる。それはあくまでその文書内でのみ有効なのであって、 一般的な文書に利用できる規則ではない。(例えばウェブブラウザ のデフォルトのスタイルシートとしてこの規則を用いることはでき ない)

概して、言語情報がスタイル指定に使える場面はあまり多くな いと言えるだろう。言語情報は、スタイル指定に全く使えないこと もないが、しかしそのためだけにあるのではない。

言語と文字は一致しない

以上、言語情報が何とは違うのか、何には使えないのかについ て触れてきた。ここで、言語と表記の違いを簡単にまとめよう。

• 用字系(スクリプト)から言語情報は導かれない。(ラテンス クリプトで表記された言語はなに語?)

• 言語情報から用字系は導かれない。(日本語だからといって 仮名漢字混じり文で書かれているとは限らない)

  系: ある種類の「文字」の表示スタイルを指定す るために言語情報を使うことはできない。(ラテン文字のスタイル を指定するつもりで「英語」のスタイルを指定すると、日本語やフ ランス語やトルコ語の文脈でのラテン文字には反映されない)

• 字体/書体は言語情報を特定しない。(「骨が折れます」 ――中のカギがどちらを向いていようと日本語は日本語)

• 言語情報は字体/書体を特定しない。(日本で用いられる字 体/書体を使って中国語を表記する自由はないか?)

• 文字コード(符号化文字集合)の種類は言語を特定しない。 (JIS X 0208で符号化できる言語はたくさ んある)

  ついでに: ISO 2022の エスケープシーケンスは文字集合を切り換えるのであって、言語を 切り換えるのではない。

厳密な言語指定は可能か?

実際に言語情報を指定しようとすると、どこまで細かく言語情 報を付ければ良いのか戸惑うことが往々にしてある。

言語指定の最も大きな単位は文書全体である。文書全体として 見たときにどの言語で書かれた文書であるのかを指定しておくのは、 大抵の場合難しいことではない。例えばこの文書は一部に英語の引 用があるが、全体としては「日本語の文書」と考えるのが普通であ る。(ただし、一つの文書内で同じ内容が二つの言語で書かれてい るなど、複数の言語が全く同等な位置づけで用いられている場合に は簡単ではないだろう)

次に、段落 (paragraph) 単位で考え るのも、やはりさほど難しくはない。この文書では、英語の引用ブ ロックには「LANG="en"」を指定している。HTMLの文書モデルでいう「ブロックレベル」の 要素で考えると良いだろう。

また、一つの文について「これはなに語の文か」と考えるのも、 さして難しいことではない。単語だけでなく文の構造を判定材料に 用いることができるからである。

より微細なレベルになると、どう言語指定したら良いのか分か らないケースが出てくる。

国語辞典に載っているような言葉だけで文章が書かれるのであ れば問題は起きないかもしれないが、現実にはそうではない。我々 の身の周りは、人名、地名、団体名、商品名、造語、略語、ジャー ゴンなどであふれており、そういった言葉がどの言語に属するかと いうことをいちいち意識しながら使っているわけではないのである。

人名や地名のような固有名詞も、言葉である以上はいずれかの 言語に属するものである[田中]。 しかし、その固有名詞の背景にある意味を知らなくても固有名詞と しての用は足りるので、なに語の言葉であるかも知らずに使ってい ることも少なくないのである。

外国人の名前や外国の地名を書くとき、それがどの言語に属す る名前であるかを常に明示しないといけないとしたら、私は音をあ げてしまう。例えば、「クルンテープに 行ってきた」という文について語句のレベルで言語の指定をしよう とすれば、「クルンテープ」というのが なに語なのかを知っていなければならない。(ちなみに、この言葉 はタイ語でバンコクのこと。「天使の都」の意)

固有名詞だけでなく外来語との絡みもある。「カルタ」のよう に日本語として定着したものもあるが、片仮名書きされているから といって一律に「日本語」とみなしてしまうことはできない。近ご ろは外国語の単語を訳さずに発音だけを写して日本語の中で用いる ことが多く行われているが、「アクセシビリティ 」のようなものを日本語だと断言するには勇気が要るであ ろう。また、韓国語の挨拶「アンニョンハシムニ カ」やタイ語の挨拶「サワディークラッ プ」などは、ハングルやタイ文字を読めない日本人に読ま せるためには片仮名で書くのが普通だが、片仮名で書いたからとい って直ちに日本語になったわけではない。日本語をラテン文字で書 いたからといって英語やドイツ語になったわけでないのと同じこと である。元々外国語であっても日本語の中で頻繁に使われていけば 日本語の語彙として認められるわけだが、日本語化されつつある外 国語を見て日本語の単語と認めるかどうかは見解が分かれるところ だろう。

さらに、言語に名前を付けて呼ぶことは時として政治性を帯び るものであることも覚えておかなければならない。この種の問題と してよく言われるのは、ある言葉が方言とみなされるのか、それと も独立した言語として扱われるのかということである[田中1981など]。こういった問題は、 その人の立場や思惑によって見解が分かれるものである。自分の書 き記した言葉がどの言語であるのかを表明することは、そのような 厄介な問題の中に自らの身を置くことなのかも知れない。

このように、正確な言語指定を、とりわけ単語のレベルにおい て期待することは、多分困難である。この困難さは、HTMLや言語タグの仕様に由来するのでなく、人 間が話す言語そのものの在り方から来るものである。なお、HTMLの仕様書には、言語情報の指定にどこまで の細かさ・厳密さを求めているのかは書かれていない。

厳密な言語指定が期待できないとすれば、言語情報を扱うプロ グラムもそのつもりでいなければならない。言語情報をスタイル指 定に使える場面は多くないと先に述べたのには、この事情も絡んで いる。スタイル指定で迂闊に言語情報を使うと、思わぬ表示結果に なってしまう可能性があるということである。

無意味な要素の出現

また別の問題として、属性値は要素単位でしか指定できないと いうことがある。このため、要素に分けられていない語句に言語指 定をするには、SPAN要 素のような意味のない要素として切り分けた上でLANGを指定しなければならなくな る。このため、複数の言語が多く入り混じる文書ではSPANだらけになる恐れがある。 これは、入力の手間が増えて文書が大きくなるだけでなく、文書の 構造を不明瞭にしてしまうという問題がある。例えばHTML文書インスタンスから木構造の表現を生成 したとき、意味のないノードが大量に現れることになる。

さらに、TITLE要素 の中には他の要素が入ることは一切できないので (つまりSPAN要素も駄目)、複数の言 語が混在する題をうまく言語指定することはできない。