php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #73824 punycode to IDN
Submitted: 2016-12-27 17:49 UTC Modified: 2017-01-23 00:15 UTC
From: spam2 at rhsoft dot net Assigned: cmb (profile)
Status: Closed Package: idn (PECL)
PHP Version: 7.0.14 OS:
Private report: No CVE-ID: None
 [2016-12-27 17:49 UTC] spam2 at rhsoft dot net
Description:
------------
http://php.net/manual/de/function.idn-to-ascii.php

that's nice to generate domain names by form-input for serverconfigurations
but it's more or less useless to replace userland code like idna_convert-class without a option to convert the punnycode back to IDN for user-readable output


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-27 23:23 UTC] cmb@php.net
-Summary: punnycode to IDN +Summary: punycode to IDN
 [2016-12-28 07:25 UTC] pollita@php.net
Did some digging and it looks like the old IDN2003 code didn't actually have a punycode->humanreadable API (Which is why it wasn't included when it was first implemented in PHP).

UTS46 does have such an API though, so it's perfectly reasonable to add at this point, but a couple consistency questions need to be thought through first:

1) Do we even include a $variant arg in the signature since we're not going to offer a 2003 variant.
2) If we include the arg for potential forward company and/or consistency with the existing APIs, do we make it default to the sensible UTS46 mode even though that differs from the existing to functions' default of IDNA2003?
3) Is it time to just switch the default of the to methods to be UTS46?
4) Would it be more expedient and far more cross-version to just reimplement the algorithm in native PHP and put it on packagist?

Basically... what's a simple request and a simple implementation (proof of concept is already working fine in my checkout) becomes a kinda sticky issue in practice.

I'll ask the mailing list about this once the spam protection stops having a fit about my emails.
 [2016-12-28 13:21 UTC] spam2 at rhsoft dot net
dunno - what i am now using for years in several admin panels is http://idnaconv.net/index.html while i would like to get rid of as much as possible 3rd party userland code because sooner or later it breaks with future PHP versions like http://www.pchart.net/ did from 7.0 to 7.1
 [2016-12-28 13:47 UTC] spam2 at rhsoft dot net
uhm that looks like a documentation problem because "idn_to_utf8" sounds more like about the difference is the output encoding but in fact it seems to translate back the punnycode generated width "idn_to_ascii"

http://php.net/manual/de/function.idn-to-utf8.php

[harry@srv-rhsoft:/mnt/data/downloads]$ php -r "echo idn_to_ascii('hüttenguide.at');"
xn--httenguide-9db.at

[harry@srv-rhsoft:/mnt/data/downloads]$ php -r "echo idn_to_utf8('xn--httenguide-9db.at');"
hüttenguide.at
 [2017-01-23 00:15 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2017-01-23 00:15 UTC] cmb@php.net
> uhm that looks like a documentation problem because
> "idn_to_utf8" sounds more like about the difference is the
> output encoding but in fact it seems to translate back the
> punnycode generated width "idn_to_ascii"

The documentation appears to be rather clear about this:

* idn_to_ascii — Convert domain name to IDNA ASCII form.
* idn_to_utf8 — Convert domain name from IDNA ASCII to Unicode.

Unless I misunderstand the ticket, there is nothing to be
improved.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Aug 20 12:01:27 2019 UTC