これまで電子メールの仕組みやセキュリティーについて学習してきた方は、もはや基礎的な知識はもちろん応用的な知識まで身についていると思います。

本項では、電子メール編の締めくくりとして、電子メール特有の書式について学習します。電子メールで使われている書式を理解すれば、ひいてはマナーの向上にもつながります。

前項でも少し触れましたが、電子メールの世界には暗黙のルールのようなものがあって、そのルールやマナーを知らずに送信してしまうと、相手の印象を悪くする恐れがあります。重要な商談メールであれば、情報リテラシーの低い会社（担当者）なんだなと思われて、契約できない可能性がないわけではないのです。

それほど電子メールはビジネスや生活に必須のツールとなっているというのはもちろん、メールを介したマルウェア（ウイルスを含む悪意あるプログラムを総称する用語）や偽装メールによる被害が社会問題となり、一方でメールが電子証明書によって公文書としての効力を持つなど「たかがメール」と軽んじられる時代ではなくなっています。

そのため、電子メールの書式の使い分けやマナーを知っておくことはとても重要です。

実際のメーラーの操作方法や実践的なテクニック等は、基本操作 メール編 で詳しく解説していますので、本項では知識と基本的なマナーについて知っておきましょう。

さて「書式」といっても、電子メールは電子的な手紙であるので、基本的に文字でのやり取りが主になります。その書式とはどういうことかというと、フォント（書体）のことではなく、

そのメールがどのような形式で記述されているか

ということです。

つまり、普段何気なくやり取りしている電子メールには複数の記述形式があるということです。

すでに前項で「MIMEタイプ」として学習していますが、MIMEに定義されたASCIIコードへの変換方法が、BASE64以外にもあるのと同じように、電子メール本文にも記述形式があるのです。

その記述形式は、大きく分けて2つです。

テキスト形式とHTML形式（リッチテキスト形式）

です。

これらの形式の特徴や違いについては、下記の表のとおりです。

下図は、Outlookの形式選択画面です。

さて、ではこれらの形式をどのように使い分けるのか、また電子メールの世界ではどんなマナーや暗黙のルールがあるのか学習していきましょう。

まず書式のマナーとして、

HTML形式（リッチテキスト形式）のメールは極力送らない

ということが暗黙のルールとなっています。

現在ではひと昔前とは異なり、あまり意識されなくなっていますが、メールの重要度が高いほどテキスト形式を使用するべきです。

なぜなら、

HTML形式のメールにはウィルス（マルウェア）混入の危険性がある

というのが大きな理由です。

怪しい添付ファイルを開かなければ感染しないと思われるかもしれませんが、HTMLメールの本文を開いただけ（プレビュー）で感染してしまうこともあります。

また、迷惑メールや詐欺メールのほとんどがHTML形式です。なぜなら、HTMLはウェブページを作成することができる言語で、画像や動画のみならず、悪意あるプログラムを埋め込むことも可能だからです。

したがって、そういった危険性がある形式でメールを送るということ自体が配慮に欠ける行為とみなされる可能性があるのです。重要なメールは、必ず「テキスト形式」でやり取りするようにしましょう。

ただし、Outlookなどの多くのメーラーは、

デフォルト（初期設定）がHTML形式に設定されている

ので注意が必要です。

すなわち、意識しなければHTML形式でメールを送信していることになります。設定を変更しておくことをオススメします。（メールの基本操作編 本文の書式とマナー を参照してください）

次に、

機種依存文字（環境依存文字）を使用しない

ことも重要です。

機種依存文字（環境依存文字）とは、文字どおり「その機種でしか扱えない文字」または「他の機種では正しく表示できない文字」になりますが、もう少し詳しく理解しておきましょう。

ガラケーのメールを利用されていた方は、docomoやSoftBankなどのメーカーの違いによって、絵文字が正しく表示されなかった経験をお持ちのことと思います。

なぜメーカーによって表示される文字が異なるのでしょうか？

前項で学習のとおり、文字は電子メールに限らず「文字コード」に変換されて通信されます。（文字コードについては、文字コードとは で詳しく学習します）

