Vue-router: router-view does not render as path contains non-ascii or unicode characters.

Created on 26 Oct 2016  ·  18Comments  ·  Source: vuejs/vue-router

  • vue 2.0.3
  • vue-router 2.0.1

When the path contains non-ascii characters like chinese words, it works fine in Chrome, but not in Safari and Firefox.

Repro link: https://jsfiddle.net/a2v5rrcp/3/

improvement

Most helpful comment

I added a warning but shouldn't we encode the path to make it work across all browsers even if it looks bad ?
中文 -> %E4%B8%AD%E6%96%87

All 18 comments

Also interesting note.

Open up the console in chrome. When switching between the routes logs both of them out. On safari and firefox the root route isn't logged but the non-ascii route is.

I'd also note that the functionality in firefox is different too... if you click the a link twice in firefox then the route actually does load. The first click fires the route change (updates the $route object anyway) and the second click propagates the changes so that they render.

Super strange.

Actually, non-ascii characters are not allowed in url, though it seems chrome decided to support them.
Spec: https://www.w3.org/Addressing/URL/url-spec.txt

ENCODING PROHIBITED CHARACTERS

When a system uses a local addressing scheme, it is useful to
provide a mapping from local addresses into URLs so that references
to objects within the addressing scheme may be referred to
globally, and possibly accessed through gateway servers.

Any mapping scheme may be defined provided it is unambiguous,
reversible, and provides valid URLs. It is recommended that where
hierarchical aspects to the local naming scheme exist, they be
mapped onto the hierarchical URL path syntax in order to allow the
partial form to be used.

The following encoding method shall be used for mapping WAIS, FTP,
Prospero and Gopher addresses onto URLs. Where the local naming
scheme uses octet values which are not allowed in the URL, these
shall be represented in the URL by a percent sign "%" followed by
two hexadecimal digits (0-9, A-F) giving the value for that octet.
This specification makes no assumptions or requirements about the
character sets, if any, referred to be the (decoded) octets a URL.
Character codes other than those allowed by the syntax shall not be
used unencoded in a URL.

Well that's great, but at the very least the router should see that and throw an error. Regardless of wether it is or it isn't, people might try to do it and have inconsistent app behavior because of that.

Regardless of browser support this is a legitimate issue. I don't feel like this thread should be closed.

Adding a warning would improve the Developer experience and it's easy to add. I'll add it

I added a warning but shouldn't we encode the path to make it work across all browsers even if it looks bad ?
中文 -> %E4%B8%AD%E6%96%87

That would be assuming the user wants to use UTF-8...(中文 -> %D6%D0%CE%C4 using GBK encoding)
I think it's fine to just warn users and let them encode the paths.

I tested a bit further and I think we should encode the path on hash mode (the default, as used on the jsfiddle)
However, it works with history mode... with some caveats:
You cannot directly access a route with extended characters (eg: é) in any browser: opening in a new tab with the link won't work but clicking on it will. This is actually related to webpak, nginx or anything else doing the routing server side

@fnlctrl Are you sure about that? I just used the encodeURI method to get that string

It's encoded in GBK using other tools. On second thought I think it should be fine to encode the path for users, since they can still encode them manually before passing into routes array if they want.

@fnlctrl They actually cannot encode the pathes themselves if we chose to encode them

When using Firefox 55.0 and routes with Chinese characters the route change event is fired twice. OK in Chrome, IE and Edge.

https://jsfiddle.net/yh65uhey/4/

I have the same issue in last Firefox 55.0.3 (32-bit) see https://github.com/quasarframework/quasar/issues/936

Hi!

I have a kind of super-ugly workaround for related issue: nuxt single file components named in cyrillic produce incorrect cyrillic URIs.

I think it is not directly connected with the issue being discussed, but may be useful for someone or give some ideas about how to fix current issue. Also I'd note that it is not good to ignore the issue and close its siblings. Using unicode url is important for SEO in many countries and it is an essential competitive advantage.

https://github.com/budden/nuxt.js/commit/781fcadeb37007c087058dff99df1b8ac3bcc333

I didn't test exactly this commit, but similar one from a bit earlier version worked fine with Edge, Firefox and Chrome with the nuxt site produced by 'npm run generate'. In Chrome, it works with 'npm run dev', 'npm run build' and 'npm run generate'.

Maybe one can clone routes with unicode paths like I do, but do it in extendRoutes config. Obviously it is not a proper fix because paths are duplicated.

Also beware that I'm a complete newbie in JS so things I do can be quite stupid :)

I agree with @budden that unicode characters in URL are important in some countries. I actually have a requirement from client that routes should be in cyrillic, like on Wikipedia
for example (https://ru.wikipedia.org/wiki/Средняя_Азия).

In my case the HTML is generated and the page is display, but no Vue.js lifecycle methods are executed (for example a console.log in the mounted method).

I opened an issue about this on nuxt.js issues page: https://github.com/nuxt/nuxt.js/issues/2888 (the problem is only manifested on statically generated site)

In VuePress, now we have a perfect workaround for that: https://github.com/vuejs/vuepress/pull/473

Hope that can help you.

Is that gonna be resolved soon?

I don't remember the initial problem as this was prior to our issue template but I think this is fixed in #2375 and 8369c6bddbdceec90f01cca7f64653b6612c1bdf

@posva Great! when will be the next release? 🤔

Was this page helpful?
0 / 5 - 0 ratings

Related issues

saman picture saman  ·  3Comments

Lyfme picture Lyfme  ·  3Comments

Atinux picture Atinux  ·  3Comments

shinygang picture shinygang  ·  3Comments

yyx990803 picture yyx990803  ·  3Comments