Talk:Uuencoding

Error in image

There is an error in the image in the "Sample uuencode" section. The "Binary representation" for the letter "a" shows nine binary digits rather than eight. The first zero should not be there. Ivar Y 16:40, 23 May 2005 (UTC)

uuencode

This utility is found in the GNU Sharutils package http://www.gnu.org/software/sharutils/sharutils.html

GNU uuencode 1.0 distribution has been merged into GNU shar utilities 4.1 distribution.

This is not a complete or precise description of uuencode

This is not a complete or precise description of uuencode, it requires simplification and clarification as well as extending

It misses the explanation of line start character being the pre-coded line length e.g. 'M' for a 45 byte input length

It misses the addition of '=' characters to pad the output if the input is not a multiple of 24 bits, so '\x00\x00' codes to "AAA="

see The Open Group Base Specifications Issue 6

Indeed, there is still no mention of "=" being used as padding at the end (mostly to ensure block-based decoders would output all characters). 74.104.188.4 (talk) 01:27, 31 March 2018 (UTC)

Trivia section may have an error

The link to COMT in the trivia section is probably incorrect. In this context COMT is not likely to be an enzyme or gene.

Problem solved. There was no reason for that to be in the article anyway, so now it's toast. RossPatterson 23:22, 7 December 2006 (UTC)

The citation for the "begin<SPACE><SPACE>"-Bug is this: http://support.microsoft.com/default.aspx/kb/898124 There really was a time when some Linux-geeks annoyed Outlook Express users in some newsgroups (like dasr (Sysadmin recovery)) by including a "begin quote from ..". This does not occur with Mime-messages

Bloat

A note about the added bloat of UUencoded data would be useful. —Preceding unsigned comment added by 69.31.174.220 (talk) 20:35, 9 October 2008 (UTC)

---

The trivia section states that the bloat is 33%. However, a typical line of UUEcoding begins with an "M" (ASCII code 45, indicating 45 bytes encoded on this line) followed by 60 characters and ending with CR/LF - ie 63 characters to encode 45 data bytes. 63/45 is 1.4, or 40% bloat, not 33%. —Preceding unsigned comment added by 82.152.211.7 (talk) 00:38, 9 December 2010 (UTC)

ASCII characters greater than 95?

Exaggerated statement "ASCII characters greater than 95 may also be used; however, only the six least-significant bits are relevant." needs citation! —Preceding unsigned comment added by 75.30.97.142 (talk) 07:22, 12 May 2010 (UTC)

Grave accent in trailer

Implementations of uuencoding that I've seen do not seem to have a grave accent on the next-to-last line, they use a space character (0x20) instead. This is the case in GNU sharutils (see http://linux.die.net/man/5/uuencode) as well as at least an other utility I've run into (libdes, which implements its own uuencode/decode routines). Is this a variant of the format, or is the grave accent currently shown in the article wrong? Mlindstr (talk) 19:57, 9 May 2013 (UTC)

I am the original author of uuencode. I used blank space, not grave accent, for zero-length lines. I have no idea where the comment about grave accents comes from. I suggest removing this comment and the one about a final line with only a grave accent. Gazotz (talk) 00:45, 7 January 2024 (UTC)

Discrepancy in "XXcoding" section

The section on relation to other coding methods says that XXcode "uses only alphanumeric characters and the plus and minus symbols", whereas the actual table showing the characters used shows A to Z, a to z, 0 to 9, +, and /. I presume / should be -, but haven't edited it in case it is the text that should have said "plus and stroke (solidus) symbols" (i. e. I don't know which is wrong).G6JPG (talk) 11:55, 13 December 2014 (UTC)

If you read the second paragraph carefully, it says that the table with the slash symbol is for Base 64, not xxencoding. But maybe there is a way to make this more obvious? Vadmium (talk, contribs) 00:16, 14 December 2014 (UTC).

outdated and wrong text on grave accent symbol

Hello,

This article claims: "Note that 96 ("`" grave accent) is a character that is seen in uuencoded files but is typically only used to signify a 0-length line, usually at the end of a file. It will never naturally occur in the actual converted data since it is outside the range of 32 to 95. The sole exception to this is that some uuencoding programs use the grave accent to signify padding bytes instead of a space. However, the character used for the padding byte is not standardized, so either is a possibility."

This is nonsense. It reports the single Unix specification (and, arguably, POSIX 1003.1 / IEEE Std 1003.1 ), but it completely ignores the actual facts. Both the BSD and GNU sharutils implementation consistenly produce the 0x60 (decimal 96, the grave accent) character where the POSIX standard defines 0x20 (decimal 32, space).

As an example, here the description from the current FreeBSD (11.1) man page:
"Groups of 3 bytes are stored in 4 characters, 6 bits per character. All characters are always in range from 1 to 64 and are offset by a space (octal 40) to make the characters printing. Character 64 represents a count of zero. The last line may be shorter than the normal 45 bytes. If the size is not a multiple of 3, this fact can be determined by the value of the count on the last line. Extra null characters will be included to make the character count a multiple of 4. The body is terminated by a line with a count of zero. This line consists of one ASCII backquote (octal 140) character"

Even if we ignore all smartphone and embedded and MacOS instances, the combined amount of Linux and BSD hosts these days represents the vast overwhelming majority of Unix systems in use.

Given this, I intend to update the article text to reflect the fact that the de facto standard is the Linux/BSD variant of the historical uuencode algorithm, while the variant documented in POSIX is increasingly rare. Opinions? Wefa (talk) 04:24, 3 February 2018 (UTC)

Mention shift-register implementation?

Should this article instead use the shift-register representation of uuencoding? This was far more common in real-world implementations since it was simpler. Block-based encoders had to watch out for endianness. Mentioning the block model is still important since that is why the format included padding (using "=") to allow block-decoders to flush their output. 74.104.188.4 (talk) 01:33, 31 March 2018 (UTC)

Perl example is weird and unreadable

Can be replaced by the shorter block:

$ perl -e 'print unpack("u","#0V%T")' 
Cat

The rest of the current code, to remove clutter from an uuencoded file is not relevant, as other languages also do not have this "extra code" to make a fully working program. The idea is to provide the function, so one can search on the term. 85.149.19.54 (talk) 11:41, 12 February 2024 (UTC)