メールと日本語

IIJ技術研究所山本和彦

日本初のハッカーである和田先生が先日 bit に Alan Kay の言葉を引用されていました。うろ覚えですが、「ものごとを進める際には 2 通りのやり方がある。 1 つは目的指向で過程への理解を疎かにするやり方。もう 1 つは、過程への理解に重きを置く方法である」という内容でした。

世の中にはいい加減なメールリーダがたくさんはびこっています。また、ユーザの多くも仕事や流行に追い付くことに忙しく、理解することよりもまず使うことに心を奪われているように思います。こういう現状を見るにつけ、この言葉はとても身にしみました。

メールがどういう思想の下に生まれどういう時代背景と共に発展したのか、そしてどのような技術で構築されているのか。このような知識を得る努力をしないプログラマがメールリーダを実装していたのでは、環境はなかなかよくなりません。また、技術やマナーの習得なしにユーザがメールを利用し続けるのであれば、結局底の浅い文化に留まってしまうでしょう。

日本のインターネットをリードする IIJ の社員がメールを理解できていないようであれば、他のユーザにそれを望むは無理な話です。そこで、この連載はメールへの理解が深まるような内容にしたいと考えています。今回の技術的なテーマは、「メールと日本語」です。

コンピュータ科学を学んだ方ばかりが読んでいるわけではないと思いますので、少しメールの書式をおさらいしてみましょう。インターネットでの約束ごとは、 RFC(Request For Comments) に英語で書かれています。メールの書式は RFC 822 (現 RFC 2822)で定義されています。この執筆は 1982 年、元になった RFC 561 に及んでは 1973 年に書かれています。現在でも通用する技術が、こんなにも昔に開発されていたとは驚きです。

少し話題がそれましたので、書式の話に戻りましょう。メールは大雑把にいって、「ヘッダ」と「本文」を「空行」で区切った形式になっています。たとえばこんな感じです。

From: kazu@iijlab.net
To: itojun@iijlab.net
Subject: test

IIJ 技術研究所のドメインでメールが届くかのテストです。

--かず

僕は、この形式に開発者のセンスを感じます。「ヘッダ」はユーザが記述する部分もある一方で、配送プログラムによっても付け加えられます。つまりヘッダの長さは配送中変わるのです。長さを決めうちにせず、終端を「空行」で表すことで柔軟に長さを変更できるようになっています。こういうデータ構造を「番兵」(sentinel)といいます。データの終りを番兵さんが教えてくれているわけですね。

「ヘッダ」は

key: value

という構造を持った行の集合です。 key にはたくさんの種類があり、それぞれの意味が決められています。たとえば、From: は送信者のアドレスを意味します。

さて、RFC 2822 で定義されたメールは、本文にテキストを格納できると定義されています。残念ながら画像などは送れません。よって、RFC 2822 に添ったメールをテキスト・メールと呼ぶことがあります。これに対して、本文を再定義することで画像なども配送できる規格がMIME です。

RFC 822 (現 RFC 2822)の規格、つまり、テキスト・メールはアメリカ育ちだったので、ヘッダにも本文にも ASCII (大雑把に言えば英語)しか使えないように定められていました。しかし、日本人にとって日本語を配送できないのはとても不便でした。

そこで、日本のインターネットの前身である JUNET では、配送に係わる情報を保有するヘッダには ASCII しか使ってはならないが、日本では本文には日本語を使えるようにしようと決めました。つまり、世界では通用しない日本ローカルな規則を定めたことになります。日本語を表現する文字コードには、 JUNET コードを新たに作り採用しました。 JUNET コードは、多くの人が単に JIS コードと呼びますし、 MIME 用語では ISO-2022-JP と名付けられています。

このような理由により、昔は「Subject: には日本語を入れてはいけません」と口をすっぱくして言ったものです。ヘッダに ASCII しか格納できない問題も、現在では MIME よって解決されています。 (今では、「Subject: に日本語を入れてはいけない」という必要がなくなりました。:)

今でもいると思うのですが、ひと昔前は「RFC 822 には本文には0 ～ 127 の文字を入れていいと定義されているのだから、なぜ JUNET コードは違反と言われなければならないのか。また、Subject: も同様に定義されているので、 Subject: にも JUNET コードを入れていいじゃないか」と主張する人がたくさんいました。

確かに、ASCII は 0 ～ 127、JUNET コードも 0 ～ 127 を使って表現します。しかし、「ASCII と JUNET コードを同一視しているところ」に、日本人に固有の偏見があるように思います。仕様ではいつも「構造」とその「意味」の両方が定義されています。

たとえば、「山本」という JUNET コードは

27 36 66 59 51 75 92 27 40 66

という数字の列で表現されています。この数字列の「構造」は、0 ～ 127 に納まっています。

逆にこの数字列を見せられただけでは、どう解釈していいのか実は分からないのです。 (日本人ならなんの疑いも持たずに JUNET コードとして解釈してしまう人が多いでしょう。) 「意味」を ASCII だと思うと、

ESC $ B ; 3 K \ ESC ( B

となります。また、「意味」を JUNET コードだと思うと、 "27 36 66" は「日本語始まり」、 "59 51" は「山」、"75 92" は「本」、 "27 40 66" は「日本語終り」となり、めでたく「山本」と解釈できるわけです。

RFC 822 は大変読みづらいのですが、本文の構造は 0 ～ 127、意味は ASCII と定めています。ですから、構造が同じだからといって、 JUNET コードだと勝手に解釈してはいけないのです。

さてくどくど書いてきましたが、現在ではヘッダや本文に ASCII 以外の文字コードの格納が可能です。これは前述のように、RFC 822 を拡張した規格である MIME のおかげです。次回はヘッダについて詳しく説明します。