Hi Gustavo! Thanks for the quick action :)
I prefer however the 1st solution so that the code using the function can use transparently the returned value. At some point we may add classes as well, for those interested in more details. Cheers, On Nov 21, 2011 4:53 AM, "Gustavo Lopes" <glo...@nebm.ist.utl.pt> wrote: > On Fri, 18 Nov 2011 13:12:01 -0000, Pierre Joye <pierre....@gmail.com> > wrote: > > >> 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. >> > > I've patched intl to support the new ICU API, adding another parameter to > the functions so they assume either the current behavior or call the new > API. > > Example: > > var_dump(idn_to_ascii("www.**fußball.com <http://www.fussball.com>", > IDNA_NONTRANSITIONAL_TO_ASCII, IDNA_VARIANT_UTS46)); > > array(3) { > ["result"]=> > string(22) "www.xn--fuball-cta.com" > ["isTransitionalDifferent"]=> > bool(true) > ["errors"]=> > int(0) > } > > However there's a little problem. The new interface reports errors via the > usual ICU mechanism AND it also uses a new structure to pass IDNA specific > errors. Also, it reports whether the use of the transitional mechanism > affects the result. So I see only two solutions so that that extra > information is passed to the PHP user. > > * Add a second new parameter, by reference, wherein this extra information > is written. > * Instead of returning a string, return an array with all the new > information. > > In the patched attached I've gone for the second one, but I'm now more > inclined to the first. So if no one objects, I'm going to change that > detail, add a few tests and commit to 5.3, 5.4 and trunk somewhere this > next week. > > -- > Gustavo Lopes > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >