Subject: About elm ( was Re: Why I'd like to .....) / elmについて

From: [email-masked] (Wataru KawaKami)
Date: 1 Dec 93 01:25:19 GMT

### Japanese subject will be read as below: ###
X-Nsubject: elmについて (was Re: なぜに"From:"に ....)

[email-masked]。

  "fj.mail"の
  "Re: Why I'd like to use japanese in From:? (Re:Why ....)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> 
  >> 　私も使ってますけど、、、最初はよかったけど、その後改良と称してどんどん
  >> 使い勝手が悪くなっていってるのが困りもの。
mohtaさん、elmを使っていたんですね。

elm2.3PL11くらいが安定していて私は好きでした。いま使って
いる、elm2.4PL20では、mimeを外して使っています。そとから
入ってくるmime'ed Subjectは、mime2xnでX-Nsubjectに。
# mohtaさんはもっと古いバージョンかな？

  >> ># elmのjis7パッチをsydさんに送ってみようかな。:-)
  >> 
  >> 　３年前ならそれで十分だったでしょうけど、、、
  .....
  >> 　今なら、日本語化だけ考えるんじゃなくてＩＳＯ　２０２２完全対応くらいじ
  >> ゃないと、やっぱ恥ずかしいんじゃないすか。
そっすね。そこらが、":-)"ですね。

  >> 　もちろん、表示を（多バイト）文字列の途中で切っても、ｄｅｓｉｇｎａｔｉ
  >> ｏｎ等のｓｔａｔｅをちゃんと戻してくれないといけないし、文字の表示幅も考
  >> えないといけないし、、、いろいろ面倒ですけど。
例えば、elmの題目一覧の実装では、printfのwidth制限("%40s"
とか)で、画面フォーマットを作っています。

  いま手元にあるjis7題目対応のelmでは、そこらをさぼるために、
jis7->eucを内部で行なって、表示幅/stateのところを逃げています。
表示の時に、euc->jis7しています。

  追加したline-edit機能でも同じことをやっています。

# 本当は、真面目にstateを解釈して、表示幅をコントロールするように
# しないといけないんですが、そうなると、文字幅を整えているところを
# 結構いじらないと済みそうにないもので。。。。

  >> > ** header に一日も早く JIScode の ESC が通りますように。**
  >> 
  >> 　昔から通るんですってば。
似非822を除けばでしょ？:-)
					wataru

# Bnewsのfix, Bnews -> Cnews/INNがすすめば、似非822がなくなる
# から、*実際問題*として、通るようになりますね。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Kurimoto Teruki)
Date: Tue, 30 Nov 1993 04:02:34 GMT

栗本ですが．．．反／排 MIME派になりつつあります．

In article <[email-masked]>
 [email-masked] (Hiroaki Sengoku) writes:

>wataru> # wataru@ntttsdは、"From:"にjis7を通す必要性を感じていない。
>
>  私はどっちでも良いのですが、MIME で encoding した header を拒む理由も
>ないのでは ?

 でも，MIMEエンコーダをインストールしなきゃ読めないゴミを送ってよこす
のは困るな．

以下ちょっと前に書いて，出すタイミングを逸した記事
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
 ほんと，Nifty,PC-VANに限らず，MIMEを勝手に送り付けるのは困ったもんだ．
 MIMEをインストールした人どうしで,MIMEエンコードメールをやり取りする分
には文句を言わないが，

「相手がMIMEエンコードされたメールが読めるかどうかも確認しないで送り付
  ける」

のはひどい．  特にFrom:ならともかく

「JISで書いても届くのに（届く範囲なのに？），わざわざ Subject: にMIME
 エンコードした物を書いて来るやつ」

 元々可視の日本語をわざわざ，MIMEで見えなくしてくるとは無意味だ．

 Nifty,PC-VANはWIDE(正確にはもう少し広い)とメール交換しているのだが
WIDE内で Subject: のESCを落とす様なゲートウェイが存在するのだろうか？

 確か昔は，NiftyかPC-VANは X-*: のフィールドに日本語を転写していたの
になぜやめてしまったのでしょう？
 WIDE内で X-*: のESCを落とす様なゲートウェイが存在するのだろうか？

 さらには，

「誰もがMIMEデコードできるわけでもないのに，newsのヘッダにMIME
  エンコードゴミ文字列を書き込んで来るやつ」

 MIME普及の為にわざとやってるのでしょうか？
 それとも日本語がでる事を自慢して自己満足したいだけ？
(デモンストレーションと自己満足の為にやってる様に思う)

 まぁnewsへの投稿は個人の勝手だけど，
------------------------------------------------------------------------
Newsgroups: fj.mail
From: [email-masked] (=!IS0-2O22-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC!=
 (MORIOKA Tomohiko))
Subject: =!IS0-2O22-JP?B?GyRCMj84ThsoQg==!= From:
 =!IS0-2O22-JP?B?GyRCJEskYkZ8S1w4bCRyO0gkJCQ/JCQkTiQrISkbKEI=!= (Re:
 =!IS0-2O22-JP?B?GyRCTX0yciRHJC0kSiQkN11JdxsoQg==!= )
In-Reply-To: [email-masked]'s message of Fri, 19 Nov 1993 01:33:16 GMT
Content-Type: text/plain; charset=IS0-2O22-JP
X-Nsubject: 何故 From: にも日本語を使いたいのか？ (Re: 理解できない芸風 )
Organization: Japan Advanced Institute of Science and Technology, Ishikawa,
	Japan
Mime-Version: 1.0
Distribution: fj
Date: Fri, 19 Nov 1993 09:19:43 GMT

-------------------------------------------------------------------------
(MIME変換されない様に手を加えてあります)

 こんな，意味不明の文字列の肥大ヘッダを見せられると，MIMEに反感は起こ
るが，共感する気は起こらんな．
 上のヘッダだと 25行の端末でGNUSだと本文は2,3行しか見えないのではないの
でしょうか？(References:が数行あったらヘッダしか見えないでしょう)

以上
--
NEC 技術情報システム開発  栗本　光樹（[email-masked]）

---

From: [email-masked] (Masahiro KITAGAWA)
Date: 4 Dec 93 07:50:23 GMT

>>>>> "tell" == Kurimoto Teruki <[email-masked]> writes:
In article <[email-masked]>

  tell>  こんな，意味不明の文字列の肥大ヘッダを見せられると，MIMEに反
  tell> 感は起こるが，共感する気は起こらんな． 上のヘッダだと 25行の端
  tell> 末でGNUSだと本文は2,3行しか見えないのではないのでしょうか？

MIME関係に限らず増え続けるヘッダの行数には閉口します。ほとんどは人間が
読むためのフィールドじゃなくて機械が読むためのもんなんでしょうけど、要
らないものもあるような気がします。X-Nsubject: も化けてくれば同罪(ごめ
ん > 川上さん)。ということで、私は栗本さんと同じく、本文を読みたいので、
gnus-ignored-headers に

^Nntp-Posting-Host:
^X-.*:
^Content-Type:
^Mime-Version:

を加えて自衛しております。こうどんどん増えて行くようだと、「無視する方」
をいちいち付け加えて行くより、「見せる方」を指定する方が合理的のような
気がします。> GNUSの作者の梅田さんいかがでしょうか?

ヘッダの日本語化も、別フィールドやMIMEじゃない方向で実現していただけれ
ばありがたいと思います。

News関係なので、Followup-To: fj.news.b にしました。本当は、もうBだけで
もないので、fj.news.softwares かなんかにすべきなんだろうな。
--
Masahiro Kitagawa <[email-masked]>     北川 勝浩
Electric Eng., Engineering Science, Osaka Univ.  阪大・基礎工・電気

---

From: [email-masked] (Katsumi Nozoe)
Date: Sat, 4 Dec 1993 11:58:03 GMT

>>>>> On Tue, 30 Nov 1993 13:02:34 JST, [email-masked] (Kurimoto Teruki) said:

栗本さん> In article <[email-masked]>

>  私はどっちでも良いのですが、MIME で encoding した header を拒む理由も

栗本さん>  でも，MIMEエンコーダをインストールしなきゃ読めないゴミを送ってよこす
栗本さん> のは困るな．

私は、昨日辺りから MH のバージョンを 6.7 から mh-6.8.1-JP.2c にあげる
作業を始めたので ついでに mh-jheader-kit.tar.gz 等を使って mime エンコー
ドしたヘッダをつけてみようかと実験を始めたのですが…

確かに mime 対応した ツールを全てのユーザが使っているのであれば、mime
エンコードしたヘッダにして送っても特に問題無いのかも知れませんが、現状
では mime エンコードしたヘッダを無条件で送るのは問題があるのでは？

