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 19:03:23 +0100
Er, I was distracted by being called for supper. The astute reader will note that the bytes I gave as the UTF-8 encoding were actually UCS2-LE.
Which doesn't negate the fact that we still need to care about legacy character sets unless we just want to be buggy for all non-ASCII content, surely?
On 20 July 2022 18:05:41 BST, David Woodhouse via curl-library <curl-library_at_lists.haxx.se> 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.
>
>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".
>
Date: Wed, 20 Jul 2022 19:03:23 +0100
Er, I was distracted by being called for supper. The astute reader will note that the bytes I gave as the UTF-8 encoding were actually UCS2-LE.
Which doesn't negate the fact that we still need to care about legacy character sets unless we just want to be buggy for all non-ASCII content, surely?
On 20 July 2022 18:05:41 BST, David Woodhouse via curl-library <curl-library_at_lists.haxx.se> 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.
>
>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.htmlReceived on 2022-07-20