[ Return ]

文字化け例とMBaker2をつかった解読方法
V0.93 June.6.2000
まだ作成中ですがとりあえず版ということで公開いたします。
このページでは私が実際に経験したものや、電子メール等で紹介してもらった文字化けを分類して、MBaker2でどこまで解読できるのかを説明したいと思います。
初心者の方を対象にしていますので、必要以上に複雑にさせないために規格書のように100%網羅した説明にはなっておりません。
これ以上の情報が必要な方は、文字化けについてほかにも同じような趣旨のページを書かれておられる方がおみえですので、参照ください。
（なるべく簡単な言葉で表現しようとしておりますが、「わかりにくい」「使用単語が不適当」等ございましたらご指摘ください。）
本ページ内の文字化け例は、実際に有りました文字化けをシミュレートしたものです。使用した文章はすべて私の創作です。
言葉の説明
本題に入る前に言葉の説明をさせてください。できる限り、わかりやすい言葉を使いたいのですが以下の単語は使いたいのでどうかご容赦お願します。
メーラー 電子メールを送受信したり画面に表示したりするソフトです。
例えば アウトルック とか ユードラ とかいろいろあります。
ビット １ビットは「オン」と「オフ」の状態のみもてるデジタル情報の最小単位です。
これを集めてたくさんの情報を表現できます。
バイト 8ビットを一まとめにしたものです。256通りの状態を表現できます。
電子メールで英文をやり取りする時の１文字は１バイトになります。
しかし、過去からのしがらみ(*1)で８ビットのうち７ビット分のみ使用する事が取り決められています。
ということで電子メールでは１文字1バイトといっても256の半分の128通りの状態しか使いません。
でもこれだけあれば、数字、アルファベットの大文字小文字、何種類かの記号、といった表示できる文字（95個）と
「行送り」などを表わす制御用のコード（33個）を表現する事ができます。
日本のプロバイダでは8ビット全て通すようになっているところがほとんどだと思いますが、
確認したわけでは有りません。
２バイト文字 日本語の文字（特に漢字）を表現する場合、6000文字以上の漢字を表現できなければ行けません。
ところが1バイトでは6000もの文字を表現できないので２バイトでこれを表現しています。
当然この２バイトは隣同士にいなければいけません。
全角
と
半角		 ２バイト文字で漢字が扱えるようになったのは良いのですが、 日本語の文字の中にも1バイトの文字を使いたいので、２バイト文字の置き方を工夫して、 両方の文字が混在してもこんがらがらないような規格を定義しています。
俗称として、２バイト文字を「全角」１バイト文字を「半角」と呼ぶ事が多いようです。
（ワープロに「全角」「半角」ボタンがあったのを思い出した人もいるでしょうね）
数字やアルファベットは２バイト文字にもあるので、
２バイト文字の １２３４５ＡＢＣ と
１バイト文字の 123456ABC とを日本人は使い分けているわけですね。
そして、英語（１バイト文字）で書かれたメールが送られてきても読む事が出来るわけです。
本来は印刷に使う活字の大きさから来ている言葉らしいのですが、コンピュータ上でも便利な言葉として 使われています。本ページでも使っています。
ＪＩＳコード 日本語の文字をいかに２バイトで表現するかを決めています。
過去からのしがらみに対応していて、２バイトの両方のバイトは７ビットづつしか使っていません。
電子メールでやり取りされる漢字情報は主にこのコードを使っています。
このＪＩＳコードというのも実はあいまいな言葉で複数の規格の総称になるのでしょう。
「ISO-2022-JP」が代表となる規格名だと思います。
シフトＪＩＳ 日本語の文字で２バイトで表現するための別の方法です。
Windowsは従来からこの方式を日本語文字列の格納用に使っていました。
8ビット全部を使って効率よくデータを扱えるようにしました。 したがって、このコードを使って電子メールとしてPCから送り出すと、中継システムが上手く中継できない場合があり文字化けになります。
このため、通常Windowsのメールソフトの場合、プログラムの中でシフトＪＩＳからＪＩＳコードへの変換が自動的に行われます。
ＥＵＣ 日本語の文字で２バイトで表現するための別の方法です。
このコードにて日本語文字列を格納しているコンピュータが有ります。
これも８ビット全部使っています。
ユニコード
(UNICODE)		 これは全世界の文字を表現しようとしているコード体系です。
このコード体系の中に日本の漢字も含まれています。
エスケープシーケンス ＪＩＳコードで半角と全角が混在する場合に互いの切り替わるところで、「ここから全角」「ここから半角」 という意味の特別なコードを挟みます。このコードは３バイト程度のもので「ここから中国語」といったようなものも表現するため、たくさんの種類が 有りますが、これをエスケープシーケンスと呼びます。日本語のメールに限ってしまえば多くありません。 詳しくは漢字コードの話（配島誠様作成）を参照してください。 先頭の1バイトがESCという制御用のコード（33個の中の一つ）なのでこのように呼ばれているようです。 シフトJISとEUCは半角で使用していない8ビット目を使っているのでエスケープシーケンスは必要ありません。
ＭＩＭＥ 「マイム」と読みます。電子メールの中に画像だとか、MP3だとかを添付する方法の一つです。
表示可能な文字（95個）だけを使って画像等のファイルを表現します。（したがってもとのデータサイズよりも長くなります）
最近のメーラーは確実に対応しているので送る時もMIME指定を「オン」にした方が良いでしょう。
あまり文字化けがひどいのなら、日本語のテキストファイルを添付して送るというのも手です。
ＵＴＦ－８ ＵＴＦ－７ ユニコードと半角の混在ができるようにする方法の一つです。
ＵＴＦ－８はユニコードの部分を表わすために１バイトの８ビット目を使用しているためメールにこれを用いるのは適当ではありません。
しかし、マイクロソフトのアウトルックエクスプレスではUTF-8のフォーマットでメールが送出できるため、 文字化けメールが発生する理由の一つにもなっています。
ＵＴＦ－７は１バイトの８ビット目を使用しないようにしていますので、原理的に文字化けは起きないとおもわれますが、これに対応していないメイラにこの形式で送り付けると、受け側は文字化けになってしまいます。
漢字コードにはユニコードを使うので人気がなくマイナーな存在になっています。
半角のカナ ８ビットで表現できる256文字のうち、128文字しか使わないと書きましたが、JISの８ビットのコード体系では、残りの128文字を使って主にカタカナを定義しています。Windowsでも使用可能です。
この部分、ヨーロッパなどでは、最初の128文字にない、ウムラウトの付いた文字など各国独自の文字を定義しています。
Ｂａｓｅ６４ ＭＩＭＥで採用されました、バイナリの情報をメールに載せる時に使用されるコード変換方式です。
日本語をメールのタイトルに使った場合、漢字の部分がこのＢａｓｅ６４という形に変換されてしまう場合が有ります。

上記の言葉の説明を読んだだけで、なぜ文字化けが発生するのかわかってくる気がしませんか？
漢字を表わす方式が複数あって、送り側のＰＣの内部で使う漢字コード、電子メールとして送られている途中の漢字コード、受け側のＰＣが使っている漢字コード、これらがすべて異なる場合があるのです。ほかにも有ります。(*2)
正しく処理されているうちはよいのですが、いろいろな原因で上手くいかなくなると文字化けになってしまうのですね。
原因としては以下のように分類できるでしょう。

1、送り側のメーラーの設定が適当でない場合
マイクロソフトのアウトルックエクスプレスは設定の複雑さで良くやり玉に上がっていますね。
それだけ機能も多いのですが・・・
あと、日本語のＷｉｎｄｏｗｓに英語版のソフトをインストールすると、出来の悪いインストーラであった場合に、日本語版プログラムを英語版に置き換えてしまう事が有ります。
メーラーそのものはちゃんと動いているのに、日本語を上手く扱えなくなってしまう事が有りますので、気を付けましょう。
2、電子メールを仲介するメールシステムに問題がある場合
電子メールが受け側のPCに届くまでにたくさんのコンピュータを経てきます。しかしながら、過去のしがらみを非常に多く背負っているメールシステムでは、 エスケープシーケンスでさえも通してくれません。先頭のESCが特殊な制御文字である事が原因で、この文字を何か別の表示できるコードに変換（または削除）してしまうメールシステム が有ります。当然、受け側のPCではこれを処理できずにどこから漢字が始まるのかがわからなくなってしまい、結局文字化けになります。
日本国内部でメールをやりとりしている場合にはこんなメールシステムに出くわす事はないと思いますが、海外にお住まいの日本人の方は多かれ少なかれ 経験しているのではないでしょうか？
「MIME」の説明のところにも書きましたが、ESCも通らないようなひどい中継システムを頻繁に使ってしまうところにお住まいの方は、日本語のテキストファイルをメールに添付して 送ればひとまず意志の疎通は出来るようになります。
たまに発生するような時のために MBaker2 の存在理由が有ると思います。
脚注の中継システムでのメイルの変換の例(*3)を参照してください。
3、受け側のメーラーの設定が適当でない場合
最近、Web上でメールが見られるサービスが出来てきています。この場合、そのサービスをアメリカの会社が供給している場合に、いくら日本語のブラウザを使ってもうまく日本語のメールを表示できない場合が有ります。
サービス供給会社側が日本語対応になることにより日本語を正しく表示出来るようになるわけですが、そうなるまでいろいろ手数をかけてしまう事になります。

