偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

深入剖析Base64加解密中遇到的坑點(diǎn)

開(kāi)發(fā) 前端
最近開(kāi)發(fā)過(guò)程中遇到了關(guān)于使用base64?加密傳輸遇到的神奇問(wèn)題。需求就是用戶(hù)的id?在鏈接上露出時(shí)需要加密處理,于是后端把下發(fā)的用戶(hù)id?改成了base64?加密處理后下發(fā)了,前端只需要把加密后的用戶(hù)id?原樣傳給后端就行。

前言

最近開(kāi)發(fā)過(guò)程中遇到了關(guān)于使用base64加密傳輸遇到的神奇問(wèn)題。需求就是用戶(hù)的id在鏈接上露出時(shí)需要加密處理,于是后端把下發(fā)的用戶(hù)id改成了base64加密處理后下發(fā)了,前端只需要把加密后的用戶(hù)id原樣傳給后端就行。就是這個(gè)看似簡(jiǎn)單的流程,折騰了半天,前端啥也沒(méi)干只是原樣透?jìng)?,但后端有概率拿到的用?hù)id不對(duì)。

問(wèn)題描述

本地寫(xiě)個(gè)后端服務(wù)模擬當(dāng)時(shí)的情景:

后端框架:nest

@Get('getUserInfo') 
getUserInfo(@Req() req) {
const query = req.query
const cookie = req.cookies
console.log('cookie', cookie)
// 優(yōu)先取參數(shù)中的userId,沒(méi)有則取cookie中的uid
const userId = query.userId || cookie.uid
// base64加密
const token = Buffer.from(userId).toString('base64')
console.log('加密后的token', token)
// 返回base64加密后的token
return {
    code: 0,
    data: {
      userId,
      // base64加密
      token: Buffer.from(userId).toString('base64')
    }
  }
}

前端請(qǐng)求后:

圖片圖片

服務(wù)這邊能夠正常拿到cookie并使用base64加密,然后把加密后的token返回給前端

前端也正常拿到了后端返回的加密后的token

圖片圖片

最后前端只需要在用戶(hù)分享時(shí)把加密的token帶在鏈接上,從這個(gè)鏈接進(jìn)入時(shí)再把鏈接上加密的token帶給后端即可,中間不需要做任何處理。

就是這個(gè)過(guò)程,出現(xiàn)了奇怪的現(xiàn)象,絕大多數(shù)用戶(hù)都是OK,但是會(huì)有一些用戶(hù)的token帶給后端時(shí),后端解不出來(lái)了。

心想這跟前端好像沒(méi)啥關(guān)系,因?yàn)榍岸藟焊鶝](méi)處理后端返回的token,后端給我啥,我只是原樣給他傳了啥。

經(jīng)排查發(fā)現(xiàn),所有有問(wèn)題的用戶(hù)id都是加密后的token中包含了+符號(hào)

比如這樣的:zm+3DQ/gYeMzQ/HM2L76+CA==傳到后端時(shí),所有的+都變成了空格,導(dǎo)致后端解出來(lái)是錯(cuò)的

圖片圖片

URL是如何進(jìn)行編碼的

這個(gè)問(wèn)題的主要原因還是因?yàn)閁RL被編碼造成的,由于請(qǐng)求是get請(qǐng)求,所以最終所有的參數(shù)都是拼接在鏈接上的,最開(kāi)始前端傳給后端的token是沒(méi)有經(jīng)過(guò)編碼的,那它為什么自己編碼了?并且編碼后與預(yù)期的還不一致?

由于種種歷史原因,RFC與W3C都定義過(guò)URL的編碼標(biāo)準(zhǔn)

RFC規(guī)范

在RFC3986中提到:除了 數(shù)字 、 字母 、 -_.~ 不會(huì)被轉(zhuǎn)義,其他字符都會(huì)被以百分號(hào)(%)后跟兩位十六進(jìn)制數(shù) %{hex} 的方式進(jìn)行轉(zhuǎn)義。在這個(gè)規(guī)則中空格會(huì)被轉(zhuǎn)為%20,而+會(huì)被轉(zhuǎn)為%2B

圖片圖片

W3C規(guī)范

在W3C規(guī)范中卻又說(shuō)空格可以被編碼為+或%20

圖片圖片

為什么會(huì)同時(shí)存在兩種規(guī)范,這不是在挖坑嗎?

這就是上面出現(xiàn)+變空格的原因,在你不確定正在以哪一個(gè)規(guī)范進(jìn)行編解碼時(shí),就很容易出現(xiàn)這個(gè)問(wèn)題。它可能是瀏覽器造成的,也可能是開(kāi)發(fā)語(yǔ)言的規(guī)范不同造成的。

比如Google搜索:

當(dāng)我們搜索s+2時(shí),地址欄出現(xiàn)的是s%2B2

圖片圖片

當(dāng)我們搜索s 2時(shí),地址欄出現(xiàn)的卻是s+2

圖片圖片

這里就是空格被編碼為+了,你要是不了解W3C這條規(guī)范,是不是覺(jué)得匪夷所思了??

前端編碼規(guī)范

在JS中對(duì)字符串進(jìn)行編碼的方法有三個(gè):escape、encodeURI、encodeURIComponent

escape已經(jīng)被廢棄了,不再推薦使用,所以我們這里只需要關(guān)注后面兩個(gè)的區(qū)別

encodeURI

該函數(shù)只會(huì)編碼URI中完全禁止的字符。該函數(shù)的目的是對(duì)URI進(jìn)行完整的編碼,因此對(duì)以下在URI中具有特殊含義的 ASCII 標(biāo)點(diǎn)符號(hào),encodeURI是不會(huì)進(jìn)行轉(zhuǎn)義的(;/?:@&=+$,#)

所以對(duì)于encodeURI來(lái)說(shuō),空格會(huì)被編碼為%20,但是+并不會(huì)編碼。因?yàn)榭崭袷荱RI中禁止的字符,而+不是

圖片圖片

總結(jié)來(lái)說(shuō)就是:

encodeURL除了這些**A-Z a-z 0-9 ; , / ? : @ & = + $ – _ . ! ~ * ‘ ( ) #**不會(huì)被編碼,其余字符都會(huì)被編碼

encodeURIComponent

功能與encodeURI類(lèi)似,但是encodeURIComponent編碼的范圍更廣,并且該函數(shù)一般用于對(duì)URI的參數(shù)部分進(jìn)行編碼

對(duì)于encodeURIComponent來(lái)說(shuō),空格會(huì)被編碼為%20,+會(huì)被編碼為%2B

圖片圖片

總結(jié)來(lái)說(shuō)就是:

encodeURLComponent除了這些 **A-Z a-z 0-9 - _ . ! ~ * ' ( )**不會(huì)被編碼,其余字符都會(huì)被編碼

兩者使用場(chǎng)景的差異

  • 當(dāng)encode的內(nèi)容不作為URI參數(shù)時(shí),使用encodeURI進(jìn)行編碼
const url = encodeURI('https://www.qidian.com')
// 'https://www.qidian.com'
  • 當(dāng)encode的內(nèi)容作為URI參數(shù)時(shí),使用encodeURIComponent進(jìn)行編碼
const deepLink = `weixin://webview?url=${encodeURIComponent('https://www.baidu.com')}`
//  weixin://webview?url=https%3A%2F%2Fwww.baidu.com

結(jié)論

對(duì)于JS的編碼方法來(lái)說(shuō),只有encodeURIComponent會(huì)對(duì)+進(jìn)行編碼,并且編碼規(guī)范是RFC3986,也就是說(shuō)使用這個(gè)方法空格會(huì)被轉(zhuǎn)為%20,而+會(huì)被轉(zhuǎn)為%2B。從而也就不會(huì)出現(xiàn)+變空格或空格變+的問(wèn)題。

上述問(wèn)題是如何產(chǎn)生的?

上面分別介紹了URL的編碼規(guī)范,以及前端編碼方法應(yīng)用的規(guī)范。總結(jié)下來(lái)就是空格不會(huì)在前端產(chǎn)生,前端應(yīng)用的編碼規(guī)范不會(huì)將+變成空格

