C#:根据 RFC4648 的 base64url [英] C#: base64url according to RFC4648

问题描述

我正在根据 RFC4648 在 C# 中.

I'm looking for a (fast) standard implementation for base64url according to RFC4648 in C#.

我发现 HttpServerUtility.UrlTokenEncode 但看起来这不遵循 RFC4648(UrlTokenEncode 在末尾添加一个数字，表示已删除的 = 符号的数量；请参阅此处和这里).

I found HttpServerUtility.UrlTokenEncode but it looks like this doesn't follow RFC4648 (UrlTokenEncode adds a number at the end which indicates the number of = signs that were removed; see here and here).

例子:

base64 编码:

Convert.ToBase64String(System.Text.Encoding.ASCII.GetBytes(AA"));//返回QUE="

Convert.ToBase64String(System.Text.Encoding.ASCII.GetBytes("AA")); //returns "QUE="

base64url 编码:

base64url encoding:

HttpServerUtility.UrlTokenEncode(System.Text.Encoding.ASCII.GetBytes(AA"));//返回QUE1"但我会期待QUE"

HttpServerUtility.UrlTokenEncode(System.Text.Encoding.ASCII.GetBytes("AA")); //returns "QUE1" but I would expect "QUE"

推荐答案

根据评论，听起来 System.Web.HttpServerUtility.UrlTokenEncode 做了正确的事情除了 用于填充的额外字符.所以你应该能够做到:

Based on the comments, it sounds like System.Web.HttpServerUtility.UrlTokenEncode does the right thing except for the extra character for padding. So you should be able to do:

string customBase64 = HttpServerUtility.UrlTokenEncode(data);
string rfc4648 = customBase64.Substring(0, customBase64.Length - 1);

但是，您应该添加单元测试以检查它是否确实使用了 RFC 4648 字母表(并且与 RFC 4648 的方式相同).文档如此稀疏有点令人惊讶:(

However, you should add unit tests to check that it really does use the RFC 4648 alphabet (and in the same way as RFC 4648). It's somewhat surprising that the docs are so sparse :(

这篇关于C#:根据 RFC4648 的 base64url的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！