電子メールの文字コードとエンコードについて教えてください。

質問

電子メールの文字コードとエンコードについて教えてください。
半角カタカナは、ISO-2022-JPに含まれないので使用できないというのはわかるのですが、機種依存文字とISO-2022-JPとの関係がよくわかりません。

機種依存文字は、ISO-2022-JPが定義しているコードのなかに存在するということでしょうか？半角カタカナは機種依存文字ではないということなので、困惑しています。
また、メール本文は、ISO-2022-JPにエンコードして送信するということですが、ISO-2022-JPは文字コードで、BASE64とは性質の異なるものなのでしょうか？
「ISO-2022-JP」と「機種依存文字」、「BASE64」についてどなたかわかりやすくご教授お願いいたします。

回答No.4

noname#73585

私からの 返答を きちんと 読んで頂けているのでしょうか？
昨晩からの繰り返しになりますが、

返答１：
＞ 電子メールの本文では、BASE64などでエンコードしない限り、
＞ ISO-2022-JPに定義されていない文字は使用できないという
＞ ことでいいのだと思うのですが

大きな 間違い！！

　・件名： base64 でエンコードします
　・メール本文： ISO-2022-JPコードのまま、エンコードしないで、
　　　そのまま送ります。

但し、本文の 添付ファイルとして、バイナリーデータを添える場合は、
BASE64などでエンコードします。

まず始めに お願いしたいことは、daimonkikoさん に一点だけ、
“原理原則”だけは 確実に理解して頂きたいということ。

　それは、インターネットでのデータ伝送が “７ビットコード体系”
　しか保証されていないことです。

この原理原則だけを理解すれば、全てが解決します。

　・“ISO-2022-JP” は、７ビット体系の文字コードなので
　　エンコードを必要とせずに、そのまま送れます。

　・半角カタカナ は、８ビットのコード体系なので送れません。

　・機種依存文字と言えども、ISO-2022-JPをベースとしているので
　　７ビットのコード文字は、送れます。

と書いても、　恐らく ご理解して頂けないものと予想するので、
今回に限っては もう一段 詳しく書きます。

メールの送信時のコード表現は、その組み合わせにより 膨大な数に
なりますが、
ここでは、具体的に 代表的なコンテンツヘッダーを例示しながら
説明します。

パターン１：
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit　（ ← 7bit の時は、省略可能 ）

メール本文を “ISO-2022-JP” に変換し、何のエンコードも
しない方法

国際表標準に準じた 最もオーソドックスな方法で、現在 流通して
いる 殆ど 全てのメールソフトが、この方法を採用しています。

パターン２：
Content-Type: text/plain; charset=euc-jp
Content-Transfer-Encoding: base64

日本語EUC は、Solaris などの基幹サーバ系、ＵＮＩＸマシンで
採用しています。　但し、メール通信においては 日本語EUC のまま、
バイナリーモード（ ＝ base64 ） で送ってくる ソフトは
殆どありません。

私自身、毎日 業務報告として Solaris から発信されたメールを
受信しますが、そこでも
Solaris と言えども 上記 パターン１に準じて、
ISO-2022-JP に変換してから エンコード無しで、送ってきます。

パターン３：
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

漢字コードを ワザワザ “ISO-2022-JP” に変換した上で、
更に バイナリーモード （ ＝ base64 ） で送る方法。

理屈的としては、間違いではありませんが、この方法は 非常に 【 愚か 】
です。
このようなコード変換を行う メールソフトは存在しません。

（ もしかすると、学生などが インターネットの学習の一環として、
こういうケースを作るかもしれませんが、 . . . . ）

愚かだという理由：
　“ISO-2022-JP” は、既に ７ビット系のコードです。
　それを わざわざ バイナリモードで送る メリットは 完全にゼロで、
　更には デメリット のみが発生します。

　・送信側で、base64へのエンコード処理が無駄

　・base64 への変換に伴って、無条件に データサイズが １.３倍 に
　　なります。　伝送路での リソースの浪費が無駄。

　・受信側で base64からの デコード処理が無駄

どうも daimonkikoさん の質問を読んでいると、この 愚かな方法が
気になって仕方が無いみたいですが、

繰り返します。
メール本文において、ISO-2022-JPコードに変換してから、
更に base64 でのエンコードをすることは、
ありません！！
＾＾＾＾＾＾＾＾

返答２：
機種依存文字ですが、

＞ 理解に苦慮しているのは、「半角カタカナ」は、ISO-2022-JPで
＞ 使用が認められていないので使えない。
＞ しかし、機種依存文字は、使用することはできるという点です。

これも間違っています。

機種依存文字は、使えません。
＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾
たまたま、daimonkikoさん の動作環境では 使えているように、
見えているだけです。

具体例を示します。
私の知人に 熱狂的な Macファンがいますが、Windows の
丸付きの数字　丸１ ＝ (1) は、Mac では“（日）”と
表示されます。
※注意：
　この Ｑ＆Ａ では、この記事を投稿する時に、
　機種依存文字として 丸１ を入力すると
　自動的に “（１）” と変換されるようです。

したがって、このようなことがあるので、機種依存文字は
使ってはいけません。

返答３：
＞ “勝手に拡張された”ISO-2022-JPが現在のメーラーで
＞ 使われているというのが原因なのでしょうか？
＞ それとも私が、全く見当違いをしているのでしょうか？

インターネットの世界では、特に “メールソフト” の開発には
困難を極めます。

その理由は、関連する 各種 “規格” や “規定” を遵守し、
アプリケーションを作り、こちら側が “正しい” 論理であっても、
通信相手とメールが交換出来なければ、
＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾
お客様には 受け入れてもらえないからです。

やはり、そこには 大数に従わざるを得ない 現実があり、どうしても
試行錯誤の連続となります。

→ 実際にやってみないと分からないことも多く、苦労が絶えません。
　 また、不具合の原因が、相手側の “規約違反” であったとしても、
　 自分の気持ちを殺しながら、相手に合わせる 柔軟な姿勢 と
　 勇気が求められます。

という訳で、もし自分の勉強の為に メールのプロトコルを実装
されるのであれば、大いに それを “賞賛” しますが、

その一方で、業務として それに関わるアプリケーションを開発されて
おられるのであれば、やめた方がいいです。

市販の メールライブラリー の購入や マイクロソフト社 からの
『 .NET Framework クラス ライブラリ 』 などのパッケージの
導入を強くお勧めします。

最後になりますが、前回、今回 と二度に渡って、回答をしてきました。
何故か、 私の書いた 回答が 受け入れてもらえずに 非常に歯痒く
思っています。

私自身も回答を書くにあたっては、それなりに 時間を割いて
対応している訳ですが、虚しさを感じました。

本件、私から回答をするのは これを最後とします。

次回からは、規格書の原本である 『 生 』の “ドキュメント” を
読んで頂くことを強くお勧めします。

お礼

oketaroさん、ありがとうございました。ご迷惑をおかけして申し訳ありません。oketaroさんのご回答を熟読させていただきました。どうやら私は、少し思い違いをしていたようです。
メールの「文章作成時」において、実際にメーラーに日本語の文章として入力された「丸1」などの機種依存文字や半角カタカナを、実際に入力してメーラーの送信ボタンをクリックすると「送信することができる」ということから、使用できないはずのものがなぜ使えるのだろうと考えていてわけがわからなくなってました。
ただ、それはそうみえているだけで、実際の通信においてはそうではないということですね。

また、「エンコード」という言葉を誤解して、文字コードであるISO-2022-JPをBASE64などと混同していました。

oketaroさんのおっしゃるとおり、“原理原則”について自分なりに再考し、“機種依存文字と言えども、ISO-2022-JPをベースとしているので７ビットのコード文字は送れる”“通信相手とメールが交換出来なければ、お客様には受け入れてもらえない”というお言葉から理解できたつもりです。

私も、もう少し勉強し、規格書の原本である 『 生 』の “ドキュメント” にぜひ取り組んでみたいと思います。
夜分に貴重なお時間を割いていただき、大変ありがとうございました。感謝いたします。

回答No.3

Hayashi_Trek

◎機種依存文字について
機種依存文字として有名な「まるいち」「まるに」等は、
元々は国民機と言われたNECのPC-9801で使われていた拡張外字でした。
マイクロソフトがWindowsを日本に広める際に、ユーザー取りこみのため
これらの拡張外字を含んだフォント「ＭＳ 明朝」「ＭＳ ゴシック」を作ったのです。
以後、Windows用のフォントは上記フォントに右倣えしている。
従って、Windows同士でのやり取りでは問題ないが、
Windows以外（MacやUnix）では表示できない（文字コードに対応する表示デザインが無い）場合があります。

ISO-2022-JPと半角カタカナに関しては下記を参照
http://www003.upp.so-net.ne.jp/hat/imail/sec02.html
http://www003.upp.so-net.ne.jp/hat/imail/sec06.html#katakana

補足

Hayashi_Trekさん、ご回答ありがとうございます。参照先のサイトは実は参照したことがあって、それでもよくわからなかったのです。
ISO-2022-JPで、機種依存文字である「まるいち」や「まるに」等が使用できるのは、Windowsのフォントがそれらの外字を含んでいるからで、実際に送信するときには、ISO-2022-JPにエンコードされる。したがって、Windows以外の環境では、文字化けがおこる可能性がある。だから、機種依存文字は使用しないほうが良いという解釈でよろしいのでしょうか？また、現在では、機種依存文字というのは、機種ではなくてフォントにも依存してるということでしょうか？
どうかご教授よろしくお願いいたします。

回答No.2

noname#73585

まず、質問の趣旨ですが、アカディミックに “文字コード体系” を深く
掘り下げて、調査、研究をしたい、ということですか？

それとも、単に メールをやっていて、もし相手に伝わらない 文字があると
支障を来たすから、その意味から疑問を持たれた、ということですか？

まず、【 規格 】 の件ですが、私も職業柄 直接 “ＩＳＯ” の規格を購入し、
色々と調査をします。
その意味からも、積極的に “生” の 【 規格書 】を直接読まれることを
強くお勧めします。

→ 正直言って、本件 このような Ｑ＆Ａ の掲示板を通して得られる
　 情報などと比べて、格段に 得られるものが多い。

なお、現在の規格では、【 ISO/IEC 2022:1994 】 です。
タイトルは、Information technology -- Character code structure
and extension techniques です。

ISOは、クレジットカードがあれば、誰にでも購入できますので、
是非買ってみてください。
（規格書は、その場でダウンロードできます。）

→ 余談ですが、ＩＳＯ規格は 結構 値段が高いのが、難点 . . .
　 特定の事象を調べるにしても、関連する 規格が多数あり、
　 最終的には あれも知りたい、これも知りたい . . .　となり、
　 日本円に換算して、２０万円、３０万円 . . . となることも
　 シバシバです。

→ もし、daimonkikoさんが 仮に学生の身分で、資力に乏しい場合は、
　 赤坂にある　財）日本規格協会　に足を運ばれるといいですよ。
　 全世界の あらゆる規格が タダで 閲覧できます。

あと、ISO/IEC 2022:1994 ですが、私自身 上記規格を 見ていない
ので、推測を交えての 答えですが、
恐らく この規格の中では、文字コードの 一個づつの規定は無いような
気がします。
→ “枠組み” だけ？　（ これまでの 経験から ）

そして、個別コードの実装は、JIS規格に 委ねられているような気がします。

と、大分 前置きが長くなってしまいました。 本題に戻ります。

返答１：BASE64 について
　メールのやり取りににおいて、メールの本文は “BASE64” で
　エンコードしません。　→ ＲＦＣ の規定から
　“BASE64” でエンコードするのは、メールの “サブジェクト”、
　 即ち “件名” の個所だけです。

　 ※ ＲＦＣ の規定 （ メールのプロトコル ） は、タダで見られるので
　　　是非読んでみてください。

返答２：ISO-2022-JP について
　機種依存文字は、ありません。

　原点に立ち戻って、そもそも “規格” とは何か？　と、考えてみて
　ください。
　規格を策定する背景には、世の中の皆さんに 広く通用する
　共通認識を決めることにあります。

　もし、規格の中で、皆さん 勝手に 機種依存文字 を作ってください . . .
　と言ったら、規格の 存在意義がなくなります。

　※そうは言っても、MIDI規格（＝これも現在は、JIS規格）などのように、
　　“NRPN” と言って 勝手に機種依存 を認めているものもあります。

返答３：機種依存文字 について
　さまざまな コンピュータメーカ、例えば マイクロソフト社を始めとして、
　その他の会社も含めて、

　うちの ＰＣ の文字コードは、“ISO-2022-JP” を使っています . .
　とは言っても、
　実は 自社の “機種依存文字” を追加して、“ISO-2022-JP” であると
　謳っています。
　但し、勝手に拡張されたものは、厳密には規格品とは言い難いものがあります。

返答４： 半角カタカナ文字 について
　インターネットは、米国が発祥地です。
　現在の通信網は、８ビットが主流ですが、かつて 英字しか使わない
　米国では ７ビットの通信網でした。

　ところが、半角カタカナ文字は ８ビットのコード体系です。
　それ故、７ビットを基本とする インターネット通信網 では、
　半角カタカナが 正しく送れないのです。

　但し、現在の 通信網は 事実上は ８ビットとなっており、
　半角カタカナを送っても 特に問題が起きない場合も多い。
　ちなみに、上記 “ISO-2022-JP” も ７ビットのコード体系です。

と、言うことで . . . . . . .
更に 深く知りたいことは、 Ｑ＆Ａ の掲示板ではなくて、直接
規格書 を読まれることを 強くお勧めします。

補足

oketaroさん、親切なご回答大変ありがとうございます。
私は、学生ではありませんが、ネットワークを少しかじった程度の仕事もしますので、インターネットについて基礎から勉強しようと思い立って独学で勉強しています。なので、初歩的な？疑問だと思うのです。

MIMEを勉強し、メールのテキスト形式やHTML形式、リッチテキスト形式などの書式について取り組んでいました。マナーとして、機種依存文字と半角カタカナは使用してはいけないというのは知っていましたが、その原因と詳しく知ろうとすると、「メール本文は、原則としてMIMEではなく、同じ7ビットのISO-2022-JPでエンコードする。ISO-2022-JP以外の文字を使用しない」とあってつまずきました。要領を得ない質問だと反省しています。

私も実は、Windowsの囲い文字やローマ数字のような「機種依存文字」はISO-2022-JPにはないのだろうと思ってはいました。しかし、理解に苦慮しているのは、「半角カタカナ」は、ISO-2022-JPで使用が認められていないので使えない。しかし、機種依存文字は、使用することはできるという点です。

電子メールの原則は、ISO-2022-JPに定義されていない文字は使用しないということでいいのだと思うのですが、そうなると、実際に使用することができる機種依存文字って何？となってしまうのです。

そこで、ISO-2022-JPとは、Shift_JISなどからエンコードする方式（BASE64のような）なのかな？と考えもしました。

oketaroさんのおっしゃるように、“勝手に拡張された”ISO-2022-JPが現在のメーラーで使われているというのが原因なのでしょうか？それとも私が、全く見当違いをしているのでしょうか？ご教授いただけると幸いです。

回答No.1

violet430

>機種依存文字は、ISO-2022-JPが定義しているコードのなかに存在するということでしょうか？

存在すると思います。実際に送信はできますから。

>メール本文は、ISO-2022-JPにエンコードして送信するということですが、ISO-2022-JPは文字コードで、BASE64とは性質の異なるものなのでしょうか？

BASE64はデータのバイナリ変換方式の一つです。文字のエンコードとは直接関係ないです。
http://e-words.jp/w/BASE64.html

補足

回答ありがとうございます。電子メールの本文では、BASE64などでエンコードしない限り、ISO-2022-JPに定義されていない文字は使用できないということでいいのだと思うのですが、そもそも、Windowsの機種依存文字である囲い文字やローマ数字は、ISO-2022-JPに定義されているということなのでしょうか？（実際に送信できるということなので）
一方、半角カタカナは使用できないので困惑しています。
Shift_JISなどで書かれた本文がメーラーによって、ISO-2022-JPにエンコードされているということでしょうか？となると、ISO-2022-JPとは一体どういう存在なのかわけがわからなくなってしまいました。