Using hasher with already percent-encoded strings

[papandreou]

I have a use case where I'd like my fragment identifiers to represent actual file names on disc, and in some weird cases those can contain octet sequences that don't decode as UTF-8. In other words I'd like to be able to pass an already percent-encoded string to setHash and to somehow be able to access the unprocecessed fragment identifier when it changes. Would you consider that out of scope for this library?

[millermedeiros]

can you provide some example of input/output? - describing what is in the browser address bar, what value do you expect back from hasher and how do you set the location.hash value.

The tricky part is that the process should be deterministic. Hasher should be able to set the value, read and decode the value from window.location, work if user press back/forward buttons and/or update the value manually on the address bar.

[papandreou]

Thanks for replying so quickly.

As an example I would like to be able to set the fragment identifier to #/%F8 using hasher. That's the Danish character ø in iso-8859-1, and the octet 0xf8 happens to be invalid UTF-8, so decodeURIComponent("%F8") throws an URIError.

hasher.setHash(text) encodes text as UTF-8 and percent-encodes the URI unsafe bytes, so hasher.setHash("%F8") sets the fragment identifier to #/%25F8. This is usually exactly what you want, because it's nice to just be able to work with JavaScript strings and not worry about percent encoding. However, it looks really weird when the string is already percent encoded.

This part could be solved by providing a hasher.setRawHash method that doesn't run the argument through encodeURI.

There would also need to be a way to get the unspoiled value of the fragment identifier when it changes. It could either be added as a 3rd parameter to the hasher.changed listeners, or maybe it could be a separate changedRaw event. What do you think?

By the way: Right now setting the fragment identifier to #/%F8 in the browser's address bar while hasher is running causes a URIError because decodeURIComponent is called without being wrapped in a try...catch. I would call that a bug.