Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

escape vs encodeURIComponent #511

Closed
rudi-c opened this issue Aug 2, 2016 · 4 comments
Closed

escape vs encodeURIComponent #511

rudi-c opened this issue Aug 2, 2016 · 4 comments
Assignees

Comments

@rudi-c
Copy link

rudi-c commented Aug 2, 2016

The function Url.encode_arguments, uses the Javascript escape function. However, according to

http://stackoverflow.com/questions/75980/when-are-you-supposed-to-use-escape-instead-of-encodeuri-encodeuricomponent

escape is broken/deprecated and should be replaced with encodeURIComponent. One example of a difference in behavior is that escape does not encode forward slashes.

I think Url.encode_arguments should use encodeURIComponent? But I'm new to this project and not sure if there was a particular reason behind the choice of using escape.

@hhugo
Copy link
Member

hhugo commented Aug 2, 2016

@vouillon, @balat, you probably have more knowledge than I do on this topic, can you have a look ?

@vouillon
Copy link
Member

vouillon commented Oct 5, 2016

In OCaml, strings are sequences of bytes. Thus, we are using UTF-8 strings. So for instance, "é" is represented as the two bytes: "\xc3\xa9". We have escape("\xc3\xa9") = "%C3%A9", which is precisely what we want, while encodeURIComponent('\xc3\xa9') = "%C3%83%C2%A9" which is incorrect. Note that encodeURIComponent('é') = "%C3%A9", so we could use this function, but we would need to reencode the string into UTF-16 before that.

Forward slashes are allowed in the query component of URIs according to RFC 3986 (section 3.4).

Hence, I think we are using escape correctly here, though it is indeed easy to misuse it.

Thanks for your remark, and sorry for not replying sooner.

@bobzhang
Copy link
Contributor

bobzhang commented Oct 5, 2016

@vouillon @hhugo are you interested in pushing more restrictions upstream to do utf8 validation for string literals?
some relevant work: https://github.com/dbuenzli/ppx_utf8_lit

@hhugo
Copy link
Member

hhugo commented Sep 30, 2021

I believe this has been answered

@hhugo hhugo closed this as completed Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants