SRP_Encode

KDIV

Is SRP_Encode 'HEX' algorithm parameter used for 8bit encoding?
Content-Type: application/xop+xml; type="text/xml"; charset=UTF-8
Content-Transfer-Encoding: 8bit
Thanks,

KevinFournier

No. SRP_Encode is used to encode binary data into textual strings suitable for transmission. It does not deal with character encoding within strings. OpenInsight already has routines for manipulating the underlining encoding of strings. ANSI_UTF8, for example, converts your string from an ANSI encoded string to a UTF8 encoded string. UTF8_Unicode converts from UTF8 to Unicode. And so on.

The real question is: what is the default encoding OI uses? It all depends on your Application Properties. If you check the "UTF8 character mode" checkbox, then the default encoding is UTF8. If not, then it is ANSI. You can view the Application Properties via the File menu of OI's Application Manager window.

KDIV

Thank you Kevin, if I may expand on the question; if the "UTF8 character mode" checkbox is checked in Application Properties, does that mean that the string I send via XML is already UTF8 encoded and I do not need to convert via ANSI_UTF8? the end game is to send the XML string as 8bit encoding. Regards,

KevinFournier

Correct. You're all set.

KDIV

Great, thanks Kevin! I'm on a roll; if I may try another!? If application was created w/o the UTF8 checkbox in application properties, if I change the setting to UTF8 now, is there anything I need to look for regarding ANSI to UTF8 issues that could backfire? This is an AREV32 application, with a handful of OI forms/SSPs that have been development but at this point I cannot see anything mission-critical. Users are really on the AREV32 application, whereas this XML/OLE project is being developed in OI v9.4, Win8 PRO, is there anything I should look for that could negatively impact the application if I made this setting change? Thank you.

KevinFournier

UTF8 is backward compatible with most of ANSI. Moreover, OI doesn't care about the raw data until it needs to display it on a form. So, no code changes are needed and your data will be fine. Once you start putting characters in other languages into a form's EDITFIELD, then OI will encode those letters into UTF8.

OLE uses Unicode (UTF16) strings, so OI will convert your variables into that before passing them in, in which case, it will assume your string is UTF8 encoded. Again, this is not likely to be an issue wince AREV32 didn't natively support UTF8 to begin with. So, unless your original ANSI string is includes Char(194), Char(226), or Char(240), you won't see anything weird.

KDIV

Thank you Kevin, your explanation was very helpful. Regards,

KDIV

Kevin - if I may ask another question, it is related to the above questions but a different question. Any suggestions on a FUNCTION or UTILITY that will convert a scanned document in .pdf format to 8bit char or UTF-8. Can I actually use OI's ANSI to UTF8 function? I did not think so, as the scanned document is an "image" vs ANSI string code. TIA for your help.

KevinFournier

You need a third party OCR library to convert a scanned document to text. I personally don't have a recommendation, but perhaps some of our other forum users do. I'll ask the guys in the office to chime in with suggestions.

KDIV

Thanks, I would prefer to use something that someone has already used with OI (v9.4) vs hacking an unknown aspect.

DonBakke

Based on your response to Kevin, it seems like he understands what you want to accomplish but I wasn't as certain. For my own sake, can you confirm that you are looking to OCR a scanned image so that it will become identifiable text?

KDIV

pickup a document in .pdf format from a folder on the server and send that electronically, requirements for sending or XML for header and most of the body, the "image" has to be encoded to an 8bit char file that is a part of the XML stream. Does that clarify better? As well, I have a 3mb filesize limit for the transmission so some documents will have to be broken up and the document could be 1 or more pages, so I have check for the number of "pages" and then determine total filesize.

DonBakke

I think what you are being asked to do is encode the binary file into a format that is safe to include within XML. A common solution is to encode using Base64, which would give you an 8-bit character format.

KDIV

Unfortunately CBSA(Canada Customs) specifically stated NOT(BASE64), they said and I quote, "The image must be in binary format. Please do not base64 encode this part of the MIME document or the transaction will fail.". The "image" per CBSA are the scanned customs dec pages declaring the goods crossing the border by the logistics company. I agree and was planning on using SRP utilities, as at first read, fairly simple, but CBSA (page #17 of the SWI-PRN document for project specifications) has added requirements that do not make sense at this point, but I guess they have their reasons. I had originally planned on just getting the filename from its folder SRP_Encode/Decode the document section of the XML stream, loop if multi-page; --- but no base64, air let out of my sails. Then considered getting the document(s) could be one or many, scanned by the logistics warehouse, into a folder in a .pdf format) from the folder pick up the .pdf and ANSI_UTF8, but I do not think a .pdf file would be considered ANSI, I already tried it and it did not look right. in the ANSI_UTF8 function, what part of the .pdf document would be considered a delimiter, but that parm is optional, still tried and it did not look correct. I do have an example of what CBSA wants in a .txt file, so trying to figure it out.

KDIV

at this point, I think I just need to take a step back and re-examine all the processes, unfortunately, I am without project specs of the client application, at this point, I do not know if the client will be storing the image in an OI file or just the filename, I am still waiting for an answer to that question and I have to funnel technical questions via the client to technical support of CBSA as CBSA complained to the client (GM) of too many questions from both developers working on the project. I am working on the MIME construct and another developer is working on the front end.

DonBakke

I tried to retrieve documentation based on the information you provided. I assume this is related to the Single Window Initiative. Unfortunately, this information isn't publicly available. You probably have no choice but to re-examine this or wait for more details. Even a sample XML document would be helpful.

KDIV

Yes Don, this is SWI for CBSA, I forwarded the email I sent to Kevin to you, there were three attachments. I have determined from the client today; I will receive the filename and path of where a scanned document will reside. I need to pick up the document from its location on the stored path/drive/harddisk, multi-part MIME, setup the XML and encode to 8bit binary. So far, I have determined only four "brokers" have deployed SWI, but as of Jan 1st 2019 all Canadian brokers must comply with SWI, so most are in a race to get there. In addition many NAFTA changes to legacy application, so Canadian brokers are feeling the heat. SWI was suppose to have gone "LIVE" 01.01.18 - but that did not happen.