base64_decode omitting CR=0D

Other open source tools published on ScottKlement.com
Post Reply
PeterLanghammer
Posts: 3
Joined: Thu Feb 22, 2024 8:07 pm

base64_decode omitting CR=0D

Post by PeterLanghammer »

Good afternoon,
Using Scottie's LIBHTTP, YAJL and BASE 64 on a new project,
all good so far.

Using UPS Shipping API to create a shipment.
Getting back a response in JSON, part of this response is the UPS label in ZPL printing language, base 64 encoded.
When I take the string and decode it using e.g. https://www.base64decode.org/ the returned data looks like this:

^XA
^LRN
^MNY
^MFN,N
^LH10,12
^MCY
^POI
^PW812
^CI27
^FO15,7^A0N,20,24^FVXXX XXXXXX^FS
^FO15,27^A0N,20,24^FV4148313523^FS
^FO446,9^A0N,30,34^FV5 LBS^FS
^FO683,9^A0N,28,32^FV1 OF 1^FS
^FO599,369^A0N,56,58^FVSAMPLE^FS
^FO106,452^A0N,30,34^FVUPS^FS
^FO64,482^A0N,30,34^FVMAXICODE^FS
^FO38,512^A0N,30,34^FVPRINTS HERE^FS
^FO300,436^A0N,30,34^FVUPS ROUTING CODE PRINTS HERE^FS
^FO270,524^A0N,28,32^FVUPS POSTAL BARCODE PRINTS HERE^FS
^FO10,1031^A0N,22,26^FVBILLING: P/P^FS
^FO416,1031^A0N,44,36^FVSAMPLE^FS
^FO175,1203^A0N,14,20^FVXOL 24.03.07 NV45 10.0A 03/2024*^FS
^FO9,670^A0N,56,58^FVUPS GROUND^FS
^FO9,731^A0N,24,28^FVTRACKING #: UPS TRACKING NUMBER PRINTS HERE^FS
^FO59,873^A0N,30,34^FVUPS TRACKING NUMBER BARCODE PRINTS HERE^FS
^FO689,650^GB124,125,124,B,0^FS
^FO0,648^GB811,14,14,B,0^FS
^FO0,423^GB812,4,4,B,0^FS
^FO244,423^GB4,225,4,B,0^FS
^FO0,774^GB812,5,5,B,0^FS
^FO0,1013^GB812,14,14,B,0^FS
^FO629,1147
^GFA,00969,00969,019,FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
F0000000000001F8000000000000F000000000
F0000000000001F8000000000000F000000000
F0000000003F81F83FC000000000F000000000
F0000000003F81F83FC000000000F000000000
F000000000FFF9F9FFF000000000F000000000
F000000000FFF9F9FFF000000000F000000000
F000000000FFFFFFFFFC00000000F000000000
F000000000FFFFFFFFFC00000000F000000000
F000000000F07FFFF0FC00000000F000000000
F000000000F07FFFF0FC00000000F000000000
F000000000FC1FFFC3F000000000F000000000
F000000000FC1FFFC3F000000000F000000000
F000000000FFFFFFFFF000000000F000000000
F000000000FFFFFFFFF000000000F000000000
F0000000003FFFFFFFC000000000F000000000
F0000000003FFFFFFFC000000000F000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000
F00000000001FFFFF00000000000F000000000
F00000000001FFFFF00000000000F000000000
F00000000003FFF9FC0000000000F000000000
F00000000003FFF9FC0000000000F000000000
F0000000003FE1F87FC000000000F000000000
F0000000003FE1F87FC000000000F000000000
F000000000FF81F83FF000000000F000000000
F000000000FF81F83FF000000000F000000000
F000000000FE01F803F000000000F000000000
F000000000FE01F803F000000000F000000000
F000000000F001F800F000000000F000000000
F000000000F001F800F000000000F000000000
F0000000000001F8000000000000F000000000
F0000000000001F8000000000000F0FFDC1C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF0FFDC1C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF00C1E3C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF00C1E3C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF00C1A2C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF00C1B6C00
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF00C1B6C00
0000000000000000000000000000000C1B6C00
0000000000000000000000000000000C19CC00
0000000000000000000000000000000C19CC00
0000000000000000000000000000000C19CC00
0000000000000000000000000000000C188C00
00000000000000000000000000000000000000
00000000000000000000000000000000000000
00000000000000000000000000000000000000
^DN
^XZ
I can put that in a file in the IFS and then use CPY from IFS to file/member in e.g. QGPL/PRTIFSFILE
and follow by CPYF from file/member to QSYSPRT and print it on a SATO CL4NXPlus, the label gets correct printed.

I use this code here to do the base64 decode in the IBM i:

Code: Select all

 
   // Local fields
   Dcl-s B64Data         varchar(8192);
   Dcl-s ZPL_ASCII      char(8192);
   Dcl-s ZPL_EBCDIC      char(8192);
   Dcl-s ZPLLength       int(10);

   Dcl-s  x int(10);

   Dcl-s PrtArray varchar(132) Dim(*AUTO: 999);

   B64Data = %trimr(jsonDoc2.SHIPMENTRESPONSE.SHIPMENTRESULTS.
   PACKAGERESULTS.SHIPPINGLABEL.GRAPHICIMAGE);

   // Decode from Base64
   ZPLLength = base64_decode(%addr(B64Data:*data):
   %len(%trimr(B64Data)):
   %addr(ZPL_ASCII):
   %size(ZPL_ASCII));

   // Translate from ASCII to EBCDIC
    ZPL_EBCDIC=ZPL_ASCII;
   rc = HTTP_xlate(%len(%trim(ZPL_EBCDIC)):ZPL_EBCDIC:TO_EBCDIC);

   if rc = -1;             // -1 = error, 0=success
      retVal = *Off;
   EndIf;

The problem is that base64_decode omits already data at the beginning.

The base64 encoded string looks like this:

Cl5YQQ0KXkxSTg0KXk1OWQ0KXk1GTixODQpeTEgxMCwxMg0KXk1DWQ0KXlBPSQ0KXlBXODEyDQpeQ0kyNw0KXkZPMTUsN15BME4sMjAsMjReRlZUSU0gTEFNRVJTXkZTDQpeRk8xNSwyN15BME4sMjAsMjReRlY0MTQ4MzEzNTIzXkZTDQpeRk8xNSw0N15BME4sMjAsMjReRlZGUkVEIFVTSU5HRVIsIElOQy5eRlMNCl5GTzE1LDY3XkEwTiwyMCwyNF5GVjEwMzAgTiBEUiBNTCBLSU5HIEpSIERSXkZTDQpeRk8xNSw4N15BME4sMjAsMjReRlZNSUxXQVVLRUUgIFdJIDUzMjAzXkZTDQpeRk8xNSwxNDJeQTBOLDI4LDMyXkZWU0hJUCBUTzogXkZTDQpeRk82MSwxNjZeQTBOLDI4LDMyXkZWQy9PIENMRUFSVklFVywgUk0gQS0zMDZeRlMNCl5GTzYxLDE5NF5BME4sMjgsMzJeRlZST0JFUlQgUC4gRkFSTkFNXkZTDQpeRk82MSwyMjJeQTBOLDI4LDMyXkZWMTk4IENPVU5UWSBST0FEIERGXkZTDQpeRk82MSwyNTFeQTBOLDQ1LDQ0XkZWSlVORUFVICBXSSAgNTMwMzleRlMNCl5GTzQ0Niw5XkEwTiwzMCwzNF5GVjUgTEJTXkZTDQpeRk82ODMsOV5BME4sMjgsMzJeRlYxIE9GIDFeRlMNCl5GTzU5OSwzNjleQTBOLDU2LDU4XkZWU0FNUExFXkZTDQpeRk8xMDYsNDUyXkEwTiwzMCwzNF5GVlVQU15GUw0KXkZPNjQsNDgyXkEwTiwzMCwzNF5GVk1BWElDT0RFXkZTDQpeRk8zOCw1MTJeQTBOLDMwLDM0XkZWUFJJTlRTIEhFUkVeRlMNCl5GTzMwMCw0MzZeQTBOLDMwLDM0XkZWVVBTIFJPVVRJTkcgQ09ERSBQUklOVFMgSEVSRV5GUw0KXkZPMjcwLDUyNF5BME4sMjgsMzJeRlZVUFMgUE9TVEFMIEJBUkNPREUgUFJJTlRTIEhFUkVeRlMNCl5GTzEwLDEwMzFeQTBOLDIyLDI2XkZWQklMTElORzogUC9QXkZTDQpeRk80MTYsMTAzMV5BME4sNDQsMzZeRlZTQU1QTEVeRlMNCl5GTzE3NSwxMjAzXkEwTiwxNCwyMF5GVlhPTCAyNC4wMy4wNyAgICAgICAgICBOVjQ1IDEwLjBBIDAzLzIwMjQqXkZTDQpeRk85LDY3MF5BME4sNTYsNTheRlZVUFMgR1JPVU5EXkZTDQpeRk85LDczMV5BME4sMjQsMjheRlZUUkFDS0lORyAjOiBVUFMgVFJBQ0tJTkcgTlVNQkVSIFBSSU5UUyBIRVJFXkZTDQpeRk81OSw4NzNeQTBOLDMwLDM0XkZWVVBTIFRSQUNLSU5HIE5VTUJFUiBCQVJDT0RFIFBSSU5UUyBIRVJFXkZTDQpeRk82ODksNjUwXkdCMTI0LDEyNSwxMjQsQiwwXkZTDQpeRk8wLDY0OF5HQjgxMSwxNCwxNCxCLDBeRlMNCl5GTzAsNDIzXkdCODEyLDQsNCxCLDBeRlMNCl5GTzI0NCw0MjNeR0I0LDIyNSw0LEIsMF5GUw0KXkZPMCw3NzReR0I4MTIsNSw1LEIsMF5GUw0KXkZPMCwxMDEzXkdCODEyLDE0LDE0LEIsMF5GUw0KXkZPNjI5LDExNDcKXkdGQSwwMDk2OSwwMDk2OSwwMTksRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDAwMDAwMDAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwMDAwMDAwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkYwMDAwMDAwMDAwMDAxRjgwMDAwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDAwMUY4MDAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGODFGODNGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRjgxRjgzRkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGOUY5RkZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZGRjlGOUZGRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRkZGRkZGRkZDMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGRkZGRkZGQzAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEYwN0ZGRkYwRkMwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGMDdGRkZGMEZDMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkMxRkZGQzNGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZDMUZGRkMzRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRkZGRkZGRkYwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGRkZGRkZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGRkZGRkZGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRkZGRkZGRkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwMDAwMDAwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDFGRkZGRjAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDAxRkZGRkYwMDAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAwM0ZGRjlGQzAwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDNGRkY5RkMwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGRTFGODdGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRkUxRjg3RkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkY4MUY4M0ZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZGODFGODNGRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRTAxRjgwM0YwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkUwMUY4MDNGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEYwMDFGODAwRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGMDAxRjgwMEYwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDAwMUY4MDAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDAwMDFGODAwMDAwMDAwMDAwMEYwRkZEQzFDMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMEZGREMxQzAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwQzFFM0MwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMEMxRTNDMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDBDMUEyQzAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwQzFCNkMwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMEMxQjZDMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBDMUI2QzAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwQzE5Q0MwMA0KMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMEMxOUNDMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBDMTlDQzAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwQzE4OEMwMA0KMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0KXkRODQpeWFoNCg==

