>>>>> In <YAS.04Nov1020516@kirk.is.tsukuba.ac.jp>
>>>>>    yas@is.tsukuba.ac.jp (Yasushi Shinjo) wrote:

> 新城＠筑波大学情報です。こんにちは。

こんにちは、山岡です。

この数年、Gnus を使って送信された junet コード以外の記事をみつけ
ると、そうなった理由を徹底的に探し、送信者が junet コードを使え
るようになるまで付き合ってきました。過去には Gnus の開発チームに
はたらきかけて、日本語環境で Gnus を使う場合には、最優先で
iso-2022-jp charset を使うようにしてもらいました。

それでもなお、iso-2022-jp で扱うことができない文字を使った場合に、
特に (メールではなく) ニュース記事では base64 や quoted-printable
を使わずに、そのまま 8bit で送信してしまう問題がある、と考えてい
たのですが、それは本当に *問題* なのかどうか疑問になったのです。

近い将来に Emacs 21.4 に含まれるはずの Gnus v5.11 には次のデフォ
ルトの設定があります。

1. no および fr ニュースグループに送信する記事に iso-8859-1 の
   文字があったら、ヘッダとボディの両方ともそのまま送信する。

2. 1 と同様に fido7 および relcom の各グループでは koi8-r の文字
   を素通しにする。

3. メールの送信では、別途定められた MIME の設定に従ってヘッダと
   ボディそれぞれをエンコードする、またはしない。

4. 上記以外のニュース記事の送信では、ヘッダは MIME の設定に従い、
   ボディは 8bit で送信する。

1 と 2 は、ASCII と Latin-1 またはキリル文字以外のテキストを書い
てはいけないという制約ではありません。fj では一般に junet コード
の日本語を使っていますが、送信者が jisx0201 カナなどの文字を使っ
た場合には、別のコードを使うしかないのと同様です。
dk グループでは Latin-1 の文字に quoted-printable を使うことが制
限されているようで、その場合は 4 の設定が奏功するでしょう。

さて、この設定に含めるべき日本に特化した決まりごとがあるか、と考
えたときに、真っ先に思い浮かぶのは fj の junet コードです。先に
書いたように、日本語環境で起動した Gnus は、デフォルトで日本語の
charset として最優先で iso-2022-jp を選択し、それに 4 の規則が適
用されて記事が出ていきます。ですから、ことさらに 1 や 2 と同様の
規則を日本語用に追加する必要は無いだろうというのがぼくの判断です。
送信者が jisx0201 カナなどを使うかどうかは、送信者に任されます。
いろんな方法で junet コードで扱うことができない文字があることを
警告することは可能でしょうけれども、Gnus の基本機能には含まれて
いません。

ぼくはついこの間まで、fj は junet じゃなければいけない、だから技
術的に可能な対策を、できるだけ Gnus に入れておこうと思っていたの
ですが、いまだにそんな制約が必要なのかどうかが疑問になりました。
大昔の技術上の制約、または利用者の実態に合わせた決まりごとが存続
することによって、逆に失われるものがあるのではないか、と。

最近の Emacs の開発者の意見に、同じテキストを扱うことができる
charset が複数ある場合、返信するときは元の記事の charset を踏襲
するのが良いのではないかという意見もあります。それは、同じ 8bit
文字でも使うことができる Latin-* charset が複数あるという背景が
あるようで、ぼくはいまいち気乗りがしない議題ではありますけれど。

> 読むのは、vin なんでずか、記事の投稿には、GNUS (オリジナル)
> も使います。

GNUS は fj ニュースグループでは junet に固定する設定がありました
ね。

> In article <yotl3bzvqgxv.fsf@jpl.org>
>    Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> \2021\202j\202M\210+\202"\2021\202F\202M\202H\202"\202q\2026\202a\202H\202"\202E\2027\202)\202K\202&\201BNNTP \202M\202`\202F\202`\202F 8bit

> GNUS (オリジナル) で読めません。EUC とか UTF-8 で記事を出す
> のはやめて欲しいです。(上の行は、GNUS の表示を意図的に再現し
> たものです。読めないことの迷惑さがわかるかと思います。なにか
> おかしいかと調べないといけないわけです。)

>> 何か規則がありましたか?  そうだとすればその目的は?

> 規則としては、JUNET時代から fj の記事は、JIS でというものが
> あります。その後、その規則は別に廃止されていません。

> http://www.is.tsukuba.ac.jp/~yas/fj/junet-tebiki/J.6.3

すみません。故意に shift_jis 8bit の記事を送信して、規則を破った
ことをお詫びします。

できれば認めていただきたいのですが、ぼくも fj を永く利用している
側の人間で、最初に fj の読み書きに使ったのは Nemacs 3.3.1 と
GNUS v3.13 です。その立場からの発言と捉えていただければ幸いなの
ですが、いつまでも junet コードに限定する規則を守ることは必要で
しょうか?

梅田さんの GNUS を Gnus として引き継いだ Lars Magne Ingebrigtsen
(一説によると、ラルス・マッグヌ・イングブリグットスンと読むそう
です) とその仲間が、主に日本で行なわれた Semi-gnus の開発の成果
も取り込んで、各国語対応を実現して久しいように、他のニュース・ソ
フトウェアも一般的な charset の指定を解釈して処理する機能をすで
に実現しているでしょう。古いソフトウェアを使い続けている人に、場
合によっては出費や体力の消耗を伴う作業を強制する権利は誰にもあり
ませんが、だからと言ってそれらに合わせるための規則が、新しい技術
の利用を阻害する、または新しいソフトウエアを使う、技術的な側面に
興味の無い人たちの投稿を拒む理由になるのは行き過ぎだと思うのです。

例えば先にぼくが投稿したような記事が fj に溢れて、junet 限定の規
則がなし崩しで反古にされてしまうことはありえると思い、一方で、強
い意志によって、正規の手続きを踏んで短期間で従来の規則を廃止する
のとは別の変化が起きるのではないかと思い、いささか後ろめたい実験
をしてみた次第です。ぼくには junet コード限定規則を改正すべきだ
という強い動機も意欲もないし、それは昔から fj で生活している多く
の人も同様ではないかと思うけれども、このまま放っておいても良いの
かどうか漠然と不安だ、ということもあります。

[...]

> MIME の思想と JIS の思想が合わないというのはあります。JIS だ
> と１つの記事に複数の言語を混ぜても平気な優れた体系です。MIME 
> の Content-Type: は、1 言語だけ。しかも、charset という概念
> を間違っているし。charset は文字集合。encoding とは別です。
> charset では、JIS も EUC も Shift_JIS も同じで、encoding が
> 違う。というわけで、MIME は、文字コードもよく知らないバカが
> 作ったしょうもない規格なわけです。

それには同意します。まあ、でも他に一般的に通用するルールはないし、
ぼくは MIME の諸規格の作成に際して発言することはできなかったし、
しなかったので、受け入れていますが。

> MIME みたいに、あとから出てきたしょうもない規格に、fj が従う
> 理由は、どこにもありません。

従う理由は無いですけれど、譲歩してはいけない理由も無いのでは?

> というわけで、この記事は、MIME なしです。

> なんでそこまでして EUC で出したい、MIME で出したいのかも聞い
> てみようかなあ。

Gnus に関して技術的な側面から少し補足しておきます。Emacs はファ
イルの読み書きに使う coding-system に優先度を持たせてあり、日本
語環境の UNIX 系では euc-japan が、Windows 系では shift_jis が第
一候補になっています。MIME charset の優先度をそれに準じて決定し
てしまうために、ちょっと古い Gnus または日本語以外の言語環境で起
動した Gnus では euc-japan などの記事が送信されてしまう性質があ
り、多くの場合、ユーザが意図的に行なっているわけではないでしょう。