url-Encode vs Base64 encoding ( usages)?

2020-02-18 21:21发布

问题:

I was wondering...

(except the issue with the base64's plus'+' sign in query string - which is translated to 'space' and can be solved by %2b) :---> which is the preferred way to transfer data in query string?

Both functions can be used through the JS commands:

  • btoa
  • encodeUriComponent

so im asking myself(and you) :

when should I use what ? ( ive always used encodeUriCompoonent - by instinct).

the problem that the definitions are different - but the implementations can be similar...

edit

I think ive found the reason for asking.... ( and why nobody asked it before)

回答1:

base64 is used to transfer binary data. (not supported in IE, cant encode spacial chars.)

encodeURIComponent only encodes special characters.

An interesting thing is that you can't apply base64 to unicode strings without encodeURIComponent: https://developer.mozilla.org/en/DOM/window.btoa



回答2:

The answer to this is entirely dependent on your server-side application.

'+' is not translated to 'space' by the client - it is auto-translated to 'space' by some server-side apps, largely for backward-compatibility reasons (conversely, some server-side apps will leave '+' as '+' in compliance with RFC3986 ).

As far as the client is concerned - btoa() and encodeURIComponent() (and encodeURI() and escape()) just encode a string of text into different abstracted strings according to different encoding or escaping algorithms - btoa() usually produces the smallest resultant string using base64 encoding but meze's comment re: unicode is worth taking into account here.

The important thing to note is what your server-side application (some ASP.NET-based setup in your case) then uses to decode that string back to it's original form.



回答3:

fwiw, I use base64 whenever I want to transport anything that CAN be unicode, between a server and a client. urlencode doesn't handle all unicode charachters all that well. It quickly gets a mess with all the percentage signs.

so, in short: expecting unicode input/output, always base64 the transportation.