I am currently working to bring CMS Pipelines Base64 stages 64Encode and 64Decode into NetRexx Pipelines. I am using the java.util.Base64 class to do the work. Encode works great, but decode gives gibberish, and different gibberish each time it is run. A note on names. CMS calls the stages 64Encode and 64Decode.
NetRexx objects to class names beginning with with a digit, so I
am using Encode64 and Decode64, and adding compiler based aliases
of the CMS names. Here is what works for Encode options nostrictcase
nostrictargs nostrictsignal Here is what does not work for Decode options nostrictcase
nostrictargs nostrictsignal Here is the trace, and a second run's result, too PS C:\Users\Jeff\documents\pipe tests> java ct
--- decode64.nrx [Thread-7,njPipes]
33 *=* method run()
35 *=* dec = Base64.getMIMEDecoder()
>v> dec "java.util.Base64$Decoder@11c1b90"
37 *=* loop label Main forever
39 *=* record_in = peekto().toString()
>v> record_in "SGVsbG8sIEJhc2U2NCE="
41 *=* ob = dec.decode(record_in)
>>> "SGVsbG8sIEJhc2U2NCE="
>v> ob "[B@18bd538"
43 *=* opr = Rexx ob
>v> opr "[B@18bd538"
45 *=* output(opr)
>>> "[B@18bd538"
49 *=* catch stageError
50 *=* rc = rc()
>v> rc "12"
51 *=* end Main
53 *=* Exit(rc*(rc<>12))
>>> "0"
# 2 64decode **FAIL** at rec 1 col 1. Less:
Actual:
[B@18bd538
Expected:
Hello, Base64!
# 2 64decode **FAIL** at rec 1 col 1. Less:
Actual:
[B@57e382
Expected:
Hello, Base64!
Notice that the two Actuals are different, even though run one right after the other. I have tried various combinations of casting things to and from
Rexx, string, byte[] with no help. I keep getting the
[hidden email]-type results. (The Encode took some such shenanigans to
coax it to work.) Any help pointers you can give would be gratefully received.
Thanks! Jeff Hennick
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Does this help?
In Base64 encoding, the length of output-encoded String must be a multiple of three. If not, the output will be padded with additional pad characters (=). Upon decoding, these extra padding characters will be discarded. To dig deeper into padding in Base64, check out this detailed answer on Stack Overflow.
From: https://www.baeldung.com/java-base64-encode-and-decode
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
In reply to this post by Jeff Hennick-3
Hi Jeff,
These are references - like memory pointers. They need some dereferencing. Let me try something.
René. On 15 Oct 2020, at 21:37, Jeff Hennick <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
In reply to this post by Jason Martin
Thank you, Jason. Using the MIME-type encoding, specifically in the Java (and implicitly in CMS), handles all that. (There can be additional bit level padding with 0s to get to a full byte.) And it is in the _working_ Encoding that all this is important. The input string in the test for Decoding, line 39, is "SGVsbG8sIEJhc2U2NCE=",
this is the result, with the padding =, from the Encoding of
"Hello, Base64!". For Encoding tests, I also use these short ones: @!*, @!, and @; with the results being QCEq, QCE=, and QA==. (I got all these test phrases from some web page, and the results of encoding agree with theirs.) I am still left hanging with the incorrect and varying decoding results. I have tried running the short examples too, but still get that enigmatic [B@57e382 - type result from them, too. On 10/15/2020 3:54 PM, Jason Martin
wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Try:
options nostrictcase nostrictargs nostrictsignal package org.netrexx.njpipes.stages import org.netrexx.njpipes.pipes. import java.util.Base64 class decode64 extends stage method run() opr='' dec = Base64.getMIMEDecoder() loop label Main forever record_in = peekto().toString() ob = dec.decode(record_in) loop i=0 to ob.length-1 opr = opr||char(ob[i]) end output(opr) readto() catch stageError rc = rc() end Main Exit(rc*(rc<>12)) Can be done better without the concatenation, but you get the picture. best regards, René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
In reply to this post by rvjansen
Even easier:
options nostrictcase nostrictargs nostrictsignal package org.netrexx.njpipes.stages import org.netrexx.njpipes.pipes. import java.util.Base64 class decode64 extends stage method run() dec = Base64.getMIMEDecoder() loop label Main forever record_in = peekto().toString() ob = dec.decode(record_in) s = String(ob) output(Rexx s) readto() catch stageError rc = rc() end Main Exit(rc*(rc<>12)) String can take a byte[], while Rexx cannot. Might be able to add that in 3.11 (will skip 3.10 for confusion with 3.1) René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
René, Thank you. Of course that works just great. In reading the Java documentation, I was concentrating on the class of the parameter (either byte[] or String), and glossing over the class (byte[]) that is returned. As for the 3.11, I'll vote to have anything "string like" be transparently handled as Rexx in NetRexx. As for 64Encode/64Decode, I'm going to try to add options to cover the other two flavors of Java Base64, beyond MIME -- which will be the default, before submitting them. Jeff On 10/15/2020 5:33 PM, René Jansen
wrote:
Even easier: options nostrictcase nostrictargs nostrictsignal package... Even easier: _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Free forum by Nabble | Edit this page |