[英]Difference between Convert.ToBase64String/Convert.FromBase64String and Encoding.UTF8.GetBytes/Encoding.UTF8.GetString
[英]Convert.ToBase64String/Convert.FromBase64String doesn't return the original string value
"encryptedHelloWorld=" ==
Convert.ToBase64String(
Convert.FromBase64String("encryptedHelloWorld="))
此語句返回 false
Convert.ToBase64String(Convert.FromBase64String("encryptedHelloWorld="))
返回"encryptedHelloWorlc="
知道為什么嗎?
encryptedHelloWorld=
的原始值未正確進行 base-64 編碼。
最后一個“d”包含一個額外的位,在這種情況下提取時會被忽略,它緊接在 padding 之前。 更嚴格的 base-64 解碼器可能會有效地引發錯誤。
最小的失敗輸入案例包括rld=
或abq=
。 只有帶有填充的最后一部分是相關的,如下所述。
考慮 base-64 字符的每個輸出字符每個代表6 位。
因此在rld=
編碼的信息是:
r
- 6 位l
- 6 位d
- 6 位(4 個相關 = "c" + 2 個額外的)=
- 不適用這必須提取為 2 個字節(8 + 8 = 16 位)。
但是,6 + 6 + 6 = 18 位並且不是8 的倍數。在初始 base-64 值中,有 2 個額外的位將“c”與“d”區分開來,這些位不反映實際的編碼信息。
在解碼過程中,.NET 解碼器實現默默地丟棄了“d”中的兩個額外位,因為它們無處可去。 (這對於像abq=
as "q" > "c" 這樣的情況也是正確的;注意大寫字母在 base-64 輸出空間中排在第一位,所以 "Q" < "c"。)
在沒有填充的正常情況下,每 4 個 base-64 字符在 3 個字節中均勻解碼,這就是為什么這個特殊問題只出現在 base-64 字符串的末尾,它不是 4 個 base-64 字符的偶數倍(不包括填充字符)。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.