したがって、どんな文字コードを使用していたとしても、それが世間一般で使用されている文字コードであれば「1000001＝A」のように関連付けられているはずで、正しく変換されるべきです。

きちんと定義された同じ文字コードを使用してやり取りしているのに、メーカーによって双方で表示される文字が異なるというのは普通に考えればおかしな話です。（使用している文字コード自体が異なれば文章全体が文字化けしたり意味不明の文字列になってしまいます）

なぜこのような現象が起きるのかというと、日本語の文字コードはその生成過程において、メーカーなどがシェアの拡大やユーザーの要望のため、コードの空き領域に独自に文字を定義して、それぞれの環境で使用できる文字を増やすことが許されてきたためです。

当時は、ネットワークで異なるメーカーや機種間のやり取りが想定されていなかったり規制なかったことから、それらの文字が統一されることはなかったのです。

つまり、同一の文字コードでも、メーカーによって違う文字が割り当てられてしまい、ある部分のコード（メーカーが独自に定義した拡張領域）は異なった文字が表示されるようになったというわけです。

このように機種依存文字（環境依存文字）とは、

文字コードの空き領域にメーカーがそれぞれ独自に定義している文字

のこと言います。

これは「その機種でしか使えない」のと同じことのようですが、機械的な環境によって使用できる文字が異なるわけではなく、そのメーカーが独自に定義している文字コードが原因となっているので注意が必要です。

つまり、携帯電話だけが対象なのではなく、文字コードを使うすべての機器が対象となります。現在はスマートフォンが主流となり、文字表示はOSの役割となっているため「機種依存」というよりも「OS依存」とも言えます。

したがって、WindowsとMACそれぞれに機種依存文字が定義されており、その文字を使わないことが通信上のマナーであり、暗黙ルールとなっています。

またWindowsでは、これらの拡張文字を含んだフォント「MS明朝」や「MSゴシック」を作ったので、同じ環境（OS）であっても、フォント（書体）によって表示される文字が異なる場合があります。

これらは、

フォント依存文字

と呼ばれています。

その他、Unicode（ユニコード）という世界中の全ての文字の網羅を目指して開発された文字コードでは、従来の機種依存文字も定義しています。機種依存文字であっても新しい文字コードには正しく定義されているものもあります。（UTF-8はUnicodeの規格になります）

したがって機種依存文字は、ある特定の文字コードで定義が曖昧なだけで、すべての文字コードで機種依存という訳ではありません。少しややこしいですが、

機種依存文字やフォント依存文字は正しく表示されない可能性がある文字

と言えます。

ただし電子メールに限って言えば、後述しますが、本文で使用できる日本語の文字コードが原則として決まっているので、この文字コードに定義されていない機種依存文字は依然として敬遠される存在のままです。

そのため、電子メールでは機種依存文字を使用しないことがマナーになっています。

下図はWindowsの機種依存文字（代表的なもの）です。MAC環境では文字化けする可能性があります。

よく使われる数字の囲み文字は機種依存文字になります。現在では文字化けすることはほとんどありませんが、電子メールでは極力使用しないのがマナーです。

上表の他にも、Windows固有の漢字などの機種依存文字があります。

ただ、Windowsも親切に機種依存文字を知らせてくれるので、覚える必要はありません。下図は文字を変換しようとした時の変換リストです。「環境依存文字」としてメッセージが表示されています。

また、人名に用いられる漢字には多くの機種依存文字があります。例えば「高」の口の部分がはしごの文字や「崎」の右上部分が「立」という文字などです。人名の場合は正しい漢字を使用すべきですが、使用する時には注意が必要です。

ただ現在では、絵文字などの明らかに特殊な文字以外、たいていの機種依存文字は正しく表示されるので、これもそこまで意識されることはなくなっています。

半角カタカナ

半角カタカナは、正確には機種依存文字ではないのですが敬遠される存在です。

このことを理解するには、まず文字コードの基礎を知っておく必要があるので、基本的なところを理解しておきましょう。（詳しくは、文字コードとは であらためて学習します）

前項の学習で、電子メールは7ビットのASCIIコードでやり取りされるというのは十分理解されたと思いますが、現在よく使われる日本語の文字コードには、2バイト（16ビット）のものや、それ以上のものがあります。

それらを7ビットのASCIIにエンコードして送受信するための規格がMIMEでした。

テキストの場合は、MIMEに定義された文字コードを選択して記述することでASCIIに変換することができ、添付ファイルなどのバイナリデータの場合は、MIMEに定義されたエンコード方式によってASCIIに変換してやり取りすることが可能になります。

ただし、7ビットでやり取りするという電子メールのルールですが、メーラーの設定等によって、8ビットコードでメールを送信することも実際には可能となっています。前項で学習したメールヘッダーを確認すると、まれに8ビットでエンコードされたメールを受け取っているケースがあります。

8ビットのメールを送信してしまうと、どうなるのでしょうか？

現在では問題とならない場合が多いですが、メールの中継をするサーバ（SMTPサーバ）の中には、7ビットにしか対応していないサーバがあります。

このため、

7ビット規格のサーバやソフトウェアを経由したら1ビット分が破棄される

という事態になることがあります。

これが「文字化け」という現象です。文字コードの違いによる文字化けもあり、文字化けの原因はこれだけではありませんが、もし文字化けメールを受け取ったらメールのヘッダーを確認してみましょう。

そこでこの現象を避けるために、日本語の文字コードでも7ビットコードを使う方法が考え出されました。

この7ビットの日本語の文字コードを、

JISコード（またはISO-2022-JP）

と言います。

詳しくは、文字コードとは を参照していただきたいのですが、正確なことを言うとJISコード（ISO-2022-JP）は「符号化（エンコード）方式」になります。

文字コードを作成するために集められた文字の集合体に、数値を割り当てて表のように整理したものを「文字コードセット（符号化文字集合）」、その文字コードセットで割り当てられた数値を、さらにコンピュータが効率的に扱えるようにエンコードする方式を「符号化方式」と言います。

つまり文字コードとは、どのような文字コードセットを用いて、それをどのような符号化方式で符号化（ビット化）するのかを定義したものになります。

もっとも、文字コードと符号化方式は同じ名称のことが多く、同じ意味で用いられる場合もあります。したがって、厳密にこれらの用語が使い分けられているわけではありません。

JISコード（ISO-2022-JP）であれば、文字コードセットは「JIS X 0208」などを用い、符号化方式は「ISO-2022-JP」になり、文字コードと同じ名称です。

またASCIIのような単純な文字コードは、文字コードセット（符号化文字集合）で定義された数値（文字と数値を対応させた単純な整数値）を、エンコードの必要もなくそのまま使うことができるので、ASCIIは文字コードセットの意味でも用いられます。

前項で、JISコード（ISO-2022-JP）はこのASCIIと同じコードとして扱えると学習しました。その理由は「エスケープシーケンス 」という切り替えコードを用いて、複数の文字コードセットを切り替えて使用することができるからです。

使用するコードはASCIIと同じです。エスケープシーケンスにより文字コードセットをASCIIと切り替えることで、同じコードでも異なる文字を表現することができ、ASCIIよりも多くの文字を扱えるのです。

エスケープシーケンスは、文字コードセットが変化する位置を示すコードです。例えば「1b 28 42」のようなコードで表され、このコードを使うことで「AAA エスケープシーケンス あああ エスケープシーケンス 亜亜亜」のように、ASCIIと同じコードで日本語を扱うことができるようになっています。

JISコード（ISO-2022-JP）に定義されている文字コードセットには、「ASCII」「JIS X 0208」など複数の種類があります。

2バイト以上を必要とする漢字などの文字コードを「マルチバイトコード」などと言いますが、JISコード（ISO-2022-JP）はエスケープシーケンスによる文字コードセットの切り替えによって、マルチバイト文字を使用することができます。

ここまで理解できると、あとは簡単です。

JISコード（ISO-2022-JP）に定義されていない文字を使用しない

ということが電子メールのマナーになるわけです。

長くなりましたが、

半角カタカナはJISコード（ISO-2022-JP）に定義されていない

ということです。

したがって、JISコード（ISO-2022-JP）で半角カタカナを変換することができません。さらに言うと、半角カタカナを送信することができないということになります。

ひと昔前は、半角カタカナを送信することによってシステムに誤作動を引き起こすこともあったそうです。現在、JISコード（ISO-2022-JP）でエンコードする場合は、メーラーが「全角カタカナ」に自動的に変換します。

機種依存文字との違いは、半角カタカナはJISコード（ISO-2022-JP）に存在しないだけで、他の文字コードには定義されており、機種や環境に依存するわけではありません。あくまでJISコード（ISO-2022-JP）だけの話です。

よって、JISコード（ISO-2022-JP）以外でエンコードすれば使用することができます。Unicodeの「UTF-8」でエンコードする場合は、半角カタカナでも送受信することができます。

現在では、JISコード（ISO-2022-JP）よりもUTF-8が推奨されており、次第にこうした暗黙のルールはなくなっていくものと思われますが、こうした歴史を知っておくことが重要です。

下図はOutlookのエンコード方式の一覧です。前項で学習した「MIMEタイプ」によってメーラーがエンコード方式を選択しています。日本語メールの場合は「日本語(自選選択)」が選択されているケースが多いです。これがJISコードになります。

上図は、任意のメールをダブルクリックして別画面で開き「メッセージ」タブの「アクション」→「その他のアクション」→「エンコード」で確認することができます。Unicodeで送信されたメールは「Unicode(UTF-8)」が選択されています。

文字化けが起こった場合は、このエンコード方式を選択しなおすことで解消できる場合があります。

また、こちらが送信する際のエンコード方式は、デフォルト（初期設定）でJISコードが設定されています。

では、最後に「添付ファイル」のマナーについてです。

添付ファイルもASCIIにエンコードして送信するというのはこれまでの学習のとおりで、テキスト以外のバイナリデータはbase64などのエンコード方式でコード化されます。

よく間違えがちなのが、Wordで作成した文書ファイルも「バイナリファイル」になることです。文字だけのWordファイルでも、実際にはレイアウト情報などのいろいろな情報が含まれているからです。純粋なテキストファイルとしては「メモ帳」というアプリケーションソフトを使って作成したファイルであればテキストファイルになります。

したがって、添付ファイルの容量が大きければ大きいほど、変換するテキストデータの容量は膨大なものになり、処理時間がかかることになります。

そのため、

原則として容量の大きい添付ファイルを送信しない

というのがマナーになります。

これは暗黙のマナーではなく当然のマナーです。添付ファイルを送る場合は、相手の通信環境に配慮することが大切です。

送信相手が光回線等の定額大容量通信であれば問題ありませんが、例えば、モバイルの契約しかしていない場合は、容量の大きいファイルをダウンロードするのにパケット通信料がかかったり、通信量の上限を超えて通信制限がかかってしまうなどの迷惑をかけることにもなりかねません。

どうしてもサイズの大きな添付ファイルを送信する場合には、事前にそのファイルのサイズを相手に伝え、了承を得ておくということも必要になります。

最近では、特に注意しなければならないのが写真を添付する場合です。近年のデジカメやスマートフォンは超高画質で撮影することができるため、1枚の写真が10MB程度になることも珍しくありません。

プロバイダによっては10MB以上の添付ファイルは受信できない場合もある

ので注意してください。

例えば、2枚の写真を添付して送信しても、相手側では1枚しか添付されていなかったり、添付ファイルがすべて削除されてしまうなどのトラブルが起こる可能性があります。基本的には10MBを目安にしましょう。

そして、添付ファイルについてもっとも大切なことは、

添付ファイルのファイル形式（拡張子）に注意する

ということです。

拡張子は、拡張子 で学習のとおり、ファイルの形式を表す文字列です。送ろうとしているファイルが、相手も扱うことができる形式であるのかどうか確認することが必要です。

特殊なソフトウェアで作成したファイルであれば、そのソフトウェアをインストールしていない環境では利用できず、ファイルを送る意味がありません。これも暗黙のマナーではなく当然のマナーになります。

また、送ってはいけないファイル形式もあります。

実行ファイル「.exe」、データベースファイル「.mdb」、バッチファイル「.bat」など

これらは、マルウェア混入の危険性があったりシステムに影響を与える可能性があるファイル形式です。これらは相手の了承を得ていたとしても「そのままの形式」で送信してはいけません。

これらのファイルは「圧縮」 という技術を使って、ファイル形式を変更してから送信する必要があります。（圧縮については、圧縮・解凍とは で詳しく解説しています）

なぜなら、プロバイダやメーラーの設定によってブロックされる設定になっている場合が多いからです。これらのファイルをどうしてもメールに添付する必要がある場合は、相手に了承を得て、圧縮してファイル形式を変更して送信します。

ただし、添付ファイルの圧縮についても近年問題となっていることがあります。

特に日本で流行している手法で、

PPAP（ピーピーエーピー）

と呼ばれる手法です。

PPAPは、パスワード（Password）付きファイルの送付、パスワード（Password）の送付、暗号化（Angouka）、プロトコル（Protocol）の頭文字を取って日本で作られた造語です。

ZIP（ジップ）という圧縮形式で圧縮すると、簡単に解凍パスワードを設定することができます。これを利用して添付ファイルに復号化パスワードを設定するというものです。

添付ファイルはパスワードを入力しないと見ることができません。S/MIME等によって暗号化通信を行うわけではなく、パスワードだけをかけることで一定の機密性を保持した手法になります。

日本社会では、注文書や見積書といった正式な書類はZIPで圧縮されて解凍パスワードが設定された状態でメールに添付されるのが一般化していました。

そして、解凍パスワードは別のメールで送付するのです。つまり、パスワードが設定された添付ファイルを1通目で送付し、そのあとに「先ほどのパスワードは〇〇です」といった内容のメールを2通目に送付するのです。

添付ファイルとパスワードを一緒に送らないことから、一定のセキュリティ対策になると考えられ、現在でもごく一般的に利用されている手法です。

しかし、PPAPはむしろセキュリティ上のリスクが高いことが指摘されています。

基本的に2通とも同じ経路で送信されるため、1通目が盗聴された場合、2通目のパスワードも盗聴されてしまうこと、圧縮ファイルの中身がウイルス対策ソフトで検索できないため、マルウェアが混入される可能性があることです。

特に後者が重大で、PPAPを装った「Emotet(エモテット)」というマルウェアが猛威を振るいました。こうしたことから、2020年11月には、政府がPPAPを廃止する（政府は使用しない）と宣言しました。

代替策としては、ファイルをクラウドストレージにアップロードし、メールにはダウンロード用のURLを記述するなどの方法が利用されています。ただし、こちらもパスワードをどうやって伝達するかという暗号通信と同じ課題に直面しています。

最後に補足として、

送信したメールは取り消すことができない

ということを忘れてはいけません。

大切なメールであればあるほど、何度も確認して送信することが大切です。取り消し機能付きメールのサービスを行うプロバイダもありますが、基本的には取り消すことはできません。

以上で基本的なマナーと書式についての学習は終了です。このほかにも実践的なマナーや注意点はたくさんありますが、メーラーやアプリケーションソフトの操作を伴うので、基本操作 メール編 で詳しく解説しています。

更新履歴

2008年11月24日

ページを公開。

2009年6月11日

ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。

2018年2月1日

ページをSSL化によりHTTPSに対応。

2023年6月13日

内容修正。

参考文献・ウェブサイト

当ページの作成にあたり、以下の文献およびウェブサイトを参考にさせていただきました。

文献

図解入門 インターネットのしくみ

「半角カタカナを入力しないで下さい」は失格？!

http://www.shtml.jp/mojibake/hankaku.html

機種依存文字・フォント依存文字

http://j-union.net/manual/manual_encode.html

• 次ページ：「ウェブページの仕組み（1） ～ HTMLとは ～」へ進む
• 前ページ：「電子メールの拡張規格 ～ MIME・S/MIME ～」へ戻る
• 基礎知識：「メニューページ」へ戻る
• ホームへ戻る

管理人のつぶやき

Twitterのフォローお願いします！