また、 JIS7 で書いたサブジェクトで送ったメイルをリプライする時に勝手に 
MIME エンコードして送り返ってくるのも問題があるのではないかと… 
(Subject だけで用件がわかならなくなってしまう(何の為のSubject ??)

栗本さん>  元々可視の日本語をわざわざ，MIMEで見えなくしてくるとは無意味だ．

その通りだと私も思います。

栗本さん> 「誰もがMIMEデコードできるわけでもないのに，newsのヘッダにMIME
栗本さん>   エンコードゴミ文字列を書き込んで来るやつ」

途中略

栗本さん>  こんな，意味不明の文字列の肥大ヘッダを見せられると，MIMEに反感は起こ
栗本さん> るが，共感する気は起こらんな．
栗本さん>  上のヘッダだと 25行の端末でGNUSだと本文は2,3行しか見えないのではないの
栗本さん> でしょうか？(References:が数行あったらヘッダしか見えないでしょう)

NEWS などでMIME を使用する場合には、先にだれでも読めるような文字列で記
述し、その後に MIME でエンコードしたヘッダをつけるようにして欲しい。。。
特に GNUS 等を使って読んでいると、*Summary* バッファでは、行末まで見る
事が出来ないので、わざわざ記事を開かないと何が書いてあるのか分からない。
--
# Katsumi Nozoe <[email-masked]>

---

From: [email-masked] (Wataru KawaKami)
Date: 6 Dec 93 01:42:35 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 増え続けるヘッダ (was Re: summary about "From:")

[email-masked]。

  "fj.mail,fj.news.b"の
  "Re: summary about "From:" ( was Re: Why I'd like to use......)"について
    (記事<[email-masked]>)、
    [email-masked]、
 >>					X-Nsubject: も化けてくれば同罪(ごめ
 >> ん > 川上さん)。ということで、
別の記事で書いたかも知れませんが、"X-Nsubject:"は、allow jis-7
in "Subject:" を進めていくためのものでした。あの当時は、おそらく
いくら主張しても、jis7を"Subject:"にそのまま通すということは受け
入れられなかったでしょうから。

  そのため、"X-Nsubject:"というフィールドを設けて、きたるべき
日のために、news/mail readerの整備に励んで来ました。(mnewsの
作者のtakumaさんをはじめ、賛同して下さった皆様に感謝しています。)

  allow jis-7 in "Subject:"が達成されれば、"X-Nsubject:"は、
不要になります。

 >> ヘッダの日本語化も、別フィールドやMIMEじゃない方向で実現していただけれ
"X-Nsubject:"で進めていったおかげか、はたまた、時代の流れか、
最近は、jis-7 in "Subject:"も受け入れられるようになってきた
みたいで、"Subject:"にenglish/jis7を併記する方向でkono@sony
さんがfj.news.bで提案して下さっています。

  是非、こちらをもりたてていって下さい。

 >>							「無視する方」
それは、私もそう思います。(elm/mnewsはその点が嬉しい。)

						wataru

---

From: [email-masked] (Tomohiko Sakamoto)
Date: Mon, 6 Dec 1993 16:09:52 GMT

In article <[email-masked]>,
>   allow jis-7 in "Subject:"が達成されれば、"X-Nsubject:"は、

質問です。「jis-7」という用語をどういう意味でお使いですか ?

fj では、文字セットとして、「JIS X 0208 漢字」と「JIS X 0201 ローマ文字
(または ASCII)」の 2 つの文字セットしか許されていません。

「JIS X 0201 片仮名」を使用しなければ、JIS の 7 ビットコードも 8 ビット
コードも同じものだと思うんですが、.....。

わざわざ「JIS-7」と言っているのは、SO(シフトアウト)/SI(シフトイン) を使
用して、片仮名も使いたいということでしょうか ?

>  ** header に一日も早く JIScode の ESC が通りますように。**

こう書かれているところを見ると、ESC ( I で 7 ビットの片仮名を使用したい
のですか ?

【参考文献】
	JIS X 0201-1976 情報交換用符号 (Code for Information Interchange)
	JIS X 0202-1991 情報交換用符号の拡張 (ISO 2022:1986 Informatin
		processing -- ISO 7-bit and 8-bit coded character sets
		-- Code extension techniques)
【おまけ】
        ESC ( B     ASCII の図形文字集合 を G0 集合として指示する。
        ESC ( J     JIS X 0201-1976 ローマ文字 を G0 集合として指示する。
        ESC ( I     JIS X 0201-1976 片仮名 を G0 集合として指示する。

        ESC $ @     JIS X 0208-1978 漢字 を G0 集合として指示する。
        ESC $ B     JIS X 0208-1983 漢字 を G0 集合として指示する。
ESC & @ ESC $ B     JIS X 0208-1990 漢字 を G0 集合として指示する。

        ESC ) B     ASCII の図形文字集合 を G1 集合として指示する。
        ESC ) J     JIS X 0201-1976 ローマ文字 を G1 集合として指示する。
        ESC ) I     JIS X 0201-1976 片仮名 を G1 集合として指示する。
        ESC * I     JIS X 0201-1976 片仮名 を G2 集合として指示する。
        ESC + I     JIS X 0201-1976 片仮名 を G3 集合として指示する。

        ESC $ ) @   JIS X 0208-1978 漢字 を G1 集合として指示する。
        ESC $ ) B   JIS X 0208-1983 漢字 を G1 集合として指示する。
ESC & @ ESC $ ) B   JIS X 0208-1990 漢字 を G1 集合として指示する。
        ESC $ ( D   JIS X 0212-1990 補助漢字 を G0 集合として指示する。
        ESC $ ) D   JIS X 0212-1990 補助漢字 を G1 集合として指示する。
        ESC $ * D   JIS X 0212-1990 補助漢字 を G2 集合として指示する。
	ESC $ + D   JIS X 0212-1990 補助漢字 を G3 集合として指示する。

シフトイン(SI) は、G0 集合の 94 文字を 0x21〜0x7e に呼び出し、0x20 及び
0x7f をそれぞれ通常の意味の意味のスペース(SP) 及び 抹消(DEL) とする。

シフトアウト(SO) は、94 個又は 96 個の図形文字の追加集合 G1 を呼び出す。
文字集合が 94 文字集合の場合は、0x21〜0x7e の位置に呼び出し、SP は 0x20
に、DEL は 0x7e に呼び出す。

--
坂本智彦	[email-masked]

---

From: [email-masked] (Shinji Kono)
Date: Mon, 6 Dec 1993 18:00:44 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] writes 
>質問です。「jis-7」という用語をどういう意味でお使いですか ?

fjが使っている ISO-2022-JP のSubset という意味でしょうけど...

坂本さんは、Subject fieldにどんなコードを許せば良いと思いますか?
専門家の助言を聞きたいですね。実際、MIMEを使うことになると実装的な
制限はなくなってしまうわけですし。

>(または ASCII)」の 2 つの文字セットしか許されていません。

将来的にそうだとは限らないと思います。

>「JIS X 0201 片仮名」を使用しなければ、JIS の 7 ビットコードも 8 ビット

fjの制限というかデファクトスタンダードというものは...

「SI/SOを使わない」
「G0集合にのみ指示する」
「ESC ( H は使わない」
「JIS X 0201 ローマ字のフォントの幅が漢字の半分だと仮定する」
「JIS X 0201 片仮名の  フォントの幅が漢字の半分だと仮定しない」
「制御コードの前ではローマ字またはASCIIを指示する」
「一行はローマ字80字以内をすすめる」
「第二漢字まで読めると仮定する」
「補助漢字が読めるところは少ないと仮定する」

ぐらいですか? これに従って、例えばハングルを通すという可能性はあると思う
のですけど。ISO-8859とかはどうするのかな。

MIMEは、「ASCIIになるのだから必ず通過する」というので「新しいfjの規格の
拡張」だというのを忘れていたのがもめた原因だと思います。なんとなく東京都
のゴミぶくろの不手際に近い気がする。今からでも議論して遅くないですよね。
fjではMIMEをどこに許すのか、MIMEのfullsetを使うのでなければ、どのような
subsetを使うのか。いろいろあると思うのですけど。

---
Shinji Kono                              [email-masked]
河野真治 Sony Computer Science Laboratory, Inc,Japan

---

From: [email-masked] (Masataka Ohta)
Date: 7 Dec 93 08:41:57 GMT

>elm2.3PL11くらいが安定していて私は好きでした。

　それを使ってます。

>  追加したline-edit機能でも同じことをやっています。

　ということですが、これじゃやっぱり、真面目な提案というよりは、単なる遊
びでしかないですね。

># しないといけないんですが、そうなると、文字幅を整えているところを

　もちろん。

　で、問題なのは、そういうことに対応してないソフトでは、ヘッダが変なｓｔ
ａｔｅの途中で切れたりすると、あとの表示がぐちゃぐちゃになることです。

　それぐらいなら、単に読めないだけですむＭＩＭＥのほうが、まだまし。

　で、こういったことがあるから、Ｓｕｂｊｅｃｔ等はＡＳＣＩＩのみとされて
いるわけです。

　だから、エスケープの透過をまっとうな提案とするには、各種ｍａｉｌ／ｎｅ
ｗｓ　ｒｅａｄｅｒに対するちゃんとしたパッチを用意してもらわないといけな
い。

　その際、日本語だけを考えてたんじゃあ、世界的にはパッチは受け入れてもら
えない。

># から、*実際問題*として、通るようになりますね。

　ニュースは関係ないんですけどね。

　似非８２２は、ｂｉｔｎｅｔとかＶＭＳとか、そういったところに棲息してま
す。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Wataru KAWAKAMI)
Date: 7 Dec 93 01:02:22 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: 増え続けるヘッダ (was Re: summary about.....)