圖片圖片

并且特意寫(xiě)了個(gè)node服務(wù)來(lái)模擬當(dāng)時(shí)的場(chǎng)景。

結(jié)論是:只要傳給后端的base64字符串在前端經(jīng)過(guò)了編碼就不會(huì)有問(wèn)題。因?yàn)樯厦嫖覀兘榻B過(guò)瀏覽器的編碼規(guī)范,確實(shí)是會(huì)存在+變空格的問(wèn)題。所以我們需要主動(dòng)編碼,不要把編碼的機(jī)會(huì)留給瀏覽器。

前端編碼了,后端拿到的也是正常的

圖片圖片

沒(méi)編碼,后端拿到的+變成空格了

圖片圖片

所以當(dāng)時(shí)前端未進(jìn)行編碼時(shí),從CURL中就能看到+已經(jīng)變成了空格,但后面前端編碼后,curl看是正常的,后端解碼出來(lái)卻還是有問(wèn)題的。

我這邊怎么都復(fù)現(xiàn)不了當(dāng)時(shí)傳給后端是編碼過(guò)的base64字符串,后端拿到的卻還是+變成了空格

沒(méi)辦法,只好找后端同學(xué)問(wèn)問(wèn)他當(dāng)時(shí)是怎么解碼的...

經(jīng)過(guò)一番驗(yàn)證后,結(jié)論是他那邊多解碼了一次,他們框架層有一次自動(dòng)解碼

'zm%2B3DQ%2FgYeMzQ%2FHM2L76CA%3D%3D'   ---->  'zm+3DQ/gYeMzQ/HM2L76CA=='

實(shí)際上這里就已經(jīng)是正確的了,但后端同學(xué)又自己解碼了一次,按理來(lái)說(shuō)再次解碼應(yīng)該也不會(huì)有問(wèn)題

圖片圖片

但是?。?!這是因?yàn)閖avascript遵循的是RFC3986規(guī)范,但java好像并不是

java自帶的decode方法底層是這樣實(shí)現(xiàn)的

圖片圖片

這里直接把+替換成了空格。真相了....

解決方案

  • 按理來(lái)說(shuō)我們只需要保證傳給后端的+字符按RFC3986規(guī)范編碼成了%2B就不會(huì)有問(wèn)題,不要把編碼的機(jī)會(huì)留給瀏覽器,在JS中只需調(diào)用encodeURIComponent即可
  • 后端接收到帶空格的base64字符串時(shí),通過(guò)正則將空格替換為+,因?yàn)閎ase64中不會(huì)出現(xiàn)空格
  • 由于標(biāo)準(zhǔn)Base64編碼包含64個(gè)字符A-Z, a-z,0-9,+,/,=,有一種URL safe的base64格式,把其中的+,/換成-,_,也能夠解決上面的問(wèn)題。

責(zé)任編輯:武曉燕 來(lái)源: 前端南玖
相關(guān)推薦

2025-02-11 00:00:10

Base64編碼二進(jìn)制

2023-11-07 08:35:26

2016-12-13 13:50:06

JAVA轉(zhuǎn)換Base64

2021-02-05 05:26:33

字節(jié)ASCII控制

2025-04-23 00:04:00

2014-02-20 10:28:28

JavaScriptBase64

2021-09-07 08:59:09

編碼Base64解碼

2010-03-03 16:14:05

Python base

2021-03-05 09:10:19

base64編碼

2021-08-26 05:27:08

Base64 字節(jié)流算法

2024-07-31 10:22:49

Go語(yǔ)言編碼

2024-02-28 23:07:42

GolangBase64編碼

2022-10-29 19:58:09

Base64Bashshell

2022-06-06 08:31:05

Base64編碼Base58

2024-09-09 09:08:28

2024-07-11 08:42:57

2019-08-09 11:40:38

JavaScriptCSS技術(shù)

2019-07-23 08:55:46

Base64編碼底層

2023-05-12 08:11:58

JavaScriptJSON克隆

2022-09-28 08:01:33

JavaScript二進(jìn)制
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)