views:

481

answers:

4

I have an action like this:

<%=Html.ActionLink("My_link", "About", "Home", new RouteValueDictionary { 
    { "id", "Österreich" } }, null)%>

This produces the following link: http://localhost:1855/Home/About/%C3%96sterreich

I want a link which looks like this - localhost:1855/Home/About/Österreich

I have tried.

Server.HtmlDecode("Österreich")
HttpUtility.UrlDecode("Österreich") 

Neither seems to be helping. What else can I try to get my desired result?

+1  A: 

I think your desire for a non urlencode url is valid, but I don't think the tools actually make it easy to do this.

John Weldon
A: 

Would putting the generated link inside an <a>, with the link text being the non-encoded string, not be good enough? It would still look bad in the browser's URL field, but your UI would be a little prettier.

Also, in Firefox anyway, the URL shown in my status bar when I mouse over your "ugly" link shows the unencoded version, so it would probably look fine there as well.

Zind
+4  A: 

I think this is an issue with your browser (IE).

Your code is correct as it is, no explicit UrlEncoding needed.

<%=Html.ActionLink("My_link", "About", "Home", new RouteValueDictionary { 
{ "id", "Österreich" } }, null)%>

There is nothing wrong with ASP.NET MVC. See unicode urls on the web, e.g. http://he.wikipedia.org/wiki/%D7%9B%D7%A9%D7%A8%D7%95%D7%AA in IE and in a browser that handles unicode in URLs correctly.

E.g. chrome displays unicode URLs without any problem. IE does not decode "special" unicode characters in address bar.

This is only a cosmetic issue.

Marek
Just verified this - FF displays them nicely, but the source shows the encoded URL.
womp
+1 Interesting!
magnifico
Yes, it seems to be and IE issue. Thanks for your help.
Bryan
+1  A: 

According to RFC 1738 Uniform Resource Locators (URL), only US-ASCII is supported, all other characters must be encoded.

2.2. URL Character Encoding Issues

URLs are sequences of characters, i.e., letters, digits, and special

characters. A URLs may be represented in a variety of ways: e.g., ink on paper, or a sequence of octets in a coded character set. The interpretation of a URL depends only on the identity of the characters used.

In most URL schemes, the sequences of characters in different parts of a

URL are used to represent sequences of octets used in Internet protocols. For example, in the ftp scheme, the host name, directory name and file names are such sequences of octets, represented by parts of the URL. Within those parts, an octet may be represented by the chararacter which has that octet as its code within the US-ASCII [20] coded character set.

In addition, octets may be encoded by a character triplet consisting of

the character "%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which forming the hexadecimal value of the octet. (The characters "abcdef" may also be used in hexadecimal encodings.)

Octets must be encoded if they have no corresponding graphic

character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme.

No corresponding graphic US-ASCII:

URLs are written only with the graphic printable characters of the

US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded.

magnifico