インターネット電子メールシステム

　インターネットはどうしてこんなに発展することができたのでしょうか？これはTCP/IPのシステム全体が良く出来ていたというのもあるでしょうが、もう一つはみんなが使いたくなるような便利機能をいくつも備えていたということだと思います。インターネットにグラフィカルなインターフェース（GUI=Graphical User Interface）が追加されてからは何といってもWebだと思いますが、それ以前のCUI（Character User Interface）時代は断然電子メールでした。電子メールはかつてはインターネットのキラーアプリと呼ばれていました。

• １　電子メールの歴史
• 2　インターネット電子メールの概要
• 3　電子メール送受信の手順
• 4　メールメッセージのフォーマット
• 5　MIME
• 6　メールの文字化け問題

１　電子メールの歴史

　電子メールはリモートのユーザが郵便のようにメッセージをやり取りする方法ですからとても便利なシステムです。そのため、電子メールのようなシステムはインターネットが登場する以前から利用されていました。

　初めのころ開発されたのはメインフレーム上のタイムシェアリングシステムで複数の利用者が相互に通信を行うシステムです。同じシステムを使うもの同士が相互に情報を伝達することが可能となりました。しかし、まだメールとは言えません。郵便とのアナロジということで言えば、まだ郵便局が関わっていないという感じです。郵便「制度」になっていません。例えて言えば、「置手紙」といったところでしょうか。

　メインフレームは非常に高価なシステムですので1企業で何台も導入することは大変です。そこで、１台のメインフレームを中心（センター）にすえて、遠隔（リモート）の端末から電話回線を介して中央コンピュータにログインするというシステムが開発されました。このシステムでは、中央コンピュータのディスクにファイルを共有し、そこに情報を書いたり、閲覧したりするシステムが導入されるようになりました。ここで少し郵便に近くなっています。まだ、郵便局は登場していない感じです。例えて言えば、社内郵便とか、学内郵便という感じです。

※インターネットが普及する以前は、パソコン通信が電子メールのような情報通信の手段としての役割を果たしていました。NIFTY-Serve（富士通）やPC-VAN（NEC）などの法人が経営する商業BBSと個人が経営する草の根BBSです。パソコン通信も中央にあるホストコンピュータ（大型の高性能コンピュータ）にパソコンを接続する形態をとっていました。パソコンをモデムにつなぎ、そのモデムをアナログ電話回線につないで中央のホストコンピュータとダイアルアップ接続をして通信をする形です。インターネットはパケット方式ですが、パソコン通信ではパケット交換というのは少数で、ほとんどは電話のような回線交換方式を採用していました。そのため、１回線につき１台のパソコンが占有し、他のユーザが利用するためには他の回線を追加する必要がありました。パソコン通信でも、加入者同士が文書のやり取りをするシステムが「電子メール」として提供されていましたが、パソコン通信では通信の範囲が1つのパソコン通信システム内に止まっていましたので、他のシステムとの間で電子メールを交換することなどはほとんどできませんでした。インターネットが一般に利用できるようになると、大手のパソコン通信システムとインターネット間で相互に通信できるようになりましたが、インターネットが普及期に入ると徐々に衰退し、2003年には全てのサービスが終了しています。

　しかし、中央コンピュータで何もかも処理するシステム（集中処理システム）の非効率性が叫ばれるようになります。中央コンピュータとしてのメインフレームがあまりにも高価だったこと、中央コンピュータに負荷が集中しすぎること、そして何よりも中央コンピュータがダウンするとシステム全体がダウンしてしまうという耐障害性の問題が原因です。そこで登場するのが分散処理システムです。集中処理システムではリモートの端末は所謂ダム端末（dumb端末、接続先の中央コンピュータが表示する文字列を受け取り、ただ表示する機能しか持たない端末、通称バカ端末）でしたが、分散処理で利用する端末は高機能な端末です。この時代の電子メールは利用者が異なるコンピュータ間で情報をやり取りするための「ネットワーク電子メール」に拡張されています。

　インターネットは当初ARPANET（アーパネット、Advanced Research Projects Agency Network）と呼ばれていましたが、このインターネットの黎明期の1969年にシステム間の電子メール転送の実験が行われたという記録があります。しかし、この仕組みはあまりにも複雑すぎると考えた研究者がいました。これがレイ・トムリンソンです。彼はもっと簡単な方法でメッセージのやり取りができないかと思案する中で、送信相手の場所を示す記号として@を使う手法を考案したようです（1971年）。

※レイ・トムリンソン：2012年にインターネットの殿堂入りを果たす。2016年3月7日逝去。

　ARPANETでの電子メールが便利だということになると、ARPANETに接続できない人たちの中にも電子メールシステムを要求する人々が増え、タイムシェアリングシステムを代替ネットワークで接続したネットワークがいくつも登場しました。この当時は電子メールのアドレスには情報伝達の経路を示す必要がありました。送信側のコンピュータから受信側のコンピュータまでの経路を示します。経路は送信元から到達可能なコンピュータのアドレスを書き、そのコンピュータから次に到達可能なコンピュータのアドレスをバング（感嘆符=!）で接続する形で、宛先までアドレスを継ぎ足していくという方法で示していました。

　この当時電子メールの相互運用を可能とするための標準として開発されていたのがX.400（OSI参照モデル対応のアプリケーションプロトコル）です。多くのコンピュータベンダがX.400の初期バージョンに基づいてネットワーク電子メールを開発を始めました。しかし、X.400はなかなか最終的な仕様が決まらず、待ちきれなくなったベンダは独自の便利機能を追加してしまいました。その結果、便利であるが、相互に通信できないシステムが出来上がってしまいました。

　特定ベンダに依存しないオープンな標準が欲しいと多くの人が思い始めたときにタイムリーに出てきたのがIETF（The Internet Engineering Task Force)のSMTP（Simple Mail Transfer Protocol）です（1980年代）。1990年代に入り、インターネットが爆発的に普及し始めるとSMTPは直ぐに電子メールシステムのデファクトスタンダードとなっていきました。

2　インターネット電子メールの概要

　インターネットでは、UUCPやSMTPなどのプロトコルを使って、メールを相手サーバに届けるという方式を使います。メールは数々のメールサーバをリレーのように経由して宛先のメールサーバに伝えられます。メールサーバ間でメールを転送する際に利用されるプロトコルがSMTPです。UUCPはUNIXマシン同士でメールを転送する仕組みで初期のインターネット通信でよく利用されていたものですが、現在はあまり使用されていません。

　現在利用されているインターネットの電子メールシステムでは、ユーザが作ったメッセージをメールクライアントからメールサーバへ、あるいはさらにサーバをいくつか経由して、宛先のメールサーバに送信する形をとっています。

2．1　電子メールの宛先

　電子メールの宛先は@を使って表します。上の例では@に続く"msv.example.com"が宛先のサーバのドメイン名です。@の前にあるのはユーザ名（hoge）です。宛先のメールアドレスがhoge@msv.example.comということは、smv.example.comというドメイン名のメールサーバ上でユーザ登録されているhogeというユーザ宛のメールということになります。従って、メールアドレスは次の通りです。

＜ユーザID＞@＜メールサーバの名前＞．＜メールサーバマシンのドメイン名＞　

@の右側のメールサーバ名は、「メールサーバの名前」＋「メールサーバがあるネットワークのドメイン名」となります。

　hogeさんがmsv.example.comという名前のサーバ上でユーザ登録されると、hogeさん専用のディレクトリ（directory）が作成され、更にそのサブディレクトリとしてメールボックス（mail box）というディレクトリが作成されます。このディレクトリがhogeさんのメールボックスです。郵便制度に例えると、hogeさん専用の私書箱のようなものになります。

※メールボックスの利用：インターネットの電子メールを使えるようになるには自分専用のメールボックスがないといけません。企業や大学等に入るとメールサーバの管理者が新入社員あるいは新入生のメールアカウントを作ってくれます。これは、管理者が組織のメールサーバ上にユーザ登録してくれるということです。あるいは自宅でインターネットをする場合はISPに加入して、ISPの管理者にメールアカウントを作ってもらいます。

2．2　MTA、MDA、MUA

　電子メールはメールサーバからメールサーバに転送されます。メールサーバ間の転送にはSMTPが使われます。このサーバはSMTPサーバなどと呼ばれます。

　SMTPサーバにメールの送信を依頼するのはメーラと呼ばれるアプリケーションです。ユーザはこのアプリケーションを使ってメールを書いたり読んだりします。このユーザ用のメールアプリケーションはMUA（Mail User Agent）と呼ばれます。MUAとやり取りするのがMTA（Mail Transfer Agent）です。これがメールサーバです。MUAとMTAはSMTPを使って通信をします。MTAは、MUAからメール送信を依頼されたら、仕訳をして、違うMTAに転送するか、当該サーバ内のメールボックスに配信するかを決め、配送役としてMDA（Mail Delivery Agent）を呼び出します。

　メールの宛先がローカルのメールボックスの場合、MTAはローカル配送用のMDAを呼び出します。MDAはMTAと同じファイルシステムにアクセスすることができますので、MTAのファイルシステムから読み込んで、ユーザのディレクトリ内のメールボックスに書き込みを行います（ローカル配送）。

　メールの宛先がリモートのメールサーバ上の場合は、リモート配信用のMDAを呼び出します。リモート配信用のMDAはリモートのメールサーバとSMTP通信をして、メールメッセージを外に配信します。

　MTA、MDA、MUAのうち、MTAとMDAの2つの機能は1つのメールサーバソフトのパッケージにまとめられているかも知れません。あるいはMUAとMDAがパッケージになっているかも知れません。メールサーバソフトとしてはUNIX系のものとしてsendmail、Postfix、qmail、Exim、Windows系のものとしてMicrosoft Exchange Server、Xmailなどがあります。

　MUAを使ってメールを送信する場合は、メールサーバに直接ログインして、メールサーバ上のMUAを使って書く場合と、ユーザが管理するパソコン上のMUAで書いて、メールサーバ上のMTAにメール送信を依頼するという形があります。現在は一般のユーザは後者の形を使ってメール送信を行っています。
　メーラ（メールクライアント、メールソフト）は、Windowsでは、Outlook（Microsoft Office製品、有料）、Thunderbird（無料）、Mac OSでは、Thunderbird、Mail（Mac標準搭載）、Outlook for Mac（Microsoft Office 365を購入）などが人気です。クラウドタイプ（Webメール）ではGmailが有名です。

●　メール配送とRFC
　インターネットで電子メールの配送のために使われた最初のプロトコルはFTPです。FTPに電子メール転送用のコマンドが追加され、1970年代を通して利用されていました。
　電子メールを配送するためのプロトコルとして作成された最初のRFCはRFC722です。これはFTPのメール転送に関する部分をプロトコルの一部として取り込んだものです。現在のSMTPが最初に定義されたのはRFC788です。これが数年間利用されRFC821で置き換えられました。RFC821はメールボックスのアドレスをuser@domainあるいはより広範囲にLocalpart@Domainpartとして指定する標準規格を定義しています（このアドレス形式はRFC821スタイルのアドレス形式と呼ばれています）。その後、RFC822によってより人間が理解しやすいインターネットアドレス形式が定義されました。これは実際のアドレスの前にフレンドリ名あるいは表示名と呼ばれるフレーズパートを追加したもので、"Phrase"<localpart@domainpart>という形式を使用しています。例えば、"taro yamada"<taro@kmownet.com>というようになります。その後、RFC1123で2、3のプロトコルが明確化され改良され、現在は、RFC822とRFC1123が電子メールの基本的な標準仕様となっています。その後もRFC1425、RFC1651、RFC1869が拡張機能について規定しています。これらの規定は基本となるプロトコルに影響を与えずにSMTPに非常に効果的な新しい機能を追加することに成功しています。

2．3　メールの閲覧

　次に問題となるのが、メールボックスに格納されたメールをどのように読むかです。インターネットの初期にはユーザはメールサーバに直接ログインしてサーバ上にあるMUAを使ってメールを読んでいました。メールサーバはUNIX（OS）であることが多く、一般のユーザにはあまり使い勝手のいいものではありませんでした。メールサーバを管理している者からすると、UNIXを良く知らないユーザに直接ログインを許すのは余り気が進みません。直接ログインすればShellでOSのカーネルに変更を加えることもできてしまうわけですから、安心できません。また、ユーザにしてみれば、いちいちメールサーバのところまで出向かないとメールが読めないというのは不便でした。メールサーバは常時インターネットに接続していなくてはならないという事情がありますので、ネットワーク環境がよくない当時は、どこにでもメールサーバを置けるというようなわけにはいかなかったのです。メールサーバはユーザから見ると不便なところにありました。

　パーソナルコンピュータが普及し、一人で1台のパソコンを利用できるようになると、自分の机の上のパソコンからメールを読みたいと考えるようになり、メールサーバにリモートからログインしてメールを読むという方法が使われるようになります。
　もちろん自分のパソコン上でMTAを起動させればいいのですが、パソコンはそのようには作られてはいません。MTAを動かすためには常時インターネットにつながっている必要があります。そのためには365日稼働し続けてもダウンしないようなソフトウェア的にもハードウェア的にも堅牢なマシンでなくてはなりません。また、パソコン用のOSはクライアント用のアプリケーションしか持っていません。そこで、パソコンからサーバにログインして、メールサーバ上のMUAでメールを閲覧する必要があります。これでメールサーバのところまで出向かなくても済みますが、依然としてメールサーバにログインする必要があり、サーバの管理者は何かあったら困るとひやひやしていました。

　現在は、メールサーバにログインする必要はありません。メールサーバ上にPOP3や、IMAP4などのサービスが稼働しており、ユーザはメーラ（メールソフト）からPOP3やIMAP4などのサーバにアクセスして、自分のメールボックス内のメールを読むことが出来ます。これでメールサーバの管理者の心配も解消されることになりました。

　メールサーバにログインする方法（「2.3の①、②」）ではシステムにログインする際にIDとパスワードを入力していますので、他のユーザのディレクトリにはアクセスできません。アクセスできるのは自分のディレクトリだけです（その他にシェル等を利用できますが、説明は省略します）。しかし、POP3、IMAP4で接続するときはどこの誰だかわからないというのでは危険ですので、IDとパスワードで認証を行い、ユーザ自身のメールボックスにしかアクセスできないような仕掛けになっています。

●　メール閲覧とRFC
　POPに関する最初のRFCはRFC918で、実験用の基本的なPOP実装について記述されていました。その後RFC937が公開されました。RFC987では新しい機能がいくつか追加され、このあたりから広く利用されるようになりました。現在のPOP Version3はRFC1081として公開され、その後数回にわたって修正されています（1225、1460、1725、1939）。現在のPOP3の標準はRFC1939です。
　POPの拡張機能についてはRFC1081、RFC1082、RFC2449が公開されています。

　IMAPに関してはRFC1064で最初に公開されました。その後RFC1176、RFC1203と改良されました。RFC1203はIMAPプロトコルのVersion3を定義していますが、IMAP開発を行っているコミュニティには認められなかったため実装されたことはありません。現在のIMAP Version4はRFC1730で初めて公開されています。その後RFC1732、RFC1733、RFC2060、RFC2061、RFC2062が公開されています。RFC1732はVersion2からVersion4への移行をサポートする文書です。IMAP4の最新版はRFC2060で、RFC2061はRFC1732を更新し、RFC2062は移行を更に進めるものです。

3　電子メール送受信の手順

3．1　MUAとMTAの通信手順

　第2章で電子メールの送信手順の大まかな部分が分かったと思いますので、次に実際のMUAとMTAの通信手順を具体的に見てみたいと思います。次に示すのはWiresharkでメーラとメールサーバのやり取りをキャプチャしたデータを分かり易いように少し編集して示しています。

　上の例はMUAとMTAの通信を簡単に示したものです。少し詳しく書くと次のようになります。

###$$$%%%&&&　＜ここから＞　###$$$%%%&&&

###$$$%%%&&&　＜ここまで＞　###$$$%%%&&&

3．1．1　SMTPコマンド

　赤字部分がMUAからMTAに送信したもので、黒字の部分がMTAからの返事です。次にクライアント（MUA）が使用したコマンドについて説明します。

　実際に上の手順で使われているコマンドについてもう少し詳しく説明すると次のようになります。

●　HELO： hostname
　　 EHLO： hostname
　HELOコマンドは、クライアントが自分の身元をサーバに知らせるために使用します。EHLOコマンドも基本的には同じですが、送信時にESMTP（拡張SMTP、Extended SMTP、RFC1425）を指定したい場合は、EHLOであいさつします。

●　MAIL FROM： reverse-path
　MAILコマンドは送信者の指定をします。FROMというパラメータを付けて、送信者のアドレスを指定します。

●　RCPT TO：foward-path
　RCPTコマンドはメッセージの受信者（forward-path）の指定をします。TOというパラメータを付けて、ユーザ名を指定します。ローカルユーザの場合は名前で、リモートユーザの場合はメールアドレスで、それぞれ指定します。

●　DATA
　DATAコマンドで指定するのはメールメッセージ本体です。DATAコマンドに続けて、メールヘッダを記述し、それに続けてメールメッセージ本体を記述し、最後に"."だけの行を入力します。最終行に「<CR><LF>.<CR><LF>」と記述することで、メッセージの終了を意味します。
※<CR>はキャリッジリターン（カーソルを左端の位置に戻すこと）、<LF>はラインフィード（カーソルを新しい行に移動する）で、<CR><LF>で改行という意味になります。

●　QUIT
　QUITコマンドは、クライアントがサーバに対して現在のSMTPセションを終了し、コネクションを切断するように要請するコマンドです。このコマンドを受信したSMTPサーバは直ぐに応答コードを返して、TCPコネクション切断のプロセスを開始します。

3．1．2　SMTP応答コード

　MTAの応答は250や354などの数字とそれに続くテキスト文の組み合わせからなります。テキスト文は起こった問題に対する説明をユーザが読めるようにしたものです。RFC821では応答コードとそれに対応した標準的なエラーテキストを規定していますが、必ずしもこれに縛られる必要はありません。標準的なテキストを短縮したものや、修正を加えたテキストを返すサーバもあります。

　応答コードは3桁の数字で、それぞれの桁ごとに異なったレベルの情報を表示しています。最上位の桁が最も重要で、そのコマンドが失敗したか否かを示しています。最上位の数字の意味は次の通りです。

●　応答コードの最上位桁の意味

●　応答コードの2桁目の意味

●　応答コードの例

　最上位桁と2桁目の数字には特定に意味が付加されていますが、3つ目の数字には特定に意味はありません。3つ目の数字は1桁目、2桁目の数字の組み合わせで表現される内容のうち、特定のものを識別するためだけに使用されます。

3．2　POP3、IMAP4の通信手順

　次に示すのはPOPクライアントとPOPサーバの通信です。実際にwiresharkでキャプチャしたものを分かり易いように少し編集して示しています。

　POPのコマンドは次の通りです。

　POP応答は、SMTP応答と比較するとずっと簡単です。応答はSMTPのような複数の数字からなるコードではなく、成功は「+OK」、失敗は「-ERR」で示されます。
　POP応答には「単一行応答」と「複数行応答」の2種類があります。

●　単一行応答の文法

　単一行応答　＝　ステータス　[SP　オプション文]
　ステータス（状態指示子）　＝　"+OK"|"-ERR"

　単一行応答は512文字以下でなくてはなりません。状態指示子は大文字でなくてはなりません。コマンドによっては予めオプション文が定義されているものもありますが、任意のオプション文を使えるコマンドもあります。

※"|"（パイプ）はORの意味です。

●　複数行応答の文法
　複数行応答　＝　単一行応答　*ドット詰め　"."
　ドット詰め　＝　*CHAR　;　ドット詰めされている

　複数行応答の最初には「単一行応答」が置かれ、ゼロ行以上のドットスタッフィングされたテキスト行が続き、最後の行は１個のピリオド"."だけの行となります。

　POPクライアントとPOPサーバのやり取りの詳細は次の通りです。

###$$$%%%&&&　＜ここから＞　###$$$%%%&&&

###$$$%%%&&&　＜ここまで＞　###$$$%%%&&&

　メールボックスにある電子メールメッセージを閲覧するという目的に限定するとPOPは十分な機能をもっています。しかし、POPではうまくできないこともあります。例えば、POPは複数のメールボックスを簡単に扱うことができません。POPはユーザに届く電子メールが全て1つのフォルダに到着することを前提としているからです。また、POPはメッセージをサーバに保存しておけないわけではないですが、設計上はメッセージをダウンロードするようになっています。IMAPは設計の段階で複数のメールボックスに対するアクセスと、リモートサーバ上へのメッセージの保存を可能としています。
　POPは同一のメッセージボックスに複数のクライアントがアクセスする場合の処理が不得意で自宅と職場にPCを持つユーザが増えると問題が深刻化します。更に、ラップトップやタブレット端末からメールを読もうとする厄介なことになります。IMAPは最初からこのようなことを考慮に入れて設計されています。更に異なるIDを持つ複数ユーザによる同一フォルダへのアクセスもサポートしています。

