先日、Twitter で僕のページを引用してくださった人がいた。
＃たびたび書くけど、エゴサーチしてますよ。
引用されていたのは、「OS の登場」のページ。
…書いたのずいぶん前で、内容が拙くて恥ずかしい。
しかしまぁ、大きく間違ったことも書いてないのでそのまま残してある。
で、引用してくださった方は、「１行が８０文字」の理由を探していたようだ。
該当ページには、IBM パンチカードが１枚に 80 文字を収めることができたため、コンピューターにディスプレイが付けられた際にも、１行に 80 文字を表示できる必要があった、ということを書いてある。
この話、のちに別のところで詳細解説している。
ハーマン・ホレリス 命日の記事。
ホレリスは、IBM の前身の１つとなる「タビュレーティング・マシン」社を興した人物。
パンチカード集計機を発明し、80桁の数値を記述できるパンチカードを標準化した。
のちに、数値だけでなく文字も表現できるようになったが、80桁、という枠組みは変わらなかった。
さて、冒頭に書いた引用してくださった方は、これが１行 80 文字の理由、としたうえで、「メールの１行を 80文字に制限するマナーは迷信だった」と結論付けていた。
いや、それは論理が飛躍しすぎている。
おそらくは、「古くは」画面の横幅が 80 文字だったことを知り、「今は」その制限がないのだから迷信、という思考の流れだと思う。
しかし、残念ながら 80文字…より厳密にいえば、78文字というのはマナーなどではなくて、システム的な「要求」なのだ。
メールの１行は、78文字を超えるべきではない。
「べきではない」と書かれているように、超えても普通は大丈夫。
だから、緩い制限の「マナー」だと思われがちなのだけど、技術文章で規定された制限なのだ。
インターネットを流れるデータの規定といえば、RFC 。
インターネットメールは、RFC 822 から始まるが、紆余曲折あり、RFC 2822 になり、現在は RFC 5322 となっている。
（なんとなく、822 から連想されやすい番号を割り振っているところが素晴らしい）
で、現在の仕様である 5322 の 2.1.1 節に、こう書いてある。
2.1.1. Line Length Limits
There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
（以下略）
意訳：
2.1.1. 行の長さ制限
１行の文字数には、２つの制限がある。
CRLF を除く１行の文字数は、９９８文字を超えてはならず、７８文字を超えるべきではない。
意訳の中の CRLF というのは、改行を意味する文字のこと。
画面上に表示はされないが、コンピューターのプログラム的には、「１行」の最後には、「行の終わり」を意味する文字が必要となる。
説明すると長いので省略するが、行の終わりは２つの見えない文字で成り立っていて、CR と LF だ。
１行は「改行を除いて」78文字を超えるべきではない。
言い換えれば、「改行を入れて」80文字までだ。
ここに、パンチカードは１枚 80文字という制限が復活している。
パンチカードが 80文字だったために、FORTRAN 言語では１行を 80文字以内と定義しており、ディスプレイは１行に 80文字を表示できるように作られ、初期のスクリーンエディタは１行を 80文字以内としていた。
エディタが１行を 80文字で扱うということは、テキストファイルも１行が 80文字を超えることはない、ということだ。
これを前提として、非常に古いメールシステムの中には、１行を 80文字としてプログラムされたものがあるらしいのだ。
今更そんなシステムが生き残っているとは思えないが、もしそうしたシステムがメールを受け取ってしまうと、80文字を超える部分は削除されたり、強制的に次の行に送られたりする。
RFC ではそうしたシステムを考慮して「78文字を超えるべきではない」としている。
場合によっては一部の情報が削除され、相手に届かなくなってしまう。
それを避けるための制限は、トラブルを未然に防ぐために使用者が心がけなくてはならないもので、マナーや迷信ではない。
ところで、RFC 5322 には、使用できる文字コードの制限もある。
2.3. Body
The body of a message is simply lines of US-ASCII characters.
（以下略）
意訳：
2.3. 本文
メッセージ本文は、単純に US-ASCII で作られた複数行となる。
そう、US-ASCII しか使ってはいけないのだ。
英語は許されるが、ドイツ語もフランス語もだめだし、日本語なんて論外だ。
しかし、実際にこれらの言語でもメールは送れる。
どうなっているかというと、US-ASCII 「以外」のメールは、計算によって US-ASCII の文字に「変換」されて送られるのだ。
この計算方法のひとつに、MIME がある。
US-ASCII に変換されるといっても、日本語が英語に翻訳されたりするわけではない。
単に、日本語の文字を示す「数値」を計算して、数文字の US-ASCII の組み合わせで表現されるだけだ。
変換の際、結果として得られる US-ASCII 文字列は、76文字ごとに改行を入れる、という決まりとなっている。
この結果、元文章の１行が 80文字以上になっていたとしても、通信経路上ではちゃんと 80文字以内に収まっている。
結果的に、「80文字を超えるべきではない」という技術的制限は守られているのだが、利用者がそれを気にする必要はない。
…と、これだけなら「80文字制限は迷信」という最初の話でも、まぁいいかな、ってことになるのだけど、話はもう少し続く。
RFC 5322 で書かれているのは、メールの内容の扱いであり、「MIME の扱いは別議論」としている。
つまり、いったん MIME に変換された際には 80 文字の制限が守られるとしても、それは「メールが」 80文字の制限を守っているのとは違う扱いになる。
通信経路上の問題が解消したとしても、メール自体の問題は残っているのだ。
また、上に、US-ASCII に変換する「計算方法の一つに MIME がある」と書いた。
別の方法もあって、その方法を使うと、MIME の「１行 76文字への変換」が行われない。
この場合、通信経路上の問題も解決していないことになる。
MIME は比較的新しい方法で、日本語の場合、古くは JIS コードでメールの通信が行われた。
これも、「日本語を US-ASCII に変換する計算方法」の一つだ。
そして、今でも互換性のためにこの方法を使えるメールソフトは、結構多い。
JIS コードが当たり前だった当時、よく言われたマナーとしては「１行は 36文字以内」だった。
JIS コードでは、日本語１文字は、英語２文字で表現される。
だとすれば、78文字の制限は、39文字以内となるはずだ。
残る３文字はどこに行ったのだろう？
実のところ、JIS では、ASCII と JIS を切り替えるために、ASCII に規定された「ESC」を使用した。
ESC とは、ASCII から「脱出」して、独自の文字コードを使うために設けられた規定だ。
そして、JIS コードは、ESC に続いて２文字を送ることで、日本語と ASCII を切り替える。
行の頭で日本語を開始し、行の終わりで日本語を終わるとしたら、これに 6文字が必要になる。
日本語に変換すると、３文字分だ。
つまり、これが日本語にした際に消えた３文字分だ。
JIS コードを使用する場合、日本語で RFC の規定を守ろうとすると、１行が36文字以内でないといけない。
ちなみに、行の中に ASCII を入れたりすると、そのたびに切り替えコードが入るため、書いてよい文字数はそれだけ減ることになる。
…JIS でメール書いていた時代でも、80文字を超えて問題出るような環境はまずなかったから、そこまで気にしなかったけどね。
＃現在、JIS コードには iso-2022-jp という名前が与えられている。
JIS コードは、日本国内のローカル規格、iso-2022-jp は国際規格だ。
メールに限らず、通信手段というのは、「相手」や「通信経路」など、多くの参加者があって成立するものだ。
そして、多く参加者があるということは、そのどこに問題が潜むかわからない。
RFC がいまだに１行を 80文字に制限しているのも、実際に過去に 80文字の制限を持つプログラムがあり、今でも残っている可能性があるからだ。
もっとも、RFC5322 の中には、80文字で情報を切り捨ててしまうような環境が本当にあるとすれば、それ自体が RFC5321 違反だ、と言及している部分もある。
（5322 は「メールの書き方」を規定していて、5321 は「メールの送信方法」を規定している）
MIME を使っている場合は、途中経路の問題は気にする必要はないだろう。
MIME によって行は 76文字に揃えられ、決して 80文字を超えることはない。
しかし、この場合も、相手が 80文字を超える行を扱えるとは限らない、ということに注意だ。
…まぁ、そんな古いメーラーを使っている場合、MIME で変換された本文を、元に戻すこともできないような気がする。
もし戻せたとしても、UTF-8 が表示できない、なんてことになりそう。
あまり気にしすぎる必要はないけど、ちょっと気に留めとけ、くらいの問題か。
RFC って、「自分には厳しく、他者には寛容に」という精神なんだよね。
超えるべきではない、と言われているのであれば、自分は超えないようにしないとならない。
でも、誰かが超えてしまったとしても、違反だと怒るのではなく、何の問題もなかったかのように扱えないといけない。
RFC の「規定」って、そういうものなの。
だから、80文字を「超えるべきではない」と規定されているのであれば、少なくとも自分は超えないようにした方がいい。
超えたとしても、「寛容」の精神で、おそらく何も問題は出ないのだけど。
ここで、問題が出ないからこそ、ただの「マナー」だと言われてしまいやすい。
でも、問題が出なくても違反行為で、「寛容さによって」助けられただけという意識は必要。
2019.10.29 追記
そもそも、なぜ「US-ASCIIしか送れない」なんてことになっているのか、という疑問をいただきました。
簡単に言うと、今のコンピューターは 8bit を情報の基本単位としているけど、古いコンピューターには 7bit のものがあるから。
US-ASCII は、7bit で文字を表現するようになっています。
この話、詳細はちょうど10年ほど前に書いてます。
少し内容が古い（最新 OS が Windows 7 だったり、メールの JIS 送信がまだ普通だったりする）けど、以下にリンクしておきます。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 古くて非力なマシンをLinuxBeanで再生してみた
申し訳ありませんが、現在意見投稿をできない状態にしています。 |