文字コード

2022.1.22
メールの文字コードについて、また頭が混乱してきたので、再度勉強した。もともとインターネットメールは英米圏で開発されたシステムなので、 ASCIIコードが前提とされてきた。これは英数字と他の記号や改行等を7bit（128種類の記号）で表現している。テキストで指し示す時にはいちいちビットを並べる代わりに、4bit単位に ASCIIコードとみなして、２つ並べて示すのが一般的である。例えば、1111 は F、0000は 0 という風に。コンピュータはバイト（8bit）単位で情報を扱うから、8bitとしてメールも扱えばよかったのだが、必要がなかったので、今でも標準は 7bit である。最近 8bitMIMEの規格ができたので、これから徐々に拡がっていくだろうが、今は過渡期である。

・・・文字コードとして、英米では ASCII で十分なのであるが、ヨーロッパの国々の文字体系は 7bitでは収まらないのが多いため、ISO-8859-1（Latin1）という 8bitへの拡張文字コードが一般的である。日本では、マイクロソフトの開発した Shift-JIS が一般的である。ASCIIコードに追加して16bitの漢字類コードも併用している。日本語環境で Windows 版 R をインストールすると、このコードが標準になる。
しかし、パソコンが世界中で使われるようになって、どんな国の文字も表現できるコード体系が必要になり、Unicode が規格化された。ただ、これは文字に番号を割り当てただけなので、これを bit列として変換する必要がある。そのやり方にはいくつもあって、代表的なのが UTF-8である。文字に応じてバイト数が異なる。これには２種類あって、BOM 付きとBOM 無しである。BOMはファイルの先頭に付く３バイトの文字コード判別記号である。BOM 付きはマイクロソフトが Shift-JIS との区別を容易にするために好んで使っていて、しばしば文字化けの原因となるので、BOM 無しが望ましい。UTF-8 は 8bit単位で符号化されているので、これを 7bit 単位に符号化して、メールとの整合性を図ったのが UTF-7である。他にも UTF-16 とかがある。これらはあまり使われていない。

・・・Ascii コード以外は 7bit体系のメールシステムで直接送ることができない。
日本語に対しては、ASCIIコードをそのまま使いながら、特別な escape sequence コードを追加し、そのコードが出てきた後は同じコードであっても２つ組み合わせて、これを漢字類に対応させる、という方式が編み出された。これが ISO-2022-JP （いわゆる JISコード）である。これを使えば、7bit体系のメールをそのまま使うことが出来るのである。日本語メールで使われるコードの標準となっている。 JIS コードでは、Windows PC で標準となっている Shift-JISとは異なり、とりわけ半角カタカナが定義されていないので、注意が必要である。
・・メールソフトでソース表示をすると、下記のように表示されているのが一般的である。
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
・・２行目は元々の文字コード（ここでは iso-2022-jp）を 7bit のASCIIコードに変換する方式のことである。7bit というのは、つまり無変換という意味である。無変換だからといって、ASCIIコードとして、つまり英数字としてソースが表示されるわけではない。これはメールソフトなりテキストエディターなりが解釈して日本語文字を表示してくれるからである。binary editor で開けば、直接の ASCIIコードが判る。

・・・ISO-8859-1（Latin1）とか、UTF-8 の場合は、8bit単位であるから、これを 7bit 単位に変換しなくてはならない。当然ながらファイルサイズはやや大きくなる。この時の変換規則（エンコード規則）の代表的なものが、「Base64」や「Quoted-Printable」である。（なお、画像等の添付バイナリーファイルも Content-Type が変わるだけで、同様。）
・・"quoted-printable" というのは、Latin1 の為に作られた規則で、=以外の英数字ASCIIはそのままであるが、それ以外の文字に対しては、8bit を２つの英数字0-9,A-Fの組み合わせで表現して、=という字に続けて入れる。この場合は、8bit が 24bit に変換されるから効率が悪いのだが、大部分が ASCII文字であれば、大したサイズにはならないし、ASCII文字の部分はそのまま読める。
・・"base64" というのは、文字列全体をビット表現（2進数）にしてしまい、6bit づつ変換表に従って ASCII文字に変換する。2^6=64個のASCII文字が必要である。文字列全体のビット数が6の倍数でない処には 0 を入れる。これを 4ASCII文字単位でまとめて、足りない部分は = を追加する。
例えば、同じく ISO-2022-JP であっても、下記のような例がある。
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: base64
こうすると、もはやエンコード結果を直接 JIS コードとは解釈できない為に、日本語であっても、ASCII文字が直接表示される。

下記の場合は UTF-8 コードなので、「Quoted-Printable」方式で 7bit にエンコードされている。
Content-Type: text/html; charset=UTF-8
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

・・・ところが、今回同じメール（medRxivからのメール）でありながら、メールソフトの新しいバージョンで、以下のようなソースファイルとなった。（このこと自身が奇妙である。）multipart/mixed というのは本文以外に添付ファイルがエンコードされて引き続くという意味である。その境界線が boundary で示された記号で示される。それ以降は添付ファイルであることを示す。添付ファイルの部分については ISO-8859-1コードであり、エンコードされていないで、直接 html 文に入っている。しかし、8bit目で区別すべきヨーロッパ独自の文字が使われていないので、このまま読めるということだろうか？こんなことが規格で許されているのだろうか？
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="_HW_159494360548245088_"
...メールの伝送経路情報...
--_HW_159494360548245088_
Content-Type: text/html; charset=ISO-8859-1

・・・最近になってしばらくのあいだであるが、JISコードではなくて、UTF-8でメールを送信していた時期がある。そうすると以下のようになる。つまり、実際には 8bit 単位でエンコードされることなくメールシステムが動いているということである。どうも Gmail の場合などがそうなっているらしいが、Asahi-net のWebmailシステムなどは歴史が古いので、この 8bit 表現には対応していない。つまり Web上で読むと文字化けしてしまう。サーバー自身は対応しているので、メールは pop3 で手元の PCのメールソフトに取り込んでから読むことになる。
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

・・・メールについてはまだよく判らない処がある。。。
その後勉強すると、メールが転送されるとき、転送先の用意したプログラムで読めるように、転送する側が形式を変換するということである。現在では 8bitMIME に対応した Extended SMTP がかなり普及しているが、対応していないメール受信者があるときには、8bitMIME をデコードして 7bit で解釈できるように変換して送るらしい。今回は PC の変更に伴って POP3メールソフトをバージョンアップしたので、メールサーバー側が形式を変えたということのようである。ただ、古いバージョンでも他の 8bitMIME はそのまま受け取っているので、古いバージョンが 8bitMIME非対応ということではない。ISO-8859-1に対応していなかった、ということも考えられない。結局よく判らないままである。
・・8bitMIMEであるが、Wikidipedia から引用すると、『行は<CRLF>で1000オクテットを超えないように区切られ、ドットのみの行でDATAの終わりを示す点は変わらないため、バイナリの配送を可能にするものではなく、8ビット文字コードを意図したものである。』つまり、バイナリーファイルはエンコードされる。その場合は ASCIIコードへとエンコードされることになるのだろう。

＜目次へ＞＜一つ前へ＞＜次へ＞