エンコード・コレクション (メール、テキスト関連)

'00.5.13 ('03.3.6更新)

エンコードとは:

データを任意のコードに変換することをエンコードと言います。戻すことをデコードと言います。文字コードの変換もファイル圧縮もエンコードの一種です。ここでは送信時に用いられるエンコードを集めてみました。

まずはASCII (アスキー) の理解から。


ASCII (アスキー) って何?

文字をデータにするときに、文字に対応するデータの値 (コード値、文字コード) が規格によって決められています。ASCIIは、いわゆる半角英数字の文字コード体系です。American Standard Code for Information Interchange (情報交換用米国標準符号) の略です。

8bitのASCIIもありますが、通常ASCIIといえば7bitのANSI X3.4-1986規格の通称です。16進数で0x00〜0x7F (0xは16進数の目印) 、2進数で0000000〜1111111の範囲ですね。

アメリカの標準ですが、これをもとに国際規格のISO 646やJIS X 0201ができました。コンピュータの文字コード体系の基本とも言えるでしょう。ISO 8859やUnicodeも0x00〜0x7F部分はASCIIと同じで、上位互換の規格となっています。

表はASCIIに相当する0x00〜0x7Fのコード。日本語フォントで表示するとJIS規格の文字になりますが、ブラウザによってはちゃんと表示されているかもしれません。

