libidn2 bug in Windows Unicode build #7228
Comments
jay
added a commit
to jay/curl
that referenced
this issue
Jun 14, 2021
- For Windows Unicode builds of libcurl that use libidn, attempt to convert the hostname from UTF-8 and if that fails use local encoding as a fallback. Prior to this change Windows Unicode builds that use libidn attempted to convert the hostname from the local encoding only. The curl tool passes the command-line URL (and therefore the hostname) in Unicode's UTF-8 encoding, so the conversion would fail. Since other applications may pass locally encoded URLs to libcurl we'll keep local encoding as a fallback. Reported-by: dEajL3kA@users.noreply.github.com Assisted-by: Viktor Szakats Fixes curl#7228 Closes curl#7246 Closes #xxxx
vszakats
added a commit
to vszakats/curl
that referenced
this issue
Jun 15, 2021
Unicode Windows builds use UTF-8 strings internally in libcurl, so make sure to call the UTF-8 flavour of the libidn2 API. Reported-by: dEajL3kA on github Assisted-by: Jay Satiro Reviewed-by: Marcel Raad Fixes curl#7228
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I think in Windows Unicode build of curl we should be calling the
idn2_lookup_u8()function of libidn2, instead ofidn2_lookup_ul()function. That is because in Windows Unicode build all internalchar*strings in curl are always encoded in UTF-8 (apprently curl converts given CLI arguments from UTF-16 to UTF-8 internally), but theidn2_lookup_ul()function assumes the system "default" encoding - which on most Windows systems is something like Windows-1252 codepage, not UTF-8. Hence libidn2 fails to decode the UTF-8 string. Replacing call toidn2_lookup_ul()withidn2_lookup_u8()inurl.cfixes this for me.Thank you and best regards.
The text was updated successfully, but these errors were encountered: