× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hello,

What it does is the following steps:

1) Translates your data from EBCDIC to whatever character encoding you've asked it to use.  (You control the encoding via HTTP_setCCSIDs or HTTP_setOption).

2) Finds any characters in the encoding you've specified that need to be encoded and translates them to a percent encoding (aka url-encoding)

3) Converts it back to EBCDIC and gives it to your application.

Is that not what you're asking for?  Your input isn't EBCDIC?

If you are encoding something and getting back two hex values for the encoding, then you likely have your network CCSID set to 1208 (UTF-8).  This is correct behavior for 1208.  If you want to use something like 1252 (which is obsolete -- but -- still supported) then you have failed to tell HTTPAPI that via HTTP_setOption or HTTP_setCCSIDs.

If you're saying "HTTPAPI already does that"...  I don't know what to say to that, HTTPAPI doesn't automatically encode anything, you have to TELL it to do so by calling one of the URL encode routines (or the "WEBFORM" routines which are really the same routines.)  It'd never "just assume" you want something encoded as there are a plethora of situations where APIs don't use/want this type of encoding.

-SK


On 6/21/2024 9:50 PM, James Lampert via MIDRANGE-L wrote:
On Fri, Jun 21, 2024 at 7:19 PM Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx> wrote:
Use the http_urlEncode() routine in HTTPAPI.
Really? I'd looked at it (and its various friends) in the source
member, and it appeared that (1) it simply translated EBCDIC, and (2)
it was what HTTPAPI was already using.

The web service in question is Google's geo-coding API. It works just
fine if I send it an address that's directly representable in ASCII.
But even one diacritical, and it's rejected. If I manually
percent-encode the diacritical using the charts at
https://www.w3schools.com/tags/ref_urlencode.ASP
it is accepted if I percent-encode it according to the "UTF-8" column,
but is rejected if I use the "Windows-1252" column (which is as it
should be).

It gets more interesting from there: one of the fields I'm capturing
and parsing in the reply is the "formal address" field, that
(theoretically) is a fully canonical version of the address I sent.
And by the time the reply gets translated back into EBCDIC, the
diacritical (specifically the lowercase n-tilde in "La Cañada
Flintridge") comes back as two unrelated characters.

--
JHHL

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.