Muse UUEncoding

[Jason Russell]

I’ve already searched and came across some really old posts, but we’re having an interesting issue with changing the encoding from a uuencoded PDF to a base64 encoded PDF. We’ve run into some ‘interesting’ things. This is passing a field into a xltp (ZRI3.5 for those in the know):

The code:

1. package require base64
2. package require uuencode
3. set index0 [lindex $xlateInVals 0]
4. set index0 [string map { \\X0D\\\\X0A\\ \n \\F\\ | \\S\\ ^ \\T\\ & \\R\\ ~ \\E\\ \\ } $index0]
5. set index0 [join [lrange [split $index0 \n] 1 end] \n]
6. set ucode $index0
7. set PDF [uuencode::decode $ucode]
8. set b64 [base64::encode $PDF]
9. set xlateOutVals

   ]

So a few interesting notes I’ve noticed while working on this:

• The uuencode::decode doesn’t want the ‘begin’ line. It puts it into the output of the PDF, this is why I have the line that splits the file after conversion, line 5. If I don’t do that, it adds a series of characters the PDF doesn’t need.
• If I comment outline 5, I get a full: CHFJOAWUUA3h20Kh0tqtJVBER
• no matter what I do, in the end, the base64 encoded data has an extra character (tJVBER).
• If I leave both the CR and LF characters, (string map { \\X0D\\\\X0A\\ \r\n }) I get even more extra characters at the start (tqtJBVER)

The uuencoding looks fine, no extra characters, and coverts properly to the PDF I’m expecting in the PDF file.

There are some extraneous lines (setting variables to each other) as we were splitting things apart and debugging. I feel like I’m missing something simple here.

Topic

[Jason Russell]

Here’s the updated code, and it’s still adding extra characters:

——

set inVal [lindex $xlateInVals 0]
set outVal “”

package require base64
package require uuencode

set ucode [lindex $xlateInVals 0]
echo $ucode
set ucode [string map { \\X0D\\ \r \\X0A\\ \n \\F\\ | \\S\\ ^ \\T\\ & \\R\\ ~ \\E\\ \\ } $ucode]
echo $ucode
set ucode [join [lrange [split $ucode \r\n] 1 end] \r\n]
echo $ucode

set pdf [uuencode::decode $ucode]

echo $pdf

set b64 [base64::encode -wrapchar “” $pdf]
echo $b64
# set b64 [string range $b64 1 end]
set xlateOutVals $b64

<hr />

Here are some of the initial echos that I have:

Direct data (first ucode): begin 644 WAV.DAT\X0D\\X0A\M)5!$1BTQ+C*)>+CS]/H"B@-2`P(\T\]B:CP\E\+U1Y<\T\4@+

second ucode: begin 644 WAV.DAT
M)5!$1BTQ+C*)>+CS]/H"B@-2`P(&]B:CP\+U1Y<&4@+T-A=&%L;V<@+U!A

Third ucode: M)5!$1BTQ+C*)>+CS]/H"B@-2`P(&]B:CP\+U1Y<&4@+T-A=&%L;V<@+U!A

pdf: Lot of binary data that is unreadable:

b64: tJVBERi0xLjAKJeLjz9PoCiAgNSAwIG9iajw8L1R5cGUgL0NhdGFsb2cgL1BhqtZ2VzIDE

The issue is in the b64 value, there are a lot of ‘t’ and ‘qt’ characters that are in place:

t JVBERi0xLjAKJeLjz9PoCiAgNSAwIG9iajw8L1R5cGUgL0NhdGFsb2cgL1Bh qt Z2VzIDE

If I leave off the -wrapchar “”, the PDF is then broken into newlines, and that’s where the qt seems to come into play, but not sure why they’re being inserted like that. If I leave the \r in place it puts a lot of extra tqt characters.

Not really sure what is going on with this.

[Jason Russell]

So I’m on TCL 8.6 cloverleaf version 2022.09. tcllib is version 1.19 and TCL has some updates that make the packages pointless, and they don’t seem to work correctly. The following code works the way I’d expect:

set ucode [lindex $xlateInVals 0]
set ucode [string map { \\X0D\\ “” \\X0A\\ \n \\F\\ | \\S\\ ^ \\T\\ & \\R\\ ~ \\E\\ \\ } $ucode]
set ucode [join [lrange [split $ucode \r\n] 1 end] \n]
set ucode [binary decode uuencode $ucode]
set ucode [binary encode base64 $ucode]
set xlateOutVals $ucode

It matches what happens on the command line.

[William Caughey]

Hi Jason,

I know this is an old thread, but this should work:

Also, FYI, MUSE supports both UUE and B64 since MUSE NX R1 SP4 (circa 2021).

Bill

set map [list "\\X0D\\\\X0A\\" \n "\\F\\" "|" "\\S\\" "^" "\\R\\" "~" "\\T\\" "&" "\\E\\" "\\"]

set ZRI3_5 [lindex $xlateInVals 0]

set ZRI3_5 [string map $map $ZRI3_5]

set ZRI3_5 [uuencode::uudecode $ZRI3_5]

set ZRI3_5 [lindex [lindex $ZRI3_5 0] 2]

set ZRI3_5 [base64::encode -wrapchar “” $ZRI3_5]

set xlateOutVals [list $ZRI3_5]

• This reply was modified 5 days, 10 hours ago by William Caughey.
• This reply was modified 5 days, 10 hours ago by William Caughey.
• This reply was modified 5 days, 10 hours ago by William Caughey.
• This reply was modified 5 days, 10 hours ago by William Caughey.

[Jason Russell]

The uuencode and base64 packages never worked right for me. As I noted, the binary encode/decode worked flawlessly without all of the additional stuff once I replaced the \r\n with just the \n (and replacing the rest of the characters). Not sure if a string map would have been more functional there instead of splitting and rejoining, but it’s functional which is what is most important.

If we do another muse upgrade, I may see if they’ll switch to base64. This was more of an in-place replacement when we were integrating Cloverleaf. Working with the UUencoding was exhausting.

[Author]

Replies