uuencodingは、バイナリからテキストへのエンコードの一種で、1980年にカリフォルニア大学バークレー校のメアリー・アン・ホートンによって書かれたUnixプログラムuuencodeとuudecodeに由来しており、 [1]電子メールシステムで送信するためのバイナリデータをエンコードするために使用されます。
「uuencoding」という名前はUnix-to-Unix Copyに由来しています。つまり、「Unix-to-Unix encoding」は、任意のファイルを 1 つの Unix システムから別の Unix システムに転送するための安全なエンコードですが、中間のリンクがすべて Unix システムである保証はありません。電子メール メッセージは、異なる文字セットを持つコンピュータを介して、またはそれらのコンピュータに転送されるか、 8 ビット クリーンでないトランスポートを介して転送されるか、8 ビット クリーンでないプログラムによって処理される可能性があるため、バイナリ ファイルを電子メールで転送すると、ファイルが破損する可能性があります。このようなデータをほとんどの文字セットに共通する文字サブセットにエンコードすると、このようなデータ ファイルのエンコードされた形式が「変換」または破損する可能性は低く、送信先にはそのままで変更されずに到着します。プログラムuudecode はuuencodeの効果を逆転させ、元のバイナリ ファイルを正確に再作成します。uuencode/decode は、バイナリ ファイル (特に圧縮されたファイル) を電子メールで送信したり、 Usenetニュースグループ に投稿したりするためによく使用されるようになりました。
現在では、主にMIMEとyEncに置き換えられています。MIME では、uuencode されていた可能性のあるファイルは、代わりにBase64エンコード で転送されます。
エンコード形式
uuencode ファイルは、次の形式のヘッダー行で始まります。
begin <モード> <ファイル><改行>
<mode>ファイルのUnix ファイル権限を3 つの 8 進数で表したものです (例: 644、744)。これは通常、Unix 系オペレーティング システムでのみ意味を持ちます。
<file>バイナリデータを再作成するときに使用するファイル名です。
<newline>各行を終了するために使用される
改行文字を表します。
各データ行は次の形式を使用します。
<長さの文字><書式設定された文字><改行>
<length character>その行にエンコードされたデータ バイト数を示す文字です。これは、実際のバイト数に 32 を加算して決定されるASCII文字です。ただし、ゼロ バイトを表す重アクセント "`" (ASCII コード 96) は例外です。最後の行 (データ長が 45 で割り切れない場合) を除くすべてのデータ行には、45 バイトのエンコードされたデータ (エンコード後 60 文字) があります。したがって、長さの値の大部分は 'M' (32 + 45 = ASCII コード 77 または "M") です。
<formatted characters>エンコードされた文字です。実際の実装の詳細については、§ フォーマットメカニズムを参照してください。
ファイルは次の 2 行で終わります。
`<改行> 終了<改行>
最後から 2 番目の行も行の長さを示す文字であり、アクサングラーブは 0 バイトを表します。
完全なファイルとして、Catという文字のみを含むcat.txtというプレーンテキストファイルのUUエンコード出力は次のようになります。
644 cat.txt の開始 #0V%T ` 終わり
開始行は標準の uuencode ヘッダーです。'#' は、その行が 3 つの文字をエンコードすることを示します。最後の 2 行は、すべての uuencode ファイルの最後に表示されます。
フォーマットメカニズム
のメカニズムは、uuencoding3 バイトごとに次の処理を繰り返し、4 つの印刷可能な文字にエンコードします。各文字は、基数 64 の 数字を表します。
- ソースから3バイト、合計24ビットから開始します。
- 4 つの 6 ビット グループに分割され、それぞれが 0 ~ 63 の範囲の値を表します: ビット (00 ~ 05)、(06 ~ 11)、(12 ~ 17)、(18 ~ 23)。
- それぞれの値に 32 を加えます。32 を加えると、可能な結果は 32 (" " スペース) から 95 ("_"下線) の間になります。96 ("`"重アクセント) を「特殊文字」とするのは、この範囲の論理的な拡張です。スペース文字は 0 の値のエンコードとして文書化されていますが、GNU sharutils [2]などの実装では、実際にはファイルの本体のゼロをエンコードするためにも重アクセント文字を使用しており、スペースは使用していません。
- これらの数字に相当する ASCII を出力します。
ソースの長さが 3 で割り切れない場合は、最後の 4 バイト セクションにパディング バイトが含まれ、きれいに割り切れるようになります。これらのバイトは行から減算される<length character>ため、デコーダーはファイルに不要な文字を追加しません。
uudecoding上記の逆で、各文字の ASCII コードから 32 を減算して (重アクセントの使用を考慮して 64を法として) 6 ビットの値を取得し、4 つの 6 ビット グループを連結して 24 ビットを取得し、3 バイトを出力します。
この表は、エンコードのプロセスを示しています。この表は、「Cat」の上記のエンコードの導出を示しています。
uuencode テーブル
次の表は、変換プロセス中に取得された 6 ビット フィールドの 10 進数値と、それに対応する ASCII 文字出力コードおよび文字の変換を示しています。
一部のエンコーダーはアクサングラーブ ("`"、コード 96) の代わりにスペース (コード 32) を生成する場合があり、一部のデコーダーはスペースを含むデータのデコードを拒否する場合があります。
例
以下は、1 行のテキスト ファイルを uuencode する例です。この例では、%0Dはキャリッジ リターンのバイト表現であり、%0Aはライン フィードのバイト表現です。
- ファイル
ファイル名 = wikipedia-url.txt ファイルの内容 = http://www.wikipedia.org%0D%0A
- uuエンコーディング
開始 644 wikipedia-url.txt ::'1T<#HO+W=W=RYW:6MI<&5D:6$N;W)G#0H` ` 終わり
フォーク(ファイル、リソース)
Unix には伝統的に、ファイル データが格納される単一のフォークがあります。ただし、一部のファイル システムでは、単一のファイルに関連付けられた複数のフォークをサポートしています。たとえば、従来の Mac OS階層ファイル システム(HFS) では、データ フォークとリソース フォークがサポートされていました。Mac OS HFS+ は、Microsoft Windows NTFS 代替データ ストリームと同様に、複数のフォークをサポートしています。ほとんどの uucoding ツールは、プライマリ データ フォークのデータのみを処理するため、エンコード/デコード時に情報が失われる可能性があります (たとえば、Windows NTFS ファイルのコメントは別のフォークに保存されます)。一部のツール (従来の Mac OS アプリケーションUUToolなど) では、異なるフォークを 1 つのファイルに連結し、ファイル名で区別することでこの問題を解決しました。
xxencode、Base64、Ascii85 との関係
文字の範囲が限られているにもかかわらず、 uuencode されたデータは、 EBCDICなどの非 ASCII 文字セットを使用する特定のコンピューターを通過する際に破損することがあります。この問題を解決する試みの 1 つは、英数字とプラス記号とマイナス記号のみを使用する xxencode 形式でした。今日では、より一般的なのは Base64 形式です。これは、 ASCII 32~95 ではなく、英数字のみという同じ概念に基づいています。3 つの形式はすべて、入力データを表すために 6 ビット (64 の異なる文字) を使用します。
Base64 も uuencode プログラムによって生成することができ、実際の文字変換を除いて形式は似ています。
ヘッダーは次のように変更されます
begin-base64 <モード> <ファイル>
トレーラーは
====
行間は、以下から選択された文字でエンコードされます。
ABCDEFGHIJKLMNOP QRSTUVWXYZabcdef ギジクルムノップルストゥフ wxyz0123456789+/
もう 1 つの選択肢はAscii85で、これは 4 つのバイナリ文字を 5 つの ASCII 文字にエンコードします。Ascii85 はPostScriptおよびPDF形式で使用されます。
デメリット
uuencoding は、フォーマット済みの 3 バイトを 4 バイトに変換し、開始/終了タグ、ファイル名、区切り文字も追加します。これにより、ソースのみの場合と比較して少なくとも 33% のデータ オーバーヘッドが追加されますが、uuencoding する前にファイルを圧縮することで、ある程度は補うことができます。
言語サポート
パイソン
Python言語は、コーデック「uu」を使用した codecs モジュールを使用した uuencoding をサポートしています。
Python 2 の場合(2020 年 1 月 1 日時点で非推奨/廃止) :
$ python -c 'print "Cat".encode("uu")' begin 666 <データ> # 0V%T
end
$
Python 3 の場合、codecs モジュールをインポートして直接使用する必要があります。
$ python3 -c "from codecs import encode;print(encode(b'Cat', 'uu'))" b'begin 666 <データ>\n#0V%T\n \nend\n' $
デコードするには、ファイル全体を渡します。
$ python3 -c "from codecs import decode;print(decode(b'begin 666 <data>\n#0V%T\n \nend\n', 'uu'))" b'Cat'
パール
Perl言語は、フォーマット文字列 "u" を指定した pack() および unpack() 演算子を使用して、uuencoding をネイティブにサポートします。
$ perl -e 'print pack("u","Cat")' # 0V%T
unpack を使用した base64 のデコードは、文字を変換することによって同様に実行できます。
$ perl -e 'print unpack("u","#0V%T")'猫
整形式のUUエンコードファイルを作成するには、モジュール[3]またはもう少しのコードを使用する必要があります: [4]
エンコード(ワンライナー)
$ perl -ple 'BEGIN{use File::Basename;$/=undef;$sn=basename($ARGV[0]);} $_= "begin 600 $sn\n".(pack "u", $_)."`\nend" if $_' /some/file/to_encode.gz
エンコード/デコード(適切な Perl スクリプト)
https://metacpan.org/dist/PerlPowerTools/view/bin/uuencode
https://metacpan.org/dist/PerlPowerTools/view/bin/uudecode
参照
- さまざまなエンコードアルゴリズムを比較するためのバイナリからテキストへのエンコード
参考文献
- ^ Horton, Mark. 「UUENCODE(1C) UNIXプログラマーズマニュアル」。Unix Heritage Society 。 2020年11月10日閲覧。
- ^ 「uuencode.c ソース」. fossies.org . 2021年6月5日閲覧。
- ^ 「PerlPowerTools ソース」。metacpan.org 。2024年2月12日閲覧。
- ^ 「uuencode.pl ソース」main.linuxfocus.org . 2024年2月12日閲覧。
外部リンク
- POSIX.1-2008 の uuencode エントリ
- GNU-sharutils – shar/unshar/uuencode/uudecode ユーティリティのオープンソース スイート
- UUDeview – Unix/Windows/DOS 用の Base64、BinHex、uuencode、xxencode などをエンコード/デコードするオープンソース プログラム
- UUENCODE-UUDECODE – Clem "Grandad" Dye が作成したエンコード/デコード用のオープンソース プログラム
- StUU – Stuart Cheshireによる Macintosh 用のオープンソースの高速 UUDecoder
- UUENCODE-UUDECODE – 無料のオンライン UUEncoder と UUDecoder
- Java UUDecoder – UUエンコードされた(メール)添付ファイルをデコードするためのオープンソースJavaライブラリ
- AN11229 – NXP アプリケーション ノート: UART ISP の UUencoding
