uuencodeは、バイナリデータをテキストデータに変換するUNIX及びUnix系OSのコマンド。或いは、それによって生成されるテキストデータのフォーマット。デコードにはuudecodeコマンドを用いる。電子メールやネットニュースで多用され、現在でも多くのメーラーが対応しているが、MIMEのBase64の方が一般的になっている。初期のUNIX系OSではUUCPと呼ばれるプロトコルで電子メールやネットニュースの配送が行なわれた。これらはテキストデータしか扱えないため、バイナリファイルをテキストデータに変換して送る手法としてuuencodeが提供された。uuencodeはUnix to Unix ENCODEの意である。その後インターネットの環境が整備され、UUCPよりもTCP/IPが一般的となるが、電子メールやネットニュースはSMTP、NNTPといったテキストベースの情報交換であったため、uuencodeは已然として広く使われた。uuencodeはあくまでも添付のためのフォーマットであるため、拡張子は重要ではないが、単一のファイルとして保存する場合は拡張子は.uuか.uueが使われる場合が多い。uuencodeにはいくつかの派生フォーマットがあるため、MIMEでは意図的にuuencodeを採用せず、新たにBase64を定義した。現在はこちらのBase64が広く使われている。uuencodeのフォーマットは、一行のヘッダー、複数行のエンコード文字列、一行のフッターからなる。ヘッダは次の書式である。ここで、は3桁の8進数であり、UNIXのパーミッションを表す。はデコードされたときのファイル名である。パス名を含む事が出来るが一般にはファイル名のみである。このあと、エンコードされた文字列が続き、以下のフッタで終わる。エンコードは3オクテット(24ビット)毎に行なわれる。これを4つの6ビット値に変換し、ASCII文字に割当てる。次は「Cat」という3オクテットのデータをASCIIの4文字に変換する例である。6ビット値に0x20を加えたときの下位6ビットをASCII値とする。この変換を表にすると次のようになる。元々「000000」はスペース文字であったが、かつて行末のスペースを取り去る転送系があったため、「`」に置き換えられた。デコードにおいては、変数 codice_1 にエンコードされた文字のASCIIコードが入っているとすると codice_2 でデコードできる（範囲外の文字が入っている可能性は考慮していない）。スペースの「`」への置き換えには、このデコード法に全く変更を必要としないという利点があった。次は「000000」にスペースを用いているuuencodeの一例である。これはSolaris 10の/usr/bin/uuencodeコマンドの出力である。行の先頭はその行に含まれるオクテット数を示す。通常は45オクテットなので「M」であり、45オクテットに満たない行は別の文字となる。このケースでは「)」である。そのあとデータの終了を示すため、0オクテットを示す「スペース」のみの行が続き、「end」で終わる。次は「000000」に「`」を用いている一例である。これはGNU sharutils 4.2.1に含まるuuencodeコマンドの出力である。行末にスペースが現れない。この他に、スペースと「`」が混在しているケースも存在する。これらのフォーマットは多くのデコーダでデコード出来る。（初期のフォーマットには）以下のような問題が存在した。これらの問題を解決するため、多くの派生フォーマットが誕生した。スペースの問題は、スペースを「`」に置き換える事で解決された。また、現在多用されているTCP/IPでは、転送エラーはTCPで検出される。同じく多用されているSMTPやNNTPも同様にASCIIを前提としている。よってそれらの環境で問題になることは稀である。次はMINIX 3.1.2aのuueコマンドの出力である。行の最後に1文字追加する事で、行末のスペースの問題を回避している。また、追加された文字はアルファベットの小文字の逆順になっており、行を分割して転送した場合に元に戻すときの目印となる。行の先頭文字でオクテット数が示されているため、デコード時に最後に付加された文字が無視されれば、正常にデコードされる可能性がある。最初のテーブルは、使っている文字を列挙することで、文字が正常に使えるかどうかを確認するためのものである。次はMark Hortonによって書かれ、Alan J Rosenthatlによって行末にチェックサムが追加されるようになったuuencode.c 5.3-2 (Berkeley) 3/1/88の出力である。最後に元データのオクテット数も追加している。次はRichard MarksによるDOS用のuuencodeに-Lオプションを付けて、チェックサムを追加した例である。チェックサムの演算方法が上記のものと異なるため、互換性がない。行単位だけでなく全体のチェックサムも追加している。次はxxencodeと呼ばれるフォーマットである。xxencode.c 5.3 (Berkeley) 1/22/85による出力である。「000000」から「111111」を「+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz」に割当てている。uuencodeはASCIIの文字を用いているが、EBCDICと呼ばれる文字コードを用いる実装では扱えない文字があったため、使う文字を入れ替えたのがxxencodeである。極めて古い転送路のための手法であり、インターネットではASCIIが使えないケースは稀であるため、xxencodeはほとんど使われない。uuencodeとの互換性は全くない。POSIXでは、今迄のアルゴリズムを「歴史的なアルゴリズム (uuencode Historical Algorithm)」とし、新たなアルゴリズムを定義した。先頭行は「begin-base64 」、最終行は「====」となっているため、今迄のuuencodeと区別出来る。変換アルゴリズムはBase64をそのまま流用している。これはxxencodeと同様、EBCDIC等への対処である。そもそもMIMEではuuencodeを除外した経緯があるが、逆にMIMEのBase64をuuencodeに取り込んだ形である。現在は通常のBase64が広く使われているため、この方式はあまり使われない。電子メールやネットニュースでuuencodeを用いる場合、本文中にuuencode文字列を直接貼付ける方法が取られた。MIMEでは意図的にuuencodeを除外したので、uuencodeをマルチパートで扱う手法は定義されていない。しかしながら、マルチパートの枠組みで扱う実装が多数登場した。大きく分けて2つの手法がある。一方はContent-Transfer-Encodingでx-uuencodeを表す。もう一方はContent-Typeでapplication/x-uuencodeを表す。前者の方が実装が多い。
出典:wikipedia