[email-masked]。

  どっから、半角かなの話がでたかは知りませんが、

  "fj.news.b,fj.mail"の
  "Re: increasing fields. / 増え続けるヘッダ (was Re: summary ....)"について
    (記事<[email-masked]>)、[email-masked]、
  >> 質問です。「jis-7」という用語をどういう意味でお使いですか ?
私がjis7といったのは、
  >> (または ASCII)」の 2 つの文字セットしか許されていません。
の意味です。
# 半角かなは、眼中になかったもので。。。

					wataru

# どう解釈すると、半角かなの話がでてくるのだらふ。。。謎。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Kusakabe Youichi)
Date: Tue, 7 Dec 1993 15:26:43 GMT

Shinji Kono ([email-masked]) wrote:
: fjの制限というかデファクトスタンダードというものは...

: 「JIS X 0201 ローマ字のフォントの幅が漢字の半分だと仮定する」

これは本当にスタンダードなのですか?
ちょっと、あれですが...。(ほかのものとレベルの違う話...)

  ヘ_ヘ   ----------------------------
ミ・・ ミ  [email-masked]
 (     )〜          くさかべよういち
--------------------------------------

---

From: [email-masked] (Tomohiko Sakamoto)
Date: Tue, 7 Dec 1993 16:34:02 GMT

In article <[email-masked]>),
	[email-masked]

> # どう解釈すると、半角かなの話がでてくるのだらふ。。。謎。

一連の記事の中で jis7 あるいは jis-7 という用語を使用しているのは、川上
さんだけです。jis でいいものをわざわざ jis7 というからには、何か理由が
あるのかな、と疑問に思ったわけです。

jis7 という用語には jis8 が対応しますよね。
jis8 と区別したいから jis7 という用語を使っているんですよね。
で、その違いと言ったら、片仮名しかありません。

	jis8 は、JIS X 0201 でいうところの 8 単位符号。すなわち、片仮名
	を 0xa1〜0xdf で使用する。

	jis7 は、JIS X 0201 でいうところの 7 単位符号。すなわち、SO で
	片仮名を呼出し 0x21〜0x5f で使用し、SI で元の文字セットに戻る。

片仮名を使用しなければ、jis8 も jis7 も同じものになります。jis7 とわざ
わざいう必要がありません。jis でいいわけです。しかし、川上さんから回答
をいただいた今、川上さんの使っている jis7 という用語は、fj で合意がとれ
ている、片仮名を使用しない JIS コード(iso-2022-jp)と同じものを指す、と
いうことがわかって安心しました。

今にして思うと、川上さんは「jis だけだと片仮名が入ってしまうかも知れな
いから、それを除外する意味で jis7 と用語を用いた」のかも知れませんね。
でも、規格上からは、7 ビットを強調しても、片仮名の使用は制限できません。
JIS X 0201 の「6.3 キャラクタの削除 及び 追加」にあるように、文字の削除
は、情報交換当事者間の合意によるものです。

この件に関しましては、この newsgroup で議論されていることとは、直接関係
があるわけではありませんので、これで終了とします。どうもお騒がせしました。

---

From: [email-masked] (Tomohiko Sakamoto)
Date: Tue, 7 Dec 1993 17:14:11 GMT

> fjが使っている ISO-2022-JP のSubset という意味でしょうけど...

川上さんから回答がありました。fj が使っている ISO-2022-JP そのもの
でした。Subset じゃありません。

> 坂本さんは、Subject fieldにどんなコードを許せば良いと思いますか?

まだ、なんとも言えません。ただ、たった 2 文字の「簡易」が MIME では、
「=?ISO-2022-JP?B?GyRCNEowVxsoQg==?=」になるというのは、おそろしい。

> MIMEは、「ASCIIになるのだから必ず通過する」というので

正確に言うと、「ASCII のうちの英数字 [0-9A-Za-z] とほんの小数の無害な
記号 [+/=?] になるだけだから、...」ですね。

---

From: [email-masked] (Tomohiko Sakamoto)
Date: Tue, 7 Dec 1993 17:31:45 GMT

> これは本当にスタンダードなのですか?

「スタンダード」をどういう意味に解釈されていますか ?
「規格」という意味でなら、答は No です。
JIS 規格でも国際規格でもありません。

でもね。vi も mule も less も kterm もその他もろもろの非常によく利用さ
れているツールは、すべてこの仮定の下に動作しています。だから、de facto
standard (業界標準)であることは誰も否定できません。

もちろん、UNIX の世界の Motif や、パソコンの世界の Macintosh、Windows
などに代表される Graphical User Interface では、プロポーショナルなフォ
ントを用いて表示することが当然のごとく行われていますから、近い将来には
de facto standard でなくなる(かも知れません)。

# なんで、こんな当然のことをフォローしなきゃいけないんだろう ?
--
坂本智彦	[email-masked]

---

From: [email-masked] (Wataru KAWAKAMI)
Date: 8 Dec 93 03:20:27 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: elmについて ( was Re: Why I'd like to .....)

[email-masked]。referenceを削りました。

 "fj.mail"の
 "Re: About elm ( was Re: Why I'd like to .....) / elmについて"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> >elm2.3PL11くらいが安定していて私は好きでした。
なるへそ。これでしたか。

 >> >例えば、elmの題目一覧の実装では、printfのwidth制限("%40s"
確認のために書きますが、これは、手を加えないもとのelmの
実装がそうなっているという意味です。

 >> 　ということですが、これじゃやっぱり、真面目な提案というよりは、単なる遊
"日本の中で、日本語のみに対応して遊んでいる、"といういう
意味では、確かにそうですね。

mohtaさんは、わかってらっしゃるかとは、思いますが、
 >> >jis7->eucを内部で行なって、表示幅/stateのところを逃げています。
は、とりあえず、ISO-2022-JPをSubjectに入れた時、途中で
ぶったぎってもとりあえず、化けないようにするということ
で、まずは、
	"日本の中で、日本語のみに対応して遊んでいる、"
ところからはじめてみようということです。

# 最初は、単にESCを通して、"ESC-(-B"を2-setほど吐いて、
# 逃げるという姑息なこともやってました。:-p 
# ktermとかでみている分には、実用上は、化けるのを防ぐ
# ことができました。
# 当然、表示幅は、対応していませんでしたが。

 >> ># しないといけないんですが、そうなると、文字幅を整えているところを
elmについては、いずれ、これをやっていく方向では、考えて
います。
# そういっている間に、MIME+base64がはびこっていたりして。
# fieldだけでなく、*body*も。

 >> ａｔｅの途中で切れたりすると、あとの表示がぐちゃぐちゃになることです。
これは、おっしゃる通りです。(ucb mailが一例。)
この問題は、"body,headerを問わず"、ですね。
# terminalが十分賢ければ、もしかしたら、そこいらを直して
# くれるのかもしれませんが。。。

 >> 　それぐらいなら、単に読めないだけですむＭＩＭＥのほうが、まだまし。
そこらが、
  "fj.mail"で"Re: header ni MIME dounyuu ni tsuite"について、
  (<[email-masked]>)[email-masked]、

  >　ま、いずれにせよ、いまさらエスケープの透過に血道をあげるよりは、文字コ
  >ード設計し直すほうがよっぽど簡単です（でした）けどね。
というところでしょうか。

 >> 　その際、日本語だけを考えてたんじゃあ、世界的にはパッチは受け入れてもら
それはおっしゃる通りです。

 >> ># から、*実際問題*として、通るようになりますね。
Bnewsについては、inewsがheader中のESCとかをはねていたので、
そのつもりでいっていたのですが、どうもmohtaさんのおっしゃって
いる意味と違っていたみたいですね。
						wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Motonori NAKAMURA)
Date: Fri, 10 Dec 1993 00:53:33 GMT

In article <[email-masked]>,
	[email-masked] (Wataru KawaKami) says:
| 8.6.4では、
(ばっさり略)
| もとのファイルに
| 	Full-Name: foo bar foo
| とかいれて、"sendmail -t < file"とかを実行してやると、しっ
| かりと、"Full-Name:"行が削除されてしまいます。
|   また、sendmail.cfの$xにも、/etc/passwdの情報が入ってしまい
| ます。
|   5.xでは、
| 	From: [email-masked] ( foo bar foo )
| とか、"Full-Name:"行が$xに反映されているようです。

sendmail 6.38 の時点で enbug(?) してしまってたようです。
sendmail 8.6.5 で元の仕様にもどるそうです。

＃ O'Reilly の sendmail本が手元に2冊… (^_^;)

- motonori

---

From: [email-masked] (Takahiro Kanbe)
Date: 10 Dec 1993 06:57:50 GMT

>   ＃ O'Reilly の sendmail本が手元に2冊… (^_^;)
手元に1冊です(届いてました)が、 ;-) 分厚い、分厚い。
(国内では、いくらなんでしょうか?)