4　メールメッセージのフォーマット

　電子メールに関する規定はメールメッセージをどのように送信するかに関する規定です。ここでは電子メールシステムの中心であるメールメッセージがどのようなものであるかについて説明します。メールメッセージに関する基本仕様を定義しているのはRFC822です。RFC822は、電子メールをホストからホストへ伝送する際にメールメッセージをどのような形式にする必要があるかについて定義しています。様々なネットワーク間で電子メールを互いに配送できるようにするためには、メールメッセージの標準的な形式が必要だというのがその理由です。

　メッセージはUS-ASCII（ASCII文字の7ビット版）で書かれており、メッセージの各行はCRLF（復帰改行）で終わっています。RFC822では、メッセージの各行にUS-ASCIIの'0'（ヌル文字）とCR文字、LF文字を含んでよいということになっていますが、これは問題です。ヌル文字はプログラミングライブラリでは、内部的に行の終端を表すためによく利用されますので、プログラミングライブラリで問題となってしまいます。また、さまざまなOSでCR文字、LF文字を様々な文字と組み合わせて終端を示すために使っていますので、これも問題を起こしかねません。電子メールの開発者は、電子メールメッセージでは、ヌル文字や、単一のCR文字、単一のLF文字を使えないようにすべきです（CRLFだけを認める）。

　メールメッセージはヘッダ行で始まります。ヘッダは誰がそのメッセージを送ったか、誰に送られるか、いつ送られたかなどの情報を示します。ヘッダはプログラムが解析できるように一定の形式に沿って構成されていなくてはなりません。MTAやMDA、MUAなどのプログラムがこれを解析し、それに従って動作できなくてはならないからです。

　ヘッダの次には空白行が置かれます。この空白行の後にメッセージの本体が続きます。

　メールメッセージのフォーマットは大体次のような形式をしています。

　メールヘッダはヘッダフィールドと呼ばれる行で構成されます。ヘッダフィールドのフォーマットは次の通りです。

フィールドによっては[;]で区切られた複数のパラメータが続くこともあります。

　次に標準的なヘッダフィールドについて説明します。

●　Receivedフィールドによるメッセージ診断
　メッセージを処理したMTAは処理の記録を残すために処理したメッセージの先頭にReceivedフィールドを追加します。従って、Receivedフィールドのリストはメッセージが最終的に通過したメールサーバのリスト（転送経路）となります。Receivedフィールドには、from、by、via、with、id、forなどの副フィールドがあります。Receivedフィールドの例は次の通りです。

　fromは、送信するホストの名前です。RFC822は単なるドメイン名としていますが、ほとんどのMTAはドメイン名の後のカッコ内に追加情報を加えています。追加情報はそのホストのIPアドレスであったり、あるいはそのIPアドレスを逆引きしたドメイン名などになります。
　byは、受信するホスト名を特定します。
　viaは、本来はメッセージを運ぶ物理的なメカニズムを示すものとされていましたが、実際の使われ方を見ると、メッセージを転送するために使わてているプログラムが何かや、伝送で使われたゲートウェイソフトウェアが何かなどを示すことが多いようです。例：via sendmail、via rsmtpなど
　withは2つのMTA間のメッセージ転送で使われた通信プロトコル、あるいはメールプロトコルを示すために使われます。
　idはMTAがメッセージの処理に使う一意の識別子です。
　forはSMTP対話のRCPTコマンドに対して返される受信者アドレスを記録するために使われます。

　Receivedフィールドは前に順に追加されていきます。受信者に近いところはとりあえず信頼性が高いといっていいでしょう。受信者に近いところから順番にfor、by、fromなどの間に矛盾がないかを見ていってください。例えば、from副フィールドのカッコ内にIPアドレスが記載されていたら、それを自分で逆引きしてみてください。副フィールドにはドメイン名も記載されているでしょう。そのドメイン名と、自分で逆引きした結果が同じかどうか確認します。同じでない場合はドメイン名の詐称の可能性があります。IPアドレスとドメイン名はTCP接続の向こう側のIPアドレスを入手してから、DNSシステムを使ってドメイン名にしたものです。従ってとりあえずは、IPアドレスは信頼してもよさそうです。このIPアドレスを逆引きした結果と、from副フィールドに書かれたドメイン名が違っているとすれば、このドメイン名は偽造された可能性が高いと思っていいかもしれません。

　メールヘッダの作成者には簡単に偽造ができますので、送信者に近いほど疑ってかかる必要があります。

　Receivedフィールドにはメッセージの通ったホストにおける時刻が記録されていますので、ある離れた場所からの電子メールが到達するまでに異常に時間がかかりすぎるなどという場合には、ここを確認することで遅延が発生しているホスト（メールサーバ）を突き止めることも可能となります。

5　MIME

　以上で、送信したメールはDNSやルータなどの手助けを受けて確実に相手先まで届きそうな気がします。でも、メールの内容を確実に読んでもらえるかは分かりません。文字化けして相手には何のことやら分からないという場合も珍しいことではありません。もともとの規定（RFC822）では、インターネットの電子メールは7ビットのASCII文字以外は送信できないということになっています。インターネットの初期はこれで問題はありませんでした。利用するのは米国の研究者だけだったのですから。しかし、徐々に利用者が拡大すると、当然不便だということになります。ラテン語系でも、フランス語、スペイン語、ドイツ語のような発音用の補助記号付の文字は使えません。また、ロシア語系の言語で多用されているキリル文字なども扱うことはできません。正式なASCII文字コードは7ビットなので、8ビットを1つの単位として考えると、最上位ビットを1とした文字空間が128文字分空いています。ここに、特殊文字を押し込めたくなるのは人情というものでしょう。日本でも8ビット文字空間の空いた部分に半角カタカナ文字を押し込める日本語用ASCII（JIS X 0201、正式名は「7ビット及び8ビットの情報交換用符号化文字集合」）が開発されています。8ビットのASCII（正規にはASCIIではありませんが）コードに対して、もともとの正式なASCIIはUS-ASCIIなどと呼ばれることがあります。

　SMTPを実装したメールサーバや、メールクライアントは当然US-ASCIIを文字セットとして扱うように設計されています。もともと7ビットの文字コードで作られてシステムを、後発の8ビットの文字コードで動作させようとするのには無理があります。現に、ヘッダに半角カタカナを入れた結果メールサーバが誤動作を起こして、インターネットが大混乱を起こしたということもあります。そこで、メールサーバの中には8ビットセットの最上位ビットを強制的に"0"に変更しようとするものも出てきました。すると今度は、本文もおかしくなってしまいます。本文に8ビットASCIIが使われている場合、最上位ビットを強制的に"0"に変換されると、本文が文字化けしてしまいます。

