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".
smime.p7s
Description: S/MIME cryptographic signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
