本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
x-gzip64
みたいなやり方も無いではないが。[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.