gpt4 book ai didi

java - 不同的 Base64 解码器

转载 作者:行者123 更新时间:2023-11-30 06:16:50 29 4
gpt4 key购买 nike

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

这是使用Base64.getDecoder().decode(claims)时我读了一下,发现我必须使用 Base64.getUrlDecoder().decode(claims) 来让它工作(看起来确实如此)。

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

Basic Uses "The Base64 Alphabet" as specified in Table 1 of RFC 4648 and RFC 2045 for encoding and decoding operation. The encoder does not add any line feed (line separator) character. The decoder rejects data that contains characters outside the base64 alphabet.

URL and Filename safe Uses the "URL and Filename safe Base64 Alphabet" as specified in Table 2 of RFC 4648 for encoding and decoding. The encoder does not add any line feed (line separator) character. The decoder rejects data that contains characters outside the base64 alphabet.

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

最佳答案

此答案基于 Alex K 的评论。

RFC 2045 是 Base64 编码的原始 RFC。在使用此 RFC 时,一段时间后很明显,此编码不适用于 URL/URI 编码,因为此 RFC 使用字符 +/

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

所以今天您必须使用两个表之一来进行 Base64 编码。应尽可能使用第一个表,而仅当使用 +/ 导致问题(例如 URL)时才应使用第二个表。

关于java - 不同的 Base64 解码器,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49007428/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com