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: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 20 Jul 2022 18:05:41 +0100
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.
If there is *any* legacy 8-bit character set in use, whether it's
ASCII-based or not, we still have to take care with conversions,
surely?
In OpenConnect I have specific tests for this kind of thing. I have a
test client cert with a password 'ĂŻ', which is two characters:
U+0102 LATIN CAPITAL LETTER A WITH BREVE
U+017B LATIN CAPITAL LETTER Z WITH DOT ABOVE
In UTF-8 that's represented by the bytes 0x02 0x01 0x7b 0x01.
In ISO8859-2 it would just be two bytes: 0xc3 0xaf.
I have tests which set $LANG and try to use the correct password. You
can't just say they're both "ASCII-based" and pray to the deity of your
choice, surely?
In any setup that actually *works,* EBCDIC is just a trivially-special
case of the general case of needing conversion.
If it only works for 7-bit ASCII characters, that isn't "works".
Received on 2022-07-20
Date: Wed, 20 Jul 2022 18:05:41 +0100
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.
If there is *any* legacy 8-bit character set in use, whether it's
ASCII-based or not, we still have to take care with conversions,
surely?
In OpenConnect I have specific tests for this kind of thing. I have a
test client cert with a password 'ĂŻ', which is two characters:
U+0102 LATIN CAPITAL LETTER A WITH BREVE
U+017B LATIN CAPITAL LETTER Z WITH DOT ABOVE
In UTF-8 that's represented by the bytes 0x02 0x01 0x7b 0x01.
In ISO8859-2 it would just be two bytes: 0xc3 0xaf.
I have tests which set $LANG and try to use the correct password. You
can't just say they're both "ASCII-based" and pray to the deity of your
choice, surely?
In any setup that actually *works,* EBCDIC is just a trivially-special
case of the general case of needing conversion.
If it only works for 7-bit ASCII characters, that isn't "works".
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pkcs7-signature attachment: smime.p7s