YEnc
From Free net encyclopedia
Template:Lowercase yEnc is a binary to text encoding scheme for transferring binary files on the Usenet or via e-mail. It reduces the overhead by using an 8-bit transfer method. The overhead is often as little as 1-2% which compares well to the 33%-40% of other encodings like uuencode and Base64, although this is at the expense of requiring an 8-bit data path.
Contents |
How yEnc works
Most competing encodings represent binary files by converting them into printable ASCII characters, because Usenet and email were originally intended to send text only. Because this reduces the available character set considerably, there is significant overhead. For example, in Base64, 1 (8-bit) character represents 6 bits of the file, a 33% overhead (not including the overhead from headers). yEnc uses 1 character to represent 8 bits of the file, with a few special exceptions.
Criticisms
The creator of the yEnc encoding scheme and others have criticized the design of yEnc. It suffers from many of the same flaws as uuencode does, a number of which had already been solved years before by MIME (which itself addressed the same flaws in uuencode). For example, yEnc requires the strings "=ybegin" and "=yend" to be placed around the encoded file in the message body. Although this is an improvement over uuencode's "begin" and "end", which occur more frequently in normal text, message readers can still see attachments where there are none (most frequently in discussions about yEnc itself). yEnc and uuencode also attempt to reassemble files split into multiple messages by using the subject line, which is unreliable.
Moreover, yEnc adds a few new flaws of its own. It attempts to turn unstructured fields into structured ones, which is unreliable given that no constraints can be placed upon the unstructured use of the fields by non-yEnc uses. Most notably, the subject line of the message is supposed to contain the string "yEnc", the filename, and the part number. (The yEnc homepage chastises yEnc article posters for themselves not observing these constraints.) MIME places all such information in the message headers, which is far more reliable. Not all transports can handle the 8-bit characters employed by yEnc, which may cause data corruption. yEnc can also be mangled by different character sets. It works poorly with the increasingly popular UTF-8, for instance. Moreover, some article transports may, on the grounds of enforcing compliance with the Internet message format standard, automatically convert any message using 8-bit characters to either Base64 or Quoted-printable, entirely nullifying the overhead advantage.
Critics also take issue with the lack of formal standardization. There is no RFC or other standards document describing yEnc. The yEnc homepage contains a draft informal specification and a grammar (which contradicts RFC 2822 and RFC 2045), although neither have been submitted to the Internet Engineering Task Force.
Some people, including yEnc's creator, have suggested including yEnc as part of MIME, which would solve nearly all of its problems and retain the low encoding overhead. However, as of March 2006, no formal or informal standard has been reached.
However, as with uuencoding—despite its flaws—yEnc remains active on Usenet. As with uuencode, there are specialised programs for encoding and decoding multiple Usenet postings. The yEnc homepage states that "all major newsreaders have been extended to yEnc support". Neither Outlook Express nor Mozilla provide direct yEnc support for either news or mail, but there are plugins available.