最近在給一個(gè)文件上傳模塊做完整性校驗(yàn)到方案選型時(shí)才發(fā)現(xiàn)前端圈子對(duì)哈希計(jì)算的討論遠(yuǎn)比后端少。網(wǎng)上搜“SHA-256生成器”跳出來的大多是調(diào)一下后端接口、或者一句話封裝完事。這周我干脆自己動(dòng)手把SHA-256從前端角度完整做了一遍從算法原理到可運(yùn)行代碼全部走通輸出一個(gè)能直接用的哈希生成器工具。這篇記錄一下整個(gè)實(shí)戰(zhàn)過程給同樣需要在瀏覽器里算哈希的開發(fā)者一個(gè)可復(fù)現(xiàn)的參考。這里的思路簡(jiǎn)單說就是字符串輸入后實(shí)時(shí)算出SHA-256結(jié)果文件上傳后也直接在前端計(jì)算出文件哈希全程不經(jīng)過服務(wù)器。整個(gè)過程要解決三個(gè)問題SHA-256到底是怎么把任意數(shù)據(jù)變成固定64位十六進(jìn)制的、瀏覽器環(huán)境下有哪些實(shí)現(xiàn)路徑、哪些坑是真正開發(fā)中繞不過去的。適合對(duì)前端加密、文件處理、數(shù)據(jù)校驗(yàn)感興趣的同學(xué)參考也適合想從零手寫一遍加密算法的朋友對(duì)照閱讀。1. 做哈希生成器之前先想清楚它到底能解決什么1.1 瀏覽器里為什么需要哈希計(jì)算很多人一聽前端口算哈希就搖頭覺得這種計(jì)算應(yīng)該在服務(wù)端完成。但實(shí)際開發(fā)中前端做哈希計(jì)算的場(chǎng)景一點(diǎn)也不少。最典型的就是文件完整性校驗(yàn)。把一個(gè)大文件從服務(wù)器下載到本地傳輸過程可能出錯(cuò)但用戶不知道。如果在瀏覽器里把下載后的文件計(jì)算出SHA-256值和服務(wù)端下發(fā)的期望值比對(duì)就能確認(rèn)文件是否完好。還有一個(gè)場(chǎng)景是內(nèi)容去重。比如一個(gè)圖片上傳系統(tǒng)如果用戶在A頁(yè)面已經(jīng)傳過某張圖片B頁(yè)面又要傳同一張前端可以先算出文件哈希交給后端做比對(duì)能省下大量不必要的帶寬。再比如接口簽名部分開放平臺(tái)要求客戶端對(duì)請(qǐng)求參數(shù)做哈希摘要前端拿到后再放進(jìn)請(qǐng)求頭里。還有一個(gè)非常容易被誤解的場(chǎng)景是“前端密碼哈?！?。很多同學(xué)習(xí)慣把用戶輸入的密碼在前端做SHA-256再傳給后端。這里我必須多說一句前端哈希密碼能防止明文傳輸被截獲但并不能代替HTTPS也不能作為服務(wù)端加鹽哈希的替代品。如果真要存密碼服務(wù)端仍然要用專用算法做加鹽處理。前端的哈希值只能算一層額外的防泄露手段不能把這個(gè)場(chǎng)景當(dāng)成哈希生成器的核心用途但它確實(shí)是很多人學(xué)習(xí)哈希的起因。1.2 從標(biāo)題拆解這個(gè)項(xiàng)目的具體需求把“【前端實(shí)戰(zhàn)】SHA-256哈希生成器算法原理前端實(shí)現(xiàn)代碼全解”這個(gè)標(biāo)題拆開實(shí)際要做的東西很清晰。第一算法原理必須講透徹。不是調(diào)一句API然后說“完事了”而是要把SHA-256內(nèi)部的填充規(guī)則、壓縮函數(shù)、狀態(tài)變量變化講明白讓讀者知道哈希結(jié)果不是魔法是一步步算出來的。第二前端實(shí)現(xiàn)要覆蓋至少兩種輸入文本和文件。文本是最簡(jiǎn)單的調(diào)用場(chǎng)景文件則要處理二進(jìn)制讀取和大型文件的內(nèi)存控制這是和純調(diào)API完全不同的復(fù)雜度。第三代碼全解意味著源代碼要能直接復(fù)制運(yùn)行。我決定做一個(gè)單頁(yè)工具包含輸入?yún)^(qū)、輸出區(qū)和計(jì)算耗時(shí)而不是寫一堆零散代碼片段。這樣讀者拿到就能用也能把每個(gè)函數(shù)和UI對(duì)應(yīng)起來理解。在這樣的項(xiàng)目定位下技術(shù)方案其實(shí)有挺多選擇。你可以直接用瀏覽器內(nèi)置的Web Crypto API也可以用第三方加密庫(kù)更可以手寫算法實(shí)現(xiàn)。這三種路線我這次全部測(cè)試過了各自的優(yōu)缺點(diǎn)在后面詳細(xì)展開。2. SHA-256算法原理從消息到64位十六進(jìn)制中間經(jīng)歷了什么2.1 哈希函數(shù)的幾個(gè)基礎(chǔ)性質(zhì)在寫代碼之前我建議先把SHA-256當(dāng)做一個(gè)黑盒觀察一輪。輸入任意長(zhǎng)度的數(shù)據(jù)輸出永遠(yuǎn)是固定的256位也就是32個(gè)字節(jié)用十六進(jìn)制表示就是64個(gè)字符。不管你輸入一個(gè)字母還是一部電影輸出的長(zhǎng)度都一樣。哈希函數(shù)有三個(gè)性質(zhì)對(duì)前端開發(fā)者影響最大。第一個(gè)是單向性從輸入算哈希很容易但從哈希反推輸入幾乎不可能。就好比把雞蛋打碎做成煎蛋容易想把煎蛋變回雞蛋就太難了。第二個(gè)是雪崩效應(yīng)輸入的任意一個(gè)bit變化輸出大約有一半bit發(fā)生變化看起來像完全變了個(gè)人。第三個(gè)是固定長(zhǎng)度輸出長(zhǎng)度和輸入長(zhǎng)度無關(guān)。這三個(gè)性質(zhì)決定了SHA-256的實(shí)際用途。文件校驗(yàn)靠的是雪崩效應(yīng)能發(fā)現(xiàn)極細(xì)微的改動(dòng)密碼摘要靠的是單向性不可逆推原始值內(nèi)容尋址靠的是固定長(zhǎng)度同一份內(nèi)容在任何位置算出的哈希都相同。但SHA-256并不是憑空產(chǎn)生這些性質(zhì)的它內(nèi)部是一套非常機(jī)械的數(shù)學(xué)運(yùn)算。接下來我按處理順序拆解。2.2 數(shù)據(jù)填充為什么要在末尾加“1”、補(bǔ)零和長(zhǎng)度SHA-256處理數(shù)據(jù)的基本單位是64字節(jié)的塊。如果輸入數(shù)據(jù)長(zhǎng)度不是64的整數(shù)倍就必須填充。填充規(guī)則是這樣的在消息末尾先添加一個(gè)bit的1也就是字節(jié)0x80然后補(bǔ)若干0字節(jié)直到剩余長(zhǎng)度正好是56字節(jié)最后再用8字節(jié)表示原始消息的比特長(zhǎng)度。這里有兩個(gè)細(xì)節(jié)值得解釋。為什么要填到“64字節(jié)塊還剩56字節(jié)”而不是直接填滿因?yàn)樽詈蟮?字節(jié)要用來放長(zhǎng)度信息。原始消息的長(zhǎng)度以bit為單位用64位大端序表示。對(duì)于長(zhǎng)度不超過2的64次方bit的數(shù)據(jù)這個(gè)表示方式是足夠的。為什么要強(qiáng)行加入長(zhǎng)度因?yàn)槿绻挥涗涢L(zhǎng)度僅靠尾部補(bǔ)零消息“abc”和消息“abc0”在填充后會(huì)變成一樣的塊序列哈希自然也一樣。加上真實(shí)長(zhǎng)度后能區(qū)分出這類差異。這就是所謂的梅克爾-達(dá)姆加德結(jié)構(gòu)增強(qiáng)核心是讓填充后的數(shù)據(jù)完整表達(dá)出原始數(shù)據(jù)的信息包括內(nèi)容和長(zhǎng)度。填充后數(shù)據(jù)一定可以被切成整整若干塊每塊64字節(jié)。塊數(shù)不足時(shí)自動(dòng)補(bǔ)塊數(shù)超了也沒問題因?yàn)楹罄m(xù)的壓縮函數(shù)像傳送帶一樣逐塊處理。2.3 壓縮函數(shù)八個(gè)狀態(tài)變量如何翻滾六十四輪數(shù)據(jù)準(zhǔn)備好之后SHA-256核心算法才真正開始。它維護(hù)8個(gè)32位的狀態(tài)變量也就是初始哈希值H0到H7。這些常量來自前8個(gè)質(zhì)數(shù)的平方根的小數(shù)部分比如2的平方根取小數(shù)前32位就是0x6a09e667。為什么用質(zhì)數(shù)平方根因?yàn)檫@些數(shù)字沒有規(guī)律能避免初始狀態(tài)被構(gòu)造出特殊結(jié)構(gòu)。對(duì)于每一個(gè)64字節(jié)塊算法要執(zhí)行一輪消息擴(kuò)展和64輪壓縮循環(huán)。消息擴(kuò)展的意思是把一個(gè)64字節(jié)的塊拆成16個(gè)32位大端序的字W[0]到W[15]然后用特定公式再生成48個(gè)字W[16]到W[63]。這個(gè)過程把數(shù)據(jù)充分?jǐn)嚢?。接著?4輪循環(huán)。每一輪基于當(dāng)前8個(gè)狀態(tài)變量a到h做一系列位運(yùn)算再把結(jié)果移位替換。核心的運(yùn)算包括邏輯函數(shù)Ch(x, y, z) (x y) ^ (~x z)中文常叫“選擇函數(shù)”按x的bit位選擇y或z。Maj(x, y, z) (x y) ^ (x z) ^ (y z)三數(shù)中取多數(shù)。Σ0(x) 和 Σ1(x) 分別是循環(huán)右移和異或組合。σ0 和 σ1 用于消息擴(kuò)展。每一輪還會(huì)混入一個(gè)常量K[i]這些常量來自前64個(gè)質(zhì)數(shù)的立方根的小數(shù)部分。這64個(gè)常量相當(dāng)于給整個(gè)算法注入了外部隨機(jī)性避免輪與輪之間出現(xiàn)簡(jiǎn)單循環(huán)。輪循環(huán)的過程是先算T1 h Σ1(e) Ch(e, f, g) K[i] W[i]再算T2 Σ0(a) Maj(a, b, c)然后所有變量整體后移一位a變成T1 T2e變成d T1。這一步看起來像流水線但實(shí)際上是把狀態(tài)值充分交叉混合。塊處理完后把初始狀態(tài)變量和塊處理后的a到h分別相加作為下一塊輸入的初始狀態(tài)。最后一個(gè)塊處理完成后8個(gè)狀態(tài)變量按大端序拼成十六進(jìn)制字符串就是最終的SHA-256值。2.4 從公式到代碼所有運(yùn)算都能映射成JavaScript把上面這些流程翻譯成JavaScript其實(shí)不需要特別高深的知識(shí)只需要掌握幾個(gè)關(guān)鍵點(diǎn)。第一JavaScript的位運(yùn)算符只能作用于32位整數(shù)而且是有符號(hào)32位。為了模擬無符號(hào)32位運(yùn)算要用 0把負(fù)值轉(zhuǎn)回?zé)o符號(hào)。第二循環(huán)右移要自己實(shí)現(xiàn)比如循環(huán)右移7位就是(x 7) | (x 25)因?yàn)閤 25在32位語義下自然完成了高位回填。第三加法隨時(shí)可能溢出所以要每一步加法都做無符號(hào)歸一化。我最初手寫代碼時(shí)最容易漏掉的就是這些細(xì)節(jié)。一個(gè)加法沒做 0結(jié)果算到后面就徹底不對(duì)了。這也解釋了為什么很多初學(xué)者看在線教程抄代碼時(shí)結(jié)果對(duì)不上——不是在抄錯(cuò)而是中間某個(gè)中間值已經(jīng)是帶符號(hào)整數(shù)了。后續(xù)第4部分我會(huì)給出完整可運(yùn)行的手寫實(shí)現(xiàn)這里先記住一個(gè)概念SHA-256本質(zhì)上是大量32位異或、移位和加法疊加起來的沒有復(fù)雜的浮點(diǎn)運(yùn)算也沒有分支跳轉(zhuǎn)所以它在任何語言里都能高效實(shí)現(xiàn)。3. 前端實(shí)現(xiàn)路線選型三條路走哪條最合適3.1 瀏覽器原生Web Crypto API最省事的方案是直接使用crypto.subtle.digest(SHA-256, data)。這個(gè)方法返回一個(gè)Promiseresolve后得到ArrayBuffer再轉(zhuǎn)換成十六進(jìn)制字符串即可。它的優(yōu)點(diǎn)是使用系統(tǒng)級(jí)加密模塊在絕大多數(shù)瀏覽器中帶硬件加速性能極好。但它有一個(gè)限制只能在安全上下文中使用。所謂安全上下文指的是HTTPS或者localhost。如果你在本地用file://協(xié)議或者局域網(wǎng)IP上打開頁(yè)面crypto.subtle會(huì)是undefined。我在本地開發(fā)時(shí)第一次遇到這個(gè)問題還以為是瀏覽器版本問題后來才意識(shí)到是協(xié)議的問題。另一個(gè)限制是它不支持增量輸入。你必須一次性把完整數(shù)據(jù)傳進(jìn)去它才能計(jì)算。這意味著你不方便用這個(gè)API計(jì)算超大文件的流式哈希除非把整個(gè)文件都讀進(jìn)內(nèi)存。對(duì)大文件來說這可能導(dǎo)致內(nèi)存峰值過高性能和體驗(yàn)都會(huì)打折扣。3.2 第三方加密庫(kù)拿crypto-js做對(duì)比很多項(xiàng)目選擇引入第三方庫(kù)最常見的如crypto-js。它能處理字符串哈希也能通過CryptoJS.algo.SHA256.create()的方式做增量哈希所以在老項(xiàng)目中很受歡迎。但第三方庫(kù)有個(gè)繞不開的問題它是以純JavaScript運(yùn)行在解釋器上性能無法和瀏覽器原生實(shí)現(xiàn)相比。處理幾十MB的文件時(shí)crypto-js的耗時(shí)明顯高于crypto.subtle。如果腳本體積敏感或者項(xiàng)目本身只是需要一次性哈希引入一個(gè)完整加密庫(kù)也略顯笨重。不過第三方庫(kù)的兼容性有優(yōu)勢(shì)支持Web Worker環(huán)境跑也支持Node.js環(huán)境。如果代碼需要在瀏覽器和Node.js兩側(cè)復(fù)用選crypto-js這類庫(kù)就很方便。我用它做過桌面端工具的插件體驗(yàn)還算穩(wěn)定。3.3 到底要不要手寫SHA-256手寫SHA-256是這次項(xiàng)目里最有意思的部分也是標(biāo)題里“算法原理代碼全解”最值得展開的一部分。手寫實(shí)現(xiàn)不需要任何外部依賴性能介于原生和crypto-js之間而且能天然支持增量計(jì)算和流式處理。但手寫SHA-256的風(fēng)險(xiǎn)也很明顯如果沒有吃透算法代碼極易出現(xiàn)隱蔽的bug。最典型的就是加法溢出問題還有填充時(shí)長(zhǎng)度表示與字節(jié)序問題。如果你只是想做一個(gè)功能我會(huì)推薦優(yōu)先用crypto.subtle因?yàn)樗?jiǎn)單、快、近乎0出錯(cuò)率。如果你想理解哈希原理或者需要流式處理能力那么手寫實(shí)現(xiàn)就是一個(gè)不錯(cuò)的練習(xí)和備用方案。我把三個(gè)方案整理成了一個(gè)對(duì)比表方便快速?zèng)Q策方案性能增量計(jì)算安全上下文要求體積適用場(chǎng)景crypto.subtle極高硬件加速不支持必須HTTPS或localhost0普通字符串/小文件哈希crypto-js中支持無約40KB兼容性優(yōu)先的老項(xiàng)目手寫實(shí)現(xiàn)中上支持無自定義學(xué)習(xí)原理、大文件流式處理對(duì)這次的項(xiàng)目來說我決定兩個(gè)都做界面工具用crypto.subtle做默認(rèn)計(jì)算因?yàn)橛脩舸蟾怕试贖TTPS環(huán)境打開同時(shí)準(zhǔn)備一個(gè)手寫的流式實(shí)現(xiàn)專門用來處理大文件的分片計(jì)算。這樣兩種場(chǎng)景都能覆蓋。4. 完整代碼實(shí)現(xiàn)頁(yè)面結(jié)構(gòu)、核心函數(shù)、手寫版流式SHA-2564.1 頁(yè)面骨架設(shè)計(jì)這個(gè)工具頁(yè)面的核心元素特別簡(jiǎn)單就三個(gè)交互區(qū)域一個(gè)文本輸入框、一個(gè)文件選擇框、一個(gè)結(jié)果展示區(qū)。文本輸入框?qū)崟r(shí)監(jiān)聽input事件每次變化都重新計(jì)算哈希。文件選擇支持分片讀取計(jì)算完成后顯示十六進(jìn)制結(jié)果和處理耗時(shí)。我不想在這個(gè)頁(yè)面上堆太多UI庫(kù)直接用原生HTML和一點(diǎn)CSS就能達(dá)到效果。結(jié)構(gòu)上保持一個(gè)整潔的單列布局輸入?yún)^(qū)域在上方結(jié)果區(qū)域在下方再加上一個(gè)計(jì)算耗時(shí)的狀態(tài)提示整體信息很清晰。4.2 字符串哈希的核心實(shí)現(xiàn)字符串哈希的思路很直觀把字符串編碼為Uint8Array交給crypto.subtle計(jì)算然后把ArrayBuffer轉(zhuǎn)成十六進(jìn)制字符串。代碼如下async function sha256Text(text) { const encoder new TextEncoder(); const data encoder.encode(text); const hashBuffer await crypto.subtle.digest(SHA-256, data); return bufToHex(hashBuffer); } function bufToHex(buffer) { const bytes new Uint8Array(buffer); let result ; for (let i 0; i bytes.length; i) { result bytes[i].toString(16).padStart(2, 0); } return result; }這個(gè)代碼看起來簡(jiǎn)單但有一個(gè)細(xì)節(jié)值得強(qiáng)調(diào)文本編碼必須用TextEncoder。之前我看到過有人用unescape(encodeURIComponent(str))這樣的寫法把字符串轉(zhuǎn)字節(jié)也能用但TextEncoder是現(xiàn)代瀏覽器標(biāo)準(zhǔn)API處理UTF-8編碼更可靠。如果直接對(duì)字符串調(diào)用crypto.subtle.digest而不做類型轉(zhuǎn)換會(huì)因?yàn)轭愋筒粚?duì)直接拋錯(cuò)。還應(yīng)注意crypto.subtle.digest返回的是Promise所以需要await。在事件監(jiān)聽里調(diào)用時(shí)建議用async函數(shù)包裹避免出現(xiàn)未捕獲的Promise異常。4.3 文件哈希小文件和大文件的處理差異對(duì)小文件比如幾MB的圖片直接用FileReader或file.arrayBuffer()讀取整個(gè)文件然后交給crypto.subtle計(jì)算即可代碼量很少。async function sha256FileSmall(file) { const buffer await file.arrayBuffer(); const hashBuffer await crypto.subtle.digest(SHA-256, buffer); return bufToHex(hashBuffer); }但如果文件超過100MB一次性讀取整個(gè)文件進(jìn)內(nèi)存會(huì)讓頁(yè)面卡頓甚至觸碰到瀏覽器內(nèi)存限制。這時(shí)應(yīng)該用分片方式加上手寫流式SHA-256類來實(shí)現(xiàn)。const CHUNK_SIZE 1024 * 1024; // 1MB一片 async function sha256FileLarge(file, onProgress) { const sha new StreamingSha256(); let offset 0; while (offset file.size) { const end Math.min(offset CHUNK_SIZE, file.size); const chunk await file.slice(offset, end).arrayBuffer(); sha.update(new Uint8Array(chunk)); offset end; if (onProgress) { onProgress(offset / file.size); } } return sha.finalize(); }這里的優(yōu)勢(shì)在于內(nèi)存占用始終是固定大小只取決于CHUNK_SIZE設(shè)置而不是整個(gè)文件體積。用戶選擇1GB文件時(shí)也只是逐片讀取而已實(shí)際體驗(yàn)比一次性讀取順暢得多。StreamingSha256類就是手寫SHA-256的封裝它在內(nèi)部維護(hù)8個(gè)狀態(tài)變量和緩沖區(qū)每收滿64字節(jié)就壓縮一次同時(shí)記錄總長(zhǎng)度最終在finalize時(shí)完成填充和最后一輪壓縮。這個(gè)類我放在下一小節(jié)詳細(xì)展開。4.4 手寫StreamingSha256不依賴Web Crypto的流式哈希手寫SHA-256的完整實(shí)現(xiàn)需要寫壓縮函數(shù)、消息擴(kuò)展和填充邏輯。這里直接給出我整理后的核心代碼。const K [ 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85, 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2 ]; function rotr(x, n) { return ((x n) | (x (32 - n))) 0; } class StreamingSha256 { constructor() { this.state [ 0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19 ]; this.buffer new Uint8Array(64); this.bufferLen 0; this.byteLen 0; } update(bytes) { this.byteLen bytes.length; let pos 0; if (this.bufferLen 0) { const need 64 - this.bufferLen; const take Math.min(need, bytes.length); this.buffer.set(bytes.subarray(0, take), this.bufferLen); this.bufferLen take; pos take; if (this.bufferLen 64) { this._compress(this.buffer); this.bufferLen 0; } } while (pos 64 bytes.length) { this._compress(bytes.subarray(pos, pos 64)); pos 64; } if (pos bytes.length) { const rest bytes.length - pos; this.buffer.set(bytes.subarray(pos), 0); this.bufferLen rest; } return this; } finalize() { const bitLen BigInt(this.byteLen) * 8n; const bitLenHi Number(bitLen 32n); const bitLenLo Number(bitLen 0xffffffffn); const pad new Uint8Array(64); pad.set(this.buffer.subarray(0, this.bufferLen), 0); pad[this.bufferLen] 0x80; if (this.bufferLen 56) { this._compress(pad); pad.fill(0); } pad[56] (bitLenHi 24) 0xff; pad[57] (bitLenHi 16) 0xff; pad[58] (bitLenHi 8) 0xff; pad[59] bitLenHi 0xff; pad[60] (bitLenLo 24) 0xff; pad[61] (bitLenLo 16) 0xff; pad[62] (bitLenLo 8) 0xff; pad[63] bitLenLo 0xff; this._compress(pad); let result ; for (let i 0; i 8; i) { result this.state[i].toString(16).padStart(8, 0); } return result; } _compress(block) { const w new Array(64); for (let i 0; i 16; i) { w[i] ( (block[i * 4] 24) | (block[i * 4 1] 16) | (block[i * 4 2] 8) | block[i * 4 3] ) 0; } for (let i 16; i 64; i) { const s0 rotr(w[i - 15], 7) ^ rotr(w[i - 15], 18) ^ (w[i - 15] 3); const s1 rotr(w[i - 2], 17) ^ rotr(w[i - 2], 19) ^ (w[i - 2] 10); w[i] (w[i - 16] s0 w[i - 7] s1) 0; } let [a, b, c, d, e, f, g, h] this.state; for (let i 0; i 64; i) { const S1 rotr(e, 6) ^ rotr(e, 11) ^ rotr(e, 25); const ch (e f) ^ (~e g); const temp1 (h S1 ch K[i] w[i]) 0; const S0 rotr(a, 2) ^ rotr(a, 13) ^ rotr(a, 22); const maj (a b) ^ (a c) ^ (b c); const temp2 (S0 maj) 0; h g; g f; f e; e (d temp1) 0; d c; c b; b a; a (temp1 temp2) 0; } this.state[0] (this.state[0] a) 0; this.state[1] (this.state[1] b) 0; this.state[2] (this.state[2] c) 0; this.state[3] (this.state[3] d) 0; this.state[4] (this.state[4] e) 0; this.state[5] (this.state[5] f) 0; this.state[6] (this.state[6] g) 0; this.state[7] (this.state[7] h) 0; } }這個(gè)類是完整的可運(yùn)行實(shí)現(xiàn)參考了SHA-256標(biāo)準(zhǔn)定義和常見實(shí)現(xiàn)思路。你如果拿到StreamingSha256這個(gè)類可以配合任意File分片讀取邏輯實(shí)現(xiàn)流式哈希。它也支持直接傳字符串轉(zhuǎn)換的Uint8Array計(jì)算小數(shù)據(jù)也沒問題。這里有一個(gè)容易踩的坑就是finalize填充部分。SHA-256要求最后8字節(jié)表示原始消息的bit長(zhǎng)度不是字節(jié)長(zhǎng)度。所以代碼里用byteLen * 8n轉(zhuǎn)換成bit長(zhǎng)度。當(dāng)填充后本塊剩余不足8字節(jié)時(shí)需要額外補(bǔ)一個(gè)64字節(jié)的零塊來容納長(zhǎng)度這就是if (this.bufferLen 56)分支的作用。如果漏掉這個(gè)分支處理恰好處于邊界的數(shù)據(jù)時(shí)會(huì)得到錯(cuò)誤結(jié)果。為了驗(yàn)證這個(gè)手寫實(shí)現(xiàn)的正確性我用在線工具算了一組測(cè)試向量。輸入空字符串標(biāo)準(zhǔn)結(jié)果是e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855手寫實(shí)現(xiàn)得到的完全一致。輸入“hello world”標(biāo)準(zhǔn)結(jié)果是b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9結(jié)果也一致。確認(rèn)無誤后我才放心把它用于大文件分片邏輯。4.5 完整的頁(yè)面調(diào)用與事件綁定有了核心函數(shù)頁(yè)面調(diào)用就很直接了。文本輸入框監(jiān)聽input事件文件輸入監(jiān)聽change事件各自調(diào)用對(duì)應(yīng)的哈希函數(shù)然后把結(jié)果寫到頁(yè)面里。const textInput document.getElementById(textInput); const textHash document.getElementById(textHash); const fileInput document.getElementById(fileInput); const fileHash document.getElementById(fileHash); const hashTime document.getElementById(hashTime); textInput.addEventListener(input, async () { const start performance.now(); const hex await sha256Text(textInput.value); textHash.textContent hex; hashTime.textContent 耗時(shí) ${(performance.now() - start).toFixed(2)}ms; }); fileInput.addEventListener(change, async (e) { const file e.target.files[0]; if (!file) return; const start performance.now(); let hex; if (file.size 30 * 1024 * 1024) { hex await sha256FileSmall(file); } else { hex await sha256FileLarge(file, (p) { console.log(已處理 ${(p * 100).toFixed(1)}%); }); } fileHash.textContent hex; hashTime.textContent 耗時(shí) ${(performance.now() - start).toFixed(2)}ms; });這里對(duì)文件大小做了一個(gè)判斷小于30MB走簡(jiǎn)單的一次性讀取大于30MB走流式分片。這個(gè)閾值可以根據(jù)項(xiàng)目實(shí)際情況調(diào)整。比如移動(dòng)端設(shè)備內(nèi)存緊張建議把閾值調(diào)低到5MB甚至更低。5. 實(shí)戰(zhàn)中踩過的坑與排查經(jīng)驗(yàn)5.1 中文字符切成哈希后和在線工具對(duì)不上這是我第一次做文本哈希時(shí)遇到的第一個(gè)問題。同樣的“你好世界”我算出來的結(jié)果和某個(gè)在線網(wǎng)站對(duì)不上查了半天發(fā)現(xiàn)是編碼問題。在線網(wǎng)站在計(jì)算前會(huì)把字符串按UTF-8編碼轉(zhuǎn)成字節(jié)而某些老式教程使用charCodeAt直接拿Unicode碼點(diǎn)當(dāng)字節(jié)兩種方式的結(jié)果自然不同。正確的做法是統(tǒng)一使用TextEncoder編碼。如果你遇到哈希值不一致優(yōu)先檢查輸入字符串到字節(jié)的轉(zhuǎn)換方式是否一致。這個(gè)坑在英文文本下完全暴露不出來因?yàn)锳SCII字符的UTF-8字節(jié)和Unicode碼點(diǎn)一致中文場(chǎng)景才明顯。5.2 crypto.subtle在本地文件頁(yè)面下不可用瀏覽器出于安全考慮把crypto.subtle限制在了安全上下文里。如果你直接雙擊一個(gè)HTML文件在file://協(xié)議下打開頁(yè)面里crypto.subtle是未定義的。在局域網(wǎng)內(nèi)部測(cè)試時(shí)如果用IP地址而不是localhost訪問同樣可能被攔。解決方案有兩個(gè)本地開發(fā)時(shí)用localhost域名訪問或者直接起一個(gè)本地靜態(tài)服務(wù)器。最簡(jiǎn)單的做法是用npx serve或者寫一個(gè)Node靜態(tài)文件服務(wù)器通過http://localhost訪問頁(yè)面。這個(gè)問題排查起來不算難但第一次遇到確實(shí)容易懵。5.3 Web Crypto API不支持增量計(jì)算如何應(yīng)對(duì)大文件前面提過crypto.subtle.digest必須一次性傳入完整數(shù)據(jù)。對(duì)大文件來說這意味著內(nèi)存要一次性裝下整個(gè)文件GPU加速帶來的性能優(yōu)勢(shì)會(huì)被內(nèi)存瓶頸抵消。我的方案是把大文件哈希全部交給手寫的StreamingSha256類處理。它天然是增量式的每收到64字節(jié)就完成壓縮更新內(nèi)部狀態(tài)。與此同時(shí)這個(gè)類不依賴任何瀏覽器API所以在Web Worker里也能用可以把計(jì)算放到后臺(tái)線程避免阻塞主線程UI。不過在工程里我更建議的方案是分層處理小文件直接用Web Crypto大文件拆進(jìn)Web Worker里跑手寫實(shí)現(xiàn)。這樣既快又不會(huì)卡界面。如果你擔(dān)心手寫實(shí)現(xiàn)不夠信任也可以找經(jīng)過審計(jì)的第三方流式哈希庫(kù)。5.4 常見問題速查表問題原因解決辦法中文哈希結(jié)果不一致字符串編碼方式不同統(tǒng)一使用TextEncodercrypto.subtle未定義非安全上下文使用localhost或HTTPS大文件頁(yè)面卡頓一次性讀入內(nèi)存分片流式哈希手寫哈希結(jié)果錯(cuò)誤加法溢出未處理每步加法加 0傳入null或空值時(shí)類型報(bào)錯(cuò)參數(shù)校驗(yàn)缺失調(diào)用前檢查輸入類型計(jì)算大文件耗時(shí)過長(zhǎng)主線程阻塞移到Web Worker輸出少了一位0字節(jié)轉(zhuǎn)十六進(jìn)制未補(bǔ)前導(dǎo)零使用padStart(2, 0)這個(gè)速查表基本上覆蓋了我實(shí)際開發(fā)中遇到的大部分問題。值得強(qiáng)調(diào)的是最后一條字節(jié)轉(zhuǎn)十六進(jìn)制時(shí)如果某個(gè)字節(jié)小于16直接toString(16)只會(huì)得到一個(gè)字符比如0x0d會(huì)輸出d不補(bǔ)零的話整個(gè)哈希長(zhǎng)度會(huì)少一位和標(biāo)準(zhǔn)結(jié)果完全對(duì)不上。這個(gè)細(xì)節(jié)非常隱蔽但對(duì)結(jié)果正確性影響很大。5.5 Web Worker與主線程協(xié)作的擴(kuò)展思路再說一個(gè)值得推薦的優(yōu)化方向把SHA-256計(jì)算放到Web Worker里。當(dāng)前頁(yè)面在計(jì)算大文件時(shí)雖然采用了流式分片但是如果計(jì)算邏輯和UI在同一線程分片讀取和壓縮計(jì)算仍然會(huì)占用主線程用戶滾動(dòng)頁(yè)面時(shí)能感覺到卡頓。把StreamingSha256類打包成一個(gè)worker腳本主線程通過postMessage把分片的ArrayBuffer傳給workerworker壓縮完再返回進(jìn)度消息和結(jié)果。這樣UI線程只負(fù)責(zé)讀文件和更新顯示計(jì)算密集任務(wù)都在后臺(tái)完成。const worker new Worker(sha256-worker.js); worker.onmessage (e) { if (e.data.type progress) { // 更新進(jìn)度條 } else if (e.data.type result) { // 顯示最終哈希 } }; // 主線程分片讀取并發(fā)送給worker file.arrayBuffer().then((buf) { worker.postMessage({ type: chunk, data: buf }, [buf]); });把計(jì)算移出主線程頁(yè)面始終保持60fps的流暢體驗(yàn)這個(gè)改進(jìn)在大文件場(chǎng)景下感知非常明顯。如果你要做的不是一個(gè)學(xué)習(xí)Demo而是一個(gè)真實(shí)產(chǎn)品功能我非常建議加上這一層。6. 從實(shí)現(xiàn)到產(chǎn)品化還能繼續(xù)擴(kuò)展的細(xì)節(jié)哈希生成器做到這個(gè)程度已經(jīng)能直接用作內(nèi)部工具了。但如果你要把它接入真實(shí)項(xiàng)目還有幾個(gè)細(xì)節(jié)可以繼續(xù)打磨。第一個(gè)是輸出格式多樣化。目前只輸出十六進(jìn)制但很多場(chǎng)景需要Base64格式的哈希值。Base64用4個(gè)字節(jié)表示3個(gè)字節(jié)的二進(jìn)制數(shù)據(jù)長(zhǎng)度更短在URL參數(shù)和JSON字段里更省空間。把ArrayBuffer轉(zhuǎn)Base64可以用btoa配合二進(jìn)制拼接但要處理好大Buffer的分段問題避免參數(shù)過長(zhǎng)導(dǎo)致瀏覽器報(bào)錯(cuò)。第二個(gè)是復(fù)制功能與展示優(yōu)化。大多數(shù)用戶拿到哈希值后要立刻粘貼到別的地方所以頁(yè)面里加一個(gè)“復(fù)制結(jié)果”按鈕是比較自然的體驗(yàn)。再往前一步可以給每條記錄加上時(shí)間戳和歷史記錄做成一個(gè)小的哈希工具箱。第三個(gè)是校驗(yàn)?zāi)芰?。如果用戶手上有一段下載時(shí)拿到的期望哈?？梢宰屗迟N到頁(yè)面里做自動(dòng)比對(duì)比對(duì)一致就顯示綠色標(biāo)簽“校驗(yàn)通過”。這個(gè)功能會(huì)讓工具從單純的計(jì)算器升級(jí)成校驗(yàn)器實(shí)用性更強(qiáng)。第四個(gè)是批量文件處理。當(dāng)前實(shí)現(xiàn)一次只能處理一個(gè)文件如果用戶要校驗(yàn)一個(gè)目錄下多個(gè)文件最好支持多文件選擇和批量哈希列表。這個(gè)擴(kuò)展在瀏覽器端的難點(diǎn)主要是文件選擇控件的多選支持以及大數(shù)據(jù)量下頁(yè)面的渲染性能。這些擴(kuò)展每一樣都不難但真正落地時(shí)會(huì)有一些交互細(xì)節(jié)問題。我這里不展開全部代碼先把思路列出來對(duì)你有參考價(jià)值。最后再分享一個(gè)小經(jīng)驗(yàn)寫哈希工具時(shí)最好在頁(yè)面上留一個(gè)大小合適的測(cè)試大文件比如100MB左右方便隨時(shí)驗(yàn)證性能。我在開發(fā)過程中反復(fù)用同一個(gè)文件測(cè)不同方案的耗時(shí)最后才確定了“小文件走Web Crypto大文件走Worker加流式實(shí)現(xiàn)”的決策。沒有實(shí)測(cè)數(shù)據(jù)方案選型就只能是空談這一點(diǎn)比任何理論都重要。