Re: libidn2 extension for php

hi Gustavo, On Fri, Nov 18, 2011 at 11:19 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote: > Em Fri, 18 Nov 2011 09:13:27 -0000, Sven Kowalski <sk01@planet-ic.de> > escreveu: > >> thanks for that tutorial. I got the compiling process working now. I've >> now the intl with ICU 4.8.1.1. But the result is still the same. fußball >> still becomes fussball. I expect that fußball becomes xn--fuball-cta. >> So intl is still not usable for me. Because the IDNA 2008 standard is now >> supported with ICU 4.8.1.1. >> > > Yes, it would appear the extension needs some changes. We're using the IDNA > 2003 API exclusively. See > http://icu-project.org/apiref/icu4c/uidna_8h.html Damned, now that was confusing. I was reading this doc but never saw something saying that 2008 is only with the new APIs. > Possibly the best course of action would be to follow the ICU API and create > a new class in the intl extension with labelToASCII > (uidna_labelToASCII_UTF8), labelToUnicode (uidna_labelToUnicodeUTF8), > nameToASCII (uidna_nameToASCII_UTF8) and nameToUnicode > (uidna_nameToUnicodeUTF8). If it is actually correct to use the new API, then I would rather do it now and by updating the current implementation in INTL. There is no need to add new functions or classes for that, we should support 2008 per default using the current IDN functions. Another possible bug is the RTL support. > However, I don't know receptive people are to add such a change to PHP 5.4 > at this point. Another option would be to do it in trunk exclusively and > sync PECL intl with it. It is more a bug fix, which can be related to security as well (spoofing attacks). If it is actually correct to use the new API and fully 2003-2008 compliant, then I will use the new API directly. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org