Open URI with German "Umlaut"

I tried it in many different ways (using unicode characters in the code, escape(), encodeURI(), encodeURIComponent() plus some other things) and couldn't get it to work. I'm not sure if it's a but in JS or in the browsers (tried in both FF, Chrome and IE), who don't seem to handle the encoded URL correctly...

If you open http://www.öpnvkarte.de/ in Chrome or Explorer it converts to a common language
http://www.xn--pnvkarte-m4a.de/
You can use this "converted" link which will open in Chrome, IE and FF.

Can I ask how you arrived to this "common language" URL?

I opened it in Chrome and Explorer and they both converted it into a url they could understand. Firefox actually kept it the original address. But apparently the other 2 had a problem handling the url just like when Acrobat tried to pass it off.

Got ya... I discovered that this sort of encoding is called PUNYCODE (Wikipedia). I've also discovered a free JS PUNYCODE converter, here: https://github.com/bestiejs/punycode.js/blob/master/punycode.js
Using it, you can run this code to get the correct URL:
punycode.toASCII("http://www.öpnvkarte.de/");

To Dieter: I just ran the following lines in the Acrobat 9 Console, line by line:

var a = "http://www.öpnvkarte.de" ;
var b = encodeURI(a) ;

app.launchURL(a) ;

app.launchURL(b) ;

In the first case, the browser opened and got the message "Safari can’t open the page “http://www.%F6pnvkarte.de/” because the page’s address isn’t valid."

In the second case, the browser opened the target page without complaint.

So, I don't see why someone else claimed that that method did not work.

Hope this can help.

Max Wyss.

I tried it in Acrobat 8 and 10 (with Firefox as the default browser), using encodeURI, and the result in both was the invalid URL: http://www.%c3%b6pnvkarte.de

Thank you all for the help!

So now i have ideas for a work-around, using punicode.

But - isn't it a bug in acrobat?
Shouldn't acrobat convert the the domain-path into "punicode"?

You will have the same effect, when you directly use the action "open web link (Webverknüpfung öffnen)" of a button...

Thak you all for the help!

@maxwyss: 'In firefox ( I use 8.0) it does not work, I tried it yet.

@try67: there are some websides, using the german "umlaute", this one is a specialised (international!!) site of openstreetmap, for displaying public bus- and railway lines etc.

I''ll try to integrate the "punycode.js" in a document.js...

Actually, if anything it's a bug in the core JavaScript implementation. You get the same results when running this code in a browser as well. I think that the encodeURI method was meant to encode the parts of the URL following the domain name (since at the time those special characters were not allowed to be a part of the domain), such as URL parameters.

I don't think that it is an Acrobat issue (otherwise, I would not have been able to make it work).

I know that it should not matter, but what happens if you capitalize the characters in the hex values, by changing

http://www.%c3%b6pnvkarte.de

to

http://www.%C3%B6pnvkarte.de

I know that it should not be relevant, but still. The reason why I am wondering is because when I made my tests, that were the results.


So, what is to blame? It could actually be the operating system/browser combination, plus the fact that the accented character is at the first place. It could be that the browser treats that first UTF-16 character code as a literal instead of interpreting it.

Supporting my suspicion is that it is not an implementation issue of encodeURI() is that if the encodeURI() method would be wrong, any data submission using URLs would fail. But with data submission, it is never the first character in the URL which gets encoded.

Max Wyss.

Hey, Max!

I'm now shure, it works, when using punycode instead of encodeURI().
Maybe, it depends on the Browser; I did'nt test Safari (no Mac), and Opera.
IE5 does not do it as well.

But concerning acrobat, the problem is not JS only (as encodeUIR() is Standard-JS, but using Links outside Javascript, when doing it by the user interface.
OK, it is, like it is; normally one does not need URL with "umlaute" inside.

Dieter Metk

"http://www.%C3%B6pnvkarte.de" doesn't work in Firefox, either.

I did some quick further tests on my Mac…

Firefox could not open, and complained. Changing the %C3%B6 to ö allowed me to open.

Camino did not open, complained, but interpreted the string correctly in the URL field, so that a second attempt worked properly.

I have a suspicion that we discovered a serious flaw in most browsers.

Of course punycode and similar URL shorteners do work, but this does not sound "standard" to me.

Max Wyss.

As the domain-names with "Umlaute" started in Germany, I remember that one had to use the "punycode"-Translation for those uri's.
What to do? I think, it might be worth to inform the Firefox-Community first...

Dieter Metk

I don't think you can place punycode and URL shorteners in the same category. The former is an IETF standard, created exactly for this purpose, while the latter are basically just a redirect service provided by some websites.

I do agree, though, that this issue should be forwarded to the various browser developers, as it should be solved, especially since now one can define domains with a much larger set of characters than was possible before (Hebrew, Arabic, Chinese letters, etc.)