- 0 1 2 3 4 5 6 7
0 NUL TC7
(DLE)
SP 0 @ P ` p
1 TC1
(SOH)
DC1 ! 1 A Q a q
2 TC2
(STX)
DC2 " 2 B R b r
3 TC3
(ETX)
DC3 # 3 C S c s
4 TC4
(EOT)
DC4 $ 4 D T d t
5 TC5
(ENQ)
TC8
(NAK)
% 5 E U e u
6 TC6
(ACK)
TC9
(SYN)
& 6 F V f v
7 BEL TC10
(ETB)
' 7 G W g w
8 FE0
(BS)
CAN ( 8 H X h x
9 FE1
(HT)
EM ) 9 I Y i y
A FE2
(LF)
SUB * : J Z j z
B FE3
(VT)
ESC + ; K [ k {
C FE4
(FF)
IS4
(FS)
, < L \ l |
D FE5
(CR)
IS3
(GS)
- = M ] m }
E SO IS2
(RS)
. > N ^ n ~
F SI IS1
(US)
/ ? O _ o DEL

0x00〜0x1F0x7Fが制御文字 (コントロールコード)。0x20(SP)が空白文字 (スペース)。0x21〜0x7Eが図形文字 (通常の文字) になっています。

制御文字としては、0x09→水平タブ(\t)、0x0A→改行(LF)(\n)、0x0C→書式送り(改ページ)(\f,^L)、0x0D→復帰(CR)(\r) などがあります。

0x23,0x24,0x40,0x5B,0x5C,0x5D,0x5E,0x60,0x7B,0x7C,0x7D,0x7Eは、各国の規格によって表示される文字の形が違うことがあります。JISだと0x5Cが\ではなく¥、0x7Cが破線でなく|、0x7Eが〜でなく ̄になります。欧文フォントはISOかASCII、日本語フォントはJISに基づいていますから、データは同じでも表示するフォントによって文字が違ってきます(厳密に規格通りじゃありませんが)。

7bitでは、この表にある文字数しか扱えませんね。8bitにすれば表が倍の大きさになりますが、せいぜい西欧各国の特殊文字を追加する程度 (ISO 8859-1)。日本語の漢字と「かな」を扱うためには16bit (8bitが2つ、2バイト) が必要になります。

Eメール送信時のエンコード(ABC順)

Eメール(SMTPプロトコル)では、8bitのデータ(バイナリデータや日本語のテキスト等)の送信は保証されない(データが欠落することがある)ため、7bitのデータ(半角の英数記号のASCII。16進数で0x00〜0x7Fの範囲)に変換して送ります。初期にはASCIIの送信しか想定されていなかったためです。

最近は8bitがそのまま通ることも多いようですが、万一にも通らない場合に、日本語だと殆ど意味不明になるので、7bitへのエンコードの必要性はまだまだ無くなりません。

メールの文字化けなら、まず次の「文字化け解消専用ソフト」を使ってみましょう。
Mac MailKanjiFixer (フリーウェア)
Win MBaker2 (フリーウェア)

8bit部分が欠落したデータの復元は、charsetがShift_JISでは難しいですが、EUC-JPとUTF-8なら8bit目を全部1にすれば読めるかもしれません。

UTF-8 → Quoted-printable というエンコードなら、その逆の手順でデコードしていきます。

Base64
主に添付ファイルを変換します。Winでは最も一般的です。元のデータの6bitを0〜63の数字としてA〜Za〜z0〜9+/の64文字で置き換えます。元のデータが8bitと6bitの最小公倍数である24bitで割り切れない場合、6bitに足りないbitには0を代入して変換し、変換後の文字列の最後には「=」を1つないし2つ付け足して割り切れるbit数にします。変換前よりデータサイズが一律33%大きくなります。ですから8bit送信のFTPやHTTPの方が効率はよいわけです。
通常Macのデータはデータフォークのみ送られます。リソースフォークしか存在しないファイルならそれだけ送ります。Subject(タイトル)の日本語に対応したメールソフトは、その部分をこれでエンコードします。AppleDoubleという呼び名のエンコードも7bitへの変換部分はBase64です。
MIMEエンコードとも言われますが、Quoted-printableもMIMEエンコードです。
参考RFC2045 / 日本語訳 RFC2045
デコードソフト
添付ファイルのデコード
Mac StuffIt Expander (ver.6以降, フリーウェア)
Win Aladdin Expander (フリーウェア)
メールヘッダ部分のISO-2022-JPプラスBase64のデコードが必要なら、(文章のデコード)
Mac MailKanjiFixer (フリーウェア)
Win MBaker2 (フリーウェア), Base64デコーダ (フリーウェア, 添付ファイルの切り出しもできる)
Quoted-printable
Base64とともにMIMEで規定されたエンコードです。「=」以外のASCII文字とスペース、タブ、改行はそのまま、その他は8bitごとに「=nn」(nnは16進数の文字コード。大文字で表記)という変換をします。たとえば「=」は =3D になります。1行が76文字を超える場合は「=」を行末に入れて改行されます。
西ヨーロッパ諸語で使われる特殊文字(ウムラウト、逆さ?、アクセント付き文字等)は8bitデータなので、ときどき現れるその文字だけ変換するのに効率がよく、アルファベット部分はデコードしなくても読めるのが利点です。 8bit部分はデータサイズが3倍になるので、8bitばかりのバイナリデータや日本語等のエンコードには全然向きません。
省略呼称として「Qエンコード」と言われることもありますが、厳密に言えば違います。
参考RFC2045 / 日本語訳 RFC2045
デコードソフト
Mac MailKanjiFixer (フリーウェア)
Win MBaker2 (フリーウェア)

EUC-JP
UNIXで標準的な日本語の漢字かな表示用2バイトコードです。ASCIIとの区別を容易にするため、すべてのバイトの8bit目は1です。通常、メール送信時にはISO-2022-JPにエンコードして7bit化します。エンコード無しでそのまま送ってしまって8bit目が欠落したのなら、すべて1を入れることで読めるようになるはずです (原理的に)。
半角カナも2バイト文字としてコード化されています。
デコードソフト
Mac ふみづかい (フリーウェア), Jedit (シェアウェア)
Win CoDesk (フリーウェア), 秀丸エディタ (シェアウェア)
ISO-2022-JP
日本語のメール本文は、一般的にISO-2022-JP (いわゆるJISコード) にエンコードして送ります。7bitだけで表現するために、コントロールコード(ESC)とそれに続く文字で目印(エスケープシーケンス)を付け、それ以下に書かれた文字が2バイト(漢字かな等)文字であるか1バイト(半角英数)文字であるか判別します。
半角カナは、ISO-2022-JPでは規格に入れてもらえなかったのでエンコードできません。メールで半角カナが使えないと言われるのはこの為ですが、ISO-2022-JPを使わずにBase64等でエンコードして送れば使えないことはありません。メーラーが規格外に仕様拡張して、半角カナを使えるようになっている物もありますが、受信側のメーラーも同じ方式に対応していなければ文字化けします。
メールのヘッダ部分にはコントロールコードが使えないので、SubjectやFromに日本語を使っている場合はBase64かQuoted-printableで更にエンコードします。
参考RFC1468 / 日本語訳 RFC1468
デコードソフト
メールヘッダ部分のISO-2022-JPプラスBase64のデコードも必要なら、
Mac MailKanjiFixer (フリーウェア)
Win MBaker2 (フリーウェア), Base64デコーダ (フリーウェア, 添付ファイルの切り出しもできる)
単純な文字コード変換なら、
Mac ふみづかい (フリーウェア)
Win CoDesk (フリーウェア)
最近のテキストエディタならISO-2022-JP (JIS) のShift_JISへの変換はできるでしょう。
ISO-2022-JP-2
韓国語、中国語も扱えるように拡張したコード。
参考RFC1554 / 日本語訳 RFC1554
ISO-2022-JP-3
JIS X 0213 (新JIS) で追加された文字を扱えるように拡張したコード。
Shift_JIS
Windows、Macintoshで使われている日本語漢字かなの表示コードです。従来から8bit領域に存在した半角カナをさけて (シフトして) コードを割り振っています。通常、メール送信時にはISO-2022-JPにエンコードして7bit化します。
コードの2バイト目にASCIIと同じコードが出現するので、プログラムで扱うのはやっかいです。
UTF-7
UTFは、UCS(Universal Multiple-Octet Coded Character Set) Transformation Format の略です。Unicode(UCS-2)のEメール送信時のエンコード方式です。Unicodeは世界中の文字を包括する文字コード体系ですが、ASCII文字を含め基本は2バイト(16bit)コードです。UTF-7は、ASCII文字はASCIIのまま、その他の文字は+-で挟んでBase64で変換して送ります。+は+-と表現します。
  1. A〜Za〜z0〜9'(),-./:? space tab CR LF はASCII。
  2. !"#$%&*;<=>@[]^_'{|} はASCIIでもよいが、メールのヘッダ等使えない場合もある。\~ は除外(エンコード)する。
  3. +から始まり、-かBase64のA〜Za〜z0〜9+/以外の文字(改行等コントロールコードも)が現れるまでがBase64の部分。
  4. 余ったbitは0を入れて6bitにして出力。=は使わない。
まだ対応しているメーラーは少ないようです。
参考RFC2152
デコードソフト
Mac ふみづかい (フリーウェア)
Win MBaker2 (フリーウェア), 秀丸エディタ (シェアウェア)
修正版 UTF-7
IMAP4のメールボックス名で使う修正版のUTF-7です。RFC2060のセクション5.1.3.にて定義されています。
オリジナルUTF-7の問題点
  1. Base64開始点の目印の「+」はメールボックス名としてよく使われることと矛盾する。
  2. 「/」を使うBase64は階層デリミタとして使われることと矛盾する。
  3. 「\」をそのまま使えないのは、一般的な階層デリミタとして使われることと矛盾する。
  4. 「~」をそのまま使えないのは、ユーザディレクトリを示すものとして使われることと矛盾する。
  5. エンコードしてもしなくてもいい文字があるという規定は、同じ文字列を複数のエンコードで表現可能になるのでよくない。
修正点。
  1. 「&」以外の印字可能なASCII文字はそのまま表します。オクテット値0x20-0x25および0x27-0x7e。文字「&」(0x26)は「&-」と表す。
  2. 他のすべての文字は、「/」の代わりに「,」を使った修正したBase64で変換します。オクテット値0x00-0x1f、0x7f-0xffおよびすべてのUnicode 16ビット・オクテット。印字可能なASCII文字をBase64でエンコードしてはいけません。
  3. 「&」がBase64開始の印で「-」が終了の印です。名前はBase64エンコードの途中で始まったり終わったりしてはいけません。
参考RFC2060
UTF-8
Unicode(ISO 10646 = UCS)の送信時のエンコード方式です。
Unicodeは世界中の文字を包括する文字コード体系で、ISO 10646で定義されたUCS-2(2バイト(16bit)コード)とほぼ同じものです。ISO 10646には、UCS-4という4バイト(31bit)コードの形式もあります(より多くの文字を含められる。UCS-2はUCS-4の上位2バイトが0x00になる部分)。
UTF-8はUCS-4,UCS-2,Unicodeをエンコードする、1〜6バイト(オクテット)の可変長コードです。コードの順番上、ASCII文字は1バイト(ASCIIと同じ)、ヨーロッパ諸語の文字は2バイト、漢字ひらがなカタカナは3バイトという具合に変換されます。非ASCII文字は「0x80〜0xFD」のみを使ってエンコードされ、ASCII文字と容易に区別されます。
UCS-4 range (hex.)
0000 0000〜0000 007F
0000 0080〜0000 07FF
0000 0800〜0000 FFFF
0001 0000〜001F FFFF
0020 0000〜03FF FFFF
0400 0000〜7FFF FFFF
UTF-8 octet sequence (binary)
0*******
110***** 10******
1110**** 10****** 10******
11110*** 10****** 10****** 10******
111110** 10****** 10****** 10****** 10******
1111110* 10****** ... 10******
変換する文字のコードを2進数にして***の部分にはめ込む
プログラムとの相性がよく、アルファベットの送信にも効率が良いように考えられています。日本語主体ならUnicode(UCS-2)そのままの方が効率的ですが。
UTF-8は特にメール用エンコードではないので8bitです。メールで使うなら、7bitにするために更にBase64かQuoted-printableでエンコードする必要があり、日本語主体だとデータ容量が恐ろしく増えてしまいます (メールヘッダでも要エンコード)。メールでUnicodeを使うならUTF-7ですね。対応していないメーラーも多いようですが。
(Win版Outlook Expressなら、エンコード方法を「なし」から「Base64」に変えてUTF-8を使います。Quoted-printableは日本語向きではありません。Mac版ではUTF-8を選ぶと自動的にQuoted-printableになってしまいます。)
Netscape Navigator 4 , MS Internet Explorer 4 からはUTF-8で記述したWebページも表示できるようになりました。
参考RFC2279 / 日本語訳 RFC2279
デコードソフト
Mac ふみづかい (フリーウェア), Jedit (シェアウェア)
Win MBaker2 (フリーウェア), 秀丸エディタ (シェアウェア)
IEやNN等のWWWブラウザで開いて、表示文字セットをUTF-8にすれば表示可能です。ファイル名に.htmlと拡張子を付けないと開けないかもしれません。

メールヘッダのエンコード
メールヘッダの「From」「To」「Subject」等でASCII以外の文字やそのままで使えない記号等を使いたい場合もエンコードが必要です。7bitであるISO-2022-JPでも、コントロールコードはヘッダでは使えないので更にエンコードします。
  • encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
  • charset = token (ISO-2022-JP, UTF-8, ISO-8859-1等IANA登録されたもの)
  • encoding = token (B (Bエンコード), Q (Qエンコード))
  • token = ASCII文字 (半角スペースとコントロールコード「()<>@,;:"/[]?.=」以外)
  • encoded-text = ASCII文字 (コントロールコードと "?" 半角スペース以外)
charsetとencodingは大文字小文字を区別しません。encoded-wordは全部で75文字まで。各行の制限は76文字まで。なので足りない場合、CRLF, 半角スペースで区切って再度"=?"から書きます。
参考RFC2047 / 日本語訳 RFC2047
Bエンコード
主にメールヘッダのエンコードに使われます。encoded-wordのことをいう場合もありますが、encoded-textを指す場合はBase64と同じです。
Qエンコード
主にメールヘッダのエンコードに使われます。
8bitデータを「=nn」(nnは16進数の文字コード。大文字で表記)にするという変換はQuoted-printableと同じですが、ヘッダという特殊な場所で使われるので、エンコードすべき文字が多くなります。
半角スペースは「_」(あるいは=20) にします。「=?_」以外の文字はそのまま書かれることになりますが、タブ改行はエンコードします。
()で囲われたコメント部分で使う時は「()」もエンコードします。
phrase内の単語、例えばFrom, To, Ccヘッダのaddressに先行する部分で使う時は、アルファベットと数字、「!*+-/」以外の文字はエンコードします。
Quoted-printableの省略呼称として使われることもありますが、厳密に言えば違います。
参考RFC2047 / 日本語訳 RFC2047

AppleDouble
これは本来エンコード形式ではなく、MacBinaryと同種のMacのファイルのパッケージフォーマットです。
メーラーの添付ファイルのエンコード方式としては、正確には、ファイルを送信する形式がAppleDoubleで、エンコード方式はBase64で送られることになります。OS XのMailでは全ての添付ファイルはこれで送られます。MS Outlook Express(Mac版)等のMacのメーラーではエンコード方法の選択肢の一つですね。
また、Macフォーマット (HFSとHFS+) 以外のディスクにMacからデータを書き込む時にも (Base64エンコードなしで) 使われます。
MacBinaryと違う点は、ファイルを2つに分け、片方がデータフォークのみ、もう片方はリソースフォークとファイル情報(MacBinaryのヘッダに相当)となっていることです。Macで受信した場合は完全なファイルとして受け取り、Win等のデータフォークのみしか理解できない受け手は、片方のみを取り出して利用できないもう一方を無視できます。

・AppleDoubleの構造 (2つに分かれている)

ファイル情報 リソースフォーク
データフォーク
相手の環境に依存せず送れる点が優れています。もちろん、Mac以外の環境へ送る場合、ファイルがデータフォークのみでも支障無く使える物であることが必要ですし、使われない余分なデータ(リソースフォーク)を送信する事になります。Macを知らない人には、意味不明の変なファイルまで送ってきたと思われるかもしれません。
OS8.5以降のicon badgeやcustom routingのFinder情報の保存に対応しています。
参考RFC1740 / 日本語訳 RFC1740

エンコード・圧縮・互換性と効率化の設定ダイアログ
Microsoft Outlook Express 5 (for Mac) の添付ファイルのエンコード方法選択肢

デコードソフト:Macのファイルとして再構成できるのは、まだメーラー以外には見つけていません。データフォーク単独ならBase64のデコードができるソフトで可能です。
Mac StuffIt Expander (ver.6以降, フリーウェア)
Win Aladdin Expander (フリーウェア)
AppleSingle
AppleDoubleと同じMacのファイルのパッケージですが、こちらは1つのファイルに纏めます。MacBinaryとは逆にヘッダ、リソースフォーク、データフォークの順。Mac用メーラーではEudoraでしか見かけませんが。
参考RFC1740 / 日本語訳 RFC1740
BinHex(ビンヘックス)
もはや古い形式ですが、Macのバイナリデータを変換します。これはMac用パッケージ兼エンコードで、ついでに簡単な圧縮までしています。リソースフォークもファイル情報(クリエータ、ファイルタイプ等)も損なわず送れます。ヘッダを付け圧縮をし、6bitごとに64個のASCII文字に変換します。変換方法はBase64に似てますが違う文字を使います。
Mac用添付ファイルの形式としては、AppleDoubleに標準の座を奪われてしまいました。また、OS8.5以降のicon badgeやcustom routingのFinder情報の保存に対応していません。
これでエンコードしたファイルが、「.hqx」の拡張子でweb上のMac用ダウンロードファイルとして使われたりしますが、圧縮してあるとはいえ7bitになっているので大抵ファイルサイズは大きくなります。サーバが対応しているなら、「.sit」のStuffIt圧縮のまま(データフォークだけFTPする)か、「.bin」のMacBinary形式(古いブラウザだと自動解凍されないかもしれませんが)ならば8bitのままなのでファイルサイズが大きくなりません。
参考RFC1741 / 日本語訳 RFC1741
デコードソフト
Mac StuffIt Expander (フリーウェア)
Win Aladdin Expander (フリーウェア)
uuencode/uudecode
UNIXで一般的なエンコード方式です(デコードするときがuudecode)。変換方法はBase64とほぼ同じですが使う文字が違います(こっちが先)。
デコードソフト
Mac StuffIt Expander (フリーウェア)
Win Aladdin Expander (フリーウェア)

enriched
text/enrichedとなるenriched形式のメール。少し前のバージョンのEudoraの文字装飾付きメールで使われていました。HTMLに似たタグを使います。
参考RFC1896 / 日本語訳 RFC1896
HTML
HTML形式のメール。文字の装飾や画像の張付けが可能。Outlook ExpressやNetscape Messenger、EudoraなどHTML形式に対応したメーラーで表示できます。
インターネット上のURIのイメージや埋め込みオブジェクトを表示すると、メールを読んだことが相手に伝わる可能性があり、それがSPAM業者だと生きたアドレスだと看做されてSPAMが増えるもとになります。気になるなら非表示設定にしましょう。
出す側としては、文章だけでも容量が4、5倍も大きくなるので、送り先の相手の許可を得てから使わないと嫌われます。
Outlook Expressでは「リッチテキスト」とメニューに書いてありますが、ワープロ等で使うリッチテキスト形式 (RTF) とは全くの別物です。こっちはWebページと同じHTMLです。
対応してないメーラーだとtext/htmlの添付ファイルになります。プレーンな本文が付く時と付かない時があります。8bit部分は通常Quoted-printableでエンコードされるようです。
参考RFC2557
MS-TNEF
リッチテキスト形式 (RTF) をメールで送信するためのエンコード (Transport Neutral Encapsulation Format)。もっぱらイントラネットや企業内のExchangeサーバとOutlook (またはExchangeクライアント) だけで使われ、基本的にインターネットで使うものではありません。
Outlookでは、インターネット経由のメールをHTML形式に変換して送る設定がデフォルトのはずですが、違っていたら直しましょう (HTML形式も嫌われるので、形式はテキストがいいですね)。Exchangeサーバを使っているなら、クライアントの設定に関わらず強制的にHTML形式に変換してインターネットに出すのがデフォルト設定のはず。
対応してないメーラーでは、装飾のない本文とBase64でエンコードされたapplication/ms-tnefとなる添付ファイルになります。ファイル名はwinmail.dat (名無しのときもある)。ファイルを添付してないならwinmail.datは無視できますが、添付したファイルが埋もれてしまったときはデコードソフトで発掘します。
一般に使われるOutlook Expressだとリッチテキストと書いてあってもHTML形式です。
デコードソフト
Mac TNEF's Enough (フリーウェア) winmail.datをファイルとして保存してから使う。
Win Fentun (フリーウェア) メーラーのヘルパーアプリケーションとして使う。
Outlookの設定変更
メッセージの受信者側で発生した問題を解決する

その他送信に関わるエンコード

ISO (8859-1) エンコード
MacのコードをISO 8859-1のコードへ変換します。西ヨーロッパ諸語で使われる特殊文字(ウムラウト、逆さ?、アクセント付き文字等)は8bit目を使用する部分(0x80〜0xFF)に割り振られていますが、この部分Macは独自拡張のためWin等との互換性がありません。
変換にはテーブル(対照表)を使います。日本語送信の際にはオフにしないと文字化けします。Fetch(FTPソフト)の英語版ではデフォルトでオンになっているので気をつけましょう。
変換ソフト
Mac MacWinText(macwintext-10.hqx) (シェアウェア), FTPソフトのFetch (シェアウェア) でFTP送受信時に可能。
Win 調査中。
Macなら、IEやNN等のWWWブラウザで開いて、表示文字セットをISO 8859-1 (Latin1) かMacRoman (Western Mac) にすれば表示可能です。ファイル名に.htmlと拡張子を付けないと開けないかもしれません。
MacBinary
これはデータフォークとリソースフォークを並べてヘッダを付けただけなので、エンコードと言うのはちょっと違う気がしますが、Macのファイル送信時には必ず出てくる形式なので取り上げました。拡張子は.bin。
OS8.5以降のicon badgeやcustom routingのFinder情報の保存に対応したのはMacBinary IIIからです。
OS XでFinderが255文字までのファイル名に対応しましたが、MacBinaryの規格では最長でも63文字 (バイト) までしか扱えません。
詳しくは、「MacBinaryって何?」「MacBinaryの規格」でどうぞ。
デコードソフト
Mac StuffIt Expander (フリーウェア)
Win Aladdin Expander (フリーウェア)
URLエンコード(エスケープ)
URLとフォームデータの送信では、URLで使えない、あるいは特別の意味を持ってしまう文字はエスケープ (エンコード) して送ります。日本語等8bitの文字もエスケープします。形は「%nn」。nnは16進数の文字コードです。たとえば半角スペースは %20 になります。
  • エスケープしない文字 (非予約文字、必要ならしてもよいが)
    • アルファベットの大文字, 小文字, 数字,「-_.!~*'()」
  • エスケープする文字
    • URLで意味がある文字 (予約文字)「;/?:@&=+$,」
      (予約文字は、意味通りに使う時はエスケープしないですよ)
    • URLで使えない文字:制御文字, SP,「<>#%"{}|\^[]`」,日本語等8bit文字
      (#はURLと部分識別子の区切り。%はエスケープのマークだし)
日本語の場合、文字エンコードはSift_JIS、EUC-JP、ISO-2022-JP、UTF-8、いずれもあって特に決まっていません。各々の文字エンコードのコードのまま8bitずつエスケープします (Sift_JISの「あ」なら「%82%A0」)
フォームのデータは、URLのうち「?」以下に使われるクエリー成分 (Query Component) に相当します (GETの場合)。ここでは半角スペース(SP)は「+」で置き換えます。ここでも「-_.!~*'()」はエスケープしなくてもかまいませんが、実際はGETでもPOSTでも、MSIEなら「*-.@_」、Netscapeなら「*-._」以外の記号はすべてエスケープしています (IEが@をエスケープしないのは謎)。改行は「%0D%0A」になる環境が多いようですが、違うこともあるようです。日本語は、通常ページの記述コードでエスケープして送られます (iCabだと全部Shift_JIS)。Sift_JISとEUC-JPなら、エスケープしないで送っても大丈夫だったりしますが、規格外ですね。
ACTION="mailto:○○"としてフォームから直接メールすると、送られた日本語が文字化けして見えるのは、これでエスケープされたままだからです。日本語環境なら、デコードしISO-2022-JPに変換してメールを送るメールデコードCGIを経由するのが一般的です。
JavaScriptのescape()でエスケープする記号は、またちょっと違いますね。エスケープしない記号は「*+-./_」で、MSIEだと「@」もしないです。また、IE4から日本語は、%unnnnとしてUnicodeでエスケープされます。これをCGIでデコードするのはちょっと面倒ですが、Jcode.pmを使えばUnicodeからShift_JIS等へ変換できます。
参考RFC2396 / 日本語訳 RFC2396
デコードソフト
Mac ClipDecoder (フリーウェア)
Win ClipDecoder for Windows (フリーウェア)
URLエンコード・デコードページでは、CGI送信時とJavaScriptでの様々な文字エンコードのURLエンコードをエミュレートします。IEの%unnnnのUnicode式のエスケープも変換できます。