文字化け例とその対処法
さて、これより、実際に文字化けの例を示しながら、MBaker2 での対応方法とMBaker2 の限界に付いても説明しようと思います。

(1) JISコードの文字化け
エスケープシーケンスの先頭のESCが置き換わってしまう場合も何種類かのバリエーションが有ります。
例えば
ESC_$B$,%"%s%@!<%P!<$K$J$C$F$7$^$C$?Nc$G$9!#_(B
ESC=1B$B$,=1B(B==1B$B$H=1B(B16=1B$B?J%3!<%I$K$J$C$F$7$^$C$?Nc$G$9=1B(B 
 $B:G6a%Q%=%3%s$ND4;R$,0-$/$9$0J8;z2=$1$7$F$7$^$C$G$9 (B

上記の３例は MBaker2 の Auto で解読できます。実際何が書かれているのかは MBaker2でためしてみてください。
MBaker2で解読させるためには、マウスで該当部分をドラッグ（マウスの左ボタンを押したままマウスで該当文字上を滑らせます） して文字列を反転させた後に、コントロールキーと'C'キーを 同時に押します。これでクリップボードに反転部分の文字がコピーされました。 この後で、MBaker2 を立ち上げるか、既に立ち上げてある場合には、 Auto ボタンを押します。
JISコードをそのまま半角の文字として読むと「$」とか「%」とかが一つおきに出てくるのが特徴です。
（３つめの例は先頭にスペースが有ります。これも含めてクリップボードにコピーしてください。）

ほかには、メーラーかまたは中継システムのどこかで、1行の長さが設定を超えたため、改行を自動的にいれてしまうものが有ります。
そのシステムが漢字コードや、エスケープシーケンスの途中に改行コードを入れてしまった場合、もはや普通には解読できない メールになってしまいます。（どこから漢字が始まるか等の情報が受信側でわからなくなってしまうからです。）
行の長さが設定を超えたため、 _$
B2~9T$r<+F0E*$K$$$l$F$7$^$&$b$N$,M-$j$^$9!#

このような場合に対応するために MBakerでは JIS1 ボタンと JIS2 ボタンを用意しています。 どちらが上手く動くかは、文字化けのなり方によって異なります。 上記の例だと、２行目のみをクリップボードに入れた場合、JIS1では解読できずにJIS2で解読できます。 （Auto では、できるかぎり分断されたエスケープシーケンスも探すようにしていますので、上記の例では、２行ともクリップボードにコピーしてAuto ボタンで解読することができます。）
このように、JIS2は部分的に漢字コードがずれてしまった文字列を解読するために使います。

(2) EUCコードの文字化け
送信側の都合で何故かEUCコードのままメールが送出されてしまった場合に文字化けしてしまう事が有ります。
この場合、漢字を半角のカタカナとして表示されてしまいます。
こうやって半角のカナに化けてしまった文字列をほかの人に転送すると。最近のメーラー半角のカナを全角のカナに自動変換して送る事ができます。
」ナ」ユ」テ、ヌ、ホハクサ嵂ス、アホ网ヌ、キ、ソ。」

上記の例はそんな文字化けの例です。これもなんて書いてあるかは、実際にMBaker2を使って解読してみてください。（EUC1かEUC2のどちらかを使う事になります。)
EUC1ボタンは、いろいろ補正する処理が入っています。EUC2ボタンは単純に変換のみを行っています。

(3) シフトJISの文字化け
これも何かの都合でシフトJISコードのままでメールが送出されてしまうのですが、こうなった場合に中継システムの処理の方法がいろいろ有って 文字化けの仕方にいろいろなものが出てきます。
その中のいくつかは、最近のメーラーでは自動的に認識して文字化けにならないものが有るようです。
文字化けの例としては
=8D=C5=8B=DF=83=70=83=5C=83=52=83=93=82=CC=92=B2=8E=71=82=AA

この文字化けは、MBaker2 で自動解読できます。

次の例は、MBaker2 自動解読はできないのですが、Auto とAuto2 のボタンを押し分けて、読めるほうで呼んでいくというという使い方になります。（いわゆる「MSB落ち」と呼ばれる文字化けです。）
=0B=43=0F=5B=12=21=02=4D=02=53=13=7A=0C=5F=0C=63=02=4F=0E=1E=02=53=02=4F=15=2A=01=41=13=0C=0B=1E

この文字化け例は シフトＪＩＳの８ビット目が無くなってしまった例です。８ビット目が「オン」か「オフ」だったかは受け取った側では、もはや知る手段が有りません。難しい文字化けの一種です。

(4) HTML形式の文字化け
無料でアカウントが取得できるため、最近増えていますWebで送信受信するタイプのメールシステムが有ります。
中には日本語に全く対応しておらず、文字化けメール製造機になっているところも有るようです。 どうしてこうなってしまうかというとＪＩＳ漢字コードで漢字文字列を１バイトの文字列としてみた場合に、ＨＴＭＬで特別視される文字が含まれる場合が有るからです。
結構たくさん有るのですが、例えば、「<」。これは、HTMLでブラウザに対しこれから制御用の情報が始まりますよという意味で使われます。
これがＪＩＳコードの中に登場するため、うまく処理ができないわけです。
ほかにも有るのですが、例としては以下のようです。 
お問い合わせの件、錫鮠
弊μ垰劼砲導稜Гい燭靴泙靴燭箸海蹇"

クリップボードにコピー後 HTMLボタン を押してください。
ＨＴＭＬ型の文字化けは、ＨＴＭＬの使い方がＷｅｂのメールシステムによって異なるので、MBaker2 ですべてに対応するのは難しいと思います。
いまのところは見付次第対応しているというのが現状です。 ＨＴＭＬ型の文字化けかどうかを判断する方法は、MBaker2で追加しましたToolsメニューの シフトＪＩＳからＪＩＳへの変換機能を使うのが有効です。
これで、ＪＩＳコードをそのまま見れますので、この中に例えば「<br>」といったＨＴＭＬ特有の文字列が出てきたらそうでしょう。
日本語に対応したWebメールでしたらこういうことは有りません。

(5) Base64形式の文字化け
メールのタイトルが文字化けしている場合が有ります。
例えば、
=?iso-2022-jp?B?kcWCv4/jgrCCzJP6kvaCxo/qj4qCyYLCgqKCxA0K?=

また、本文も以下のようになってしまっている場合が有ります。
kcWCv4/jgrCCzJP6kvaCxo/qj4qCyYLCgqKCxJhBl42CooK9grWC3IK3gUINCpeIj1SCzIvgl2qT
+oJVjp6CqYLngUGDXoNDg2iDboNFg1gNCoy7km6PV42HgsWCt4FCDQqXv5edgs2Kso6WiOqUQ4LG
gqKCpI6WgsWBQYLHgqSCtYLEguCK85ZdgswNCoKggumCqYK9gs2BQZFPguCCwYLEirKOloLJiOqV
8YKtgr6Cs4KigUINCoKxgrGCzYFBg3KBW4OLgsWXTJa8gsWCt4LMgsWBQYNtg5ODeINGgsyV+4LN
DQqCsor6kdKCrYK+grOCooFCDQo

MBaker2 は上記の２つともに Auto で解読可能です。
?iso-2022-jp という部分もすべてクリップボードに入れてください。
手動で明示的に処理させるため Base64ボタン を用意してあります。2つめの例は Base64ボタン でも解読できます。

(6) MBaker2で解読できない文字化け －１
MBaker2で解読できない文字化けを紹介します。 どこかが上手くデータを処理できずに、すべての文字が ? に変化してしまったような文字化けが有ります。
?????? ? ????????
??????????????????????????
?????????????
??????????????????????

??

最後の ?? は多分 「以上」とか「敬具」 とかが化けてしまったのでしょうね、でもこれでは全く解読する事ができません。

(7) MBaker2で解読できない文字化け －２
次に、その後 のところでも書きましたが、 まず、送り側のPCがシフトＪＩＳ でメールを送り出してしまい、
ある中継メールシステムで、８ビット目が削除されてしまい
つぎの中継メールシステムで、制御文字がすべて削除されてしまた状態で
受信側のPCにたどり着くと、情報量が約半分になってしまう文字化けをいただいた事が有りました。
これではMBaker2でも解読できません。

ほかにも「解読できない」ということで、使っていただいた方よりメールをいただく事が有るのですが、
それを例としてこのページに載せてしまうと、将来解読できる様になってしまうかもしれませんので、
ここには載せる事ができません。ご了承ください。
終わりに
なるべくわかりやすさを主眼において書いてみました。 まだ、とりあえず版ですので、今後少しづつでも文字化け例を充実させていこうと思います。 MBaker2でできる事がわかっていただければ幸いです。

脚注

「過去からのしがらみ(*1)」について
この部分どのように書いたら一番わかりやすいかと思ってこう書いてみました。（少し過激かな？）
でも、いま新しくこの部分のソフトを作り直すことになったのなら、確実に8ビット全て通すようにするでしょうから。
MicrosoftのOutlookExpressのように、8ビットを全部使用したコード体系で日本語メールを送出できるソフトも有ります。 このことはほかのホームページでも批判の対象にしています。困るのは文字化けメール製造機からのメールをもらった人です。 情報の欠落してしまったメッセージは100%復元する事はできません。 では、iso-2022-jp に準拠したメールを送出して文字化けがでないかというと、これもだめで、ESCシーケンスの先頭にある ESCコードを通さないメールの中継システムが有るからです。（削除したりスペースに置き換えたりしてしまいます。）
メールを出す時に、どの中継システムを通すか指定しなくても良いのがインターネットの利点のひとつでしょうから、 特定の中継システムを通らないように指定する事はできません。
日本語は世界に対してマイナーな存在にすぎないのでしょうね。

「ほかにもあります。(*2)」について
コード体系としては、EBCDIKが良い例でしょう。メインフレームに使われていたコードにかな文字を追加したものです。
漢字の拡張として KEIS コードというのが有ります。（EBCDIK KEIS で検索をかければ何か引っかかるはずです。）


「中継システムでのメイルの変換の例(*3)」について
この例は私が経験した中継システムがメールを変換した例です。ですから良い例ではないのですが、雰囲気がわかっていただければ良いと思います。 ジオシティーズは、メールのアカウントももらえますが、そこにUTF-8フォーマットでメールを送り込むと以下のようなヘッダになります。
Message-ID: <xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: <belden@geocities.co.jp>
To: <belden@geocities.co.jp>
Subject: =?utf-8?B?44OG44K544OI6YCB5L+h77y177y077ym77yN77yY?=
Date: xxx, x xxx 1999 06:07:03 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Priority: 3
X-MSMail-Priority: Normal
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by xxxx.geocities.co.jp id xxxxxx

44GT44KM44Gv44OG44K544OI44Gn44GZ44CCDQpUaGlzIGlzIGEgdGVzdCBtYWlsLg0KDQoNCg0K

つまり、ジオシティーズのメイルシステムはUTF-8で来たメイルが８ビット全て使っていると正しく判断し、メッセージ全体を Base64に変換しています。 「Base64にしてしまえば７ビットしか使わないので大丈夫さ」とジオシティーズのメールシステムは思った事でしょう。 Outlook Express V5 はこうなったメールも正しく画面に表示する事ができます。 あと、まだMBaker2 V2.0.0 が不完全で申訳有りませんが、（V2.0.3では対応しました。）
Subjectの「?utf-8?B?44OG44K544OI6YCB5L+h77y177y077ym77yN77yY?=」の部分はAutoで解読できません。
中身をまず、Base64で解読してから、CopyAllしてさらに UTF-8 ボタンを押さなければいけません。
次のバージョンアップで対応しようと思います。（UTF-8を使う事は相当まれな事だと思います。必要な方がございましたら メールください。早急に対応します。）