yEnc

本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。

(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)

yEnc

[9] 119964 – (yEnc) Support yEnc encoding (including multipart) ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=119964>

[10] gecko-dev/nsMimeTypes.h at dfd4efa147e3604707e65b502e142aa8e1dce737 · mozilla/gecko-dev ( 版) <https://github.com/mozilla/gecko-dev/blob/dfd4efa147e3604707e65b502e142aa8e1dce737/netwerk/mime/nsMimeTypes.h>

[11] Re: yencoding -- gnus? slrn? - The Usenet Archive ( 版) <http://www.theusenetarchive.com/usenet-message-re-yencoding-gnus-slrn-22351483.htm>

No, the approach proposed in that message just doesn't make any sense.

It's still using magic text strings.

yEncode as a content transfer encoding is not at all incompatible with

MIME. It's actually quite straight-forward. Take the current yEnc

encoding rules, strip out the needless begin and end markers, remove the

checksum in favor of using Content-MD5, and call it a content transfer

encoding of x-yencode using the standard MIME encoding rules. All done.

As a content transfer encoding, there's no need to worry about multipart

messages, interaction with other MIME parts, or any of that. It just all

falls neatly out of the existing rules for content transfer encodings.

Any MIME part that's encoded using yEncode has in its header section the

line:

Content-Transfer-Encoding: x-yenc

and the body of that part is yEncode-encoded information.