我遇到了验证JWT的问题。我正在运行的代码是一个相当肮脏的黑客，它需要JWT的第二个组件并通过Base64解码器运行它。然而事实证明，对于一些超级特殊的JWT，我得到了一些非法字符（5f）。
这是在使用Base64.getDecoder().decode(claims)时
我读了一下，有点想通知我必须使用Base64.getUrlDecoder().decode(claims)来使它工作（它似乎在做）。
但我不完全明白为什么......我在Base64的文档中找到了这个：
基本 使用＆＃34; Base64字母＆＃34;如RFC 4648和RFC 2045的表1中所规定的用于编码和解码操作。编码器不添加任何换行（行分隔符）字符。解码器拒绝包含base64字母表之外的字符的数据。
URL和文件名安全 使用＆＃34; URL和文件名安全Base64字母＆＃34;如RFC 4648的表2中所规定的编码和解码。编码器不添加任何换行（行分隔符）字符。解码器拒绝包含base64字母表之外的字符的数据。
这里唯一的区别是Basic也使用RFC 2045，但有人可以解释这是一个什么问题吗？
答案 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）时才使用第二个表。