views:

952

answers:

4

When one creates web content in languages different than English the problem of search engine optimized and user friendly URLs emerge.

I'm wondering whether it is the best practice to use de-accented letters in URLs -- risking that some words have completely different meanings with and without certain accents -- or it is better to stick to the usage of non-english characters where appropriate sacrificing the readability of those URLs in less advanced environments (e.g. MSIE, view source).

"Exotic" letters could appear anywhere: in titles of documents, in tags, in user names, etc, so they're not always under the complete supervision of the maintainer of the website.

A possible approach of course would be setting up alternate -- unaccented -- URLs as well which would point to the original destination, but I would like to learn your opinions about using accented URLs as primary document identifiers.

+1  A: 

Considering URLs with accents often tend to end up looking like this :

http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant

...which is not that nice... I think we'll still be using de-accented URLs for some time.

Though, things should get better, as accented URLs are now accepted by web browsers, it seems.

The firefox 3.5 I'm currently using displays the URL the nice way, and not with %stuff, btw ; this seems to be "new" since firefox 3.0 (see Firefox 3: UTF-8 support in location bar) ; so, not probably not supported in IE 6, at least -- and there are still quite too many people using this one :-(


Maybe URL with no accent are not looking the best that could be ; but, still, people are used to them, and seem to generally understand them quite well.

Pascal MARTIN
+2  A: 

When faced with a similar problem, I took advantage of URL rewriting to allow such pages to be accessible by either the accented or unaccented character. The actual URL would be something like

http://www.mysite.com/myresume.html

And a rewriting+character translating function allows this reference

http://www.mysite.com/myresumé.html

to load the same resource. So to answer your question, as the primary resource identifier, I confine myself to 0-9, A-Z, a-z and the occasional hyphen.

Bob Kaufman
So, thinking of transliteration, `ṃỹṛèşưḿĕ` would describe in the same resource? Or do you have a specific mapping?
Gumbo
Yes it would. The mapping is any accented character -> the corresponding unaccented character. Although the example you cite is an extreme case, I consider it to be a mostly harmless consequence of the mapping. Opposing viewpoints are, of course, most welcome!
Bob Kaufman
+1  A: 

You should avoid non-ASCII characters in URLs that may be entered in browser manually by users. It's ok for embedded links pre-encoded by server.

We found out that browser can encode the URL in different ways and it's very hard to figure out what encoding it uses. See my question on this issue,

http://stackoverflow.com/questions/1233076/handling-character-encoding-in-uri-on-tomcat

ZZ Coder
+1  A: 

There are several areas in a full URL, and each one might has different rules. The protocol is plain ASCII. The DNS entry is governed by IDN (International Domain Names) rules, and can contain (most) of the Unicode characters. The path (after the first /), the user name and the password can again be everything. They are escaped (as %XX), but those are just bytes. What is the encoding of these bytes is difficult to know (is interpreted by the http server). The parameters part (after the first ?) is passed "as is" (after %XX unescapeing) to some server-side application thing (php, asp, jsp, cgi), and how that interprets the bytes is another story). It is recommended that the path/user/password/arguments are utf-8, but not mandatory, and not everyone respects that.

So you should definitely allow for non-ASCII (we are not in the 80s anymore), but exactly what you do with that might be tricky. Try to use Unicode and stay away from legacy code pages, tag your content with the proper encoding/charset if you can (using meta in html, language directives for asp/jsp, etc.)

Mihai Nita