Thunderbird 31.4.0で、「濵」を件名に書いて、メールすると、
Subject: =?ISO-2022-JP?B?GyRCenAbKEI=?=

と "ISO-2022-JP" でB encodeされているようにみえます。


"ISO-2022-JP"　は、JIS X 0208-1990までで、「濵」の字は、それに含まれず、JIS X 0212に含まれるので、
"ISO-2022-JP-1"　とならないといけないのではないか、と考えました。

"ISO-2022-JP-1"としなくても、規格上は問題ない、ということなのでしょうか。

識者の方、ご教示いただけますと幸いです。

よろしくお願いいたします。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

メールで指定する「ISO-2022-JP」という、文字エンコーデングの「名前」「ラベル」は、
厳密に、JIS X 0208-1990とかJIS X 0208-198xだとか、JIS規格の各種バージョンごとの違いを反映させよう、とするものではありません。

で、この「メールで指定するISO-2022-JPという、文字エンコーデングの名前・ラベル」は、
JISの規格で決まっているわけではなくて、IANAで規定されているものです。
「JISの規格との対応を考えると、ISO-2022-JPファミリー」ってな感じかな。
IANAで、"ISO-2022-JP-1"が規定されていて、JIS X 0212の文字があるならISO-2022-JP-1と指定しなければいけない、と規定されているのですか？
Unicodeも、一杯バージョンがあるわけで(たとえば絵文字の拡張があったバージョン)、それを反映して、UTF16-BE-V2とかUTF16-LE-V6とか、UTF-8--V3とか指定せよ、ってな規定になっている？

Webとかメールでの「文字エンコーディング」は、Unicodeへの変換のためのコード表、とでもいうべきものであり、
ブラウザーやメーラーは、Unicodeへの変換が意味を持つ範囲で、JIS規格の中の、可能な限り広い範囲の「コード表」を使うようにするはず。
だから、「濵」のような、追加されたものを含むものを使うようにしていて、
ISO-2022-JPと指定されているんなら、JIS X 0208-1990にはないからと「濵」を表示してやらない、なんてな意地悪はしません。
198xの規格では、コードポイントAがUnicodeのABの文字のグリフ、コードポイントBがUnicodeのBAの文字のグリフ、だったのを、
198yの規格で、コードポイントAをUnicodeのBAの文字のグリフ、コードポイントBをUnicodeのABの文字のグリフ、ってな風に変えて、
コードポイントの入れ替えをJIS規格ではやった前科があったはずですが、
さすがにこれは、Shift_JIS_198x、Shift_JIS_198y、ってな風に、送る側が教えてくれない限り対処のしようがない。

「"ISO-2022-JP"　は、JIS X 0208-1990までで、「濵」の字は、それに含まれず、JIS X 0212に含まれる」から気持ち悪い、というのなら、UTF-8で送ったらいかがですか？
Unicodeなら全然問題ないでしょ？

返信ありがとうございます。



ISO-2022-JPについては、RFC 1468にて、どの文字集合を使うか記載があります。ASCII、JIS X 0201-1976、JIS X 0208-1978、JIS X 0208-1983とあります。 （Background Informationでの説明で、JIS X 0208-1990も許容されているのでしょうか。）

同様に、ISO-2022-JP-1については、RFC 2237に記載があります。ASCII、JIS X 0208-1978、JIS X 0208-1983、JIS X 0201-Roman、JIS X 0212-1990とあります。

「濵」は、JIS X 0212に含まれる文字なので、ISO-2022-JP-1、になるのではと考えたわけです。

ISO-2022-JP、と表記していても、厳密に考える必要はなくて、それはファミリー名のようなものであって、クライアント側はよしなにしろ、というのが、メールの世界なのでしょうか。



わたくしはUnicodeの話をしていませんし、Unicodeへの変換について話をしているわけではありません。

ThunderbirdがISO-2022-JPとして示して送ってくるデータが、実際、RFCで規定されている、ISO-2022-JPで使えるとされる文字集合にはない、というのは、なにか、わたしが知らないことがあって、規格上もんだいないとされているのか知りたい、ということだけです。

（規格上は問題があっても、通例としてそういうもんである、ということはあるかもしれません。だた、そういったこともわからないので、うかがってみたわけです。）



「UTF-8で送れば別に問題ないんじゃね？」というのはたしかにそうかもしれませんね。でも、別に問題ないからいいや、とか、そういう話をしているわけではないのです。

（なんで、Unicodeの話にこだわるんでしょうか。そんな話をしているわけではないのですが。）

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

IBM拡張文字としてWindows-31J(CP932)に含まれているので、丸付き数字などと同じく手抜き計算によってISO-2022-JPにしてしまうのだと思います。

Unicode: U+6FF5
Windows-31J: 0xFB4D

もちろんISO/JISには沿っていないのですが、困ったことに同じ手抜きをしているソフトが多く、それらの間では送信側の意図した通りに表示されてしまいます。
むしろ厳密に解釈するソフトでは表示されないというのが現状です…orz

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

それはわかっております。
0x5Cは、Shift_JISでは円記号なんだから、何が何でもUnicodeの円記号 (U+00A5)にマップされる、あるいは変換されるべきである、と主張なされて、HTMLのURIの中の0x5CやJavaScriptの中の0x5Cのお話には耳を傾けようとしない、下手すると理解できてないんじゃないか？、というような方々と、
長いことお付き合いしてきましたから(別な表現をすると、泣かされてきた、ですけど)。
http://ja.wikipedia.org/wiki/%E5%86%86% ... 8%E5%8F%B7
http://ja.wikipedia.org/wiki/%E3%83%90% ... 7%E3%83%A5

