iso-2022-jp+base64
kos...@hiroshima-u.ac.jp
下記のように、NOTESのあるバージョンでは通常のテキストでも
全てbase64で送信されてしまうのでbase64を処理できない受け
取り側のmailerが多発しているのですが、こういう送信側の振舞いは
ルール違反でしょうか。
つまり、rfc1468で書かれている、「iso-2022-jpのテキストに対して
さらにbase64でencodeしているのは良くない」という状態なのですが
最新の情報を知らないのでよろしくお願いします。
--
X-MIMETrack: Serialize by POP3 Server on NOTES(Release 5.0.2b|28 December
1999) at 2000/06/28 18:14:25
MIME-Version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: base64
---
ukoseki
Koichi Nakatani
koseki さん>
> つまり、rfc1468で書かれている、「iso-2022-jpのテキストに対して
> さらにbase64でencodeしているのは良くない」という状態なのですが
> 最新の情報を知らないのでよろしくお願いします。
> --
> X-MIMETrack: Serialize by POP3 Server on NOTES(Release 5.0.2b|28 December
> 1999) at 2000/06/28 18:14:25
> MIME-Version: 1.0
> Content-type: text/plain; charset=iso-2022-jp
> Content-transfer-encoding: base64
RFC 1468 にそう書かれているとしても、 RFC 1468 は INFORMATIONAL
なものでしかないので、ルール違反ではありません。
(IANA registry は、ひとつの `charset' の定義としてだけ RFC 1468 に
言及しています。その charset の使われ方についてはその限りではありません。)
これは「そうする必要がない」方法かもしれませんが、「そうしてはいけない」
方法ではありません。
Shinji KONO
In article <395CC8E2...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>これは「そうする必要がない」方法かもしれませんが、「そうしてはいけない」
>方法ではありません。
それと、これとは話が別なような... iso-2022-jp でないメールを
Internet 上あるいは、Intranet 上に出力するようなアプリケーション
は、はっきり問題があります。
NOTES はなんか直す方法があったような気がします。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
kos...@hiroshima-u.ac.jp
> これは「そうする必要がない」方法かもしれませんが、「そうしてはいけない」
> 方法ではありません。
早速有難うございました。
そのこと（ISO-2022-JP+base64を使っても良いのだよ）を積極的に
指示しているrfc等はないのでしょうか。たしかにrfc1468に強制力
がないのは文面から読み取れるのですが、上のようなメールを読む
ことができない組織が「送るほうで調整（止めてくれなければ）しな
ければ困る。つまり、送信側の設定ミスである」という見解なので
それは違うのだよとハッキリ都言えるかどうかなんですが。受信側に
base64対応を迫ることにはなるので相手側のいいたいことも分るので
すが。
--
ukoseki
Koichi Nakatani
koseki さん>
> そのこと（ISO-2022-JP+base64を使っても良いのだよ）を積極的に
> 指示しているrfc等はないのでしょうか。たしかにrfc1468に強制力
> がないのは文面から読み取れるのですが、上のようなメールを読む
> ことができない組織が「送るほうで調整（止めてくれなければ）しな
> ければ困る。つまり、送信側の設定ミスである」という見解なので
> それは違うのだよとハッキリ都言えるかどうかなんですが。受信側に
> base64対応を迫ることにはなるので相手側のいいたいことも分るので
> すが。
基本的に、いまどき MIME に対応していない組織または個人は、その
ことから起こりうるさまざまな不都合を自分の責任として甘受すべきです。
ISO-2022-JP+base64 を読めない MUA がいまだにはびこっている組織
というのは、(もし主に日本語を使っている組織であれば) MIME への
対応を怠っている組織、ということになります。送信側の落ち度が
全くないという訳ではありませんが、受信側のこの落ち度に比べれば
程度が軽いものです。従って、このメールの送受信がうまく行かない
主たる責任は受信側にあります。
なんらルールに違反していないメールが読めないという受信側の異常な
振る舞いを直すことが第一に必要でしょう。その上で、送信側が今後
無用のトラブルに巻き込まれないために、 content-transfer-encoding
が base64 でなく 7bit かなにかになるよう対策を打つのは結構なこと
だと思います。
Koichi Nakatani
河野さん>
> In article <395CC8E2...@pop02.odn.ne.jp> ,
> Koichi Nakatani <k...@pop02.odn.ne.jp> writes
> >これは「そうする必要がない」方法かもしれませんが、「そうしてはいけない」
> >方法ではありません。
>
> それと、これとは話が別なような... iso-2022-jp でないメールを
> Internet 上あるいは、Intranet 上に出力するようなアプリケーション
> は、はっきり問題があります。
ん? なにか、河野さんの真意と言葉どおりの内容が一致していないような
印象がありますが....
まさか、フランス人がメールに iso-8859-1 かなんかを使うことを
間違っていると主張する訳ではないでしょうね?
charset というものは、合理的な範囲である程度自由に選んで構わないものだと
私は思います。
※ ここで「合理的」というのは、たとえば殆どロシア語しか使わない人が
わざわざ iso-2022-jp を選ぶのは合理的とは言えない、というほどの意味。
Yasushi Shinjo
日本語のメールの漢字コード論理的に考えると、こうです。
(1) JIS コードで送り出したメールは、受手は問題なく読める。
(2) base64 でエンコードすると、読めない人がいる。
(3) 故に、送り出す方は、JIS で出した方がよい。
In article <8jjj2r$q6s$1...@news.hiroshima-u.ac.jp>
kos...@hiroshima-u.ac.jp writes:
> なかたに さま
> そのこと（ISO-2022-JP+base64を使っても良いのだよ）を積極的に
> 指示しているrfc等はないのでしょうか。たしかにrfc1468に強制力
> がないのは文面から読み取れるのですが、上のようなメールを読む
> ことができない組織が「送るほうで調整（止めてくれなければ）しな
> ければ困る。つまり、送信側の設定ミスである」という見解なので
> それは違うのだよとハッキリ都言えるかどうかなんですが。
古文書としては、JUNET の手引きがあります。これは、RFC1468 よ
りも古い約束です。別に、RFC になっていなくても、守るべき約束
はあります。
MIME に関しては、形式としては、RFC になってますけれど、日本
語のメールを出す時に MIME を使うべしという約束は、どこにもあ
りません。JUNET 時代からのJISの約束は、破棄されていません。
そういう意味では、JISで出す方法は正しいと言えます。この古文
書に弱い相手なら、この古文書を見せると効くかと思います。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
----------------------------------------------------------------------
Path: gama!etlcom!kusumoto
From: kusu...@etlcom.etl.JUNET (Hiroyuki Kusumoto)
Newsgroups: fj.guide.general
Subject: 6.3 kanji code convention in JUNET
Message-ID: <TEBIKI881...@etlcom.etl.JUNET>
Date: 12 Feb 88 10:43:29 GMT
Expires: 28 Feb 88 00:00:00 GMT
Sender: kusu...@etlcom.etl.junet
Reply-To: junet-guide@junet
Followup-To: fj.junet
Distribution: fj
Organization: Electrotechnical Laboratory, Tsukuba Science City
Lines: 440
Approved: fjnews@junet
Posted: Fri Feb 12 10:46:22 GMT 1988
<1> JUNET での漢字の取り扱い
[kanji-conventions]
JUNET で使う漢字のコード（系）に関する協約事項については、大筋についてはほぼ
合意されていますが、詳細についてはまだ合意が完全には出来ないままになっていま
す。現在のネットワークにおける漢字コードの協約事項を合意点について述べてみま
した。（漢字に関する議論は、fj.kanji と呼ばれるニュースグループでなされてい
ます。）
また、メールとニュースで使われる漢字についてのおおまかな約束は、「4.4.2 メー
ルとニュースにおける漢字の取り扱い」の項にも説明があります。そちらも参照して
下さい。
<1,1> JUNETにおける漢字利用の約束
以下に協約事項を(1)から(11)まであげていきます。これらのうちのいくつかはぜひ
守らなくてはいけません。また、いくつかは、守って欲しいという推奨事項です。
「JUNET における標準の漢字コード」というのは、ネットワークに流すメール、ニ
ュースなどコミュニケーションのためのコードであって、各システムがローカルにど
んなコードを使うかとか、交信する二者間があらかじめ了解した上で用いるコードに
は関知しない。
この「JUNET 標準の漢字コード」によるメッセージについては、ネットワーク上での
伝達が保証されるし、されるべきである。しかし、それ以外のコードを各組織の内部
で使用し、伝達を保証することは特に規制しない。しかし、少くとも組織間の通信に
おいては、このコードの協約を守れるようにしてほしい。
つまり組織の内部で協約以外のコードを使用することは可能であるが、組織からニュ
ースが出る場合には協約のコードに変換すべきであり、かつ、組織へ入る協約のコー
ドを使ったニュースはあらかじめ変換するなどして受理できるようにしなくてはなら
ない。
同様なことは、既知の二者間のメールにもいえる。二者間の伝達経路において、協約
以外のコードの伝達が保証されており、かつ、その確認ができているならば、その二
者間で協約以外のコードを使用することは特に規制しない。しかし、既知の相手でな
く、伝達の保証が確認されていない場合は、協約のコードを使用するべきである。
コミュニケーションのコードは、もはや国内だけの問題ではないので ISO に準拠し
たコード系を使う。（厳密には、図形文字セットとよばれる文字集合の一部を用いる
。これについての詳細は、この章末の参考資料を読んで下さい。）
すなわち、
JIS X0201 (C6220) の7単位符号
JIS X0208 (C6226) の漢字符号系
JIS X0202 (C6228) の符号拡張法
を使用する。
アナウンサー等は一切省略する。そして、アナウンサーが省略されているものとし
て扱う。
現在、漢字に関するエスケープシーケンスとしては、
ESC $ @ , ESC ( J
ESC $ B , ESC ( B
のいずれをつかってもよい。しかし、
ESC ( H
は使わない。これについては、必ず別のシーケンスにすること。
【注意】 自分の使っているエスケープシークエンスが何かを知るためには、短い漢
字ファイルを作って、その中を od (octal dump) などで調べて見ましょう。
たとえば、「あいうえお」の平仮名5文字のみが書かれたファイル temp を作ったと
します。
Unix : od -c temp
0000000 033 $ @ $ " $ $ $ & $ ( $ * 033 ( J
--------- ---------
と表示されたら、あなたのシステムでは漢字コードとし
て JIS を使っており、エスケープシークエンスとしては
ESC-$-@ と ESC-(-J を使っていることがわかります。
Unix : od -c temp
0000000 202 240 202 242 202 244 202 246 202 250 \n \n
と表示されたら、あなたのシステムではシフト JIS が使
われています。このままで外に送ってはいけません。
あなたのシステムの管理者と相談してください。
また、これらの4つのシーケンスのいずれについても、保存して伝達しなければなら
ない。 例えばあるホストでローカルに ESC-$-B は ESC-$-@ とみなすということに
するのは自由であるが、メイル、ニュースをリレーするときに、 ESC-$-B を ESC-$-
@ に書き換えてしまってはいけない。
（ただし、シーケンスの保存については、ホスト間相互に了解がある場合にはその限
りではない。また、保存しなくても当面問題はないのではないかという意見もあった
ことを付記しておく。）
ファイル末では、ASCII/ JIS Roman 選択をして、改行をしてから終る。すなわち、
メッセージの終了は、必ず英字選択（漢字をぬける）をした後でなければならず、か
つ、最後は改行（行を終了している）でなければならない。
いわゆる半角カナは使わない。
半角カナとは、 JIS X0201 (C6220) の8単位符号のカナのことであり、8ビット目
が1の場合だけでなく、SI、SO によってシフトした場合の半角カナについても同様で
ある。すなわち、半角のカナは使用しない。
また、現在のニュースシステムでは、^O、^Nは、無視するようになっており伝達され
ない。このため、SI、SOを使用して、半角カナを表現しようとしても伝達できないよ
うになっている。 以上から明らかなように、この協約では、7ビットのコードの
みを使用することが前提となっている。
というのは、伝送経路の一部で8ビットコードが通過できない場合があるからである
。例えば、4.3BSD の sendmail はそのままでは 8ビット目を落としてしまうし、ま
た MH もそのままでは inc の際に8ビット目を落としてしまう。さらに、ニュースシ
ステムも同様である。
そこで、仮に送り手・受け手の両者ともがシフト JIS を利用できる環境であっても
、8ビットの転送メッセージがそのまま送られると仮定するのは危険である。さらに
、仮にある時点までうまくいっていたとしても中継ホストのバージョンアップによっ
て8ビット伝達が不可能になることもある。十分注意されたい。
さらに、7ビットであっても、制御コード( < 0x20) のすべての伝達が保証されてい
るわけではないので注意されたい。しかし、少くともエスケープ、改行、タブなどの
制御コードについては、伝達は保証されるし、保証しなければならない。
一行はエスケープを含め255バイトをこえないこと。 また、これを超過する長い行
については、その伝達を必ずしも保証しない。そのようなメッセージを送った場合に
、転送されなかったり、行が途中で切れたり、その行から後ろの部分が無くなったり
する可能性がある。
（これは、伝達のためのソフトウェアが持つ、メッセージ用の行バッファのサイズの
限界から来る制限です。ワープロで作った文書ファイルを送るときには注意しましょ
う。）
漢字列の中では、改行コードはなるべく使わない方がよい。
行をまたいで漢字を継続する場合でも、改行前に、一旦、英字選択をし、改行後、行
の先頭であらためて漢字選択をするようにする。 （これは less 等の Pager でフ
ァイル中をあちらこちら見て回る人のための配慮です）
[rn-restriction]漢字列の中に（2バイトコードに混じって）タブ、バックスペース
等の制御コードおよびスペース(0x20)が入ることは構わない。ただし、漢字列中に混
在した制御コードが来ても制御できないような端末やソフトウェアを使っている人が
いることを思いやり、混じらないように、改行コードと同様な処理を行う方が好まし
いといえよう。
一行は、画面で、あるいは、ハードコピーをとって読んだ時（つまり、エスケープ
シーケンスを除外し、タブを展開し、バックスペースは戻した時）70-76文字以下で
あることが、なるべく望まれる。
（これは、一行に80字を表示できるディスプレイを仮定し、さらに、漢字の折りかえ
しがあると画面がうまく動作しないものがあることを考慮し、何回か引用され行頭に
数個 '>' などが付加されたメッセージの表示をしても、そうしたディスプレイで行
の折り返しが出ないための配慮です）
日常パソコンなどで使っていても、 JIS で定義されていなかったり、標準化されて
いなかったりする文字・罫線があるので注意すること。
具体的には：
JIS 漢字だけを使いましょう。
たとえば、PC9801 等をターミナルとして使っていると、ついローマ数字や、（株）
、丸に数字、といった字を使うことがありますが、これは NEC が拡張した文字で、
JIS 漢字ではありません。他社のターミナルでは読めませんので使わないように注意
しましょう。
罫線素片は使わない。
JIS 漢字コードには表を書くための部品（罫線素片）がありますが、これはうまく
標準化されていません。端末・パソコンによっては無かったり、あっても漢字コード
がちがっていたりしますので、使わないようにしましょう。
第二水準が読めない人もいることを心に留めておきましょう。
上記の協約に反したり、各種の制約のある端末やソフトウェアを使用することが多
いホストでは、それに対処したフィルター、ページャーをユーザに対して用意したり
、ニュースやメールのシステムを改良するべきである。
例えば、漢字コード中には一切1バイトコードは混じってはいけないという(8) の制
限については、その制限の制約を受けないように改良されたrnなどのソフトウェアが
fj.sources などに流れているので、それらをインストールするべきである。また、
moreは早く捨てて“漢字 less”にすることで、能力を上げるようにするべきである
。 また、ESC-(-H しか受け付けない端末や、シフト JIS しか使用できない端末を
使っているとか、シフト JIS や EUC の日本語UNIXを使用しているホストおよびユー
ザは、外からの JUNET 協約のコードによるメッセージを自分のコードに変換するフ
ィルタや、外へ出す場合のフィルタの作成や、ソフトウェアの改良などを行うべきで
ある。
自分のホストや端末の制限や特殊事情によって JUNET 全体の利用環境を低下させる
ことにならないように心がけるべきであろう。
【漢字コード変換のソフトウェア】 各種の漢字コード間の変換をするプログラムが
いくつか投稿されています。詳しくは、fj.sources を参照して下さい。
kc (kanji converter) 和田さん＠東工大作成
nkf (network kanji filter) 市川さん＠富士通作成
<1,2> 参考資料: 複数の図形文字セットの使い方
（注） JIS は、旧名称のままにしてあります。
JUNET で漢字のメイルやニュースがとび交っているが、図形文字セットの切り換え方
に誤解もあるようなので次に説明する。更にくわしくは JIS C6228-1984 および bit
Vol.14 No.6 エディタとテキスト処理(2)を見てほしい。
ASCII や JIS ローマ字、日本語漢字のような文字セットを図形文字セットという。
通常は1文字を7単位（7ビット）（列2～列 7）の1バイトか2バイトで表現する。（CR
や ESC などは制御文字といい制御文字セットというものが別に存在する。）
複数の図形文字セットをとっかえひっかえ使いたいときには、これからどの図形文字
セットを使うかを指定しなければならない。この指定は一般的には2段構えになって
いる。沢山の図形文字セットから使おうとするものを一旦 G0 、 G1、G2、G3 のバッ
ファのいずれかに取り出す。この操作を「指示する (designate)」という。バッファ
は新しく別の図形文字セットをそこへ取り出してくると、そこに前にあったものは失
くなる。最大4つの図形文字セットをバッファに取り出しておくことができる。（バ
ッファといっても1バイトの ASCII も2バイトの漢字も入るから不思議である。）次
の操作はバッファのいずれかの図形文字セットを7単位のコード表へ持ち込むことで
、これを「呼び出す (invoke)」という。コード表は7単位環境にはひとつ、8単位環
境には左と右とふたつある。 G0、G1、G2、 G3 から7単位環境のコード表に持ち込む
にはそれぞれ SI (Shift In) 、SO (Shift Out)、LS2 (Locking Shift 2)、LS3 (Loc
king Shift 3) を使う。そこで7単位環境では G0 に JIS ローマ字、G1に JIS 片仮
名を指示しておき、SI でローマ字に切り換え、SO で片仮名に切り換えることができ
る。8単位環境では G0、G1、G2、G3から左のコード表に持ち込むのにそれぞれ LS0 (
Locking Shift 0)、 LS1 (Locking Shift 1)、LS2、LS3 を使う。LS0 と LS1 は SI
と SO と同じコード (0/15、0/14) である。G1、G2、G3 から右のコード表に持ち込
むにはそれぞれ LS1R (Locking Shift 1 Right) 、 LS2R、LS3R を使う。歴史的理由
で G0 から右に持ち込むことはできない。
7 bit environment
----------
invoke | code |
--------------->| table |<---------------
| | | |
| -->| |<-- |
| | | | | |
| | ---------- | |
| | | |
---------- ---------- ---------- ----------
| | | | | | | |
| | | | | | | |
| G0 | | G1 | | G2 | | G3 |
| | | | | | | |
| | | | | | | |
---------- ---------- ---------- ----------
^ ^
ESC( B| | ESC $ ) @ designate
| -----------------------------
| |
---------- ---------- ---------- ----------
| | | | | | | |
| | | | | | | |
| ASCII | | JIS | | JIS | | JIS |
| | |roman | |katakana| |kanji |
| | | | | | |1978 |
---------- ---------- ---------- ----------
LS2、LS3、LS1R、LS2R、LS3R の制御機能にはどういうコードを使うかというと、 こ
れは ESC Fs シーケンスといってこの順にそれぞれ ESC 6/14、ESC 6/15、ESC 7/14
、ESC 7/13、ESC 7/12 ときめてある。
話を第一段階、指示の仕方に戻す。1バイト7単位の図形文字セットを指示するには取
り出す先が G0、G1、G2、G3 のいずれかに従ってそれぞれ ESC 2/8 F、ESC 2/9 F、E
SC 2/10 F、ESC 2/11 F の形のエスケープシーケンスを使う。F は終端文字 (Final
character)といい、図形文字セット毎にきまっている。7ビットの図形文字セットで
は
----------------------------------
図形文字セット F
ASCII 4/2
JIS 片仮名 4/9
JIS ローマ字 4/10
スウェーデン名前用 4/8
----------------------------------
従って ASCII を G0 に指示するには ESC 2/8 4/2 とする。 図形文字で表わせば 2/
8 が ( 、4/2 が B だから ESC ( B となる。 JISローマ字を G1 に指示するにのは
ESC ) J を使う。 複数バイトの指示は G0、G1、G2、G3 に対しそれぞれ ESC 2/4 F
、 ESC 2/4 2/9 F、ESC 2/4 2/10 F、ESC 2/4 2/11 F の形を使うことになっていた
。 G0 だけ形がちがうのは複数バイトがその昔 G0 へしか指示できなかった時代の名
残りである。F の方は、
----------------------------------
図形文字セット F
----------------------------------
日本語漢字（旧） 4/0 JIS C6226-1978
日本語漢字（新） 4/2 JIS C6226-1983
中国漢字 4/1
----------------------------------
となっている。従って 1978 年版の JIS 漢字を G1 に指示するには ESC $ ) @ とな
る。（G0 へ指示するときだけ形が違うのは気持ちが悪いというので、 F=4/3 以降は
G0 への指示も ESC 2/4 2/8 F とすることになった。） 以上のように、使いたい
図形文字セットをバッファに指示し、コード表へ呼び出して使うのが正式なのだが、
それは面倒という場合には、あるバッファはあるコード表に直結していて、指示した
だけで即使えるという方法もある。それには使う前にアナウンサというのを送る。例
えば ESC 2/0 4/1 を送ると、これは「バッファは G0 しか使わない、そのかわり、G
0 へ指示したものは7単位環境ではすぐコード表へ呼び出す。8単位では G0 へ指示し
たものを左のコード表へ呼び出す」という約束をする。アナウンサにはまだ沢山ある
がそれは JIS C6228 の 8 章を見てほしい。しかし上には上があって、情報交換当事
者間の合意があればアナウンサも省略してよいことになっている。
そこで JUNET で漢字を使う場合だが、次のようにするのはどうであろうか。当事者
間の合意があったとして ESC 2/0 4/1 のアナウンサがあったように使う。つまり図
形文字セットを切り換えるには常に毎回 G0 への指示からやり直すものとする。そし
て呼び出しの制御機能は使わない。
----------------------------------
ASCII へ切り換えるには ESC ( B
JIS ローマ字へ切り換えるには ESC ( J
JIS 漢字 (1978) へ切り換えるには ESC $ @
JIS 漢字 (1983) へ切り換えるには ESC $ B
----------------------------------
これまで JUNET の漢字ニュースなどで漢字へ入るのは ESC $ @で、出るのは ESC (
H といわれたりしていたが、サブルーチンを呼んだり戻ったりするように考えるのは
間違いで、エスケープシーケンスによる切り換えは常に GOTO 文であり、以前何を使
っていたかには関係ないことに注意してほしい。 従って ESC ( H は漢字から出るの
ではなく、1バイトのローマ字へ「行く」という表現が正しい。
しかし、ここにもうひとつの誤りがある。上にあるように JIS ローマ字へ切り換え
るには ESC ( J を使わなければならない。 しかしこれは世の中では間違って ESC (
H と伝わっている。それは JIS C6228-1975 が制定されたとき、JIS C6220 の片仮
名とローマ字の F はそれぞれ 4/7 と 4/8 になると予想してそう記述してしまった
からである。制定のときには 4/6 までしかきまっていなかったからだ。一方片仮名
とローマ字の F を貰うべく登録手続きをしたのだが、その頃同じく登録手続き中で
あったスウェーデン基本コードとスウェーデン名前用コードが 4/7 と 4/8 を貰い、
日本の片仮名とローマ字は 4/9 と 4/10 になった。そこで JIS C6228-1975 には正
誤表をつけて頒布したが、 このことは徹底しなかった。JIS C6228-1984 の解説の15
ページには正しい表がでているが、 JIS ハンドブックには解説がないからそれだけ
見たのではわからない。
JIS のローマ字とスウェーデン名前用の文字セットは次の点で字形がちがっている
。スウェーデンのものだけ示す。
----------------------------------
2/4 $ ではなく一般の通貨記号（太陽マークといわれるもの）
4/0 大文字E＋アキュートアクセント
5/11 大文字A＋ウムラウト
5/12 大文字O＋ウムラウト
5/13 大文字オングストロームのA
5/14 大文字U＋ウムラウト
6/10、7/11-7/14 上のものの小文字
----------------------------------
ついでに ASCII と JIS ローマ字のちがいは次の通り
----------------------------------
ASCII JIS ローマ字
----------------------------------
5/12 ＼ ￥
7/14 ~ （チルド） ￣（オーバーライン）
----------------------------------
この方は軽微な差と思われる。
JUNET のシステムとしては次のように考えるのはどうか。送信側は自分の端末が ASC
II か JIS かにより ESC ( B か ESC ( J を先行させる。受信側は ESC ( B、ESC (
J、ESC ( H を見たら受けつける。 ソフト、ハード的に厳密にできるなら、このどれ
を受けたかにより、それぞれの図形文字セットの図形をだす。面倒なら適当に ASCII
か JIS ローマ字で出力する。大切なことは送信側はスウェーデン名前用を使ってい
ない限り ESC ( H をなるべく早くやめることである。 世の中から大体なくなったと
思ったら受信側も ESC ( Hをはねるようにソフトを変更する。
漢字については次のようにしたい。JIS C6226-1978（旧版）にくらべ 1983 （新版）
は特殊文字が39文字、けい線素片が32文字、漢字が4文字ふえた。旧版しか知らない
端末には新版の端末から困るコードも送られてくるかもしれない。漢字にも第一、第
二水準間で入れ換えがあったが、一応同じ字になっているから読むには困らないであ
ろう。そこで漢字の方も、送信側が自分はどちらの JIS のつもりかをつけて送るこ
とにする。受信側は ESC $ @、ESC $ B のいずれがきてもあわてずに処理をする。規
格協会で売っている16ドット、24ドットの漢字パターンは新版の JIS のものである
。 IBM5550 のコードは旧版である。
制御文字について一言、CR とか ESC とか制御文字はどの図形文字セットが呼び出し
てあるかに関係なく使えるようなコード構造になっている。改行するのに漢字から一
度 ASCII へでなければならないと思っている人もいるようだがこれは誤りである。
以上 出典： 和田英一(wa...@tansei.u-tokyo.junet)
Shinji KONO
In article <395F4A46...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>ISO-2022-JP+base64 を読めない MUA がいまだにはびこっている組織
>というのは、(もし主に日本語を使っている組織であれば) MIME への
>対応を怠っている組織、ということになります。
MIME が読める読めないが問題になっているわけではないですよね?
問題は、そういう構成では、Internet のメールのルールとしては
違反しているってことです。
例えば、Mail<->News のゲートウェイなどで問題を引き起こすでし
ょうし、EBCDIC系のサイトの変換などでも問題を起こすでしょうし、
Mailing list での検索でも問題になるでしょうし、Mailing list
のユーザコマンドなどでも問題を起こすでしょう。
個人のメールスプールでもコードの混在の原因になります。また、
不必要なフォーマット(Word形式とか)を送り出す設定になっている
のに気付かないのかも知れないですよね。
base64 encode されたMIME系のメールは、
MIME decode すると、電子メールとしての形式に違反してしまう可能性がある
ために、どの時点でもMIME encodeされた形式を維持しなければな
らないからです。これらは、メールの処理を根本から変えてしまい
ます。なので、MIME encode された形式は、内容に関わる処理系で
は、基本的に無視することになります。MIME decode するかどうか
は、基本的にユーザの選択を待つ必要があります。まぁ、それは設
計ミスなんでしょうけど、おかげで、メールの検索とかがまったく
できなくなってしまいます。
>なんらルールに違反していないメールが読めないという受信側の異常な
>振る舞いを直すことが第一に必要でしょう。その上で、送信側が今後
>無用のトラブルに巻き込まれないために、 content-transfer-encoding
>が base64 でなく 7bit かなにかになるよう対策を打つのは結構なこと
>だと思います。
iso-2022-jp が base64 encode しないってのがルールなんだから、
それに違反したメールが不都合を受けてもしょうがないと僕は思い
ます。だから、対策が必要なんですよね。
Miki Hoshino
>(1) JIS コードで送り出したメールは、受手は問題なく読める。
>(2) base64 でエンコードすると、読めない人がいる。
>(3) 故に、送り出す方は、JIS で出した方がよい。
>MIME に関しては、形式としては、RFC になってますけれど、日本
>語のメールを出す時に MIME を使うべしという約束は、どこにもあ
>りません。JUNET 時代からのJISの約束は、破棄されていません。
>そういう意味では、JISで出す方法は正しいと言えます。この古文
>書に弱い相手なら、この古文書を見せると効くかと思います。
(以下略)
このJUNETの手引きでは「本文に日本語を直接書く場合」の約束が書かれている
ようにしか読めないのですが。
すなわち、8bitスルーな環境ばかりでは無いのでShift_Jis等の8bit系で本文を
記入しない、日本語の直接記述にはiso-2022-jpを使いましょうってな事が書か
れているのだと思います。
そう言う意味から「日本語を直接書くならJISにすべし」と言うことはあって
も、「本文をMIME base64エンコードしない」になる訳では無いと思います。
＃直接日本語を本文に書いている訳では無いので、手引きの内容に該当しない事
＃になりますよね？
＃で、それが良いか悪いかは別に、推奨されるべきは冒頭に有るような「読め
＃る」形で出す事ではないかと。
--
Miki Hoshino mailto:mi...@section21.com
Shinji KONO
メールシステムは、あるサンプル実装があれば十分だってわけでは
なくて、既存のシステムとのバランスが問題になります。MIMEr は、
誰でもそうなのかも知れないけど、「自分が読めるから、それでメ
ールを送って良い」という発想ではだめです。
In article <3960B8F9...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
> このとき、たとえば IMAP クライアントから「『毛沢東』という文字列を
>検索してくれ」というリクエストが来たとします。 IMAP サーバは、中に
>格納されているメールが ISO-2022-JP であれ、 Big5 であれ、 UTF-8 であれ
>EUC-JP であれ、その文字列を含むメールを検索できるようになっています。
>さらに、 transfer encoding syntax が 7bit であれ base64 であれ問題には
>なりません。
そのサンプル実装では、Word 文書の検索も可能なんでしょうか?
当然出来るんでしょうけど、いったいどこまでできるんでしょうね。
ISO-2022 フル実装とかいうのだと感動です。
> 重要なことは、 UW imapd という特定の実装だけでそれが可能になって
>いるのではなくて、 IMAP4rev1 というプロトコルの設計自体がそれを可能と
>するような実装を要求しているという点です。
もちろん、Mail のbasic text が、現在の標準であるASCII であり、
iso-2022-jp であり、CNS , Korean EUC などであるというならば、
かなり可能でしょう。
しかし、base64 encode を認めつつ、それを実装するのは、僕は、
不可能だと思います。現に、CNS, Korean EUC でも メールでは、base64
encode は使われていません。MIMEは、日々、format が追加されて
しまいますから、それをfull 実装することは不可能です。
どうせ、使えるものに制限があるならば、正しい制限である iso-2022-
jp を使うべきです。
IMAP4 に.mailcap があるなら、まだ、話はわかりますが....
僕だったら、サーバ側にそんなものを入れたりはしない...
>いえ、まさに MIME が読めるか読めないかが (言い換えれば、
>受信側の環境が RFC 2049 の条件を満たしているか否かが)
>問題になっている訳です。
MIME は decode したものが必ず読める規格ではありません。
Koichi Nakatani
新城さん>
> 日本語のメールの漢字コード論理的に考えると、こうです。
>
> (1) JIS コードで送り出したメールは、受手は問題なく読める。
> (2) base64 でエンコードすると、読めない人がいる。
> (3) 故に、送り出す方は、JIS で出した方がよい。
そう、必ずしも最適な方法で送っているとはいえないことは、送信側の
わずかな落ち度です。しかし、最適な方法だけがいつも唯一の正しい
方法とは限りません。 ISO-2022-JP+base64 というのは国際的に認められた
正しい方法のひとつです。
> 古文書としては、JUNET の手引きがあります。これは、RFC1468 よ
> りも古い約束です。別に、RFC になっていなくても、守るべき約束
> はあります。
JUNET の手引き、というのはその前文に示されていることから、
INFORMATIONAL あるいは HISTORIC と解釈せざるを得ない文書です。
Koichi Nakatani
河野さん>
> In article <395F4A46...@pop02.odn.ne.jp> ,
> Koichi Nakatani <k...@pop02.odn.ne.jp> writes
> >ISO-2022-JP+base64 を読めない MUA がいまだにはびこっている組織
> >というのは、(もし主に日本語を使っている組織であれば) MIME への
> >対応を怠っている組織、ということになります。
>
> MIME が読める読めないが問題になっているわけではないですよね?
いえ、まさに MIME が読めるか読めないかが (言い換えれば、
受信側の環境が RFC 2049 の条件を満たしているか否かが)
問題になっている訳です。
> base64 encode されたMIME系のメールは、
>
> MIME decode すると、電子メールとしての形式に違反してしまう可能性がある
>
> ために、どの時点でもMIME encodeされた形式を維持しなければな
> らないからです。これらは、メールの処理を根本から変えてしまい
> ます。なので、MIME encode された形式は、内容に関わる処理系で
> は、基本的に無視することになります。MIME decode するかどうか
> は、基本的にユーザの選択を待つ必要があります。まぁ、それは設
> 計ミスなんでしょうけど、おかげで、メールの検索とかがまったく
> できなくなってしまいます。
この部分には反例があります。 IMAP4rev1 のリファレンス実装として
UW imapd (ftp://ftp.cac.washington.edu/mail/) というものがあります。
よく知られている通り、 POP3 のサーバとクライアントの役割分担に比べて、
IMAP4rev1 というプロトコルはサーバ側の役割が大きくできるように設計
されていて、サーバ側でメールの全文検索を行なう機能なども備えています。
このとき、たとえば IMAP クライアントから「『毛沢東』という文字列を
検索してくれ」というリクエストが来たとします。 IMAP サーバは、中に
格納されているメールが ISO-2022-JP であれ、 Big5 であれ、 UTF-8 であれ
EUC-JP であれ、その文字列を含むメールを検索できるようになっています。
さらに、 transfer encoding syntax が 7bit であれ base64 であれ問題には
なりません。
重要なことは、 UW imapd という特定の実装だけでそれが可能になって
いるのではなくて、 IMAP4rev1 というプロトコルの設計自体がそれを可能と
するような実装を要求しているという点です。
# 面白いことに、 IMAP4rev1 の主たる設計者であり UW imapd の実装者でも
# ある Mark Crispin さんは RFC 1468 の共著者のひとりでもあります。
従って、(引用が前後しますが)
> 問題は、そういう構成では、Internet のメールのルールとしては
> 違反しているってことです。
という部分は河野さんの誤解です。メールの中の文字列検索というのは、
Crispin さんが実装したようなレベルでなければ語れなくなっています。
# 同様にして、 encoded-word を含む subject の文字列検索なども
# オニのように複雑ですが、 IMAP 流の解き方はあります。
SAKIYAMA Nobuo
わるようにフォーマットされているものを「間違い」というのはなかなか難しい
と思うのです(メーリングリストなどで「ここでは間違い」と決めるのは問題な
い)。その上で、
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> しかし、base64 encode を認めつつ、それを実装するのは、僕は、
> 不可能だと思います。現に、CNS, Korean EUC でも メールでは、base64
> encode は使われていません。MIMEは、日々、format が追加されて
> しまいますから、それをfull 実装することは不可能です。
base64 とか Q-encoding といったビット列のエンコーディング方法の話と、文
字コードの話は別の話ではないかと思うのですがいかがでしょうか？
--
崎山伸夫
Shinji KONO
In article <y73u2e6...@chicago.isl.rdc.toshiba.co.jp> ,
SAKIYAMA Nobuo <no...@isl.rdc.toshiba.co.jp> writes
>そもそもニュースじゃなくてメールなんだから、end to end に壊れず中身が伝
>わるようにフォーマットされているものを「間違い」というのはなかなか難しい
>と思うのです(メーリングリストなどで「ここでは間違い」と決めるのは問題な
>い)。
まぁ、それは、その通りなんだよね。閉じている世界で「base64ed shift
jis text が読めなければならん!」といっている分にはOk でしょう。
でも、RFC ふんたらとかいうならば、今の現実のインターネットの標準を
議論しているのだから、「電子メールに関しては、iso-2022-jp が普通」
ってのは動かせないところでしょう。
>base64 とか Q-encoding といったビット列のエンコーディング方法の話と、文
>字コードの話は別の話ではないかと思うのですがいかがでしょうか？
そうね。MIME で、
MIME-Version: 1.0
Content-Type: text/plain; charset="Shift_JIS"
Content-ID: <xxxxx>
Content-Transfer-Encoding: base64
ってするって話ですよね。結局、電子メールとしては、これは「こ
のまま」で受け取るとしか規定してないわけだし、この先、これを
どうやって読むかは、また別な話ですよね。
MTUなりMTAが、このbase64の中身を見るってのは、刺激的な
発想だけど... 実装する方には回りたくないです。
.mailcap に、非常にUniversalな記述で、どんなものでも表示でき
る定義をプログラムとして記述できるとかいうなら、賛成してもい
いかな。そうすれば、MTU の方で、そのプログラムをplug- in 的
に実行してやれば「なんでも処理できる」ってことになるような気
がする。で、そういうプログラムがないとMIMEのcontent-type と
して受けつけないとしてやれば良いわけだ...
そうではなくて、特定のcontentsを、「読めるのが当然だ」みたい
な感じで強要するのは無理じゃないかなぁ。
Keiichi Suzuki
>>>>> "な" == Koichi Nakatani <k...@pop02.odn.ne.jp>さま曰く...
な> 送信側が今後無用のトラブルに巻き込まれないために、
「不要にネットワーク、計算機資源を消費しないように、」という理由にしてい
ただけませんか?
たとえ読むのには支障なくても、意味も無く大きく*した*メッセージを受け取ら
せるのは、勘弁してほしいと思います。
--
鈴木圭一 / kei...@nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B
Shinji KONO
In article <3962064C...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>iso-2022-jp がいちばんポピュラーなのは、日本語圏という範囲での話です。
>一般論としては、 multipart/mixed であるメッセージのパート毎に CES が
>異なる場合をも想定しなければなりません。
せんせい、この話ってもともと日本の話なんじゃないですか?
もし、ISO-8859 の話だとしても、Q-encode せずに8bitで送るほうが
普通のようです。
># さらには、ひとつのサブジェクトの中に複数の encoded-word が含まれて
># いて、それぞれの CES が同じではないケースも想定する必要があります。
Subject に関しては僕は非MIME的立場なのでどうでもいいですが...
いずれにせよ大変なことは確かですよね。
>このふたりの仕事に共通しているのは、 Unicode 抜きでは成り立たない
>という点です。 Unicode を利用して多種類の CES を統合的に扱うという
>戦略のために、まず「JUNET コード」という怪物を MIME という檻の中に
>入れる必要があった、と考えるのは穿ち過ぎでしょうか。
CES ってなんだしたっけ?
もしそうだったら、utf でMIME encodeするのが正統的なアプローチ
でしょう。JUNET コードは怪物とは言えないが、ISO-2022 は、怪物
であったことは確かだと思います。ISO-2022 と Unicode を共存させる
のは馬鹿げているので、(それが一つの解決策だったとは思いますが)
flat text に対しては、現在の標準的なものについてサポートする
UTF-8 を base64 でサポートする
というのが普通のアプローチだと思います。UTF-8 をサポートしろ
というなら、まだ、納得できます。
Unicode は、フォント指定をどうするという問題がまだ、尾を引い
ているみたいですね。こまったものだ... もちろん flat text を
捨ててしまえば良いのでしょうが...
Koichi Nakatani
河野さん>
> でも、RFC ふんたらとかいうならば、今の現実のインターネットの標準を
> 議論しているのだから、「電子メールに関しては、iso-2022-jp が普通」
> ってのは動かせないところでしょう。
iso-2022-jp がいちばんポピュラーなのは、日本語圏という範囲での話です。
一般論としては、 multipart/mixed であるメッセージのパート毎に CES が
異なる場合をも想定しなければなりません。
# さらには、ひとつのサブジェクトの中に複数の encoded-word が含まれて
# いて、それぞれの CES が同じではないケースも想定する必要があります。
> MTUなりMTAが、このbase64の中身を見るってのは、刺激的な
> 発想だけど... 実装する方には回りたくないです。
MIME の作成に携わった人達には、前述の Crispin さんも含めてそういう
複雑な実装をやるつもりの人が含まれていたんだと思います。
こちらも RFC 1468 の共著者のひとりである Erik van der Poel さんは、
今は Netscape 6 の実装に携わっておられるということを聞きました。
Koichi Nakatani
河野さん>
> In article <3962064C...@pop02.odn.ne.jp> ,
> Koichi Nakatani <k...@pop02.odn.ne.jp> writes
> >iso-2022-jp がいちばんポピュラーなのは、日本語圏という範囲での話です。
> >一般論としては、 multipart/mixed であるメッセージのパート毎に CES が
> >異なる場合をも想定しなければなりません。
>
> せんせい、この話ってもともと日本の話なんじゃないですか?
「せんせい」呼ばわりはぜひ止めてください。そんなに歳食ってません :-)
標準の話をするときに、国毎に分けて考えるのはあまり意味がないんじゃ
ないかと思っています。国というより、言語ごとの「圏」別にいろいろな
傾向を論じることはできます。ただし、傾向はあくまで傾向なので、
標準の議論があまりそれに寄りかかると整合性を失う心配があります。
> CES ってなんだしたっけ?
失礼しました。 RFC 2130 の中で CCS, CES, TES という用語が使われて
います。
CCS (Coded Character Set):
文字の集合が整数と対応付けられたもの。
たとえば JIS X 0208, JIS X 0212 など。
CES (Character Encoding Scheme):
ひとつ、または複数の CCS を使って、テキストをバイト列で表わすための
仕組み。たとえば ISO-2022-JP, EUC-JP, UTF-8 など。
TES (Transfer Encoding Syntax):
base64, quoted-printable など。
記憶にたよって書いているので正確ではないかも知れません。
noz...@biol.tsukbua.ac.jp
> この部分には反例があります。 IMAP4rev1 のリファレンス実装として
> UW imapd (ftp://ftp.cac.washington.edu/mail/) というものがあります。
<snip>
> このとき、たとえば IMAP クライアントから「『毛沢東』という文字列を
> 検索してくれ」というリクエストが来たとします。 IMAP サーバは、中に
> 格納されているメールが ISO-2022-JP であれ、 Big5 であれ、 UTF-8 であれ
> EUC-JP であれ、その文字列を含むメールを検索できるようになっています。
これって、variants も適切に処理してくれるのかしらん。
(適切って、ナニ? という質問は本質なので却下)
--
ＮＯＺ 伊藤 希 (のぞみ) 筑波大学 生物科学系
Ｏ Ｏ noz...@biol.tsukuba.ac.jp
ＺＯＮ