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

[egoist]

• 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/

[zephraph]

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.

[fnlctrl]

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.

[zephraph]

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.

[posva]

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

[posva]

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

[fnlctrl]

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.

[posva]

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

[fnlctrl]

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.

[posva]

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