ほかでも書いたとおり、NetNewsにファイルを流すためには、エンコードと呼ばれる処理を施さなければなりません。
これは、ニュースの記事を流すソフトウェアが主に7ビット文字(いわゆるUS-ASCII)専用であったことから、8ビット文字を含むバイナリデータがそのままでは流通できなかったことに由来します。
しかし、一口にエンコードと言っても種類があり、しかもソフトウェアによって各エンコードに対応するもの・しないものもあり、あなたの使用しているソフトウェアが不幸にして見たい記事のエンコードに対応していない、ということもままあります。
そういった場合、そのエンコードが何であるかを判断することが必要になります。
ここでは、各エンコードについて特徴についてまとめておきます。
主な種類
NetNewsで流れている主なエンコードの種類は、下の３種類になります。ほかにもMac系のグループなどでBinHexなどが使われることがありますが、まれです。
各エンコードについて
NetNewsでは最も古くから利用されているエンコードです。
添付ファイルに対応しているニュースリーダで有れば、まず間違いなくサポートしているはずです。
仕様が単純なためか、多くの自動投稿ソフトウェアもこの形式を標準で採用しているようです。
このエンコードは、24ビット（3バイト）を1セットとして6ビットで分割しなおし、それぞれUS-ASCIIの文字にマップしたものです。
また、エンコードされたデータで構成される各行の頭には、行の長さを表す1文字が付加されます。（チェクサムと勘違いしている人が居ますが、あくまで「長さ」です。）
このことから、UUEncodeでエンコードされた記事は、元のデータに対して4/3倍＋αのサイズ（133%以上）になります。
UUEncode単独でエンコードされた記事は、記事の頭に「begin 644 xxxxxx.jpg」等のように「begin」から始まるヘッダがあり、「`」だけの行と続く「end」行で１つのファイルの終端を表現します。
また、各行の先頭は長さを表す文字が付加されています。この文字は、最後の行を除いてほとんどの場合「M」です。
（これに関連して、古いバージョンのMicrosoft製ニュースリーダ「Internet News」「Outlook Express」などに、添付ファイルが無くても記事の本文中に「end」だけの行があると、それ以降の文章が読めなくなるバグがあることが知られています）
以上から、見分け方としては
|
近年、Outlook Express等が標準で採用するようになってから使われるようになってきたエンコード方式です。
日本のニュースグループでは、Outlook Expressで投稿する人が多いため、この形式でエンコードされている記事に出会うことが多いと思います。
逆に、海外のグループでは自動投稿ソフトが普及しているため、UUEncodeが主流です。
このエンコードは、UUEncodeと同じく24ビット（3バイト）を6ビットずつ分割してUS-ASCIIにマップするのは同じですが、マップされる文字が異なり、また各行の長さを表す文字が有りません。
このことから、エンコード後のサイズは、UUEncodeよりは若干小さくなります。（それでも133%以上にはなりますが。）
また、UUEncodeと異なり、Base64単独ではファイルのエンコード形式としては認識されず、かならずMIME（Multipurpose Internet Mail Extension）とセットで使用されます。
MIMEは、データの名前や形式といった情報を表現する様式です。ここに、エンコード形式として「Base64」と、エンコードされたデータのファイル名といった付加情報が記述されます。
MIME自体はエンコード形式について制限しませんので、UUEncodeなMIMEデータ、というのも可能です。よって「MIME = base64」ではありません。
Base64の特徴としては、
|
2001年後半から2002年初頭にかけて、急速に普及したエンコード方式です。
主に海外のグループで使われており、対応ソフトウェアが未だ少ない状況が続いています。
特に、Outlook Expressが標準で対応していないため、yEncでエンコードされた記事は対応ソフトか、特殊なソフトを使ってみるほか手段がありません。
このエンコード方式の最大の特徴は、現在ではサーバソフトウェアのほとんどが8ビットのデータでも正常に処理できることに着目し、あえて8ビットのデータを流すことで、データの分割とマッピングによるオーバーヘッドをなくし、数%の容量アップで押さえることができる点です。
あえて数%増やしてエンコードするのは、Netnewsのプロトコル（NNTP）で制御コードとして使用される改行などを別の文字に置き換えるためです。
このような特徴から、大きなデータを流す際に非常に有効なため、海外の動画系グループを中心に急速に普及してきています。
また、現在エンコード仕様はドラフト状態で、正式に確定したものではないようですが、今後も対応ソフトウェアの増加・普及が見込まれます。
注意点としては、海外のソフトウェアの中には、yEncode対応を謳いながら完全準拠ではない壊れたデータを吐き出すものがある点です。
yEncodeされた記事は、=ybeginヘッダで始まり=yendフッタで終わります。
記事が分割されている場合には、分割情報などもヘッダに付加されています。
また、ほとんど90%以上がバイナリで構成されることから化けて汚く見えることが多く、対応していないソフトウェアではデータが壊れて受信されることもあります。
このため、できるだけネイティブに対応したニュースリーダを使用した方が、確実にデコードできると思われます。
以上の点から、見分け方は
|
どのエンコードにすべきか
これから投稿する際に、上記にあげたエンコードのうちどれを採用するかですが、とくに理由がなければUUEncodeをおすすめします。
特に日本のグループに投稿するということであれば、yEncodeは避けるべきです。
現状では、日本語のソフトウェアでyEnc対応のソフトはごく限られており、またOutlook Expressがサポートしていない現状では、（特に初心者に）いたずらに混乱を招く結果になります。
yEnc自体、まだまだ仕様はドラフト状態で固まったものではありませんので、もう少し待ってからでも遅くはないように思います。