Talk:Uuencoding

message: 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)
thread_title:  Error in image 

message: 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)
thread_title:  This is not a complete or precise description of uuencode 

message: 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)
thread_title: Trivia section may have an error 

message: 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)
thread_title:  Bloat 

message: 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)
thread_title:  ASCII characters greater than 95? 

message: 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)
replies: text: 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)
thread_title:  Grave accent in trailer 

message: 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)
replies: text: 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)
thread_title:  Discrepancy in "XXcoding" section 

message: 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)
thread_title:  outdated and wrong text on grave accent symbol 

message: 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)
thread_title:  Mention shift-register implementation? 

message: 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)
thread_title:  Perl example is weird and unreadable