Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Is EBCDIC support gone?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 21 Jul 2022 01:49:04 +0200
On 7/20/22 19:05, David Woodhouse wrote:
> On Wed, 2022-07-20 at 12:29 +0200, Patrick Monnerat via curl-library wrote:
>> On 7/20/22 12:11, Daniel Stenberg via curl-library wrote:
>>> On Wed, 20 Jul 2022, Stephan Mühlstrasser via curl-library wrote:
>>>> Do I understand it correctly that EBCDIC support is gone now in general?
>>> Yes, that is correct.
>> This is true: libcurl internally only works on ASCII-based character sets.
> Hm, I don't understand how "works on ASCII-based character sets" is a
> thing that makes sense to say.
An ASCII-based character set is a superset of 7-bit ASCII.
This is the case for legacy 8-bit charsets and UTF-8. And wider Unicode
sets match ASCII for codes < 128.
This is NOT the case for any of the many variants of EBCDIC.
libcurl source code does not contain any non-ASCII character, does not
recognize them as such and never generates them. If seen from the
network or in an API parameter, they are considered as opaque (i.e.:
binary data) and never match a constant in some internal test.
As a consequence, it may be needed to convert or escape them in
accordance with protocol and context in use (base64, quoted-printable,
RFC2047, etc). If not, data must match what the server expects. However
the ENORMOUS advantage is you can be sure the sent/received bits will
exactly match what's on the other side!
Similarly, local file names must be passed in the encoding expected by
the file system API, like in any other encoding-unaware application.
In short, libcurl is CS-agnostic outside the 7-bit ASCII character set.
>
> In any setup that actually *works,* EBCDIC is just a trivially-special
> case of the general case of needing conversion.
No, this is not true: first it ALWAYS require code conversion to match
the protocols while libcurl never does it.
Next, there are other discrepancies that, in absence of conversion, need
a special processing, like letters being not consecutive for example.
What you mean by *works,* is in fact "full cs aware": libcurl *works*
perfectly without performing charcode conversions that can be done by
the caller, when needed.
Date: Thu, 21 Jul 2022 01:49:04 +0200
On 7/20/22 19:05, David Woodhouse wrote:
> On Wed, 2022-07-20 at 12:29 +0200, Patrick Monnerat via curl-library wrote:
>> On 7/20/22 12:11, Daniel Stenberg via curl-library wrote:
>>> On Wed, 20 Jul 2022, Stephan Mühlstrasser via curl-library wrote:
>>>> Do I understand it correctly that EBCDIC support is gone now in general?
>>> Yes, that is correct.
>> This is true: libcurl internally only works on ASCII-based character sets.
> Hm, I don't understand how "works on ASCII-based character sets" is a
> thing that makes sense to say.
An ASCII-based character set is a superset of 7-bit ASCII.
This is the case for legacy 8-bit charsets and UTF-8. And wider Unicode
sets match ASCII for codes < 128.
This is NOT the case for any of the many variants of EBCDIC.
libcurl source code does not contain any non-ASCII character, does not
recognize them as such and never generates them. If seen from the
network or in an API parameter, they are considered as opaque (i.e.:
binary data) and never match a constant in some internal test.
As a consequence, it may be needed to convert or escape them in
accordance with protocol and context in use (base64, quoted-printable,
RFC2047, etc). If not, data must match what the server expects. However
the ENORMOUS advantage is you can be sure the sent/received bits will
exactly match what's on the other side!
Similarly, local file names must be passed in the encoding expected by
the file system API, like in any other encoding-unaware application.
In short, libcurl is CS-agnostic outside the 7-bit ASCII character set.
>
> In any setup that actually *works,* EBCDIC is just a trivially-special
> case of the general case of needing conversion.
No, this is not true: first it ALWAYS require code conversion to match
the protocols while libcurl never does it.
Next, there are other discrepancies that, in absence of conversion, need
a special processing, like letters being not consecutive for example.
What you mean by *works,* is in fact "full cs aware": libcurl *works*
perfectly without performing charcode conversions that can be done by
the caller, when needed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-07-21