The decoded string in hex has a CR/LF 0D 0A at the beginning in the first line
and then the different following printer language commands also end with CRLF.

B64Data:
Cl5YQQ0KXkxSTg0KXk1OWQ0KXk1GTixODQpeTEgxMCwxMg0KXk1D......
ZPL_ASCII:
0A5E58410D0A5E4C524E0D0A5E4D4E590D0A5E......
it should be:
0D0A5E58410D0A5E4C524E0D0A5E4D4E590D0A5E......


The returned decoded string begins with 0A = LF, the CR=0D is missing for the first line.

Then each printer command line is there, followed by a CRLF as it should be.
Then suddenly in line 41 where is
^FO629,1147 that is only followed by LF, the CR is missing again.
And then until the end of the command string each line is terminated by CRLF again.

The translate from ASCII to EBCDIC works, but the problem is that base64_decode omits 2 CR's.
I am scratching my head why and have no idea.

I tried the decode in Python, works...

Code: Select all

import base64
mystr = 'Cl5YQQ0KXkxSTg0KXk1OWQ0KXk1GTixODQpeTEgxMCwxMg0KXk1DWQ0KXlBPSQ0KXlBXODEyDQpeQ0kyNw0KXkZPMTUsN15BME4sMjAsMjReRlZUSU0gTEFNRVJTXkZTDQpeRk8xNSwyN15BME4sMjAsMjReRlY0MTQ4MzEzNTIzXkZTDQpeRk8xNSw0N15BME4sMjAsMjReRlZGUkVEIFVTSU5HRVIsIElOQy5eRlMNCl5GTzE1LDY3XkEwTiwyMCwyNF5GVjEwMzAgTiBEUiBNTCBLSU5HIEpSIERSXkZTDQpeRk8xNSw4N15BME4sMjAsMjReRlZNSUxXQVVLRUUgIFdJIDUzMjAzXkZTDQpeRk8xNSwxNDJeQTBOLDI4LDMyXkZWU0hJUCBUTzogXkZTDQpeRk82MSwxNjZeQTBOLDI4LDMyXkZWQy9PIENMRUFSVklFVywgUk0gQS0zMDZeRlMNCl5GTzYxLDE5NF5BME4sMjgsMzJeRlZST0JFUlQgUC4gRkFSTkFNXkZTDQpeRk82MSwyMjJeQTBOLDI4LDMyXkZWMTk4IENPVU5UWSBST0FEIERGXkZTDQpeRk82MSwyNTFeQTBOLDQ1LDQ0XkZWSlVORUFVICBXSSAgNTMwMzleRlMNCl5GTzQ0Niw5XkEwTiwzMCwzNF5GVjUgTEJTXkZTDQpeRk82ODMsOV5BME4sMjgsMzJeRlYxIE9GIDFeRlMNCl5GTzU5OSwzNjleQTBOLDU2LDU4XkZWU0FNUExFXkZTDQpeRk8xMDYsNDUyXkEwTiwzMCwzNF5GVlVQU15GUw0KXkZPNjQsNDgyXkEwTiwzMCwzNF5GVk1BWElDT0RFXkZTDQpeRk8zOCw1MTJeQTBOLDMwLDM0XkZWUFJJTlRTIEhFUkVeRlMNCl5GTzMwMCw0MzZeQTBOLDMwLDM0XkZWVVBTIFJPVVRJTkcgQ09ERSBQUklOVFMgSEVSRV5GUw0KXkZPMjcwLDUyNF5BME4sMjgsMzJeRlZVUFMgUE9TVEFMIEJBUkNPREUgUFJJTlRTIEhFUkVeRlMNCl5GTzEwLDEwMzFeQTBOLDIyLDI2XkZWQklMTElORzogUC9QXkZTDQpeRk80MTYsMTAzMV5BME4sNDQsMzZeRlZTQU1QTEVeRlMNCl5GTzE3NSwxMjAzXkEwTiwxNCwyMF5GVlhPTCAyNC4wMy4wNyAgICAgICAgICBOVjQ1IDEwLjBBIDAzLzIwMjQqXkZTDQpeRk85LDY3MF5BME4sNTYsNTheRlZVUFMgR1JPVU5EXkZTDQpeRk85LDczMV5BME4sMjQsMjheRlZUUkFDS0lORyAjOiBVUFMgVFJBQ0tJTkcgTlVNQkVSIFBSSU5UUyBIRVJFXkZTDQpeRk81OSw4NzNeQTBOLDMwLDM0XkZWVVBTIFRSQUNLSU5HIE5VTUJFUiBCQVJDT0RFIFBSSU5UUyBIRVJFXkZTDQpeRk82ODksNjUwXkdCMTI0LDEyNSwxMjQsQiwwXkZTDQpeRk8wLDY0OF5HQjgxMSwxNCwxNCxCLDBeRlMNCl5GTzAsNDIzXkdCODEyLDQsNCxCLDBeRlMNCl5GTzI0NCw0MjNeR0I0LDIyNSw0LEIsMF5GUw0KXkZPMCw3NzReR0I4MTIsNSw1LEIsMF5GUw0KXkZPMCwxMDEzXkdCODEyLDE0LDE0LEIsMF5GUw0KXkZPNjI5LDExNDcKXkdGQSwwMDk2OSwwMDk2OSwwMTksRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDAwMDAwMDAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwMDAwMDAwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkYwMDAwMDAwMDAwMDAxRjgwMDAwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDAwMUY4MDAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGODFGODNGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRjgxRjgzRkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGOUY5RkZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZGRjlGOUZGRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRkZGRkZGRkZDMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGRkZGRkZGQzAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEYwN0ZGRkYwRkMwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGMDdGRkZGMEZDMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkMxRkZGQzNGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZDMUZGRkMzRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRkZGRkZGRkYwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkZGRkZGRkZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGRkZGRkZGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRkZGRkZGRkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwMDAwMDAwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMDAwMDAwMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDFGRkZGRjAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDAxRkZGRkYwMDAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAwM0ZGRjlGQzAwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDNGRkY5RkMwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDNGRTFGODdGQzAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDAzRkUxRjg3RkMwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkY4MUY4M0ZGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEZGODFGODNGRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGRTAxRjgwM0YwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwRkUwMUY4MDNGMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMEYwMDFGODAwRjAwMDAwMDAwMEYwMDAwMDAwMDANCkYwMDAwMDAwMDBGMDAxRjgwMEYwMDAwMDAwMDBGMDAwMDAwMDAwDQpGMDAwMDAwMDAwMDAwMUY4MDAwMDAwMDAwMDAwRjAwMDAwMDAwMA0KRjAwMDAwMDAwMDAwMDFGODAwMDAwMDAwMDAwMEYwRkZEQzFDMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMEZGREMxQzAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwQzFFM0MwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMEMxRTNDMDANCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMDBDMUEyQzAwDQpGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjAwQzFCNkMwMA0KRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYwMEMxQjZDMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBDMUI2QzAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwQzE5Q0MwMA0KMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMEMxOUNDMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBDMTlDQzAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwQzE4OEMwMA0KMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0KXkRODQpeWFoNCg=='
mystr_decoded = base64.b64decode(mystr).decode('utf-8')
print(mystr_decoded)
 
If all fails I could call the decoding in Python on the IBM i, I saw that Richard Schoen has a QSHONI which allows calling Python from ILERPG,
but I am not willing to give up on the base64_decode so easy...

Has anybody an idea what to check, to do different ?

Thanks for looking into this,

Peter
jonboy49
Posts: 206
Joined: Wed Jul 28, 2021 8:18 pm

Re: base64_decode omitting CR=0D

Post by jonboy49 »

Maybe this thread has some possible answers?

https://www.scottklement.com/forums/vie ... se64#p1756
PeterLanghammer
Posts: 3
Joined: Thu Feb 22, 2024 8:07 pm

Re: base64_decode omitting CR=0D

Post by PeterLanghammer »

Thanks for pointing that out. I did read all the posts about base64 on this forum,
but I didn't get a solution from that, at least I didn't see one.
PeterLanghammer
Posts: 3
Joined: Thu Feb 22, 2024 8:07 pm

Re: base64_decode omitting CR=0D

Post by PeterLanghammer »

Just found something.
Please ignore this post for now,
don't want to waste anybody's time,
need to do some review.
Post Reply