Re: Kanji code in fj
こんにちは、山岡です。
>>>>> In <YAS.04Nov2212245@kirk.is.tsukuba.ac.jp>
>>>>> yas@is.tsukuba.ac.jp (Yasushi Shinjo) wrote:
>> 1. no および fr ニュースグループに送信する記事に iso-8859-1 の
>> 文字があったら、ヘッダとボディの両方ともそのまま送信する。
>> 2. 1 と同様に fido7 および relcom の各グループでは koi8-r の文字
>> を素通しにする。
>> 規則を日本語用に追加する必要は無いだろうというのがぼくの判断です。
> Gnus でも、私はこの手の配慮を fj でもやってくれるといいなあ
> と思います。(具体的にどうはればいいんですか?)
新城さんはどんな規則を追加する必要があると思いますか?
ぼくは、現在の Gnus の対応は十分だと思っていますが、本当に必要な
ことならば、盛り込むことに難はありません。
この Gnus のデフォルトは、一見すると charset を限定する規則みた
いですが、実際の動作は iso-8859-1 または koi8-r の 8bit 文字と
ASCII の文字を含む テキストを、base64 や quoted-printable の
encoding で 7bit 化することを抑制するものです。no, fr などのグルー
プ階層では、fj の junet コードと同様にデフォルトの charset が決
まっているのと、わざわざ余計な encoding を行なう必要が無いと考え
られているのでしょう。
それらのグループでデフォルト以外の charset を使っても構わないか
どうか、ぼくは調査していませんが、少なくとも Gnus はそれができな
いようにしていません。
Gnus が日本語の記事を送信するときに使う charset は、上記とは別の
枠組みで設定された優先順位に基づいていて、その日本語用の第一候補
が iso-2022-jp です。それで扱うことができない文字があった場合に
使われる charset は iso-2022-jp-2, shift_jis, utf-8 の順になりま
す。iso-2022-* の記事は 7bit encoding でそのまま出て行きますが、
shift_jis や utf-8 が選択された場合に、それを 8bit のまま出して
しまうか base64 や quoted-printable で 7bit 化するかを決めるのが、
最初に出した例だったのです。fj の規則から離れて、技術的な観点か
ら得られる結論は、まだあるかもしれない 8bit を通さないシステムを
考慮して 7bit に encode するメールとは違って、NNTP は 8bit のま
まで良いということです。
では fj の規則に戻って、ユーザに iso-2022-jp charset で扱うこと
ができない文字を書くことを、fj に限定して禁止することは可能でしょ
うか? 可能だとして、それがもたらすものは何ですか? それを考える
と、ぼくは暗い気分になるのです。
[...]
> JUNET/fj で「JIS コードを使う」といことは、技術的な議論を積
> み重ねて、合意したものです。これを変更するのは、同じくらい議
> 論を積み重ねて合意を取り直す必要があるでしょう。(国連決議を
> 無視して既成事実を作るという方法を取るというなら議論は不要な
> んだけど。)
ちょっと前だったら、他人から意見を求められたならば、ぼくは新城さ
んと似たことを書いたでしょう。それが突然に変わったのは、Gnus の
メーリングリストで encoding に関する話しを持ち出したときに、ドイ
ツの友人が書いた「NNTP はもともと 8bit だよ」の一言によりました。
規則は守るためにあるかどうかについては、新城さんとぼくには大きな
隔たりがあるかもしれませんが、それ以外については、新城さんのお考
えに返事を書くことは、まるでちょっと前の自分を諭すようでもあり、
なかなかに面白いです。同時に、過去の自分に照らしてみれば、この議
論は平行線のままであろうとも思いますが。
[...]
> 上で書いたように、標準化してネットワークに出すのは合理的なわ
> げです。Date: を JST じゃなくて +0900 で出すようなものです。
MIME も一つの標準化です。
[...]
> でも、NNTP を JIS と思うのも変かもね。1つのファイルに複数の
> 文字集合、文字符合が混じっているということかな。そうなると、
> 解釈するには、上の層の知識が必要ですね。つまり、ニュースグルー
> プ群ごとの標準の文字集合とか文字符合化とかの知識です。
それを fj 独自の規格で実現することに意味があるかどうか疑問です。
MIME にはいろいろ不満があるかもしれませんが、それに代わる広汎に
通用する規格を新たに提案することと、メールなどではごく普通に流通
しているやり方を受け入れるのとでは、どちらが現実的でしょうか。
ぼくは fj が iso-2022-jp をデフォルトの charset にしていることに
反対しているのではありませんし、ことさらに特殊な文字を使いたいわ
けでもありません。もっとも、iso-2022-jp で扱うことができない文字
にかかわる問題を議論したいときに、RMS に出すメールでは画像にしな
ければならないのと同じでは不便です。規則が、あれはいけない、それ
はだめ、に終始して、例外を認めないのは狭量ではないかと思います。
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735