前 6 - 07 p ｜ 
もくじ i ｜ 次 6 - 09 n 
このメモでは、日本語Windows環境において、「中国語、ロシア語圏などのFTPやIRCに入ったがメッセージが文字化けして読めない」「そういう言語圏のソフトのメニューや説明書が文字化けして読めない」「韓国語メールを受信したが文字化けしていて読めない」「フィンランド語圏のウェブメールで日本語メールを受信したが文字化けして読めない」といった種類のさまざまな問題をすばやくその場で解決するための一般的な方法を説明します。えられた中国語、韓国語、ロシア語の文章を自動翻訳によって意味まで理解するところまで説明します。
例えば、
ｽﾐｿ鬢JｧAｦb Yahoo! GeoCities ｪｺｷ|ｭ﨣KｽX
などと表示されるはずです。このような半角カタカナと変な漢字が混ざったテキストは、非日本語環境のものを日本語環境で解釈したときにみられる典型的なものです。ふつうのユーザは「文字化けして読めない」とここで引き上げあるかもしれません。人間の世界で妖精の行動がめちゃくちゃで意味不明に見え「あいつは電波だから一般人には理解できない」と見捨てられるように……。実際には相手が使ってるエンコード法と異なるコーディング（それはあなたにとっては唯一絶対の常識かもしれない）でデコードしようとするから文字化けしてしまうにすぎません。FTPやIRCのこうした初期メッセージには、「まず readme を読め」とか「○○したら即座に蹴る」とか「最初にアップロードしないとダウンロードできません」とか「☆☆のパスワードは＊＊だ。うまくやれ」といったクリティカルな情報が凝縮されていることが多いわけで、その種の注意書きを読む、守る、ということは、言うまでもなく、この世界の基本的なルールです。解読できなければ次のステップに進めないことも多いでしょう。
以下では、おもにこの問題を扱いますが、関連する話題として、同様の原理で発生するメールの文字化けについても説明します。
xyzzy（ジジィ）は解凍すればすぐ使えます。このエディタは、デフォルトで Emacs ふう、しかも一部のキーバインドが独自なので最初は面倒に感じ抵抗があるかもしれませんが、慣れてしまえばべんりなものだし、よく使うキー操作は限られていてすぐ覚えられるので、使ってみてください。右クリックからWindows標準の方法でのコピーやペーストもできますから、最初はそれでも良いでしょう。
Tips: Emacsでは [Ctrl]+[V] はペーストでなく、Windows 標準でいう [PageDown] に相当するので最初は特に気をつけてください。Windows標準のソフトと相互に何度もコピペしてるうちに混乱して、ペーストのつもりで xyzzy で [Ctrl]+[V] を押してしまうことは、ありがちですが、そんなときは、[Alt] + [V] を押せばもとに戻ります（ Windows標準の [PageUp] ）。
さて、理屈はこのくらいにして、プラクティカルな手順をとっとと説明します。
FFFTPなどのFTPクライアント、ないし、mIRCなどのIRCクライアント、そのほか、どこかでなにかをしたとき、半角カナや妙な漢字の混ざった文字化けテキストが表示されたとします。とりあえず、その文字化け部分をコピーしてください。FFFTPならマウスでなぞって右クリック→コピーとかで。次に xyzzy にペーストします。ペーストのやり方に不慣れなうちは、右クリック→貼り付けなら間違いないでしょう。ここで最重要のポイントは、ペーストを行う前に、xyzzy の「編集→クリップボードエンコーディング」にて、自分がコピペしてる文字化けテキストの本来のエンコーディングを初期設定しておくことです。これは一度、指定してしまえば、エディタを閉じるまでずっと有効なので、最初に正しく指定しておけば、ロシア語でも中国語でも原文をほぼリアルタイムでデコードできます。コピーして、（クリップボードエンコーディング設定済みの）xyzzyに貼り付ければ、それで読めます。
クリップボードエンコーディングの指定法。中国の大陸（.cnドメイン）につないでいるなら、中国語 → GB2312 を試す。中国語でも台湾や香港（.tw ないし .hk）につないでいるなら、中国語→ Big5 を試す。分からなければ、GB2312、Big5 両方ためす（クリップボードエンコーディングを変更してから、もういちどペーストしてみる）。ロシア語圏の場合、欧米→キリル文字 Windows 1251 または KOI-8 を試す。韓国語圏の場合、韓国語→EUC-KR。
Tips: 文字化けしていて読めないのがソフトのメニューやダイアログのメッセージのような、ふつうにコピペできない場合でも、「コピット！」を経由してコピペできます。
ロシア語、中国語、韓国語などの文字がきちんと表示されましたか？ その言語をあなたが読んで理解できるなら、これで作業は終了です。
本来のテキストを復元できても、その言語自体がそもそも理解できない、ということがあるかもしれません。（中国語に関しては、漢字の知識のある大半の日本語圏のユーザの場合、中国語それ自体の知識がなくても、見るだけでだいたい理解できることも多いです。）その場合は、ウェブの自動翻訳で翻訳して意味を調べましょう。ロシア語や中国語を含む多くの言語は、BabelFishで英訳できます。韓国語に関しては、BabelFishの翻訳精度では意味がとれないことが多いです。All Korea や netomo が良いでしょう（利用には無料の登録が必要です）。
ウェブの翻訳のエディットボックスにペーストするときは、xyzzy のクリップボードエンコーディングを Unicode → UTF-16 にしなければなりません。ブラウザ（IE）はユニコードベースで動作するからです。まとめると、
Tips: キーボードを使って xyzzy にペーストするには、[Shift]+[ins]、xyzzy からコピーするには、[Ctrl]+[ins] を使います。これは xyzzy 独特のキー操作ですが、覚えにくければ、右クリックからコピーないしペーストを選ぶこともできます。
いちばん初めに書いた例ですが、FFFTP で Yahoo! 香港につないでみて、
ｽﾐｿ鬢JｧAｦb Yahoo! GeoCities ｪｺｷ|ｭ﨣KｽX
と言われました。何と言われたのでしょうか。xyzzy を起動して、*scratch* （Emacs系でちょっとしたメモを書き留めたりするのに使う場所のこと。あとから名前をつけて保存もできるので「新規文書」と考えても良い） が開いたら、編集メニューをクリックしてクリップボードエンコーディングを中国語にします。香港ですから繁体字のはずなので Big-5 です。そして [Shift]+[ins] を押せば、
請輸入你在 Yahoo! GeoCities 的會員密碼
と表示されました。（4文字めの 你 は、中国語を表示できないブラウザでは表示できませんがニーハオのニー、「あなた」という意味です。ほかの文字は日本語にもある漢字です。）「請輸入」ですから「輸入を請います」と言ってます。「GeoCities 的會員密碼」だから目的語は「ジェオシティの會員密碼」で「會員」は「会員」だし「密碼」は「密」がつくのでパスワードのことと分かるでしょう。まとめると「あなたのパスワードを入力してください」と言われたことが分かります。FTPサーバが言ってきそうなことにそくして考えれば、ウェブ翻訳を使うまでもないですね。
中国（大陸）のFTPからダウンロードさせてもらっていると、
error 421 ﾒﾑｳｬｹ（以下略）
と言われて転送が止まってしまいました。何かまずいことをして蹴られたのでしょうか。それとも単なる技術的な問題でしょうか。対応を取り違えると「うざいユーザ」と思われてブラックリストに入れられてしまうかもしれません。これもxyzzyにペーストしてみましょう。大陸なので簡体字GB2512を使うと……
已超过最大任务时间 - 正在关闭。
最初の文字は高校生のかたなら古文でならう「
必要なパスワードをえるためにIRCでロシアのチャンネルにつないで!passwordなどとタイプしたりしてパスワードをもらったあとに、
ｿﾞ瞻ﾕ ﾟﾞﾛ肅ﾕﾝﾘ・ﾛﾞﾓﾘﾝﾐ ﾘ ﾟﾐ玻ﾛ・ﾟﾞﾚﾘﾝ・ﾕ 涬ﾞ・ﾚﾐﾝﾐﾛ!
という文字化けテキストが出ました。パスワード使用上の重要な注意事項かもしれないし、「おまえもううざいんだよ。来ないでくれない？」とか言われてたらやばいので、解読してみましょう。欧米→Windows 1251なエンコードでxyzzyに貼り付けると、
После получения логина и пароля покиньте этот канал!
と出ました。もしロシア語が分からなくても、BabelFishで簡単に英訳できます。
After obtaining of logina and password leave this channel!
「アカウントとパスをえたあとは、このチャンネルを去れ。」の意味であることは高校程度の英語で分かるはずです。このチャンネルはパスワード配布専用なので、ここでチャットとかしないで、そして、忘れず /leave してチャンネルに入りっぱなしのままにしないこと、という注意事項でした。
韓国のファイル共有ソフト「ソリバダ（Soribada、音海）」を日本語環境で起動してみましょう。
ｼﾒｸｮｹﾙｴﾙｿ｡ ｿﾀｽﾅｰﾉ ﾈｯｿｵﾇﾕｴﾏｴﾙ.
などと言われます。韓国語版WindowsでEUC-KRで正しく表示されるはずのバイト列を無理やりSJISで表示してしまってるわけです。EUC系をSJISで化けさせると半角カナの大行列になりますが、半角カナはSJISにとっては合法的な文字なので日本語環境で情報を失わずに簡単にコピペできるという利点があります。
それはともかく、メッセージが理解できなければ使い方がよく分からないというもの。もっともこの種のソフトのインターフェイスはある程度、似ているので、慣れてるユーザなら、メニューが全部文字化けしていてもカンだけでほしいファイルをダウンロードするところまでいけるかもしれません……が、とりあえずコピット！で吸い取ってxyzzyにEUC-KRとして貼り付ければ、
소리바다에 오신걸 환영합니다.
と、本来の文字が見れます。韓国語を知らなくても、例えば All Korea のウェブ翻訳を使えば、
音海にいらっしゃることを歓迎します。
というウェルカム・メッセージであることが分かります。この調子でアプリからのメッセージや警告――それは本来は韓国語であるが日本語環境では無意味な半角カナのられつにみえる――をほぼすべて理解できるでしょう。ちょっとがんばって逆変換すれば、リアルタイムのチャットさえ可能かもしれませんね。
xyzzy を経由することで、本来、読めないはずの日本語英語以外のメッセージをハックできることはお分かりになったと思いますが、これをウェブの自動翻訳にかける操作を反復するとなると、クリップボードエンコーディングを入力のときはロシア語ならロシア語、出力のときはUTF-16と、そのたびに何度も何度も切り替えねばなりません。1つ2つの短いテキストを理解するならともかく、リアルタイムでIRCに流れるものを読んだりするには、もうひとくふう必要です……。
上の方法でエンコーディングを切り替える必要が生じるのは、なぜでしょうか。入力のときはクリップボードエンコーディングをロシア語ならロシア語にします。次にIEで開いた翻訳ページに貼り付けるために、UTF-16に切り替えています。xyzzyからみると、最初にクリップボードにある不明のTEXTをロシア語としてデコードして、次にはクリップボードにそれをユニコードでエンコードしたものを送信しています。クリップボードという同じ「ポート」をべつのエンコーディング法で切り替えながら使うのが、複雑性の原因になっています。
それが分かれば、おのずと解決法も見えてくるでしょう。入力には絶対にクリップボードを使いたいですが、出力は別にクリップボードでなくても良く、ファイルに書き出してもいいわけです。ので、xyzzyの（ローカルな）クリップボードエンコーディングは入力用に固定してしまい、それを翻訳ページに送る通信経路は以下のようにします。第一にxyzzyで解読した文字列を tmp.html という名前で保存します。このとき文字コードはUTF-16を選びます。デフォルトのSJISなどで保存したらロシア語はともかく中国語や韓国語では情報が失われてしまうからです。おまけに、SJISなどで保存すると、IE自身が文字コードで迷う原因になります。
第二に、いま保存した tmp.html をIEで開きます。UTF-16のテキストには自分で自分のエンコーディングを説明する BOM というしくみがあるので、HTML自身にmetaタグで文字コードを書かなくても、IEは、これをユニコードとして正しく表示してくれます。IEでひらいた tmp.html の画面から翻訳ページにコピペすれば、IEからIEへのコピペなので同じユニコードを使って、万事うまくいくでしょう。
でもって、例えばチャットでロシア語（あるいはほかの言語）のテキストがどんどん流れていても、xyzzyに貼り付ければ自動的に本来のテキストが表示されるので、xyzzy にて [Ctrl]+[X]→[Ctrl]+[S] で上書き保存して（これは Emacs 標準のキー操作）、次にIEで tmp.htmlをリロードすれば、いまチャットで流れている文字化けテキストが正しく復元されたテキストがそこにどんどんリロードされるので、適当な分量ごとに翻訳ページにはりつけて翻訳すれば話の流れを追えるでしょう。
以上は、かなりアドホックなハックであって、将来的には、すべてユニコードかなんかで統一して文字化けがおきないようにする、そして必要ならリアルタイムでチャットに翻訳フィルターが入って、最初から自分の望む言語での翻訳結果が表示されるようにする、といったことになるのが望ましいと思われます。
関連する話題として、簡単にふれておきます。
例えば、韓国語、ロシア語、フランス語、スペイン語などの非英語圏からのメールを日本語環境のメーラで受信すると、文字化けして読めないことがあります。この場合もコミュニケーションに支障が生じます。フランス語のような iso-8859-1 なテキストでもアクセント記号のようなものがついた文字のあたりが化けることがあります。
Tips: EdMaxフリー版では、西ヨーロッパ（iso-8859-1）と中央ヨーロッパ（iso-8859-2）のエンコードを正しく表示できます。日本語メールを受信しないアカウントなら、アカウント設定の「その他」タブの「日本語,英語以外の文字コードセットを使用」にて設定を行います。日本語メールと西欧／中欧語メールの両方を受信するアカウントでは、同じタブにある「ヘッダの文字コードセットに応じてフォント切替え」を使い、適切なフォントを設定します。サンセリフ系を望むなら小さい文字でも読みやすい Verdana が良いでしょう。セリフ系では Times New Roman が一般的ですが、Windows 2000 のユーザなら、Palatino Linotype も試してみてください。受信したメールのエンコードに応じて、EdMaxフリー版は自動的に表示を切り替えてくれます。次の画像は実例。
中国語、韓国語、ロシア語などさらに多様な文字セットを扱うには――Outlook Expressは危険なので――Mozilla（Netscape 6のことでは、ありません）のメーラがべんりです。
メーラで日本語・英語以外のメールを受け取る可能性がある場合、最初からモジラのような対応しているメーラで受信するようにするのが最善でしょう。モジラのメーラが使いにくいと思う場合――多いにありうることですが――、「ふつうは使い慣れたメーラで受信するがロシア語メールなどが来たらモジラで再受信して読めるようにする」という発想で、「受信したメールをすぐにはメールサーバから削除せず数日は残す」ような設定にするのも良いでしょう。ただし、受信済みのメールを無制限にサーバに残すと、サーバのリソースを浪費し受信するときの効率も悪くなる（受信に時間がかかる）ばかりか、ディスクスペースの制限によって最終的には新着メールが来てもいっさい受け取れず差出人に送り返されてしまうという事態になりかねないので、気をつけてください。まともなメーラなら、「受信したメールはサーバから削除する」のがデフォルトの動作のはずです。
ご存じのかたも多いと思いますが、ネットを流れるメールは、「どんなシステムでも絶対に読める半角英数字や @ + = などの半角記号」（ここではばくぜんと「半角文字」と呼んでおきます）だけでエンコードされています。それを受信したメーラ側で日本語なら日本語に復元して表示するわけですが、多くのメーラでは受信したそのままの「半角文字でエンコードされたソース」を自動的に保存しているか、あるいは設定によって保存しておくことができます。Outlook Express――おすすめできないメーラですが――のユーザなら、選択したメールを右クリックして「プロパティ→詳細→メッセージのソース」とすると、
Subject: Re: =?ISO-2022-JP?B?GyRCPEF……
のようなの（この例では、日本語のJISコード（ISO-2022-JP）を半角文字でエンコーディングしている）が見れます。JISコードの日本語メールなら、エンコードされた本文はドル記号 $ がひとつおきくらいにいっぱい入った暗号文のように見えるはずです。日本語英語以外だと、最初に言ったような「半角カナと妙な漢字が混ざったテキスト」に見えるかもしれません。モジラのメーラでソースを見れば、半角文字だけ（ただし ¡¢£ のような特殊記号も含む）に見えます。見え方はともあれ、これらの半角文字だけにエンコードしたソースさえ持っていれば、必ず本来の文字セットで読む方法が存在します（送信者が送信したメールそのものが、そのソースだからです。送信者の側のメーラが送信の瞬間に、オリジナルの文字セットのメールを半角文字にコーディングして発送するわけです）。
ですので、いろいろな文字セットのメールをやりとりする予定がある場合、受信メールのソースを保存しておくのが最終的に最強の安全策となります。すでに見たように、モジラやOEでは、そもそもソースそのものを保存していて、ユーザがメールをひらいたときに動的にオリジナルの文字セットになおしているようなので、この点に関するかぎり理想的なメーラです。一般的なメーラでは――EdMaxフリー版もそうですが――ソースそのものでなく日本語にデコードしたあとのすぐ読めるテキストで受信ログを保存するかもしれません（多くの場合、そのほうが軽快で効率的だし、実際的でしょう）。しかし、EdMaxであれば、アカウント設定→受信タブにて「受信メッセージのログをとる」「受信したままの形式で保存」をオンにできます（デフォルトではオフ）。日本語にデコードしたすぐ読めるテキストと、ソースの両方を保存することになって、受信メール量に対して通常の約2倍のディスクスペースを消費することに注意します。
次に、非日本語圏のウェブメール（いわゆる海外ウェブメール）では、日本語のメールが文字化けすることが多いです（意図的に日本語をサポートしていなくても、たまたま日本語メールを送受信できる場合もあります――PerlでEUC-JPやUTF-8が使えるのと同じ）。このようなメールアカウントで日本語メールを受信した場合は、単にソースを保存して、JISコードを解釈できるエディタで開き直すだけで読めることが多いです。ブラウザのソースを表示するエディタが文字コードを自動判別してくれる場合、単にソースを表示するだけで日本語メールが完全に読める場合すらあります。一方、そのウェブメールのシステムにとって「読めない」文字を疑問符などに置き換えてしまうメールサービスもあり、この場合は情報が失われるので復元できません（たとえば日本語環境で韓国語メールを受信した場合も、???に置き換えられてしまうと復元しようがありません）。さらにまた、「読めない」文字はユニコードのコード番号で参照してくるメールサービスもあり、この場合は必ず復元する手段があります。最悪でも、ユニコード番号（例 1234 ）を、それが16進数であるか10進数であるかに応じて一文字ずつ
ሴ または Ӓ
に書き換えてブラウザで日本語文書として開けば読めるでしょう。
いくらxyzzyで正しいデコードをしても、そもそもロシア語なり中国語なりのフォントがないことには文字の表示のしようがありません。ブラウザで（Windowsシステムで）各国語フォントを導入する方法については、ウェブを検索すれば簡単に説明が見つかるはずですが、ここでは Arial Unicode MS の導入をおすすめします。これは Unicode 2.1 で定義された51180のグリフをすべて含んでおり、これひとつで、多くの言語が表示可能になります。現在のユニコードのバージョンである Unicode 3.x で追加された文字は含まれませんが、無料であること、含まれる文字の多さなどにおいて、Windows 用のフォントとしては最強のものです。ダウンロードページには「Office 2000 Service Release 1 にはこのフォントが含まれている」と書いてあるので、該当するユーザは新たにインストールする必要は、ありません。
このフォントをインストールするためのインストーラは、Arial Unicode MS Font for Publisher 2000からダウンロードできます。ダウンロードサイズが13.3MB、展開後のフォントファイルが23MBという巨大なものです。自分のシステムにすでにこのフォントがインストールされているかどうか知るには、Windowsフォルダ内のFontフォルダに Arialuni.TTF があるか確かめます。
このファイルの入手については別記事「Arial Unicode MS を手に入れよう」をごらんください。
このフォントの欠点は、グリフ（フォントの形）が必ずしも美しくないことです。 Arial Unicode MS の日本語文字は、たいていの日本語圏のユーザにとって、読みにくいと感じられるでしょう。ハングル文字や中国語簡体字、繁体字も、必ずしも読みやすくありません。流麗なグリフや、クールで軽快で読みやすいグリフでなしに、もともと「太字」系な Arial フォントの拡張なので、それが仕様といえばそれまでですが……。多言語環境が必要なかたは、各国語ごとの標準的なフォントも準備なさると良いでしょう。韓国語ならGulim系（一般に GulimChe として知られる）、中国語なら SimHei とか MingLiu が例です。フォントの欠点というよりソフトの問題ですが、xyzzy を含むいくつかのソフトのフォント選択コモンダイアログでは、Arial Unicode MS を追加してもそれを選択できず、各国語ごとにフォントを選択する必要があります。煩雑だしふべんですが、必要な言語ごとに足らないフォントを追加する必要があります（WindowsのCDに入ってることが多いと思います）。
このセクションでは、「多言語間の文字化け」の原因について（厳密でも正確でもないですが、ひととおりの）技術的な説明をします。単にFTPメッセージ等の文字化けを修復する方法だけを知りたいなら、このセクションを読む必要ありません。
同じ日本語でもSJISとEUC-JPなどがあって、ブラウザが文字コードを勘違いすると文字化けすることは、たいていのユーザが一度は経験しているでしょう。Yahoo! のような文字コードについての意識の低いサービスでは、文字化けがよく発生します。HTTPレスポンスヘッダで定められているとおりきちんと文字コードを指定すれば、文字化けは起こらないはずなのですが、日本語圏の一般のサイトでもこの規約はあまり守られてません。かくいうこのサイト（妖精現実）でも、すべてのレスポンスヘッダに文字コード情報を乗せているわけでは、ありません（大半のページではちゃんとやってますが、手抜きもある）。――それはそれとして、以下で問題にするのは、日本語なら日本語内でのエンコーディング方法の違いによる文字化けの話じゃなく、多言語間でのそれです。
実際に文字化けテキストを復元する作業においては、なぜどうやって文字化けしているかの原理を理解する必要は、ありませんが、これはべつに難しい問題じゃないので、要点だけ書いておきます。ここでは基礎から分かりやすくすべてを説明することはしませんが、分からない点は検索すればすぐ分かることばかりなので調べてみてください……。
多くのテキスト処理システムは――UTF-8でいえば、たとえ表面上、ぼうだいなユニコードを扱っている場合ですら――受け取ったすべてのテキストを、とりあえずぜんぶ半角文字（1バイト文字、アスキー文字）で書いてあるかのように扱うことがあります。というか、低水準では1バイトずつ処理できるし、処理しなければならないのが当然です。
テキストを扱う実質的にすべてのシステムは、たとえ多バイト文字を扱えなくても、「すべて1バイト文字」という見方ならできるし、ネット上のどこをどう通って配信されるか分からないメールなどでは、途中の中継システムが日本語のような多バイト文字を処理できる、と仮定するほうが問題なので、1バイト文字しか扱えないシステムを通しても情報が失われないように1バイト（半角英数字など）だけでコーディングしてテキストを流すわけです。将来的には、UTF-16ですべて（今でいう）2バイト幅が基本単位（WCHARとか）になるかもしれませんが……。
1バイト文字ということは、つまり8ビット、2進数でいえば8個の0か1、すなわち00000000から11111111までの256種類、10進で0～255、16進で0x00～0xFF。文字や制御記号のコードを割り当てられる「コードポイント」が1バイトにつき256種類あるわけです。アスキー文字として見た場合、256コードポイント前半（0番～127番）には、半角英数字や一般的な英文記号等がほぼ世界共通にわりあてられてて、0x00から0x7Fまでを使うシステムだけなら、ほとんど文字化けは生じないでしょう。2進数でいえば、00000000から01111111までで、先頭ビットは0に決まっているので「7ビットのコーディング」。
1バイトのなかの7ビットだけを通信に利用すると、1バイトあたり128通りの記号が送れますが、先頭ビットは常に0に決まっているので、送信されるデータの8分の1、つまり12.5%がムダな通信になる。もし1バイトの8ビットをフルに使えば、1バイト転送するごとに256通りの記号が送れる。つまり8ビットフルに使えば1バイトあたりの情報量を単純計算で2倍にできて、理論値では転送速度が2倍になる（厳密な説明でないですが、だいたいのイメージ）。だから、現実的には8ビットをフルに使いたいわけです。7ビットと8ビットの違いは1ビットでなく、2の指数であるから2倍の違いであることに注意します。
8ビットをフルに使った場合において、10進数で256通り区別できる記号の「後半」つまり128番から255番、16進0x80-0xFF（2進数でいえば「先頭ビットが立っている」範囲）がどのようなコードポイントと解釈するか？ という、そこの解釈の違いが、多言語間の文字化けの根底です。（これに反して、ユニコードでは、0番から65535番までを平坦に割り当てて、同じ番号が解釈によって違う文字になったりすることは、ありません。もっともユニコードにも特有の問題がいろいろあるのですが……）なお、文字セットによっては、127番までの「前半」の使い方にも違いがあります（場合によっては相当の違いが）。日本語SJISでも、わずかな違いはあります。例えば、標準ではバックスラッシュが割り当てられているところに￥が割り当てられてます。韓国語の文字セットだとここはウォン記号だったりします。
事実上の標準では、0x80～0xFFには西欧語の特殊文字や記号が割り当てられてます。アクセント記号のついた文字とか、著作権記号、商標記号など……。ウェブページで Á ないし Á ないし Á などと書いて特殊文字を参照できますが、まさにこのユニコード番号で F+0080 から F+00FF 、十進数で € から ÿ の範囲が問題（�からの範囲は、ほぼ世界共通に文字が割り当てられている）。ユニコードだったら0x80から0xffがどんな文字（コードポイント）か？は明らかだし、西欧語（ISO-8859-1）では10進128～255番にどの記号を割り当てるかユニコードとほぼ互換。が、我々はいつもユニコードや西欧語を使うわけでなく、日本語圏なら SJIS や EUC-JP や ISO-2022-JP（通称JIS）を使うし、ロシア語圏なら Windows1251 や KOI-8 を使うし、中国語圏なら GB2312 や Big5 を使うし、韓国語圏なら EUC-KR や ISO-2022-KR を使うし……そして、こうした「非ISO-8859-1」の文字セットは、それぞれ独自の方法で10進128～255番の領域を使うことで、日本語なら日本語の文字を表現してます。日本語SJISの場合、この領域は半角カナや全角文字（漢字など）を表現するためのコードポイントに割り当てられてます。韓国語や中国語などを日本語SJISとしてデコードしてしまうと、半角カナと妙な漢字になるしだいです。
日本語版 Windows なら、現在のデフォルトとして、文字コードが明示されてなければ、パソコン用の日本語、つまりSJISとして扱う。ある意味、自然なことでしょう。日本語ソフトなのだから、特に断らない限りテキストは日本語の文字で書いてある、と思うのは、おかしなことでないし、英語のテキストでもアスキー127番までの文字はSJISとほぼ共通なので、英語も化けない。そんなわけで、英語と日本語しか使わないと割り切ってしまえば――つまりロシア語や中国語を処理できないことは――、大半のユーザにとって、どうでも良かったのでしょう。
けれどネットが発達して全世界がFTPやHTTPで結ばれ、英語圏や日本語圏以外のいろんな場所から発信されるすてきなリソースを日常ふつうに利用するようになったいま、そうした昔のローカルな発想だとちょっとうまくないことがある。例えばロシア語のメッセージを日本語のSJISだと思って表示しようとすれば、同じコードポイントを違う使い方をしているために本来のロシア語が読めず、「半角カナと変な漢字などのまぜこぜ」に見えてしまうでしょう。
また、モジラのメーラでメールのソースがきれいに見えるのは、128～255番の記号をISO-8859-1として表示しているから、OEでメールのソースが同様な文字化けをすることがあるのは、128～255番の記号を同様にSJISとして処理するからでしょう。
しかし、本来のエンコーディングと違うエンコーディングでデコードしてしまったために文字化けがおきるとしても、デコード前の内部的なバイト列そのものはオリジナルのまま健在なのです。その（間違ってデコードされた先の）文字セットでは使われないコードポイントを、デコードしたソフトが？や■や□や・などと表示するのはそれとして、実際のコード番号まで疑問符なりに対応するものに変更してしまうとしたら、そこで情報が失われてしまいます。いくつかのエディタでフィルタすると、このような情報喪失が発生して、オリジナルの文字列を復元不可能になります。さいわい、表示は文字化けになっていても、内部的にはオリジナルのバイト情報を保持しているソフトも多く、そのようなソフトから文字化けした部分をコピー＆ペーストした場合、そのソフトそれ自体はロシア語なり中国語なりをまったくサポートしていないにもかかわらず、クリップボードにオリジナルそのもののバイト列をとりこむことができます。クリップボードに入れたとしても正しいエンコーディングに関する情報が分かるわけではないのですが、エンコーディング不明のままであっても、オリジナルのバイト列をクリップボードに送ることさえできれば、ほとんどの場合、問題解決の道がひらけます。以下で説明するように xyzzy で「クリップボード・エンコーディング」を指定してやりさえすれば良いのです。
同じ原理による別解として、文字化けしたまま保存してから、そのエンコーディングを解釈できるエディタで開き直す、という方法もあります。韓国語と Kajero の組み合わせは、これができる可能性があります。けれどFTPやIRCのメッセージはリアルタイムに近い方法でどんどん文字化けをなおして読みたいでしょうから、クリップボード経由が軽快でしょう。xyzzy なら、ロシア語、中国語など、多くの文字セットに対応しているので、きわめてべんりです。
このメモの目的でxyzzyを使う場合、Emacsについての知識は必ずしも必要ありません。Emacs、xyzzyそのものについてもっと知りたいかたは、以下の別記事をごらんください。以下の記事は独特の立場から書かれているので Emacs のヘビーユーザーからみると不満足な内容かもしれませんが、初めて使うかたがとりあえず雰囲気だけでも理解するには多少は役立つものと思われます。
Cost 856.5 milliseconds.