![[Attention]](stimpy.png)
この件に関して私は一つ意見を表明しています。皆さんもご自分自身の利益のために（必要とあらば）プロバイダーに苦情を言うことを勧めます。文責 楠 哲士 Satoshi KUSUNOKI
サブジェクトや差出人の名前（From）などを日本語（漢字ひらがな等「全角文字」）で書くことは、「当然のこと」かもしれませんが、いまだにその是非や方式を巡って論議の対象でもあります。実際、例にあるように化けて（turning into unintelligible characters）読めないサブジェクトをしばしば目にするでしょう。（自分は「ちゃんと」書いても誰かにフォローされる内に、あるいは世界中を転送されてゆく内に本人は気付かぬところでそうなることも多い。） また、サブジェクトが乱れたり途中で切れたりして、故にthreadが乱れてしまうことも──これは日本語を使うこと自体が必ずしもその原因ではないものの──日本語を使った場合に起きやすい。そこで、先ず次の点を押さえておくことを勧めます。
日本語（漢字ひらがな等）でサブジェクトや差出人名を書いた場合、必ずしも皆が読めるわけではなく──方式の違いもある──、また特にサブジェクトに関してはthreadが乱れて話題を追いにくくなることもある。このthreadの乱れに関してはForte Agentを使っている場合その「Watch Thread」を活用しきれないことになる。
この上で各人の判断により使うことになります。筆者は差出人欄には日本語（漢字ひらがな等）を一切使わず、サブジェクトについてはその時々の判断で使い分けています。たいていは英数字（ローマ字書きの日本語を含む）で間に合います。ちなみに、日本語サブジェクトを敢えて読まない人もいるわけですが、そういう人にはコンピューターの達人やfjの常連が少なくありません。
以下は必要に応じて読んでください。方式について、つまり自分のnews readerを設定する際どう考えればよいかの示唆も含みます。
名称について重要なことですが、簡単に名称について触れておくと、ここで言う
全角英数字について一口に「英数字」と言っても「漢字と同じ横幅」「何やら大きくて目立つ」全角の英数字はここで言う「日本語」と同じ扱いになることには注意を要します。つまり、「こっちのほうが目立つから」という理由でMS-Windowsのかな漢字変換ソフトのF8（全角英数字に変換）を常用するとことNetNewsでは思わぬ結果を招くことになりかねません。しかも「漢字と同じ横幅」といった見た目のことは他人の環境では必ずしも当てはまりません。更に、パソコンに話を限っても最近はプロポーショナル・フォントといって全角半角の別なく見やすいように横幅を自動調節する潮流にあります。aａの違いが──離ればなれで出てきたとしても──あなたのWindows95では一目瞭然ですか？ 少なくとも横二倍には見えてない人が多いでしょう。いずれにせよ、NetNewsを使っているのはMS-Windowsの利用者だけではりません。 |
ところで、日本語（漢字ひらがな等）で書いたとき、「それは禁止されている」との忠告メールを寄せてくる人がいまだいるそうですが、（fjでは）少なくとも禁止はされていません。上述のように、是非や、とりわけ方式が（いまだ）論議の対象になっており、なおかつ実際に──その人のポリシーで読まないことにしている人がいることは仮に措いたとしても──先の例にあるように図らずも判読不能になってしまうことすらあるというだけです。読んでもらえない記事を書けば本人も損しますし、情報の共有という点でも瑕疵になります。
なお、一口に「日本語」と言ってもパソコンとfjとでは異なる文字規約（いわゆる漢字コード）を使っており、SJISや、はたまた半角カナでヘッダーを書くのは（少なくともfjでは）厳禁です。これはニュースの規約RFC 822（当時はメールと一緒）にてヘッダーのフィールドにはASCII文字しか使えないことになっており、半角カナはもちろんSJISはASCII文字の範囲を超えるコードを含む（一バイト単位で見たときASCIIコードにない文字を含む）からです。ヘッダーは本文とは違って人間ではなく機械が内容を解釈する部分ですから、規格外の場合うまく配送されるかは運次第ですし、ネットニュースはパソコン通信と違って自分と他人とが同じ「原文」を目にしているわけではないので、尚更厄介です。
サブジェクトに関しては「JISでそのまま書くこと」と「MIMEエンコード」との２つが目下流通しています。（この場合のJISはISO-2022-JP。「JIS直書き」とか「生JIS」と呼ぶこともある。） MIMEエンコードとは前者JISコードで書かれたものを（そのまま流すのではなくもう一段）変形（encoding）したもの・することで、以下のようなものです。（解読（decode）はnkf（ネットワーク漢字フィルター）でも可能です。）
MIME符号化された日本語サブジェクトの例 Subject: "=?ISO-2022-JP?B?GyRCJSslSiVANXlMMSRLJGgkayUiJTYlaSU3JE4bKEI=?= =?ISO-2022-JP?B?GyRCNVRCVBsoQg==?= "
ただしこれらは個々のnews readersがどちらを採用しているかによって決まってくることが多く、つまり個々のユーザーには必ずしも選択の余地がありません。後者が読めれば通常前者も読めるでしょう。しかしMIME式記事を読むには多少とも工夫を要するソフトを使っている人──fjの常連にも少なくない──や、またその人のポリシーで読まない（ままにする）人がいます。MIMEヘッダーの利用は「なしくずし的に流布しているが、fjで明示的に合意したことはない」のは真実でしょう。また、次項で述べるようにサブジェクトの途中に余計な空白が入ったりまた尻切れになる原因の一つです。一方、JIS直書きは先の例にあるように世界中を転送されて行く内に化けてしまうことがしばしばあります。これを専門用語で「経路がJISのエスケープを落した」と呼びます*1。
一方、差出人（From:）については「JIS直書き」は容認されません。端的にはRFC 1036 2.1.1節でニュースのFrom行にはエスケープコードや ( ) などが含まれてはならないと書かれている（それなのにISO-2022-JPはエスケープコードや ( ) @ などが大量に現れる）ためですが、折角ですのでその理由を説明しておきます。（以下伊藤一光氏の記事を参考にしています。） ISO-2022-JPはSJISとは違いASCIIコードの範囲内（ASCIIコードの組合せで2バイト文字を表現している）なのでRFC822を満たしているように思えます。そこで、例として滋という漢字を名前に含む人がいるとします。彼のFromは以下のどちらかのようなものとなるでしょう。
From: "滋" <foo@bar.co.jp> From: (滋) foo@bar.co.jpニュース（やメール）の処理系には「滋」は漢字一字としてではなくASCIIコードで見えるので、ISO-2022-JPの場合以下のようになります。（^[はエスケープ文字。）
^[$B<"^[(Bここには " と ( が含まれています。つまり、上記のFrom:記法のうち上の記法では " の対応関係が意表外のところに移り、しかも ( 以下はコメントとして無視されますので（RFC822 3.4.6.節）、処理系にはどこがアドレスだか分らなくなります。下の記法でも ( ) の組みは律義にもネストして解釈されますので同様のことが起きるのは理解出来るでしょう。しかも漢字に @ が含まれると意表外のアドレスを与えたことになります。ところがこれら " @ ( ) はJISのコード表（JIS X0208）を見れば分るように頻出であり不可欠です。（注1:上例「慈」の ( はISO-2022-JPのエスケープシーケンス。注2:異論あり…RFC 1036はfjを規定するか？）
ヘッダーのうちこのような特定の幾つかのフィールドを、確とした構造を持った「structured fields」と呼び、かつ一部のニュース/メールサーバーは処理過程でその中身を読みます。一口にASCII文字ならとは言っても、実際にはそこに使える文字が限られてきます。メールアドレスを含むフィールドはその典型です。一方サブジェクトに関しては配送系ではその中身を関知しないので生JISだろうと配送に障害を起こすことは基本的にありません。（しかしユーザー側（user agents）で「正しく」読めるかは二重の意味でまた別の話。）
ですからFromに関してはもし全角文字を入れるのであれば必ずMIMEエンコードする。自力でMIMEエンコードできないのならはなから英数字で書くことになります。MIMEエンコードとは特殊処理により以上のような問題が起きない形に変換することと考えられます。（しかしMIMEしてもFromに関しては事故が起きることもある。） なお、ここで言う「差出人」とは（記事本文の）いわゆる署名のことではありません。署名は本文の立派な一部ですから日本語をじゃんじゃん使えます。
ところで、署名は「自己表現」の手段なのかもしれませんが、他人はそれを強制的に読まされている（見せられている）という視点は常に必要です。これに関してはネットワーク資源云々という観点でしか理解しようとしない聡明な人も多いですが、資源云々以前にことは（凡庸なる市民社会における）節度の問題なのだよ。
方式について詳しくは
なお、WinVN日本語版では（自分が読む分と書く分双方に関して）上記どちらを採るか選べます（設定→MIMEヘッダ）。同じくMS-Windows用では「tsworks ver 2.25」も。
MIMEエンコード/デコードされたときに言えることですが、全角文字と半角文字の境界でサブジェクトが元と同じになる保証は何と必ずしもありません。元の記事にはなかったスペース（空白）が入ったり逆に抜けたりする可能性があるのです。（これはかなり厳しいことだ。）
また、サブジェクトが切れてしまうのは、長いサブジェクトにnews readersの側が対応していない場合もありますが、たいていはnews serversの側の問題です。長いサブジェクトは（news reader上の最終的な見た目とは別に）news server内では途中に改行を入れて折り返されて保存・管理されているのですが、serverによってはreaderからサブジェクトを求められたときその1行目しか返さないのです。（早稲田のmnのINNはversion 1.4なのでその部類。） そして悪いことに、サブジェクトをMIMEエンコードした場合サブジェクトが元より大幅に長くなるので簡単に一線を越えてしまいます（上例）。僅か漢字13字ほど。しかもASCII文字と漢字とが混ざっていると僅か数文字で折り返されてしまうこともあります。ニュースサーバーの管理者はこの件について「FAQ: Overview database / NOV General Information」（和訳）を見てください。INNはversion 1.5以降が必要です。
ヘッダーの各フィールドを一行しか返さないと他にも問題が出ます。中でも、UNIX系のnews readersには「Refereces」フィールドにMessage-IDを縦に並べるものが多いようですが、こうした記事を読む場合２つ目以降のmessage-idが無視されることになります。つまり、別の例のようにthread表示が正しくなされません。これではネット上で議論に参加する上でかなりの支障があります。
この件に関して私は一つ意見を表明しています。皆さんもご自分自身の利益のために（必要とあらば）プロバイダーに苦情を言うことを勧めます。
最後に実習として、
しかしこれで万全とは必ずしもいきません。昔からあったこととはいえ、最近サブジェクトが化けていて読めないものが目に付き、そしてそれが少なからずMicrosoft Internet Newsから投稿された記事であることに気づいている人も多いでしょう。これは記事が各地を転送されて行く内に化けてしまったもので、化けずに読めているプロバイダーもあります。投稿者本人には問題なく読めているかもしれません。（専門用語で「経路がJISのエスケープを落とした」。） サブジェクトが化けていて読んでもらえないとしたらそれは損な話です。これを避けるには「MIMEエンコード」することが可能です。
Content-Type: text/plain; charset=ISO-2022-JPという変なヘッダーをつけてくれるのです。2行目は「7bit」が正しい。（英文を投稿すると「7bit」になるのだが、今度はcharsetが内容にそぐわない。） しかしこれは通常実害はないものと思われます。（ただしまれに実害があります。） この問題にパッチで対処する試みもあります。（しかしやはり英文の投稿に支障が出る。）
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft Internet News 4.70.1155
以上で分るように、「当然のこと」かもしれないがいまだにその是非や方式を巡って論議の対象、なのです。