Question

两种编码可以映射到同一解码的预期行为吗？我正在尝试通过对base64编码的中间字符串进行完整性检查来解决数字签名问题。

例如，以下base64编码：

R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=

和

R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==

都解码为：

GET


Fri, 04 Sep 2009 11:05:49 GMT+00:00
/

（转义的字符为：GET\n\n\n Fri, 04 Sep 2009 11:05:49 GMT+00:00\n/）

第一个编码来自测试两个在线base64编码器。

第二种编码来自Objective-C base64编码器available here。

我用Obj-C编码器生成的结果有问题吗？

Answer 1

使用Python证明字符串不相等的另一个例子：

>>> from base64 import decodestring as d
>>> a = "R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8="
>>> b = "R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw=="
>>> d(a)
'GET\r\n\r\n\r\nFri, 04 Sep 2009 11:05:49 GMT+00:00\r\n/'
>>> d(b)
'GET\n\n\nFri, 04 Sep 2009 10:33:28 GMT+00:00\n/'
>>> d(a) == d(b)
False

较长的字符串使用CRLF-linebreaks，较短的一个普通LF。

Answer 2

很明显，编码的字符串具有与字母数字字符对应的模式，与字线对应的字符串不同。所以不同之处在于因为软件处理换行符（CR（\ r），LF（\ n）或CRLF（\ r \ n））的“编码” - >“解码”方式不同而且这就是为什么你有这样的结果。

除此之外，没有两种不同的方法可以将给定的字符串编码为Base64，也没有两种不同的方法来解码有效的Base64编码数据。

Answer 3

实际上，他们并没有解码同样的东西。

$ echo 'R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==' | base64 -d | hexdump 
0000000 4547 0a54 0a0a 7246 2c69 3020 2034 6553
0000010 2070 3032 3930 3120 3a30 3333 323a 2038
0000020 4d47 2b54 3030 303a 0a30 002f          
000002b
$ echo 'R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=' | base64 -d | hexdump
0000000 4547 0d54 0d0a 0d0a 460a 6972 202c 3430
0000010 5320 7065 3220 3030 2039 3131 303a 3a35
0000020 3934 4720 544d 302b 3a30 3030 0a0d 002f
000002f

Answer 4

正如@sharptooth建议的那样，第一个换行符中的 \r\n ，第二个换行符中的 \n 。

>>> base64.b64decode("R0VUDQoNCg0KRnJpLCAwNCBTZXAgMjAwOSAxMTowNTo0OSBHTVQrMDA6MDANCi8=")
'GET\r\n\r\n\r\nFri, 04 Sep 2009 11:05:49 GMT+00:00\r\n/'
>>> base64.b64decode("R0VUCgoKRnJpLCAwNCBTZXAgMjAwOSAxMDozMzoyOCBHTVQrMDA6MDAKLw==")
'GET\n\n\nFri, 04 Sep 2009 10:33:28 GMT+00:00\n/'

Answer 5

关键是base 64字符串解码为 bytes 的序列，而不是字符。比较每个基本64字符串产生的字节数组表明差异在于如何完成行终止 - 无论第一个有13然后是10，第二个只有10。这是标准的Windows-vs- Unix行终止差异。

两个Base64编码产生相同的解码

5 个答案: