[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ftpapi] At my wits end



The base64 service program does not care anything about the ccsid of the input/output data. It also does not know anything about ASCII or EBCDIC.

 

It just takes the input data as a stream of bytes and encodes them to BASE64. The hex values of the characters of a Base64 stream (the encoded data), are the same for all code pages. Hence they can be decoded to the original data on every system, regardless of the code page of that system.

 

When you wrote your data to an IFS file with code page 819, how did you read it? Did you read it as a binary data or text data? When you read it as text data, then it has been converted back to EBCDIC in your program and you did not won anything.

 

The same is with SQL function SYSTOOLS.BASE64ENCODE(). You need to convert your data to the target code page (most likely utf-8 or 819) before encoding it to Base64.

 

You may check the IBM ivonc() function or Scott’s HTTP_xlatedyn() for converting your data to utf-8 before passing it to Base64_encode() or the SQL function.

 

You can check the result of the encoding operation with one of the various online encoders/decoders, such as https://www.base64decode.org/.

 

Thomas.
 

Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Braden Lincoln
Gesendet: Dienstag, 17.
November 2020 15:40
An: FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Betreff: Re: [Ftpapi] At my wits end

 

Thanks, Kevin, but I tried that approach as well.  Moved my base64 encoding to the point after I wrote/read the file from IFS.  Same issue.  Maybe 819 isn't the code page I should be using?  But Somehow I thought I had seen comments floating in the internet that the base64 encoding service program was meant to be used with EBCDIC data.  I could be mistaken.  I also tried sending the string just after encoding to base64, without writing to IFS and reading again.  Same bad result.

 

On Tue, Nov 17, 2020 at 6:31 AM Kevin Bucknum <Kevin@xxxxxxxxxxxxxxxxxxx> wrote:

It will need to be ASCII/UTF/etc before you encode it. Translate it before you base64 encode it.

 

On Tue, 2020-11-17 at 06:09 -0800, Braden Lincoln wrote:

Hoping someone can help.  I have overcome all the connectivity issues with this SOAP web service I am connecting to.  And I can even send the file payload.  But the encoding of the data is just wrong, and I can't seem to find the magic solution.

 

I've tried sending the raw data as a string.  Server rejects it immediately with http 500 error.  It suggested it was not "properly base64 encoded data".  So, I downloaded and installed the BASE64 encoding service program from Scott.  I encoded the string, and it went through, http 200, we thought we were home free. But the data on the receiving server was garbled - apparently not encoded in a way that they could decode it correctly.  I thought maybe it was an EBCDIC/ascii issue, so i decided to write the encoded string to the IFS using code page 819, then read it back in and send it.  Same result.

 

I've tried every which way I can think of (which is apparently just short of enough).  I need some expert advice on how to get this string to the receiver correctly.

 

Attached are the program source, the http log (where the request string can be seen), and the garbled mess from the receiving server.  Hoping for some sage advice.  Thanks in advance. 

 

https://www.medtronsoftware.com/img/MedtronMinilogo.bmp  Kevin  Bucknum
                   Senior Programmer Analyst
                   MEDDATA / MEDTRON
                   120 Innwood Drive
                   Covington LA 70433
                   Local: 985-893-2550
                   Toll Free: 877-893-2550
                 
https://www.medtronsoftware.com

 

CONFIDENTIALITY NOTICE

This document and any accompanying this email transmission contain confidential information, belonging to the sender that is legally privileged.  This information is intended only for the use of the individual or entity named above.  The authorized recipient of this information is prohibited from disclosing this information to any other party and is required to destroy the information after its stated need has been fulfilled.  If you are not the intended recipient, or the employee of agent responsible to deliver it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or action taken in reliance on the contents of these documents is STRICTLY PROHIBITED.  If you have received this email in error, please notify the sender immediately to arrange for return or destruction of these documents.

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi

-- 
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi