base64 encoding PDF file data in TCL proc adding line feeds

[Peter Heggie]

I’ve got a TCL proc in a raw route detail that takes a Cloverleaf message and base64 encodes it. The message is binary PDF file data. I can see it in the process log because I’m using a debug echo statement of the $msg variable. See code below – the first debug message is writing the message to the process log and that log entry clearly shows the binary data.

I encode the message to base64 using this logic:

Code:

           # get message id
           keylget args MSGID mh

           set msg “”

           # get message data
           set msg [msgget $mh]
           if {$debug > 3} {echo “$module – msg: $msg”}

           # get MRN and document CreationDate from msg metadata
           set userdata [msgmetaget $mh USERDATA]
           if {$debug > 2} {echo “$module – userdata: $userdata”}
           set ekgmrn [keylget userdata EKGMRN ]
           if {$debug > 1} {echo “$module – ekgmrn: $ekgmrn”}
           set ekgdate [keylget userdata EKGDATE ]
           if {$debug > 1} {echo “$module – ekgdate: $ekgdate”}
           
           # prepare for base64 encoding
           package require base64

           set code [catch {base64::encode “$msg”} encoded_data]
           if {$debug > 1} {echo “$module – base64 encode code: $code”}
           if {$code} {
             echo “$module error code $code for base64 encoding PDF document”
             lappend dispList “ERROR $mh”
             msgmetaset $mh USERDATA “base64 decoding error – MUSE EKG PDF mrn: $ekgmrn date: $ekgdate”
             return $dispList
           }
           if {$debug > 2} {echo “$module – encoded_data: $encoded_data”}

The last debug statement above showing the encoded data writes the base64 formatted data to the process log. That log entry shows line feeds. And it is not the formatting of the printing of the process log, where each line can only display so much data, no – there are actual line feeds. All downstream threads show the same line feeds in the same position. The external vendor getting the output message is getting errors from their decoding utility, complaining about the unexpected data which happens to line up exactly with the start of the second ‘line’.

As you can see from the code, I’m not doing anything special with the base64 encoding statement. Why would it add line feeds? How can I get around this error? Should I just use a string map statement to remove the line feeds?

Peter Heggie
PeterHeggie@crouse.org

Topic

[Jim Kosloskey]

Looking at the Core tcllib base64 doc it indicates the default wrapchar is newline and the default maxlen is 76.

Setting -maxlen to 0 eliminates wrapping.

So are you seeing newline every 76 characters?

If so perhaps setting -maxlen to 0 might help.

Not speaking from experience here.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Peter Heggie]

That was exactly the problem. The debugging output showed the line breaks at 76 characters. And thank you for pointing to the documentation for the base64 package – I would not have known to look there.

Peter

Peter Heggie
PeterHeggie@crouse.org

[Robert Milfajt]

Klingon coders axiom, documentation is for the weak and timid.   😆

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Peter Heggie]

Full speed ahead! glad it is in Test.

Peter Heggie
PeterHeggie@crouse.org

[Author]

Replies