ISO-2022-JP

telnetでメールを送信する方法としてこれまで2つのエントリで方法を紹介してきました。 - [コマンドプロンプトだけでメールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/03/26/%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%81%A0%E3%81%91%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%92%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B/) - [telnetで日本語メールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2012/01/04/telnet%e3%81%a7%e6%97%a5%e6%9c%ac%e8%aa%9e%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%92%e9%80%81%e4%bf%a1%e3%81%99%e3%82%8b/) 前回の方法でとりあえず日本語メールが遅れているのですが、もうちょっときちんとしたヘッダを付けてメールを送信する方法を紹介したいと思います。 まず、SMTPで日本語を(も)取り扱うための規格としてMultipurpose Internet Mail Extensions(MIME)があります。 - [Multipurpose Internet Mail Extensions - Wikipedia](http://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions) これによってUS-ASCII以外の文字や添付ファイルなどが扱えるようになっています。今回はきちんとMIMEを使って日本語メールを送ってみようと思います。 ヘッダとボディ これからMIMEの説明をするにあたっては、まずヘッダとボディをきちんと認識する必要があります。前回送信したメールで説明すると以下のようになります。 dataコマンドでデータを送信することを指定した後でメールのヘッダとボディを連続して書き込んでおり、ヘッダとボディの区切り目は空行によって表現されているわけです。MIMEヘッダの記述はヘッダ部分に行っていきます。 MIME-Version MIMEのバージョンを区別するためのヘッダです。現在1.0しかありませんので必ず以下のような記述になります。 M i m e - V e r s i o n : 1 . 0 Content-Type メッセージ(ボディ部分)の形式を指定するヘッダです。様々なものがありますが、日本語メールを送りたい場合にはここはtext/plainになります。さらにtext/plainの場合にはその文字コードを表すcharsetが追加されます。具体的には以下のような記述になります。 C o n t e n t - T y p e : t e x t / p l a i n ; c h a r s e t = " i s o - 2 0 2 2 - j p " ; ...

telnetでメールを送信する方法について以前紹介しました。 - [コマンドプロンプトだけでメールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/03/26/%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%81%A0%E3%81%91%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%92%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B/) 今回はtelnetから日本語でメールを送信する方法を紹介してみようと思います。もちろん実用性はほぼ無いのですが、メールの仕組みを理解するためには結構良い練習になると思います。是非この記事を見ながら、自分のアドレスにメールを送信してみてください。 (※注意※ 昨今はSPAM対策でプロバイダによってはそもそもSMTPでの接続を許可していないところが多いです。初めのメールサーバーへの接続の段階でうまく接続できなかったら残念ですが、別途勉強のためにSMTPサーバーを立ててそこに対してメールを送信してみるなどしてみてください。) とりあえず日本語で入力してみる まずはtelnetでメールサーバーに接続します。(ここでは私の自宅のメールサーバーに接続しています。) 前回紹介した方法で、メールの送信元、送信先を入力します。 まず、ヘッダ部分を入力します。メールヘッダとメールボディの間には空行が1行必要です。 さて、ここで日本語を入力してみましょう。Alt + 全角半角キーを押して、えいやと。「日本語のテストメールです。」と入力してみます。 おや？なんだか、入力しているそばから文字が化けていきますね…。 とりあえず送信を完了します。送信の最後は「.」です。「改行.改行」ですね。 さて、とりあえずメールは送ってみました。どうなったでしょうか?着信したメールをgmailで確認してみます。 おお！文字化けせずにきちんと日本語が見えますね。本当は記事を書く前にはここでは文字化けすることを想定していたのですが、Windows7からgmailへの送信では化けませんでした。gmailは優秀ですね！ gmailでは化けませんでしたが、結構な数のメールシステムではこの送信方法では文字化けが発生すると思います。自分のシステムで試してみてください。 到着したメールのチェック せっかく文字化けせず送信できましたので、中身をもうちょっと見てみましょう。gmailではメッセージのソースを見ることができます。ソースを見てみましょう。 ソースの状態でもきちんと日本語が見えてますね。それではこの状態でエンコードを確認してみます。 ちょっと見づらいですが、Shift-JISになっていることがわかると思います。これで確認できましたが、先ほどは日本語をShift-JISで送信したのでした。そして、メール本文をShift-JISで記述してそのまま送信するのはRFC違反であり、文字化けする可能性が結構高くなってしまいます。 日本語をメールで送信する際には文字コードにJIS(ISO-2022-JP)を使用するのがお約束になっており、これであればまず文字化けしません。なので、telnetから日本語メールを送信する場合もJISで送信すべきです。(このあたりの細かい話はまた別エントリで…) telnetのcodesetを設定する さて、それでは今度はきちんとtelnetの設定をおこなって、RFC的に正しいメールを送信してみましょう。 まず、telnetを起動します。引数無しでtelnetだけですね。 まず、現在の設定を確認してみます。displayコマンドを入力します。 codeset = 漢字コードセット は設定されていない状態になっています。helpを表示するとset codesetコマンドで漢字コードセットの設定ができることがわかりますので、JIS Kanjiに設定しましょう。 この漢字コードセットの設定は保存されますので、一度telnetを終了しても再度設定する必要はありません。さて、それではこの状態でもう一度メールを送ってみましょう。openコマンドで接続を開始できます。 今度は telnet上でも日本語がきちんと見えるようになりましたね。(※ただ、終端の改行.改行が意図したとおりになりませんでした。これは私も原因がよくわからない…というか.になってないからなのは確実なのですが、ちょっと変な挙動のように思います。telnetのバグ?) とりあえずgmail側で確認してみましょう。 今度もきちんと日本語が表示されました。ソース、文字コードも確認しましょう。 ソース上では日本語がそのままは読めません。エンコードはShift-JISになっています。これを「日本語(ISO-2022-JP)」に変更します。 きちんと日本語が読めるようになりました。これできちんとJISで送信できていたことが確認できました。この形式であればほぼ間違いなく、すべての日本語メール環境でメールが読めるはずです。 細かいところはひとまずおいておきましょう。メールでは日本語はJIS(ISO-2022-JP)で送るという事をまずは抑えておいてもらえればと思います。

コンピューターの世界で文字がどのように扱われているかということを理解するには「符号化文字集合」と「文字符号化方式」という2つの異なる概念があり、それぞれがどのようなものであるかを理解することが非常に重要です。これを理解しているかいないかでコンピューターの世界での文字の扱いに関する理解がまったく違ってきますのでぜひ抑えておきましょう。 符号化文字集合 まず符号化文字集合というのは「どのような文字を扱うか」ということを定義するものです。文字といってもアルファベット、ひらがな、カタカナ、数字、記号はもとより日本語には非常に多くの漢字が存在しています。さらに世界に目を向ければいったいどれだけの数の文字が存在しているのでしょうか? ちょっと検索してみると以下のようなサイトが見つかりました。 世界の文字　Written characters of the world ちょっと見てみてほしいのですが、ものすごい数の文字が世の中には存在しています。コンピューターは今でこそ高性能になり、世界中のありとあらゆる文字を使えるようにしてしまおうという構想が現実的に実装できるようになっていますが、歴史的にはごく限られたリソースの中で何とかやりくりをしていた時代の方が長いわけです。そうするとその中では「どの文字を使えるようにするか」ということが非常に重要です。 あなたがコンピューターを「限られたリソースの中で」新しく設計するとしたら、どのような文字を使えるようにしたいと思いますか? リソースには限りがあるので、極力少ない文字の種類で済ませたい かといって通常使う用途に不便するようでは使ってもらえないので必要十分な文字の種類は扱えるようにしたい 世の中に存在しているほかのコンピューターとデータをやり取りできないようでは使い物にならないので、他のコンピューターで使える文字はある程度使えるようにしないといけない このくらいのことはまず考えないといけません。このように考えてみるとどのような文字をコンピューターが扱えるべきなのかという規格があり、世の中に存在するコンピューターがみんなその規格にしたがっていればみんなが幸せになれるはずです。 符号化文字集合の具体例 このような符号化文字集合を定めた規格が複数存在しています。ここでは日本語に深いかかわりを持つもので代表的なもののみを紹介します。 ASCII - Wikipedia JIS X 0201 - Wikipedia JIS X 0208 - Wikipedia 補助漢字 - Wikipedia JIS X 0213 - Wikipedia Unicode - Wikipedia Wikipediaの説明を読むといきなり難しいことが沢山書いてあって混乱するかもしれませんが、まずは「色々あるんだな」くらいに考えておいてもらっていいでしょう。私が考えるポイントは以下です。 アルファベット圏ではアルファベットだけあれば事足りるので、それが定義されているASCIIが主に使われている。 日本語はアルファベットだけでは全然たりないので、ひらがな、カタカナに加えて日常よく使う漢字がまず必要。現在のコンピューターで普通に使える漢字はJIS X 0208で定義されている。 最近のコンピューターではさらに多くの漢字が使えるようにしようという動きがあり、最新のコンピューターではJIS X 0213で定義されている文字(JIS X 0208よりも多くの文字が定義されている)が使えるようになってきた。ただしまだ使えないコンピューターも多くあり、互換性に問題がある。 文字符号化集合が複数あるから互換性の問題が起きるのであって、「世界中の文字を集めた符号化文字集合がひとつあって、それを全てのコンピューターが使えば問題はなくなる」という考えで世界中の文字を集めているのがUnicode。普及はそれなりに進んできたが使えない環境もまだある。 文字符号化方式 コンピューター上では最終的には全てが0と1のデジタルで表現されます。もちろん文字もそうです。ですので符号化文字集合だけがあっても実際にそれをコンピューター上ではどのような0,1の並びで表現するのか、ということが決まっていないとコンピューターでは扱えません。その0,1の並びを定義しているのが文字符号化方式です。 符号化文字集合は複数ありますが、そのそれぞれの集合ごとに1つの文字符号化方式がある･･･というわけではありません。実際にはひとつの文字符号化方式で複数の符号化文字集合を対象にしていますし、ひとつの符号化文字集合に対して複数の文字符号化方式が存在しています。 なぜこのように複雑な関係になっているのかというと、結局それは、「同じ問題でも解き方は複数ある」からだと私は思っています。そしてどれが一番良いのかは「何を目的とするか」によっても変わってきます。 たとえば、アルファベットだけで完結することのできる文化圏の人がいます。そして、アルファベットは文字数が少ないので7ビットもあれば全ての文字を表現できてしまいます。コンピューターにとってきりのいいところで8ビットもあれば十分です。一方私たち日本人はひらがなもカタカナも漢字もありますので8ビットではまったく足りません。このときある人は「8ビットで足りないなら、全ての文字を8ビットを2つくっつけて16ビットで1文字にしよう」と考え、あるひとは「8ビットで足りないなら1文字8ビットのルールは変えないで、使う文字集合を切り替える仕組みを作ろう」と考えたとします。(仮に、です。) これはどちらもコンピューターにルールを教えてあげれば(プログラムをつくれば)コンピュータ上で実現できます。どちらが完全に優れているということもありません。一長一短があります。たとえば16ビットで1文字にすれば「切り替え」を意識しなくてよいので文字の検索などが簡単に実装できます。ですが、16ビットで1文字にしてしまうと1文字8ビットで済む文字にも16ビット使ってしまうので、仮にアルファベットしか使わない文章を書いたとしたら容量が2倍になってしまいます。 この例は解説のために簡略化してあくまでも例として出していますが、実際の文字符号化方式においてもこのようにトレードオフがあり、複数の方式が混在しているのです。 文字符号化方式の具体例 文字符号化方式の具体例としては以下のようなものがあります。 ISO-2022-JP - Wikipedia EUC-JP - Wikipedia Shift_JIS - Wikipedia Microsoftコードページ932 - Wikipedia UTF-8 - Wikipedia UTF-16 - Wikipedia UTF-32 - Wikipedia 沢山あっていきなりだと混乱すると思いますが、まずは以下のような理解をしておくと良いと思います。 ...