我在想...
(除了base64的加号'+'在查询字符串中的问题-它被翻译成'空格'并且可以通过%2b解决) :--->这是在查询字符串中传输数据的首选方式?
这两个功能都可以通过 JS 命令使用:
btoa
encodeUriComponent
所以我问自己(和你):
我什么时候应该使用什么?(我一直使用 encodeUriCompoonent
- 本能)。
定义不同的问题 - 但实现可能相似......
编辑
我想我找到了问的原因......(以及为什么以前没有人问过)
我在想...
(除了base64的加号'+'在查询字符串中的问题-它被翻译成'空格'并且可以通过%2b解决) :--->这是在查询字符串中传输数据的首选方式?
这两个功能都可以通过 JS 命令使用:
btoa
encodeUriComponent
所以我问自己(和你):
我什么时候应该使用什么?(我一直使用 encodeUriCompoonent
- 本能)。
定义不同的问题 - 但实现可能相似......
我想我找到了问的原因......(以及为什么以前没有人问过)
base64用于传输二进制数据。(在 IE 中不支持,不能编码空间字符。)
encodeURIComponent只对特殊字符进行编码。
有趣的是,如果没有 encodeURIComponent,您将无法将 base64 应用于 unicode 字符串: https ://developer.mozilla.org/en/DOM/window.btoa
答案完全取决于您的服务器端应用程序。
'+'不会被客户端转换为'space' - 它会被一些服务器端应用程序自动转换为'space',主要是出于向后兼容的原因(相反,一些服务器端应用程序会将'+'保留为'+'符合RFC3986)。
就客户端而言 - btoa()
and encodeURIComponent()
(and encodeURI()
and escape()
) 只是根据不同的编码或转义算法将文本字符串编码为不同的抽象字符串 -通常使用base64btoa()
编码产生最小的结果字符串,但meze 的评论re: unicode isworthing into帐户在这里。
需要注意的重要一点是您的服务器端应用程序(在您的情况下是一些基于 ASP.NET 的设置)然后用于将该字符串解码回其原始形式。
fwiw,每当我想在服务器和客户端之间传输任何可以是 unicode 的东西时,我都会使用 base64。urlencode 不能很好地处理所有 unicode 字符。它很快就会把所有的百分比符号弄得一团糟。
所以,简而言之:期待 unicode 输入/输出,总是 base64 传输。