不同的Base64解码器

时间:2018-02-27 11:18:15

标签: java base64 jwt decode

我遇到了验证JWT的问题。我正在运行的代码是一个相当肮脏的黑客,它需要JWT的第二个组件并通过Base64解码器运行它。然而事实证明,对于一些超级特殊的JWT,我得到了一些非法字符(5f)。

这是在使用Base64.getDecoder().decode(claims)时 我读了一下,有点想通知我必须使用Base64.getUrlDecoder().decode(claims)来使它工作(它似乎在做)。

但我不完全明白为什么......我在Base64的文档中找到了这个:

  

基本   使用" Base64字母"如RFC 4648和RFC 2045的表1中所规定的用于编码和解码操作。编码器不添加任何换行(行分隔符)字符。解码器拒绝包含base64字母表之外的字符的数据。

     

URL和文件名安全   使用" URL和文件名安全Base64字母"如RFC 4648的表2中所规定的编码和解码。编码器不添加任何换行(行分隔符)字符。解码器拒绝包含base64字母表之外的字符的数据。

这里唯一的区别是Basic也使用RFC 2045,但有人可以解释这是一个什么问题吗?

1 个答案:

答案 0 :(得分:1)

此答案基于Alex K的评论。

RFC 2045是Base64编码的原始RFC。在使用此RFC时,很明显此编码不适用于URL / URI编码,因为此RFC使用字符;WITH daterange(mindate, maxdate) AS ( SELECT MIN(insdate) AS mindate, MAX(insdate) AS maxdate FROM dt ) WITH t(specific_day) AS ( SELECT mindate -- Seed Row UNION ALL SELECT specific_day + 1 -- Recursion FROM t WHERE specific_day + 1 <= maxdate ) SELECT * FROM t OPTION (maxrecursion 5000) +

后来修改了RFC(RFC 4648),其中包含一个新表,其中包含可用于编码的字符。此表使用其他字符代替/+

所以今天你必须使用两个表中的一个作为base64编码。应尽可能使用第一个表,而仅在/+的使用导致问题(例如URL)时才使用第二个表。