　7ビットコードという制限の打開策として提案されたのがMIME（Multipurpose Internet Mail Extensions；　多目的インターネットメール拡張、通称はマイム）です。MIMEはRFC1521、RFC1522、RFC2045、RFC2046、RFC2047、RFC2049、RFC4288で規定されていますが、MIMEを使うことでインターネット電子メールでさまざまなフォーマットを使うことができます。

　電子メールの規定はメッセージの本文に関して、（制御コード以外の）US-ASCII文字を使うことしか規定していません。開発者はここに目をつけました。音声や画像などのバイナリデータ（1と0の組み合わせのうち、文字コードで割り当てられた組み合わせ以外を使っているデータ、つまり、任意の"1"、"0"の組み合わせのデータ）や8ビット文字コードなどを全部US-ASCII文字に変換してしまえば、問題がないということになります。

　MIMEメッセージがメッセージヘッダと本文から構成されるという点は通常のメッセージと同様です。ヘッダ部分にはMIME用の特別のヘッダフィールドが置かれます。MIMEメッセージの本文には、MIMEバウンダリ（境界）と呼ばれる特別な文字列で区切られたいくつかのパートがあり、その各パートにはASCIIエンコーディングされたデータが保持され、各パートの先頭にはでコードのための情報などを含むMIMEパートヘッダが置かれています。MIMEデータを持つメールのフォーマットは次の通りです。

　MIMEヘッダにはヘッダ部分のMIMEメッセージヘッダと、メッセージ本体のMIMEパートヘッダがあります。MIMEメッセージヘッダはMIME拡張によって追加されたヘッダで、そのメッセージがMIME準拠であることを示すとともに、受信者側のMUAにメッセージの構造とエンコードの方法についての情報を与えます。

　MIMEパートヘッダはメッセージ本文内に置かれた各パートの先頭に置かれます。MIMEヘッダがヘッダフィールドに置かれたときは、メッセージ全体に適用されます。これに対して、MIMEメッセージパートの先頭に置かれたときは、そのパートに対してだけ適用されます。

　MIMEメッセージヘッダフィールドは次の通りです。

5．1　Content-Typeヘッダ

　Content-TypeヘッダはMIMEメッセージに組み込まれたデータの種類を明らかにします。MEMEヘッダのフォーマットは次の通りです。

Content-Type：　タイプ/サブタイプ

タイプとサブタイプでMIMEメッセージ本体に含まれたデータを識別します。次に基本的な7つのタイプとその主なサブタイプを示します。

●　textタイプ
　textは、データがASCIIテキストであることを示します。サブタイプはplainとenriched、HTMLです。

●　imageタイプ
　imageはグラフィックス画像（静止画）を表すバイナリデータが組み込まれていることを示します。サブタイプとしてはjpegとgifが定義されています。これらはJPEG（Joint Photographic Coding Experts Group）、GIF（Graphic Image Format）を示します。

●　audioタイプ
　audioタイプはオーディオデータを表すバイナリデータが組み込まれていることを示します。サブタイプはbasicです。

●　videoタイプ
　videoタイプは動画像を表すバイナリデータが組み込まれていることを示します。サブタイプとして定義されているのはmpegです。

●　applicationタイプ
　applicationタイプは、スプレッドシートやワープロ文書などのアプリケーション固有のバイナリデータが含まれていることを示します。サブタイプはpostscriptとoctet-streamです。

●　multipartタイプ
　構造化タイプとも呼ばれています。これはデータそのものを表しているのではなく、1つのメッセージにいろいろのタイプのデータを組み込んでいることを示しています。multipartは前置部分（preamble）、1つ以上の本体部分（body-part）、後置部分（epilogue）から構成されます。前置部分と後置部分はオプションで、本体部分の前にMIMEバウンダリ（境界行）が必要となります。

　MIMEバウンダリは2個のダッシュ(--）で始まり、一意の文字列がそれに続き、必要に応じて空白が付加されます。一意の文字列は次のようにContent-Typeヘッダ内のboundaryパラメータによって与えられます。ダッシュと一意の文字列は本体に現れることのない値でなくてはなりません。

MIMEバウンダリは各本体部分の前に置かれて、それぞれの本体部分を前の本体部分と分離します。そして、本体の集合の最後には、境界文字列の最後に更にダッシュを2つ追加した文字列が置かれます。

　multipartのサブタイプにはmixed、parallel、alternative、digestなどがあります。
　mixedはメッセージがテキスト、オーディオ、ビデオなどの独立の様々なパーツから構成されることを示しています。これらは、メッセージに組み込まれた順に受信者に示されます。
　parallelは各パーツを同時に再生しなくてはならないことを示します。例えば、オーディオデータとビデオデータを同時に再生したい場合などに指定します。
　alternativeは同じデータが何通りかの形式で、提示されていることを示します。受信者側の能力を考慮して、何通りかの形式で送りたいという場合に便利です。例えば、標準のプレーンテキスト形式、enriched形式、Word形式などで送っておけば、受信者側で能力の範囲で、データタイプを選択することができます。
　digestは送信内容の各セクションがダイジェストメッセージと呼ばれるデータ型で構成されることを示しています。

●　messageタイプ
　messageタイプは、電子メールシステムが1通のメッセージで複数のRFC822メッセージを送信できるようにしたものです。サブタイプはrfc822、partial、externalbodyです。
　rfc822はメール本文がRFC822に完全準拠していることを示します。
　partialはメッセージ全体の一部であることを示します。メッセージサイズは最大で64KBでそれを超えると小さなメッセージに分割する必要があります。メッセージをいくつかに分けて送信する場合にはpartialを使います。
　external-bodyは電子メールメッセージの外にあるファイルを参照します。通常、FTPでダウンロードする大きなファイルへの参照に使用します。

●　送信例
　multipartタイプとmessageタイプはコンポジット（複合）タイプと呼ばれ、メッセージの構造を考慮して更に処理が必要な場合に使用されます。コンポジットタイプはメッセージが複数のパートで構成される場合に、その全体を包む「ラッパー」として使用されます。次の例はプレーンテキストとHTML文を送る例です。
　2つのタイプを使用しますので、外側のラッパーで2つのメッセージを包みます。使うのはmultipartです。プレーンテキストとHTML文を送信していますので、alternativeを使っています。

　添付ファイルを送信する場合は、その前で本体としての終わりを宣言し（バウンダリの最後に"--"を追加）、その後に改めてバウンダリを使って添付ファイルのヘッダの宣言をし、添付のファイル（例ではbase64でエンコーディングされています）を載せ、最後にバウンダリ（"--"で終わり）で付けて添付ファイルの終わりを示しています。

5．2　MIMEエンコーディング

　メールで送りたいデータ形式の中には、メールメッセージの中で許容できないバイト値を含んでいるものもありますし、長すぎるという場合もあります。このような場合にはContent-Type-Encodingフィールドで定義した方法で解決するというのがMIMEの手法です。

　Content-Type-Encodeingで定義されているのは7bit、8bit、binary、quoted-printable、base64です。7bit、8bit、binaryは識別符号化と呼ばれています。これらは符号化が行われたということではなく、7bit、あるいは8bitのデータを含んでいる、あるいはバイナリのデータで構成されているということを示しています。データ転送の際にエンコーディングを実施するのはbase64とquoted-printableの2つです。

5．2．1　7bit、8bit、binary

●　7bit
　RFC822標準のテキスト行と同じでUS-ASCIIの128よりも小さい値からなる7ビットのデータです。行の長さは998オクテット以下で、CRLFで終端されています。データの中には"0"、単独の"CR"、単独の"LF"を使うことができません。Content-Type-Encodingの行がない場合は、7bitと仮定されています。

●　8bit
　7bitと同様に998オクテット以下の行からなり、CRLFで終端します。データの途中に単独の"CR"と単独の"LF"が使えませんが、"0"は使うことができます。7bitとの違いは、8bitではASCIIの128以上が使えることです（128～255まで使えます）。この符号化のメカニズムを使っているメッセージの転送には8bitmimeという拡張機能（RFC1652）が使えます。
　8bitmimeの拡張機能をサポートしているサーバはEHLOコマンドへの返答に8bitmimeというキーワードを追加してクライアントに通知します。8bitmime拡張では、MAILコマンドにbodyパラメータを追加します。bodyパラメータの値は「7bit」あるいは「8bit」になります。

●　binary
　binaryという符号化メカニズムは行の長さや、文字の制約がない任意の8ビットデータに対して使われます。ただし、現在は最もレベルの高いMIMEエンティティの中ではbinary符号化は使われず、メディアタイプのmessage/external-bodyの中で使用されています。

5．2．2　base64

　base64符号化はバイナリデータをインターネット上で転送するのに適した形に符号化するために使われます（RFC3548、RFC4648）。

　バイナリデータをインターネットに転送するのに適した形にする方法はbase64とquoted-printableの2つの方法が規定されていますが、全体の中でバイナリデータがどれ位混じっているかで使い方が分かれます。画像データのように全部が、あるいはほとんどがバイナリという場合は、全部をいっぺんに符号化してしまったほうが手っ取り早くて簡単です。しかし、ところどころにバイナリが混じっているような場合には個別に対応したほうがよさそうです。

　base64はほとんどがバイナリあるいは8ビットコードの文字だという場合は、有無を言わせず全部変換してしまうという方法です。

　base64では8ビットコードの3文字分あるいはバイナリの3文字分（24ビット）を取り出して、6ビットずつに分割し、その分割したビット並びに対して1文字ずつ計4文字のUS-ASCII文字を割り当てる方式です。6ビットでは2^6=64文字を表現することができますので、"A-Za-z0-9+/"の計64文字を割り当てることが可能です。元のデータを6ビットずつに分割しますが、6ビットに足りない場合は"0"を追加します。そして、各6ビットを変換表に従って、文字を割り当て、その文字を4文字ずつのセットにします。このとき、4文字に足りない場合は、"="を補います。

　テストという文字を変換してみましょう。まず、"テスト"という文字をShift-JISやUTF-8などの文字コードで変換してみましょう。ここでは試しにUTF-8に変換してみます。"テ"=E38386、"ス"=E382B9、"ト"=E38388です。これを並べると"E38386E382B9E38388"となります。これを2進数で変換すると次のようになります。

　2進表示した結果を6桁ずつとって並べ、base64で変換すると次のようになります。

　バイト列全体が符号化されたら符号化データが送出ストリームが76文字以下の行長になるようにCRLFを挿入します。通常のバイナリデータは行志向ではないのでこの作業が必要となります。復号化の際にはこのCRLF文字は取り除かれるので、元のデータの正確な複製が出来上がります。

5．2．3　Quoted-Printable

　base64の手法を使えば、任意のバイナリデータを送信できますが、その代わりデータ量が増加してしまいます。画像データなどのようにメッセージデータの大部分が非US-ASCII（8ビット文字）である場合は、それでもいいでしょうが、US-ASCII文字の中に少しだけ非US-ASCII文字が混じっているだけという場合は、base64では変換効率が悪くなります。このような場合に使うことを想定しているのがquoted-printableです（RFC2045、RFC2821）。

　殆どのUS-ASCII文字（印字可能な7ビット文字）は符号化の必要はありませんから、quoted-printableでもUS-ASCII文字はそのまま符号化しないで使用します。従って、US-ASCIIの0x21（10進の文字コード33）から0x7e（10進の文字コード126）まではそのまま送信します。ただし、0x3D（10進の文字コード61）の"="は例外です（エスケープコードとして利用するため）。
　上記以外の文字と"="は、1個の文字を16進のコードに置き換え、更にその前に"="を追加します。例えば、<SYN>は0x16ですが、quoted-printableでエンコードすると"=16"となります。ただし、元のデータ形式で行終端として使われているCRLFは、quoted-printable符号化でも、CRLFとして表現されなくてはなりません。
　途中のメールサーバでデータが破壊される可能性ありますので、それを回避するため、quoted-printableでは76文字を超える行を認めません。この制限に対応するため、ソフトウェア的な行終端を定義しています。この行終端は行末の"="として表現され、復号の際には削除されます。
　スペース文字とタブ文字はエンコードされた行中の最後の文字でない限りは、そのままエンコードせずに使うことができますが、行末の空白は最終的にエンコードしなくてはなりません。これは途中のメールサーバの中には行末の空白を取り除くものや、行末に空白を追加するものがあるためです。エンコードされた結果の行末に空白（0x20）があれば、それは途中のメールサーバが追加したものとして復号化の際には取り除く必要があります。

上のquoted-printable符号化された文を元に戻すと次のようになります。

　MIMEを使うことで、8ビット文字もバイナリーもUS-ASCIIの7ビット文字に変換することが出来ました。これによって、フランス語などの発音用補助記号付きの文字や、キリル文字なども扱うことが出来るようになっただけでなく、音声や画像、動画なども問題なく扱うことが出来るようになりました。また、日本語、中国語などの1バイトでは不自由な言語も扱うことが出来るようになりました。

6　メールの文字化け問題

　MIMEですべて問題が解決したということになればいいのですが、そうとも言えません。この方式を使うか使わないかはユーザしだいです。メールを出す場合に使うのがメールソフトですが、どのようなコードを使うかはメールソフトの設定しだいということになります。一般的には、日本語用のメールソフトの場合は、添付ファイルはbese64でエンコーディングして、本文は7ビットコードのJIS（iso-2022-jp）で送るというのがデフォルトの設定になっていることが多いようです。

　文字化けは依然として無くなっていませんので、その原因を考えてみましょう。今言いましたように添付ファイルはエンコーディングし、本文はエンコードしないという設定が普通です。パソコンでよく使う文字コードとしては、WindowsやMacintoshのshift-jisやUNIXでよく利用される「EUC」などがあります。これらは、8ビットコードの文字セットです。例えば、Wordファイルなどは8ビットコードで書かれています。これを添付ファイルとして送信しても問題はありません。本文は7ビットコードで書くことが前提になっている場合が多いので、日本語を使う場合は、7ビットのJIS（iso-2022-jp）コードを使います。8ビットコードで書かれた文章をコピーして、メールの本文に貼り付けても7ビットコードに変換してくれます。ところが、メーラーによってはJISコード以外で送れるように設定できるものもありますし、途中で半角カタカナが入っているとそれを8ビットコード（shift-jis）で送ってしまうものもあります。また、転送途中のメールサーバが8ビットコードを嫌がり、base64やquoted-printableに変換してしまうものがあります。受信したメーラーは多分7ビットコードで表示するように設定されていますので、デコードせずにそのまま表示してしまい、文字化けが起こります。また、途中のメールサーバによっては8ビットの最上位の1を0に変えてしまうものがあるといいましたが、この場合も文字化けをしてしまいます。いずれにしても、送信する際の文字コードはJIS（iso-2022-jp）にして、本文中に半角カタカナを使わないように注意しなくてはなりません。

　送信側のメーラーがHTMLで書いているのに、受信者側のメーラーがテキストメールとして開くと、おかしなタグが挿入されているのが見えてなんだが読みにくいということもあります。HTMLメールは、ホームページと同様に、文字の大きさや、位置、背景色などをレイアウトできるメールの形式ですが、受信側がそれに未対応だとHTMLのタグがそのまま表示されてしまいます。デフォルトの設定がHTML形式というメーラー（例：Outlook Express）もありますので、注意して下さい。相手もHTMLに対応できるということが分かっている場合以外は、テキスト形式でメールを送るようにして下さい。

　HTML形式と同じような問題をはらんでいるのがenriched形式です。プレーンテキストと比較して、フォントの指定や、文字の色・大きさなどの装飾指定、画像の表示や中央揃え・箇条書き、表などの簡易レイアウトの機能を持つ文章形式で、MicrosoftのWORDなどが採用しています。デフォルトでenriched形式を使っているメーラーなどもあります（例えば、Eudora Pro 3.0、Microsoft Internet Mail）ので、注意が必要です。

6．1　日本語文字コードはほんとにやっかい

　現在、日本で使われている符号化文字のコードにはいろいろのものがあります。公的に規格が定められているものでも、JIS X 0201、JIS X 0208、JIS X 0212、JIS X 0213、JIS X 0221などがあります。この他にも、Microsoft Windowsで使用されているShift jisなどがあり、これにも拡張コードなどが定められています。その他にEUCコードなどもあります。

　JIS X 0201はすでに説明したように、US-ASCIIコードの最上位ビットが1つ空いているところに、半角カタカナを押し込んだいわゆる8ビットASCIIコードです。

　JIS X 0208は2バイトの文字コードですので、合計で2^16＝65536種類の文字を表すことができます。これが最も一般的な規格で、日常的によく利用される数字、英字、ひらがな、カタカナ、漢字、記号など6879文字が規定されています。正式な規格名は「7ビットおよび8ビットの2バイト情報交換用符号化漢字集合」といいます。JIS漢字コード、JIS漢字、JIS第1水準第2水準漢字、JIS基本漢字などの通称があります。「ESC」を使って、US-ASCIIとJIS X 0208が共存できるようにしたのが7ビットコードのISO-2022-JPです。

　JIS X 0212はJIS X 0208に含まれない文字を集めて規定したものです。規格名称は、「情報交換用漢字符号－補助漢字」で、通称はJIS補助漢字です。

　JIS X2013はJIS X 0208の拡張版です。規格名称は「7ビットおよび8ビットの2バイト情報交換用符号化拡張漢字集合」で、何回か改定され、2004年に改定された規格は、JIS2004などと呼ばれています。JIS X 0212とJIS X 2013には互換性がありません。JIS X 0212はJIS X 0208にない文字を集めた文字集合ですが、JIS X 0213は、JIS X 0208を包含し更に第3水準第4水準漢字などを加えた上位集合です。

　JIS X 0221は、UnicodeをベースにしたISO/IEC 10646という国際規格を元にJISが制定している文字コード規格です。

　公的規格ではありませんが、Microsoft社が規定したshift jisもよく利用されています。Microsoftはパソコン用のOS（当時はMS-DOSと呼ばれるOSです）を日本語化するに当たり、いちいち「ESC」（エスケープ・シーケンス）を使う方式（iso-2022-jp）では処理が面倒だと考えました。そこで、Microsoftは独自の文字コードを開発することにしました。目をつけたのが、JIS X 0201で使っていない領域です。JIS X 0201はUS-ASCIIの最上位のビットが1の領域に半角カタカナを割り当てる方式です。空いている部分は128文字分ありますが、使ったのは半角カタカナの文字分（記号も含めて0xA0～0xDFまでの64文字分）だけです。0x80～0x9Fと0xE0～0xFFがすっぽり空いています。そこで、MicrosoftはJIS X 0208で規定した文字を、先頭の1バイトがこの空いている部分（0x80～0x9F、0xE0～0xFF）から始まるように、そっくり移動（シフト）する形でコード化しました。これで、1バイト目が0x80～0x9Fあるいは0xE0～0xFFで始まると、その部分は1バイト文字が規定されていないので、続くバイトと合わせて2バイト文字として扱うことができます。

6．2　機種依存文字（環境依存文字）って何？

　本文を7ビットコードで書き、添付ファイルは8ビットコードで書いてbase64等でエンコーディングして送ったとしましょう。これで問題ないでしょうか。ちゃんとデコードしても、そのコードそのものを受信側のコンピュータ（OS）が表示できない、あるいは間違って表示してしまうということがあります。機種によっては正常に表示できるが、違う機種だと正常に表示できない文字があるということです。これを機種依存文字と言います。①などの丸文字、Ⅱなどのローマ数字、㈱、㎏などの特殊な文字です。

　機種依存文字は歴史が古いので、パソコンが普及し始めたころまで少し歴史を遡ってみたいと思います。かつての1990年以前の日本では、NECの9801やIBMのPS/55などいくつもの機種のパソコンが出回っていました。これらのPCは文字コードの処理を機械的に行っていました。使っていた文字コードは、JIS X　0208です。パソコンがキャラクター・ジェネレータと呼ばれるチップを（別名漢字ROM）を備えていてそれが適切にフォントを生成してくれました。しかし、JIS X 0208はパソコンの処理能力が不十分な時代に開発されたコードですので、頻繁に使用される漢字や記号の中にも、洩れているものがたくさんありました。そこでパソコン各社はユーザの便宜を考えて、JIS X 0208で抜けてしまった文字を次々に追加していったのです。しかし、それらの追加文字は各社が勝手に追加したもので、他社のパソコンでは正しく表示できませんでした。

　その後IBM社が内部アーキテクチャ（基本設計）を公開したPC/ATというパソコンを発売しました。内部仕様の多くが公開されたため、Compaq、Dellなどの多くのメーカがPC/ATの互換機を発売しました。更に、IBMはPC/AT互換機上で稼働し、専用のハードウェアを必要とせずに、ソフトウェアだけで日本語処理が出来るOSを発表しました。このOSはDOS/Vと呼ばれました。また、DOS/Vを搭載したパソコンをDOS/Vというようになっていきました。これが1990年です。これ以降は、日本語処理はOSが担うということが普通になりました。このころMicrosoft社はWindows3.0を発売し、1992年にはWindows3.1を発売し、OS業界に確固たる地位を築き始めます。Microsoft社は機種ごとに異なる機種依存文字があることは良くないと考えて、NECのPC-98とIBMのPS/55で使用されていた機種依存文字を統合してShift-Jisを設計しました。Shift-Jisについては既に説明しました。これでめでたしめでたしと言いたいところでしたが、実はそうはいきませんでした。Shift-Jisを採用していたMac OSが違う機種依存文字を規定してしまったのです。従って、現在もなお機種依存文字が残っています。①などの丸文字、Ⅱなどのローマ数字、㈱、㎏などの特殊な記号を使わないことです。

6．3　世界中の文字コードを統一出来ないか

　これまで日本語の文字コードを中心にして説明してきましたが、世界中の言語を統一的にあらわそうという動きもあります。Unicodeがその例です。Unicodeはゼロックス、Apple、IBM、Microsoftなどの米国の情報関連企業が非営利団体のUnicodeコンソーシアムを設立して、そこで提唱したコードです。このコードは、国際標準化機構（ISO）でISO/IEC 10646の一部のUCS-2として標準化されています。一部というと皆さん？と思われるでしょう。全体はISO/IEC 10464で、これはUCS-4と呼ばれています。UCS-4は国際標準化団体であるISOが標準化を進めている4バイトコードで、その一部に2バイトコードのUnicodeがUCS-2として採用されたという形になります。

　ややこしいので少し歴史を遡りたいと思います。情報関連企業は、なぜ世界的に統一されたコードを必要としたのでしょうか。それは、そのコードで一度アプリケーションを書けば全ての言語に対応できるからです。情報関連企業は、世界中の言語を統一的に扱うことで劇的なコスト削減を実現できると予想できます。多くの情報関連企業がコンソーシアムに積極的に参加しています。

　Unicodeコンソーシアムが最初に提唱したのは2バイトで世界の主要な言語のほとんどを体系化しようとするものでした。これが4バイトで世界各国の言語を統一的にコード化しようとしていたUCS-4（Universal Multi-octed Character Set 4）のサブセットとして採用されました。UCS-4は上位バイトから、それぞれ群（group）、面（plane）、区（row）、点（cell）と呼ばれます。UCS-2と呼ばれているのは、群00、面00に当たる領域です。UCSは4バイトのコードで、群の最上位ビットを使っていませんので、0～0x7FFFFFFFの約21億文字分の領域を用意しています。そのうちの0～0X10FFFFにUnicodeが規定したコードセットを取り込んでいます。UCSの開発グループが領域の下位部分にUnicodeのセットを取り込んだため、この部分に関して、UnicodeとUCSの間に互換性が発生しています。

　Unicodeは2バイト（16ビット）コードですので、全部で2^16＝65536文字が表現可能です。しかし、2バイトで多国語を処理しようとするのは少し無理があります。中国語や日本語、韓国語(CJK）で同じ意味やルーツの漢字は全て同じ文字とみなし、全て同じ文字を割り当てる統合作業（ハンユニフィケーション）が行われたため、文化の違いを無視しているという批判もあります。

　Unicodeはその後、何回かのバージョンアップを通じて、多くの漢字を取り込んでいます（Version3.0のCJK統合漢字拡張Aで6582字、Version3.1のCJK統合漢字拡張Bで4271字、Version5.2.0のCJK統合漢字拡張Cで4149字、Version6.0のCJK統合漢字拡張Dで222字）。更に、日本の地図記号、携帯電話の絵文字、顔文字なども取り込みました。最新のUnicodeでは群00の面0Fに当たる部分までが使用できるようになっています。

　UCS-4やUCS-2で定義された文字を実際にどのようにバイト列で表現するかのルールとして、UTF-8、UTF-16、UTF-32（各数字はビット数を表す）などの形式が使われています。

　今後はUnicodeが世界中のコンピュータで採用されていくと思われます。Windowsは当初はShift-Jisだけでしたが、最近はUnicodeも取り入れられ、どちらも利用できるようになっています。Windows上のアプリケーションもShift-Jisにだけ対応しているものと、Shift-JisとUnicodeの両方に対応しているものがあります。Mac OSも徐々にShift-JisからUnicodeに転換中です。もちろん多くのパソコンで表示できるかは、別問題です。正しくエンコードされたとしてもフォントが揃わなければ表示することはできません。

6．4　UNIX上の文字コード

　インターネット上にはここまで取り上げたWindowsとMac OS以外に、LinuxなどのUNIX系のOSを初めさまざまなOSを採用しているコンピュータが数多く存在しています。UNIXでも基本となる文字コードはASCIIですが、漢字をあらわすためには、UNIX独自の規格であるEUC（Extended Unix Code）を採用しています。EUCはJIS X 0208で規定されている文字を、ASCIIで規定されている文字と重ならないようにシフトしたもので、MicrosoftのShit-Jisとまったく同じ仕組みを採用しています。ただし、シフトの方法が異なっていますので、まったく互換性はありません。

6．5　メールヘッダの文字化け

　メールヘッダには日本語の文字コードは使えませんので、ヘッダの日本語は必ずMIMEでエンコードされることになっています。しかし、受信側のメールソフトがMIME形式のデコードが出来ない場合は、やはり文字化けしてしまいます。最近はほとんどの日本語メールソフトはMIME形式に対応していますが、日本語が使えないソフトを使っている人に出すときは件名（サブジェクト）やFromなどの欄は欧文で書くようにして下さい。

6．6　エンコーディングはbase64だけじゃない

　エンコーディング方式についてはbase64だけしか説明しませんでしたが、UNIXで使われるuuencode、Macintoshで使われるBinHex等もあります。添付ファイルはメーラが自動的に設定通りの文字コードでエンコードしてくれますが、受信メールソフトが、これらの方式に対応していない場合は、添付ファイルを本文と勘違いして、間違ったデコードをしてしまうことがあります。現在は、base64がほぼ標準となっており、多くのメーラーが対応していますので、とりあえず初期設定はbase64にしておくのが無難です。ただし、相手のソフトが対応いていない場合もあるので、添付ファイルを送るときには必ず相手に確認をしておくことが大切です。

6．7　その他

　RFCの討議の方法としてメーリングリストを使うと言いましたので、ここで簡単にメーリングリストの話をしておくことにします。メーリングリスト（mailing list、ML）は、複数の人に同時に電子メールを送信する仕組みです。メーリングリストは、登録メンバーの電子メールアドレスのリストと、メーリングリストの代表電子メールアドレスを用意しておき、代表アドレスへ送信されたメールを、リストに登録されたメンバー全員のアドレスに転送します。

　最近はWebブラウザ（クライアント）を通じて利用するWebメールという方法が普及しています。フリーのメールサービスとして、有名なGmail、Yahoo!メール、gooメールなどはWebメールのシステムを採用しています。

Tweet

ネットワーク超入門講座 セキュリティ編【電子書籍】[ 久米原 栄 ] 価格:2,268円 (2018/1/21 11:07時点) 感想(0件)

更新履歴

2016/05/07　作成