筆者は Mutt という UNIX 用のメイラ─を普段使っていますが、現在、公式リリースされている 1.2 系列までは国際化されていなく、日本人の有志による日本語への対応が別途行われていました。当然、この手の地域化は本家のリリースが行われる度にそれに対応するためのパッチを毎回書かなければなりません（以前のもののコードの流用で済む場合もありますが）。これは結構大変な作業です。一方、現在開発中の 1.3 系列では文字符号化の変換関数 iconv やワイド文字を扱う関数が導入され、国際化され、その枠組みの中で日本語を使うことができます。しかし、国際化されたとはいえ、日本語を扱うためにはいくつか問題がありました。そのため、開発用メイリングリストにいくつかパッチを投稿したり、国際化関係のコードを書いている人とメイルをやり取りしたりして、かなりまともに日本語を扱えるようになりました（まだ少々不具合がありますが）。そこで、その経験を踏まえ、国際化の枠組みの中で日本語を扱う際に生じやすい注意点などを紹介したいと思います。
まあ、「国際化プログラミング - I18Nハンドブック -」（清兼 義弘・末廣 陽一／編著、共立出版）を読んでください。なにぶん高い（1万円）本なので買えない人のためにこの本に示されている国際化の条件の項目だけ上げてみます。
実際に国際化プログラミングを行う人はぜひ買ってください。良い本です。
また、メイルに特化した話ですが、RFC indices related to the Internet Mail に各国の文字符号化方式に関連する RFC のリンク集がありますので、そちらもお読み下さい。
いわゆる生JISへッダ問題です。ISO-2022-JP で記述されたへッダを MIME B encoding せずに送ってしまうという問題です。一部の人が妙なポリシーをもってそうしている場合もありますし、設定ミスでそうなっている場合もあります。文字符号化方式を指定していないため、受け取ったメイラーはその文字列が US-ASCII の文字列であると判断を行います。そのため、日本語の文字列としては表示されず、わけのわからない文字列が並んで表示されます。なお、この問題は実は ISO-2022-JP だけの問題ではなくて、海外で使われている文字符号化方式でも同様のことが生じています。
対策としてはある程度限定して文字符号化方式を決め打ちするしかありません。限定方法としては振り分け後のディレクトリ／フォルダ毎に設定を行うとか、送信者のメールアドレスで判断するとか、使用しているアカウント毎に決めるとかの方法があります。限定しない場合は誤った判断の元になりますので注意が必要です。
本文で使用する文字符号化方式は Content-Type フィールドの charset パラメータで指定することになっています。しかし、MIME に対応していないメイラー、腐っているウェブメイル、一部のメイリングリストドライバのコントロールメッセージなどでは charset パラメータの指定のないメッセージを送ります。受け取った側は charset の指定無きメッセージの文字符号化方式は US-ASCII であると判断を行います。そのため、生JISへッダと同様に日本語の文字列としては表示されず、わけのわからない文字列が並んで表示されます。
対策方法は生JISへッダと同様です。また、文字化けして表示された後に、charset の指定をユーザができるような仕組みでもいいと思います。
これは UNIX 上の端末上でよく起こる問題ですが、行末の80桁目に日本語の文字の1バイト目が来てしまう問題です。次の行は2バイト目から始まるため文字化けが生じます。
対策としては文字が必要とする桁の幅に注意する必要があります。
ISO-2022-JP のようなエスケープシーケンスにより文字集合を切り替える文字符号化方式を用いている場合、折り返し(folding)をする際に、何も考えずに MIME B encoding を行うと復号化する際に文字化けします。
対策としては folding する前に必ずその状態(shift state)を ASCII に戻してから MIME B 符号化を行う必要があります。当然、符号化後の文字列の長さは決められた長さに収まるように調整する必要があります。
へッダに記述された日本語を MIME B/Q encoding するときに符号化後の文字列の長さだけで判断すると Q encoding になる場合があります。一方、RFC1468 "Japanese Character Encoding for Internet Messages" によると B encoding を使うとの記述があります。この RFC は information ですが、日本語を扱うにあたっての実質的な標準として扱ってもいいと思われます。そのため、特別なルールとして ISO-2022-JP の場合は B encoding をするというコードを追加する必要があります。
海外のメイラーの場合、ASCII として表示できない文字が本文にある場合は、Content-Transfer-Encoding を Quoted-Printable にする傾向があります。この場合に、ISO-2022-JP を使うと、ESC がチェックにかかり、本文が Quoted-Printable に符号化されてしまいます。しかし、ESC 自体は本文に含まれてもよい文字です。一方、RFC1468 によると、ISO-2022-JP で使用する文字は全て（ESC も含めて） 7bit であるのだから、Content-Transfer-Encoding は 7bit であるとの記述があります。（デフォルトは 7bit なのでこのフィールドはつけなくてもよいということです。）そのため、ESC がチェックにかかるメイラーにおいては ISO-2022-JP の場合は Content-Transfer-Encoding を 7bit にするという特別なルールを追加する必要があります。
ASCII と JIS X 0201 ラテン文字集合 はほとんど同じですが、２つ文字が異なっています（説明用の文字はあえて JIS X 0208 （いわゆる全角）で記述します）。 ASCII における "＼"(バックスラッシュ) と "~"(チルダ)の位置に JIS X 0201 では "￥"(円マーク)と"￣"(オーバーライン)が入っています。この２つの違いは非常に大きな問題を生じさせます。それは Shift_JIS と EUC-JP で使える文字集合の違いです。Shift_JIS では JIX X 0201 を使うことができるが ASCII は使えない。逆に EUC-JP では ASCII を使うことができるが、JIS X 0201 ラテン文字集合は使うことができない。そのため、この２つの文字は互いに変換できないわけです。まあ、実際は文字コードの位置だけを取り出して変換しているケースが多いわけですが、国際化が絡むと、文字符号化方式を変換する際に変換関数の内部処理で UCS-2/UCS-4 に変換されるため、全く異なる文字として認識されます。そのため変換ができないということが生じます。実際に UNIX 上で Bruno Haible 氏の LIBICONV というのがありますが、"￥" が EUC-JP に変換できないため "yen" という文字列にに無理やり変換しています。また、オーバーラインは変換できません。このようなことが生じるのを防ぐための最良な方法は、Shift_JIS な環境の方が ISO-2022-JP として送信する際に、JIS X 0201 ラテン文字を ASCII として扱うしかありません。PGP の問題も含めて、JIS X 0201 ラテン文字集合は使わないようにするべきです。まあ、関連する話ですが、機種依存文字は UCS-2/UCS-4 には変換できても、ISO-2022-JP や EUC-JP には変換できないので注意が必要です。
表示用の文字符号化方式として Windows/Mac/一部のUNIX では Shift_JIS が、大抵の UNIX では EUC-JP が使われてきましたが、最近、UCS-2 や UTF-8 も使えるような環境も増えてきました。そこで問題なのが Unicode/ISO10646(以降 UCS と呼ぶ) のフォントです。固定ピッチの端末においては JIS X 0208 のフォントではその文字は2桁を使って表されていましたが、UCS フォントでは必ずしも2桁を使うとは限りません。たとえば、"×"という記号がありますが、これは UCS においては Latin-1 Supplement の領域にあります。つまり、欧米の言語で使われる文字ということです。そうなると、この文字の幅は1桁の幅で表示されるのが自然です（実際にどうなるかはその実装によりますが）。つまり、固定ピッチであれば文字の幅はどの環境でも同じように表示されるというわけではないということです。まあ、これはメイラーを作る側の注意というよりは使う側の注意ですが、作る側も多少意識して欲しいところです。
Thanks to SUZUKI Norio.