"ISO-2022-JP-1"って、ちゃんと定義されているんですね。
http://tools.ietf.org/html/rfc1468
http://tools.ietf.org/html/rfc2237
rfc2237の記述。
> 1. Abstract
> This memo defines an encoding scheme for the Japanese Characters,
> describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822]

RFC822はObsoleteで、RFC2822に置き換えられ、RFC2822も既にRFC5322で置き換えられているからその記述は無効、ってなチャチャは無しにして(^^)

http://ja.wikipedia.org/wiki/ISO-2022-JP
ISO-2022-JP-1　の他に, ISO-2022-JP-2, ISO-2022-JP-3, ISO-2022-JP-2004 などもあって、ISO-2022-JP-3については、以下のように書いてある。
> ISO-2022-JP-3
> JIS X 0213:2000の附属書2に記述される符号化表現で、ISO-2022-JPの漢字集合をJIS X 0213に変えるなどしたもの。
> IANA登録簿への登録が提案されたが、RFC 2278（当時。RFC 2978により廃止された）の手続きに従っていない
>（いっぺんに複数の文字コードを登録する手続きは存在しないのに6つ同時に申請されている）
> などの理由により却下された[1]。

で、IANAの方は？、と探すと、http://www.iana.org/assignments/character-sets/character-sets.xhtml があった。
Preferred MIME Name=ISO-2022-JP の Source=RFC1468 & RFC2237 と規定してある。
今回の ISO-2022-JP vs ISO-2022-JP-1 問題は、これにて一件落着。
RFCで言っている　ISO-2022-JPホゲホゲって、紛れが少ない方の呼び方だと ISO/IEC 2022-JPホゲホゲ になるものですよね。
で、メールのエンコーディングの文字セット指定やcharset指定は、IANAで定義された「Preferred MIME Name」なんだから、ISO/IEC 2022-JP-1に関しては、何ら問題はない。

「文字の集合」について、特に「コンピュータにおける文字集合」については、概念的に微妙に異なるものがあって、
http://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E9%9B%86%E5%90%88
> 1.1 レパートリ
> 1.2 符号化文字集合
> 1.3 符号化文字集合と文字符号化方式
とうように感じで区別している。
JISの規格やISO-2022-JPみたいなものでも、正式名称は「交換符号化方式」といった感じのものだったような気がするから、
「文字符号化方式」という、マッピングだけを意識したものの上に、「交換符号化方式形式」といった疑念もありそう。
7bits-asciiは1バイトのまま、エスケープシーケンスを使い、日本語などは多バイトで、というのは、
厳密にコードポイントを規定する、というだけでなく、通信量を意識した規定のはずだし。
で、ただでさえややこしいのに、こういったものの上にEメールのためのRFCがあって、その上にまたIANAのPreferred MIME Name、がある...

IANAのiso-2022-jpが、iso-2022-jp-Xもiso-2022-jp-Yも包含しているものになっているのは、
JIS X 0212は、他iso-2022-jpの独自拡張とはバッティングしづらいだろうし、
よしんばJIS X 0212とMS Winの独自拡張とバッティングしたって、ごく一部だしグリフが変っても影響はなさそうだし、
わざわざiso-2022-jp-Xとiso-2022-jp-Yを区別して、それによって、含まれない文字は無視するとか表示しないとかをしたって無意味だし、
Source=RFC1468 ⇒ Source=RFC1468 & RFC2237 に拡張したように思えます。
これなら、ブラウザーやメーラーが内部で持っている iso-2022-jp⇔Unicodeの変換表 にJIS X 0212の文字を加えたものを、パッチなり新バージョンとして提供するだけで済む。


なんで、ある文字に関する規格のあるバージョンにある文字が含まれているかいないか、とか、その規格のバージョンをなんと呼んでいるか、とかにこだわるんでしょうか。
そんな話をしているわけではないのですが。

Web(HTML)の世界では、ISO/IEC 10646 (JIS X 0221)を使う、あるいは、文字とはISO/IEC 10646 とかUnicode、ってな感じで規定してなかったですか？
「 レパートリ (repertoire) - 符号化文字集合で表現する文字の指定された集合」は、ISO/IEC 10646 とかUnicodeを使う、といった感じ。
ちょっと古いみたいだけど、W3CのFAQ ： http://www.w3.org/International/O-unicode.html
だから、「Unicodeに変換できるのものだけ」というような言い方も可能でして。

E-mailの世界もWebの世界と無関係ではないから、それに準じて、あるいは矛盾しないように規定しようとしているはずだし、
全部Unicodeに変換して処理して必要ならどれかの符号化方式に変換して送る、ということをしても何ら問題が無いように規定しようとしている、
と考えてもいいと思います。
どの呼び方であっても概念であっても、「共通に認識されている、文字のグリフとか文字の意味」があり、一連のバイトコードのそれへのマッピングの表があって、それを色々な呼び方で区別しているだけ、と単純化して考えてもいいこと。
伝えたいものは、「共通に認識されている文字のグリフとか文字の意味」であって、
バイナリーのデータそのものではないわけだし、マッピングの表でもないんだから、どのマッピングの表を使って送っても構わなくて、
受け取った側に、こちらの意図どおりにバイナリーのデータの解釈をしてもらえるようにすればいいわけであって、
ISO/IEC iso-2022-jpとISO/IEC iso-2022-jp-1の違い、とか、それらの、他のISO/IEC iso-2022-jpの独自拡張との競合、などによる何らかの問題を気にするんだったら、
そういった問題のおこらないUnicodeというような文字符号化方式を使って送ればいいだけの話。

厳密な規定がある「JIS X 0212」の文字が含まれていないものをiso-2022-jp-Xと呼び、含まれないものをiso-2022-jp-Yと呼ぶ、というのは、そう呼びたければそう規定すればいいだけのこと。
JISの規格では、規格の拡張時には。他の独自拡張との競合もきちんと考慮しないといけないから、どうしても細かくなりますよね。
で、あとは、みんながその規定に沿って動けば、メデタシメデタシ。
でも、ある好き勝手な規定があったとしても、別に、その通りにしなければいけないという法律もないし罰則規定があるわけじゃないし、別にしたぐなきゃぁしなくたっていい。
IANAは、JISの意向に沿ってiso-2022-jpとiso-2022-jp-1を分けることはせず、ある時点でiso-2022-jp＝iso-2022-jp＋iso-2022-jp-1;を実行したんでしょう。
「JIS X 0212による拡張と他の ISO/IEC 2022-JPの独自拡張の競合による弊害　＜＜＜　Preferred MIME Nameをiso-2022-jpとiso-2022-jp-1 に分けることによる弊害」
は、JIS X 0212に限って言えば、火を見るよりもあきらか、じゃないんですか？

[追記]
ポストしたら、IANAの名前=Windows-31J,CP932、に関係するコメントがあった。
http://en.wikipedia.org/wiki/Code_page_932 を見ると、
> Code page 932 (abbreviated as CP932, also known by the IANA name Windows-31J) is Microsoft's extension of Shift JIS to include NEC special characters (略)
のほかに、
> The windows-31J name however is IANA's and not recognized by Microsoft, which historically has used shift_jis instead.
と書いてあった。
MS では、"IANA name Shift_JIS" == "CP932" であって、"IANA name Shift_JIS" != "ISO/IEC Shift_JIS" であり、"IANA name windows-31J"は無視、のようです。
NEC文字問題って、多分これだったんでしょう。

どのみち、"IANA name Shift_JIS" にフォールバックしてCP932、自動検出でShift_JIS＝CP932、知らないものだからCP932、となるんでしょうから、
厳密に、"IANA name windows-31J" ⇒ CP932、"IANA name Shift_JIS" ⇒ "ISO/IEC Shift_JIS"、を期待して、MSのメーラーとか、MSの世界しか知らないメーラーに送ると、痛い目にあう、ということになりそうです。
ちしはら さんは、こんなことを許してきて、あるいは受け入れてきておきながら、Thunderbirdが"ISO/IEC ISO-2022-JP"のコード表にはなくて、"ISO/IEC ISO-2022-JP-1" のコード表にしかないコードポイントを"IANA name ISO-2022-JP"で送ることは許せない？ (^^)
[/追記]

相手がどういう人が一方的に決め付けて話をする方なんですね。



なるほど、ISO-2022-JP-1は、IANA Character Setsの一覧には載っていなかったのですね。知りませんでした。そして、たしかに、Sourceとして、「[RFC1468] (see also [RFC2237])」と記載があります。

MIME Type名として、この文書に記載されている名前を使うのであれば、Thunderbirdが"ISO-2022-JP"とするのはうなずけますね。



Sourceとして、RFC2237も示しているのであれば、JIS X 2012の文字「濵」に対して、エスケープシーケンスが、そうなっていない（JIS X 0208-1983のエスケープシーケンスになっている）のは、なぜかな、とは思います。（歴史的経緯や、相互可用性のもんだいがあるので、そうしているのでしょうかね。）



質問を論題とそれに対する主張ととらえ、本人が書いてもいない「主張」をあれこれ導き出し、反論する形で自分のいいたいことを書く、という芸風をお持ちであることはわかりました。

いろいろとお調べいただき、ありがとうございました。勉強になりました。ではでは。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

返信ありがとうございます。




WADAさんへのお返事にも書きましたが、ISO-2022-JP-1は、IANA Character Setの一覧に載っておらず、ISO-2022-JPのSourceとして、RFC1468とRFC2237が挙げられているので、MIME Type名について、"ISO-2022-JP"とThunderbirdはしていると、今は考えています。

おっしゃられるとおり「手抜き計算」されているかどうかは、自分ではちょっとわかりませんでした。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

「ESC $ ( D …」(JIS X 0212)ではなく「ESC $ B …」(JIS X 0208-1983)とエンコードする理由は、RFC1468/RFC2237のどこに書いてあるのでしょうか？
「実はISO-2022-JP-1エンコードなんだけど、過去との互換性を考慮してISO-2022-JPという名前にする（その方が読める環境が多くなるだろうから）」というのなら理解できますが。


ソースを少し読んでみると、「ESC $ B …」(JIS X 0208-1983)とエンコードするのは意図的のようですが、根拠・理由はわかりませんでした。
ISO,JIS,IANAよりもMSを選んだということでしょうか。

thunderbird-31.4.0.source/comm-esr31/mozilla/intl/uconv/ucvja/nsUnicodeToISO2022JP.cpp

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

エスケープシーケンスも拡張していたんですね。
でも、そうしないと、完全無比な正確な情報交換ができないから、納得。
こちらは、規格に反している・反していない、といった話ではなく、JISの規格の ISO/IEC 2022-JP-1 にどこまで対応するか・しているか、JISの規格の ISO/IEC 2022-JP-1を受け取り側にどこまで強制するか、ということになってきますね。

IANAの定義は、正式にはMIBenumで指定される規定によって定まるはずで、Source=RFC2237がポイントしている ISO/IEC 2022-JP-1のどこまでを強制しているかは不明なので、正確なことはいえませんが、
基本的には、JIS X 0212の文字は、ISO/IEC 2022-JPにおける、JIS X 0208-1983のエスケープシーケンスで指定される領域の中の未定義部分だから、
ISO/IEC 2022-JPの規定の範囲に留め、というか、ISO/IEC 2022-JP-1の規定の範囲まで全面的に拡げてしまうことはせず、
ISO/IEC 2022-JPの規定の範囲で言うと「外字」、として扱う形にしている・なっているのでしょう。

ISO/IEC 2022-JPにおける、JIS X 0208-1983のエスケープシーケンスで指定される領域の中の未使用部分については、独自の拡張が可能であり、
実際にJIS X 0212に使われる区点を使っているものがあったとして、それを、以下のように呼ぶことにしましょう。
　拡張2022-JP(DOCOMO) : ISO/IEC 2022-JPのルールで、外字がDOCOMOの絵文字
　拡張2022-JP(AU) : ISO/IEC 2022-JPのルールで、外字がAUの絵文字
　拡張2022-JP(SB) : ISO/IEC 2022-JPのルールで、外字がSBの絵文字
で、この領域に対して、独自拡張として、JIS X 0212の文字を外字として割り当てても構わないから、
　拡張2022-JP(JIS X 0212) : ISO/IEC 2022-JPのルールで、外字がJIS X 0212の文字
こうしておけば、同じ拡張2022-JP(XXX)を使う人の間では、文字情報は正確に交換できます。
Thunderbirdも多くのメーラーも、拡張2022-JP(JIS X 0212)派である、と考えればいい。
送る側も受ける側も、文字コードの変換表にJIS X 0212の文字を追加するだけで済む。

ISO/IEC 2022-JP-1に全面対応して、送る時に、正確な文字情報交換なんだからと、JIS X 0212-1990のエスケープシーケンスで送った時のことを考えてみましょう。
データの中にJIS X 0212-1990のエスケープシーケンスがあるから、受け取り側がそれをきちんと認識して、きちんと処理しない限り、ISO-2022系/ISO-2022-JPのエスケープシーケンスの性格上、改行でリセットされるはず、とはいえ、それ以降は全面的に文字化け。
全ての受け側がISO/IEC 2022-JP-1に全面的に対応している、ということは考えられない時点で、JIS X 0212-1990のエスケープシーケンスで送る、というのは、一種の「愚挙」と言えますよね。

受け側としてのThunderbirdがどうしているかは知りません。
送り側としてのThunderbirdは、通りすがりさんがソースを調べてくださったので、拡張2022-JP(JIS X 0212) 派であるのは確かですが。

JISの規格で、正確な文字情報交換が確実にできるようにするためには、
ISO/IEC 2022-JP-1のコード表で、ISO/IEC 2022-JP-1に定義されている文字を、ISO/IEC 2022-JP-1のエスケープシーケンスを使って、ISO/IEC 2022-JP-1であるときちんと宣言して送った時に、
受け手側で文字化けが発生したら、それは受け手側が全面的に悪い、と主張できて、全世界の人が、受け手側が全面的に悪い、と言ってくれるようにする必要があります。
基準とか規格って、そうでなきゃ困ります。
ただ、JIS X 0212に限っては、
送り側も受け側も、コードの変更は一切なしにして変換表に文字を追加するだけにして、「拡張2022-JP(JIS X 0212)」にしても、
非「拡張2022-JP(JIS X 0212)」派との文字情報交換はまず発生しなくて、
メーラーとしての実際の文字情報交換は、「拡張2022-JP(JIS X 0212)」派との間だけと考えていい、
というはずだから、規格を制定する側ではなく、規格を使って現実社会の中での円滑な情報・データ交換を推進する立場のIANAは、
ISO/IEC 2022-JP-1は却下して、JIS X 0212の文字だけを包含するようにしたのでしょう。
IANAの規定の中に、ISO-2022-JP-2はあっても、ISO-2022-JP-1は一切見られないのは、こういったことが理由なのだと思います。
ちしはらさんの言葉では「相互可用性」「Interoperability」、を、絶対に間違いが起こらないJIS X 0212の文字の正確な情報交換、よりも優先した、ということになりますね。

こういった「相互可用性」を崩せないから、ある規格に、受け側としては対応しても、送り側としてはまだ時期尚早だから無視、というのは、他にもあって、Thunderbirdでは、format-flowed,DelSp=yesの対応に見られます。
format=flowedは、80バイト弱のところで「改行+空白」を入れてしまうので、日本語やハングル文字だと余計な空白がたくさん入ってしまいます。
で、それをなくすために、挿入された「改行+空白」は常に除去する、というDelSp=yesを追加したのですが、
多くのメーラーがDelSp=yesに対応していない今の時点でDelSp=yesで送ると、英語圏で、単語間の空白が一杯無くなってしまう、ということになります。
それで、まだ、DelSp=yesで送り出していません。DelSp=Yesで送るコードはまだ作っていないので当然ですが(^^;
iso-2022-jpなどの日本語だと、format=flowedでは送り出さない、という風にして、日本語ではformat-flowedの問題を回避していたのですが、
format=flowedで送るのがデフォールトではオンで、最近ではUTF-8で送られることもあって、この余計な空白問題の報告も時々みかけるようになりました。
MSの最新以外のメーラーのバグがあって、そのメーラーはまだ数多く使われていて、それに対応する「MSのメーラーのバグとの相互可用性」とは違う、ピュアな「相互可用性」ですね。
そんなに新しいわけではないRFCに対応したら、MSの古いメーラーが対応していなくて、政府とか大企業とかで無視するわけにはいかず、あわててそれを殺すオプションを作った、という、「MSの古いメーラーとの相互可用性」とも違う、ピュアな「相互可用性」になります。

文字コードに絡む「文字化け」問題とは違う「余計な空白」問題ですが、規格と実装・現実の違い、送り側と受け側の違い、といった観点では似たようなものなので、ご参考までに。

PS.
「決めつけ」とおっしゃいますが、文字絡みで規格に相当詳しい方の「規格とは異なることに関する質問」って、ほとんどが「規格に違反している、けしからん」を内含していました。
「（歴史的経緯や、相互可用性のもんだいがあるので、そうしているのでしょうかね。）」、には、
「本来はJIS X 0212-1990のエスケープシーケンスで送られるべきである。にも関わらず、JIS X 0212-1990のエスケープシーケンスで送られていないのは、」という前置きがある、と考えるのが普通だと思います。
で、そのうちに、「規格に違反している、けしからん」と考えているのが見えてくる、と(^^)
気を悪くなさったかもしれませんが、「規格に違反している、けしからん」が表に出てくる前の「牽制球」とお考えください。
IANAの名前の規定って、単なる、みんなで共通して使う名前の一覧、というような感じで捉えていたのですが、
今回のISO-2022-JP-1問題や、WikiPediaに書いてあったIANAによるISO-2022-JP-3の却下の話を知って、
初めてIANAの規定の中身にまで目を通してみたら、どの規格を使うか、ということに関する一種の宣言につけた名前、と言うような感じになっていて、ちょっと驚きました。
charsetに関することだから、拡張子とMime-Type、といったものとは異なっていて当然ですが。
そして、やっぱり、規格・規定・基準、とかって、よくできていてまとも...、RFCとは大違い...、と、改めて感じました(^^)

ＭＳはJIS X 0212やISO/IEC 2022-JP-1に対してどうしたんだろうか、と、JIS X 0212でググってみたら、
JIS X 0212の失敗の反省の上に立ってJIS X 0213が作られた、とかいう記述がヒットしてきた...
で、もう少し検索してみて、http://ja.wikipedia.org/wiki/補助漢字 にたどりついた。

Unicodeの制定の時には、JJIS X 0208 とJIS X 0212 をベースにしていて、Unicodeには最初から入っているらしいし
制定では、国文学研究資料館の書誌データベース構築における研究成果に基づいた文字選定を行っていて、学問研究向きの文字集合となっている、と書いてあって、結構いろいろな文字を含めてくれていそう。
でも、JIS X 0212については、以下のように書いてあった。
> しかしShift_JISでは符号化方式の制約により利用できず、
> Shift_JISでも利用できる設計の拡張文字集合として2000年にJIS X 0213が制定されることになる。
ここでいうShift_JISは、MSのCP932と同義語に決まっている。
文字集合は定義されても、MSのCP932に入らなきゃ、誰も使ってくれないみたいなもの。
で、Shift_JISでも利用できる設計の拡張文字集合としてJIS X 0213を制定し、
JIS X 0213を第3水準および第4水準の文字として定めたらしい。
2000年にJIS X 0213(:2000)が制定されて、2004年にはJIS X 0213:2004が制定されたようだ。
で、以下のように書かれている。
> その後の公的規格などにおいてもJIS X 0212ではなくJIS X 0213を使う事を推奨するものが増えている。
> 2004年にはJIS X 0213:2004が制定されJIS X 0212に含まれる一部のグリフも変更されたが、
> JIS X 0212は過去の規格ということで、JIS X 0213に含まれていない文字は変更されなかった。

ISO-2022-JP-1は、IANAが拒否、ではなくて、自然消滅、ってな感じです。
で、ISO-2022-JP-2は、多言語対応だから日本語部分は関係なく、すんなりIANAが受理。
その後、JIS X 0213用だと思われるISO-2022-JP-3は、チョンボがあってか、IANAに却下されたようだ(^^;

通りすがりさんが提示してくれたソースによると、 JIS X 0208以降については、「cp932 ext」として定義している文字を、ISO-2022-JPの独自拡張部分としているようですね。
　拡張2022-JP(CP932) : ISO-2022-JPのルールを使い、外字はMSのCP932にある文字
これなら、MSのメーラーとの相互の文字情報交換が、全く問題なくできるはずです。

文字集合としては全部Unicodeに入っているだろうし、JIS X 0212/JIS X 0213:2000/JIS X 0213:2004 ⇔ Unicodeの相互変換も可能だろうから、
一部の、グリフが異なるものとか、コードポイントの入れ替えを又やってしまったものとかを除き、文字データの処理や表示上は何ら問題なし。
Unicodeで送られてきた、JIS X 0212、JIS X 0213:2000、JIS X 0213:2004、の中の文字も、
拡張2022-JP(CP932)の中に入っていれば、ISO-2022-JPで、JIS X 0208-1983のエスケープシーケンスで送っても問題は無いはずだし、
受け取り側も、ほとんどが拡張2022-JP(CP932) 派であろうから、相互の文字情報交換も、なんら問題なし。
ＭＳも、JIS X 0212の全部をShift_JISに取り込むのは不可能だから、JIS X 0212をサポートと言っていないだけで、サブセットは追加しているだろうし、
JIS X 0212とJIS X 0213は、かなりが同じ文字であろうし、JIS X 0213の文字のサブセットを追加すれば、JIS X 0212の文字のサブセットも追加されるわけで、
JIS X 0213は、第三水準・第四水準と規定されているようだから、MSが一部をCP932に取り込んでも不思議はない。

文字集合(CCS)と、符号化方法(CES)、という言い方は、Shift_JIS時代には良く聞いたのですが、
Unicodeになって、文字集合(CCS)や符号化方法(CES)の中の要素を指すときはU+ABCDの文字とやるようになってからは、
「文字集合」は、個々の部分集合については気にかけずにUnicodeという文字集合、としておけば、何も考えなくて済むし、
「符号化方法」は「Uniicode」に決まってるんだから、気にする必要は更々ないから、
あまり「符号化方法」がどうのこうのは、気にしなくなってしまっていました(^^;
せいぜい、UTF-8にした時のバイナリー表現は何か？、ってな時くらいしか、「符号化」という感じはしない。
ある文字がU+XXYYの文字とわかれば、ある文字集合や符号化方法⇔U+XXYYの双方向変換が効くから、
どんな文字集合(CCS)でもどんな符号化方法(CES)でも、何も気にする必要なし。
ISO-8859-5とかWindows-1251とかKOI8-RとかKOI8-Uといっても、コード表を見てUnicodeの番号を知れば、あとはコード表を見て、ISO-8859-5/Windows-1251/KOI8-R/KOI8-U ⇔-UTF-16 ⇔ UTF-8 の変換をするだけだから、怖いものなし。
どれであっても、Unicodeで考えておいて、送る時に好みの符号化方法(CES)でメールを送ればいいだけ。

そんなこともあって、
JIS X 0212の文字だからISO-2022-JP-1で送られてしかるべき、というスタートで、
JIS X 0212という文字集合は生きていて世の中で使われているものだと思い込んでしまった。
その上、JIS X 0213が、JIS X 0212の置き換えみたいなものだなんて、思いもよらなかった。
JIS X 0212が第三水準みたいなもので、JIS X 0213が第四水準みたいなもの、といった感じで、拡張されているものだとばかり思っていました。
だから、ISO-2022-JP-1が無視されたのに、上位のISO-2022-JP-2を受理され、でもその上位のISO-2022-JP-3は却下されるなんて、IANAって何考えているんだろう、と不思議でした(^^)
『「濵」の字は、それに含まれず、JIS X 0212に含まれるので、』で、「JIS X 0212にだけ含まれる」と思ってしまったのが敗因。
「JIS X 0208に含まれなくて、JIS X 0212に含まれる」⇒「JIS X 0208とJIS X 0212以外のJIS X xxxには含まれない」、は、必ずしも真ではない。
MS CP932だとどのコードポイントで、JIS X 213だとどのコードポイントか、を、ちゃんと調べるべきでした、
JIS X 0212とJIS X 213は全く別の文字集合と思い込んでいるから、JIS X 213だとどのコードポイントか、には絶対に行けなかったでしょうけど。

今更自然消滅or絶滅寸前のものについてあれこれ調べた結果自体は無意味だったけれど、いい勉強になりました。

でも、漢字の世界は、Unicodeよりも遥かに広い範囲を扱わなくてはいけなくて、大変そう。
かなり前の話のはずのISO-2022-JP-1で、エスケープシーケンスが既に4バイトになっていた、なんて、思いもよりませんでした(^^;
エスケープシーケンスの文字を大量に消費したのは、非漢字のコード系でしょうけどね。

それと、自然消滅or絶滅寸前のものとはいえ、IANAの表も誤解を招きますよね。
Source=RFC2237と書いてあれば、誰だって、RFC2237をきちんとサポート、だと思います。
符号化方法(CES)としてのISO-2022-JP-1はサポートしないのならば、RFC2237は、IANAのISO-2022-JPのSourceからは除去すべきであり、必要ならば、サポートするあるいはサポートするべき文字集合(CCS)のJIS X 212なりJIS X 213なりに言及すべきだと思いました。
まぁ、これも、一種の、文字集合(CCS)と符号化方法(CES)の混同なんでしょうけど。

「JIS X 0208に含まれなくて、JIS X 0212に含まれる」⇒「JIS X 0208とJIS X 0212以外のJIS X xxxには含まれない」、は、必ずしも真ではないのに、
質問者の方の『「濵」の字は、それに含まれず、JIS X 0212に含まれるので、』で、「JIS X 0212にだけ含まれる」と思ってしまったことの反省の上に立って、ちょっとまとめておきます。
文字に関する規格などに相当詳しいであろう方の質問、と思っているから、JIS X 0212以外にも含まれる可能性がある、なんてことが、頭に浮かぶはずもない。

以下のような違いがありました。

• JIS X 0212とJIS X 0213との間に互換性はない。
• JIS X 0212は、JIS X 0208にない文字を集めた文字集合。
• JIS X 0213は、JIS X 0208を包含し、更に第三・第四水準漢字などを加えた上位集合

JIS X 0212の失敗の反省の上にたって、JIS X 0213は「上位集合」にしたのかな？

[参考資料]
情報交換用符号化文字集合
JIS X 0212 http://ja.wikipedia.org/wiki/補助漢字
JIS X 0213 http://ja.wikipedia.org/wiki/JIS_X_0213
情報交換用符号化文字集合に対応する情報交換用符号化方式の名称
http://www.wdic.org/w/WDIC/ISO-2022-JP
（ISO-2022-JP-1, ISO-2022-JP-2, ISO-2022-JP-3, ISO-2022-JP-2004 も見てください）
情報交換用符号化方式の、登録された規格
http://ja.wikipedia.org/wiki/ISO/IEC_2022
（ISO-2022-JPも見てください）
IANAに登録された、メールのcharsetに書ける、情報交換用符号化方式の呼称
http://www.iana.org/assignments/character-sets/character-sets.xhtml
[/参考資料]

質問に対するお答え。


メールのContent-Type:のcharsetやエンコーディングのcharset指定に使えるものは、IANAに登録されたものだけです。
ISO-2022-JP系は、ISO-2022-JPとISO-2022-JP-2のみがIANAに登録されています。
登録されていない場合は、X-ISO-2022-JP-2004のようにして、実験用だと明記し、送信側と受信側の合意の下に使うことになります。
「情報交換用符号化文字集合に対応する情報交換用符号化方式の名称」が定められていたからと言って、メーラーがそれをX-xxx-yyy-zzとして送る義務はありません。
従って「規格上問題がある・問題がない」という話ではありえなくて、Thunderbirdは、規格どおりにきちん動いている、ということになります。

それに、「濵」の字は、JIS X 0212にも含まれていますし、JIS X 0213にも入っていると思います。
もしかすると、MSのCP932に入っていて、MSのISO-2022-JPの独自拡張、として扱われている可能性もあります。
また、前述の通り、charset=ISO-2022-JP-1とすることは、IANAが許可しておりません。
ですから、「"ISO-2022-JP-1"とならないといけないのではないか」とのお考えは、間違っています。
「"ISO-2022-JP-1"としてはいけない」、なのです。


RFC2237がISO-2022-JP-1をポイントしていて、そのRFCをSource=RFC2237としてIANAの表に載っている場合、
送る側全員が厳格にそのRFCに書いてある内容を常に実行せよ、というものではなくて、
RFC2237のcharset=ISO-2022-JP-1部分はIANA拒否したけれど、
それを除いて、RFC2237に従って送ることを許しているから、
受け取り側の人は、RFC2237に従って送られたメールを受け取った時に、拒絶したりしないで正しく受け取ってね、という意味の方が強いと思います。
送る側が、ある情報交換用符号化方式で符号化したデータを送った、と宣言したのなら、その情報交換用符号化方式で正しく符号化したデータを送るのは当然の義務ですし、
送る側に対しては、メールを送る時に使うことができる情報交換用符号化方式のリスト、載っていれば使うことが禁止されているわけではないとわかるリスト、というものになると思います。
実験としてX-xx-yy-zzとして使う為の参照用、というような意味合いもあるかもしれません。

Thunderbirdが以下のことを実行しないのは、
　Source=RFC2237⇒ISO-2022-JP-1
　⇒JIS X 0212の文字は、JIS X 0212-1990のエスケープシーケンスで送らねばならない
今そんなことをしたら受け取り側で文字化けの嵐になるからしない、ということと、
その文字はJIS X 0212以外にも含まれているから「RFC2237⇒ISO-2022-JP-1」の制限・制約を受けない、ということの、
どちらかあるいは両方なのだと思います。

今回、メールのメッセージュヘッダーには現われてはいけないISO-2022-JP-1という名前について、
文字集合の定義としては優れていたとしても、MSのCP932に入りきらなくて、使われることのなかった、
かわいそうな、JIS X 212という文字集合に付随する情報交換用符号化方式について、
その後のリベンジのJIS X 213について、IANAの名前の表について、などを、調べてみて思ったことを書いておきます。

RFC2237は、
(a)JIS X 0212の文字をメールで送ることの許可、
(b) JIS X 0212の文字はJIS X 0212-1990のエスケープシーケンスで送らねばならない、
(c) JIS X 0212の文字があったらISO-2022-JP-1であると宣言しろ、
(d) JIS X 0212の文字がないのにISO-2022-JP-1であると宣言してはならない、
だけだから、
ISO-2022-JP-1という名前が却下された以上、(c)/(d)は自然消滅。
(b)は、メールのメッセージヘッダーの話とは無関係。
RFC2237があろうがなかろうが、JIS X 0212-1990のエスケープシーケンスはきちんと定義されているわけだし。
メッセージヘッダーの規定なのに、符号化の中身までこのRFCで規定すること自体がいけない。
それに、RFC2237は、JIS X 0212の文字はJIS X 0212-1990のエスケープシーケンスで送らねばならない、というような書き方をしているから、(c)はもう消滅したことだし、(b)にも消えてもらう。
となると、残るは、JIS X 0212の文字をメールで送っても構わない、ということくらい。
IANAのSource=からは除去しておいた方が、誤解を生みにくいと思います。
ISO/IEC 2022の規則と規定であることと、ISO/IEC 2022で定義されたどのエスケープシーケンスであるか、だけで、符号化された文字集合 ⇔ 文字集合 の一意的な相互変換ができるはずだから、
ISO/IEC 2022の中のキャラクターセットにつけられた名前の「ISO-2022-JP」であることを受け取り側に伝えるだけですむはず。
ISO-8859系ではISO-8859-Xの[X]まで伝えないと変換表を特定できない、ということとは、事情が異なります。

そもそも、RFC2237は、RFC822/RFC2822/RFC5322に従ったメッセージヘッダーのcharset指定のためのものであり、
ISO-2022-JP-1という名前が認められなかった以上、存在意義が無いものだから、RFC2237を引っ込めたっていいはず。
JIS X 0212という文字集合、ISO/IEC 2022で規定されているJIS X 0212-1990のエスケープシーケンス、それに付随するISO-2022-JP-1という符号化方式の名前とそれが意味する規則など、は、
RFC2237があろうがなかろうが、厳として存在していて、認知されているわけだし。

RFC2237を見て、RFCの欠点を再認識したようにも思います。
「標準」であって、規格・規則・基準ではなく、マナーみたいなものだから、厳密性などさらさら無いのは当然ですが、
一度できると、その曖昧さの故に、特に、マナー違反があった時にどうすべきか、などについては全然言及していないので、
MSの横紙破りがあった時とか、他のメーラーのバグのせいで、あるいはWebメールアプリのカジュアルプログラマーのRFCなんてほとんど気にかけない、のせいで、文字が化けたり、添付ファイルが表示されないと、
Thundeibirdユーザーが言ってくるのは、「Tunderbirdのバグでメールがまともに見られない。俺がちゃんと見られるようにしろ」、になるんですよね(^^;
今回のRFC2237がらみでも、
もしMSのメーラーがJIS X 0212-1990のエスケープシーケンスで送って来て、Thunderbirdで表示できないと、Thunderbirdのバグ、
もしThunderbirdがJIS X 0212-1990のエスケープシーケンスで送って、MSのメーラーで表示できないと、Thunderbirdのバグ、
と、必ず「Thunderbirdのバグ」になります(^^)

[追記]
MSが第3水準をサポートをした、というようなことを見たような気がしたので、
「ms cp932 "jis x 0212" "jis x 0213"」でググって見て、
http://www.asahi-net.or.jp/~ax2s-kmtn/character/japan.html#jis_point01
にたどりついた。
以下のように書いてあった。
やっぱり、JIS X 213はMS CP932に入れるためだったようです。

JIS X 213をJIS X 0208の上位集合とすれば、JIS X 208に関するこれまでの規定は、JIS X 208をJIS X 0213と読み替えることでほぼそのままいけるし、
エスケープシーケンスは、ISO-2022-JP/RFC 1468に対応する、JIS X 0208:1983までに留めて、
JIS X 0212:1990エスケープシーケンスは、メールの世界では、無視あるいは消滅・絶滅させても構わないし、、
JIS X 0213:2004 第1面、JIS X 0213:2004 第2面、のエスケープシーケンスは、受け取り側の対応状況を考えて、メールの世界であることだし、とりあえず(ずっとかもしれないですが)封印し、
JIS X 213の文字部分は、MSのISO-2022-JPの独自拡張部分として、
　拡張2022-JP(CP932) : ISO-2022-JPのルールを使い(JIS X 0208:1983のエスケープシーケンスまで)、
　　　　　　　　　　　　外字はMSのCP932にある文字(JIX X 0213とMSの拡張)
とすれば、MSのメーラーとの相互の文字情報交換が、全く問題なくできるはずです。
Thunderbirdも、JIS X 0213の文字はUnicodeに入っているから、「cp932 ext」と区分する文字をMSのCP932のコードと同じにして、JIS X 0208:1983のエスケープシーケンスで「ISO-2022-JPの独自拡張の外字」としてメールデータを送受信するだけ。
通常のメーラーは、これを行っているであろうから、
携帯に大量のJIS X 0213の文字をISO-2022-JPで送りつけるとか、
JIS X 0212の文字があるからと、JIS X 0212のエスケープシーケンスで送り出すとか、
JIS X 0213の文字であると知っているからと、JIS X 0213のエスケープシーケンスで送り出すとか、
そういったことをしない限りは、
ISO-2022-JPでのメールデータの交換において、問題はない。
[/追記]

これでスッキリしました。
IANAの表でRFC2237をポイントしていて、それがJIS X 0212:1990エスケープシーケンスをポイントしていれば、何で使わないの？、と思いますよね。
多分、JIS X 0212:1990エスケープシーケンスに対応しているメーラーが少ないだろうから、と、想像はできても、JIS第１水準・第2水準からの拡張なんだし、何でJIS X 208以降の拡張は受け入れられていないのだろうか、と不思議でした。
やっぱり、IANAのISO-2022-JPの項目から、Source=RFC2237は除去すべきです。
これさえなければ、

には、どうあがいてもなり得ないから、「ISO-2022-JP-1はIANAに登録されていない」だけで、すんなり終わっていた。
諸悪の根源は、未だにRFC2237を撤回しないこと、と言えそうです。

[補足]
「ISO/IEC 2022という規格」にもう一度目を通して、「ISO/IEC 2022-JPという規格」は無いことに気づきました。
情報交換用符号化方式の、きちんと定義された規格
http://ja.wikipedia.org/wiki/ISO/IEC_2022
この中では、『「文字集合 ⇔ エスケープシーケンス(文字集合の選択の指示)」の対応』、を複数集めた集合に、「キャラクターセット」というグループの名前が付けられていました。
で、符号化データの中のエスケープシーケンスによって文字集合がきまるんだから、『「キャラクターセット」というグループの名前』は無くてもいいのではないか、と思っていたのですが、そうではないこともわかりました。
「ISO-2022-JP」という、「ISO-2022という規格の中のキャラクターセット名」を与えられたグループについては、
　JIS X 0208が指示(かつ呼び出し)されている状態では、SPACE (空白) や制御文字を使ってはならない。
　行末では指示(かつ呼び出し)をASCIIにもどさなければならない。
といった、ローカルルールが定められていて、
これは、文字集合やエスケープシーケンスなどとは独立した「規則」なので、別途指定が要ることになります。
で、メールのメッセージヘッダーの中のcharsetで指定しても良い「ISO-2022という規格の中のキャラクターセット名」の一覧が、IANAの表。

となると、ISO-2022-JP-1がIANAの一覧表に掲載することが許可されなかったということは、
ISO-2022-JP-1という「ISO-2022という規格の中のキャラクターセット名」が指し示す「エスケープシーケンス(文字集合の選択の指示)」のメールでの使用も、
IANAによって許可されてはいない、と考えるべきです。
そうであるとすると、ISO-2022-JP-1という「ISO-2022という規格の中のキャラクターセット名」や、JIS X 0212-1990エスケープシーケンスの、メールでの使用がIANAによって認めらていないことになります。
そして、RFC2237は、メーラーに対する規定ではなく、IANAに対する登録依頼のようなもの。
規格自体は「ISO-2022という規格」にきちんと定められているのだから、RFC2237がどうこう言う話ではない。
ならば、JIS X 0212という優れた文字集合に対する思い入れがあるんでしょうけど、やっぱり、RFC2237はさっさと撤回し、IANAのSource=から自動的に消されるようにすべき、ということになります。
RFC2237に振り回されて、余計な誤解をさせられたり疑問を持たされたり過去のいろいろなことを調べさせられたりする、かわいそうな犠牲者をこれ以上ださないように。
[/補足]