JWT Base64 解码在 Notepad++ 中失败
JWT Base64 Decode failed in Notepad++
在 Notepad++ 中，我在解码 JWT 时遇到问题。当我尝试将 Plugins -> MIME Tools -> Base64 Decode 与：
一起使用时
eyJleHAiOjE0NDIzNjAwMzQsIm5iZiI6MTQ0MjM1NjQzNCwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tLzc3NTUyN2ZmLTlhMzctNDMwNy04YjNkLWNjMzExZjU4ZDkyNS92Mi4wLyIsImFjciI6ImIyY18xX3NpZ25faW5fc3RvY2siLCJzdWIiOiJOb3Qgc3VwcG9ydGVkIGN1cnJlbnRseS4gVXNlIG9pZCBjbGFpbS4iLCJhdWQiOiI5MGMwZmU2My1iY2YyLTQ0ZDUtOGZiNy1iOGJiYzBiMjlkYzYiLCJpYXQiOjE0NDIzNTY0MzQsImF1dGhfdGltZSI6MTQ0MjM1NjQzNCwiaWRwIjoiZmFjZWJvb2suY29tIn0
我得到：
Length of selected text (not including EOL) to be decoded is invalid.
It should be mod 4.
但是如果使用 www.base64decode.org 它工作正常:
{"exp":1442360034,"nbf":1442356434,"ver":"1.0","iss":"https://login.microsoftonline.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/","acr":"b2c_1_sign_in_stock","sub":"Not supported currently. Use oid claim.","aud":"90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6","iat":1442356434,"auth_time":1442356434,"idp":"facebook.com"}
这是为什么？我是不是用错了Notepad++？
我使用的值来自 Azure AD B2C: Token reference。
更新2020/01/28
我刚刚尝试了上面的 JWT，Plugins -> MIME Tools -> Base64 Decode 现在可以处理这个用例了。我在插件的 v2.5 上。我猜 v2.2 "fixed" this:
Npp mime tools v2.2 release
donho released this on Nov 28, 2018
Enhance base64: decode/encode without padding
上面的token和Azure B2C doc indicated and it seems invalid. Unless this question is about Notepad++, I'd recommend using a site like https://jwt.ms解码的token不一样。 jwt.ms 不仅可以帮助您解码令牌，还可以帮助您理解每个声明的含义。
JWT 使用 "base64url" 编码，后者使用 URL 安全字母表。
“base64url”编码是 Base 64 编码，其中 URL- 保留字符被替换（例如 - 替换 +，_ 替换 /) 并且删除了填充字符。
简答：
要使字符串可解码，您必须使编码后的字符串中的字符数为 4 的整数倍。这意味着您必须将字符数除以 4，且不得有余数。在这种特殊情况下，您有 443 个字符。在末尾添加 = 将使其可解码。
长答案：
Base64 编码使用一种叫做填充的东西。输出中的字符数必须是 4 的整数倍。如果实际输出不满足该要求，编码算法将向输出添加额外的填充字符。填充字符通常是=。
Wikipedia of how this works. You can also see this SO post.
上有一些示例
"ordinary" base64url 编码与 JWT 使用的 base64url 编码之间存在差异：JWT 会跳过填充字符。它们根本没有被添加。所以 JWT 的任何解码算法都必须考虑到这一事实。
普通的 base64 解码器不允许将没有填充的编码字符串作为输入（如果需要填充）。大多数解码器在解码算法的开头都有一个断言，他们检查输入字符串的长度并检查长度 % 4 = 0。你可以从错误消息中看到
Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.
长度错误，因为缺少填充字符。
因此，使用处理无垫弦的解码器是可行的方法。安德烈已经链接了一个网站。 Here 是另一个。
在 Notepad++ 中，我在解码 JWT 时遇到问题。当我尝试将 Plugins -> MIME Tools -> Base64 Decode 与：
eyJleHAiOjE0NDIzNjAwMzQsIm5iZiI6MTQ0MjM1NjQzNCwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tLzc3NTUyN2ZmLTlhMzctNDMwNy04YjNkLWNjMzExZjU4ZDkyNS92Mi4wLyIsImFjciI6ImIyY18xX3NpZ25faW5fc3RvY2siLCJzdWIiOiJOb3Qgc3VwcG9ydGVkIGN1cnJlbnRseS4gVXNlIG9pZCBjbGFpbS4iLCJhdWQiOiI5MGMwZmU2My1iY2YyLTQ0ZDUtOGZiNy1iOGJiYzBiMjlkYzYiLCJpYXQiOjE0NDIzNTY0MzQsImF1dGhfdGltZSI6MTQ0MjM1NjQzNCwiaWRwIjoiZmFjZWJvb2suY29tIn0
我得到：
Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.
但是如果使用 www.base64decode.org 它工作正常:
{"exp":1442360034,"nbf":1442356434,"ver":"1.0","iss":"https://login.microsoftonline.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/","acr":"b2c_1_sign_in_stock","sub":"Not supported currently. Use oid claim.","aud":"90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6","iat":1442356434,"auth_time":1442356434,"idp":"facebook.com"}
这是为什么？我是不是用错了Notepad++？
我使用的值来自 Azure AD B2C: Token reference。
更新2020/01/28
我刚刚尝试了上面的 JWT，Plugins -> MIME Tools -> Base64 Decode 现在可以处理这个用例了。我在插件的 v2.5 上。我猜 v2.2 "fixed" this:
Npp mime tools v2.2 release
donho released this on Nov 28, 2018
Enhance base64: decode/encode without padding
上面的token和Azure B2C doc indicated and it seems invalid. Unless this question is about Notepad++, I'd recommend using a site like https://jwt.ms解码的token不一样。 jwt.ms 不仅可以帮助您解码令牌，还可以帮助您理解每个声明的含义。
JWT 使用 "base64url" 编码，后者使用 URL 安全字母表。
“base64url”编码是 Base 64 编码，其中 URL- 保留字符被替换（例如 - 替换 +，_ 替换 /) 并且删除了填充字符。
简答：
要使字符串可解码，您必须使编码后的字符串中的字符数为 4 的整数倍。这意味着您必须将字符数除以 4，且不得有余数。在这种特殊情况下，您有 443 个字符。在末尾添加 = 将使其可解码。
长答案：
Base64 编码使用一种叫做填充的东西。输出中的字符数必须是 4 的整数倍。如果实际输出不满足该要求，编码算法将向输出添加额外的填充字符。填充字符通常是=。
Wikipedia of how this works. You can also see this SO post.
上有一些示例"ordinary" base64url 编码与 JWT 使用的 base64url 编码之间存在差异：JWT 会跳过填充字符。它们根本没有被添加。所以 JWT 的任何解码算法都必须考虑到这一事实。
普通的 base64 解码器不允许将没有填充的编码字符串作为输入（如果需要填充）。大多数解码器在解码算法的开头都有一个断言，他们检查输入字符串的长度并检查长度 % 4 = 0。你可以从错误消息中看到
Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.
长度错误，因为缺少填充字符。
因此，使用处理无垫弦的解码器是可行的方法。安德烈已经链接了一个网站。 Here 是另一个。