sendmail,
Bryan Costales with Eric Allman & Neil Rickert,
O'Reilly & Associates, Inc.,
ISBM 1-56592-056-2.

I. Tutorials

1.  Introduction
2.  The E-mail Message
3.  The Roles of sendmail
4.  How to Run sendmail
5.  The sendmail.cf File
6.  Mail Delivery Agent
7.  Macros
8.  address and Rules
9.  Rule Set 0
10. Rule Set 3
11. Rule Sets 1 and S=
12. Class
13. Setting Options
14. header, Priority, Trusted
15. Loose Ends

II. Administration

16. Compile and Install sendmail
17. DNS and sendmail
18. Security
19. The Queue
20. Aliases
21. Mailing Lists and ~/.forward
22. Logging and Statistics

III. Reference

23. The Configuration File
24. Rule Sets
25. Rules
26. Delivery Agents
27. Defined Macros
28. Class Macros
29. Database Macros
30. Options
31. Headers
32. The Command Line
33. Debugging With -d

IV. Appendices

A: The qf File Internals
B: Obscure Error Messages
C: #define Macros in conf.h
D: client.cf File
E: V8 m4 Configuration
F: IDA m4 Configuration

Bibliography

--
神戸　隆博（かんべ　たかひろ）		FXIS/APD/EG

---

From: [email-masked] (Kusakabe Youichi)
Date: 8 Dec 93 15:19:53 GMT

Tomohiko Sakamoto ([email-masked]) wrote:
: でもね。vi も mule も less も kterm もその他もろもろの非常によく利用さ
: れているツールは、すべてこの仮定の下に動作しています。

viやlessがその仮定をしているということは、
マニュアルには書いてないのですが、
どのような動作を確認すれば、それを仮定していると証明できるのでしょうか?
それができないと、

: だから、de facto standard (業界標準)であることは誰も否定できません。

とはならないと思うのですが...。

# そんな仮定のない世界でviしても違和感がないのですが...

---

From: [email-masked] (Masataka Ohta)
Date: 21 Dec 93 12:50:56 GMT

>"日本の中で、日本語のみに対応して遊んでいる、"といういう

　今日、ＩＥＴＦのＭＬのほうで、とあるヒステリーおばちゃんから、

   You are interested just in one thing, how to make difference of C/J/K
   character sets in using UNICODE. Such restricted interest can not lead
   to an international solution. All attempts in that direction will result in 
   a local solution to a restricted region as is  2022 JP.

とか言われましたが、まあ、内容が私にあてはまらないことを除けば正しい意見
でしょう。

　というわけで、ＩＳＯ−２０２２−ＪＰに閉じこもっていちゃあいけないから、
ＩＳＯ−２０２２−ＪＰ−２（一応ＭＩＭＥ　ｃｈａｒｓｅｔ　登録済）の仕様
を、半田さん＠ＥＴＬと共著で書いたわけなんですけどね。早くＲＦＣでないか
な。

>ぶったぎってもとりあえず、化けないようにするということ

　だから、とりあえずのときにＥＵＣに頼るようじゃあ、、、

>elmについては、いずれ、これをやっていく方向では、考えて

　ｅｌｍもともかく、ｃｕｒｓｅｓとかでも誰かやらないですかねえ。

># そういっている間に、MIME+base64がはびこっていたりして。

　ＩＳＯ−２０２２−ＪＰやＩＳＯ−２０２２−ＪＰ−２を（ｃｈａｒｓｅｔ指
定なしでもいいから）使う限り、ｂｏｄｙにＱエンコーディングは要らないんで
すが？

># terminalが十分賢ければ、もしかしたら、そこいらを直して

　ｃｕｒｓｅｓ、ｔｅｒｍｃａｐあたりに手を入れないといけない。めんどい。

>  >ード設計し直すほうがよっぽど簡単です（でした）けどね。

　はあ。

>そのつもりでいっていたのですが、どうもmohtaさんのおっしゃって

　ま、ニュースは関係ないというのは言い過ぎですが、世の中（特に海の向こう
とか、Ｘ．４００の霧の中とかには）変なメイラーはいっぱいあるってことです。

> **** 漢字文は、日本人にとっての plain text だと思う。 ****

　で、そのヒステリーおばちゃん曰く：

私	>You can't force us give up plain text.

	No one can do it!

ですと。将来はＵＮＩＣＯＤＥ＋ｒｉｃｈｔｅｘｔで薔薇色の未来、ときたもん
だ。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Wataru KAWAKAMI)
Date: 22 Dec 93 03:11:54 GMT

### Japanese subject will be read as below: ###
X-Nsubject: ISO-2022-JP-2 : ISO-2022-JPの多言語拡張(=?q)

[email-masked]。

 "fj.mail"の
 "Re: About elm ( was Re: Why I'd like to .....) / elmについて"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> を、半田さん＠ＥＴＬと共著で書いたわけなんですけどね。早くＲＦＣでないか
これは見てみたいですね。
# fj.mailにpre-release(投稿)して下さるとか。:-)

もしや、fj.meetingsにでていた、1/28のJAIN consortiumの
 {\large \bf 国際化、活動報告} Chair: 下條真司 (大阪大） 4:30 -- 5:30
  \item   「Multilingual Extension of ISO-2022-JP」\\
  \hspace*{2cm} 太田昌孝 （東工大）
ですか?
# 実は、しっかりと宣伝を兼ねているとか。:-)

 >> 　だから、とりあえずのときにＥＵＣに頼るようじゃあ、、、
まぁまぁ、そういわずに。

 >> 定なしでもいいから）使う限り、ｂｏｄｙにＱエンコーディングは要らないんで
いえね、ysato@etlさんみたく、MIME+base64をheaderに入れてとかを
やり過ぎると、海の向こうから、
	headerをMIME+base64にしたのなら、なんでbodyもしないの
とかいう声が聞こえてきそうだという意味ですよ。

 >> 　ｃｕｒｓｅｓ、ｔｅｒｍｃａｐあたりに手を入れないといけない。めんどい。
同感。
# ま、これも、流れが定まれば。。。

 >> とか、Ｘ．４００の霧の中とかには）変なメイラーはいっぱいあるってことです。
なるへそね。
# "Ｘ．４００の霧の中"っていうのはいいですね。:-)

 >> ですと。将来はＵＮＩＣＯＤＥ＋ｒｉｃｈｔｅｘｔで薔薇色の未来、ときたもん
実に、mohtaさんらしい。:-)
# ironyたっぷり。:-)
					wataru

---

From: [email-masked] (Masataka Ohta)
Date: 24 Dec 93 04:07:46 GMT

In article <[email-masked]>

># fj.mailにpre-release(投稿)して下さるとか。:-)

　残念ながら（笑）、それには間に合いませんでした。

> {¥large ¥bf 国際化、活動報告} Chair: 下條真司 (大阪大） 4:30 -- 5:30
>  ¥item   「Multilingual Extension of ISO-2022-JP」¥¥
>  ¥hspace*{2cm} 太田昌孝 （東工大）
>ですか?

　そこでも紹介はします。

># 実は、しっかりと宣伝を兼ねているとか。:-)

　ま、宣伝もそれなりに重要ですけどね。そういう政治レベルだけでやってると
ディベート合戦になって技術的な議論ができないのが困りもの。

>	headerをMIME+base64にしたのなら、なんでbodyもしないの

　はあ。まあ毛唐は何いいだすかわかんないですからね。

					太田　昌孝
					[email-masked]