为啥.NET BASE64编码效率这么低？

Posted 2023-05-10

我用php可以实现将一个图片转换成base64编码的小程序，而且执行速度非常快，同样是我自己的电脑，500K的图片，瞬间编码完成，但是我用下面这段代码的时候，最大只能用20K左右的图片，再大程序就直接卡死，这是为什么呢？都是同样的方法，数据也不是特别大，为什么会出现卡死的情况？

源码：
Dim memorystreami As New System.IO.MemoryStream
Dim bytei As Byte()
Dim base64text As String
PictureBox1.Image.Save(memorystreami, PictureBox1.Image.RawFormat)
bytei = memorystreami.GetBuffer
base64text = Convert.ToBase64String(bytei)

求解，这是怎么回事！难道一定要用API？我水品不好，看不懂MSDN文档里的参数

你用的是.net 和别的base64有点区别
举个例子吧：一跟黄瓜要切成片（片好比base64后的代码），php 是一次所有的切完，而.net是先计划把黄瓜切成段(分配内存段大小)，每段的长度需要指定（这里是问题所在），然后根据你指定段的长度把这根黄瓜切成片。 参考技术A C++的总比.net的快这又是什么原因呢？这表明，运行环境不同，语言不同，计算的方式也会不同，自然效率也会不同，这样编程语言就没有比较可言。

为啥 ASP.Identy 使用 Base32 对 SecurityStamp 进行编码（内部实现）

【中文标题】为啥 ASP.Identy 使用 Base32 对 SecurityStamp 进行编码（内部实现）

【英文标题】：Why ASP.Identy encodes SecurityStamp using Base32 (internal implementation)为什么 ASP.Identy 使用 Base32 对 SecurityStamp 进行编码（内部实现）

【发布时间】：2020-05-16 22:16:11

【问题描述】：

我正在考虑使用 Base64 将 SecurityStamp 存储在我的用户聚合中。在进入陷阱之前，我试图了解 ASP 团队选择使用 Base32 而不是简单地使用 Base64 的原因。

SecurityStamp 不是人类应该在请求中手动读取或传递的东西。我找不到添加内部 Base32 实现而不是使用现有 Base64 的任何明显优势。

private static string NewSecurityStamp()
    
        byte[] bytes = new byte[20];
        _rng.GetBytes(bytes);
        return Base32.ToBase32(bytes);
    

https://github.com/dotnet/aspnetcore/blob/master/src/Identity/Extensions.Core/src/UserManager.cs#L2438

【参考方案1】：

如果您查看Base32 is using 的字母表，您会发现它都是大写字母和234567。这样做是为了在传输代码时专门减少人为错误（请参阅this SO answer 中的更多背景信息）。

当您进一步检查 UserManager 源代码时，您会看到 NewSecurityStamp 被 GenerateNewAuthenticatorKey 引用，我相信它的目的是提供人类可读的输出（例如，设置 2FA）没有要扫描的二维码）。

【讨论】：

对于 authentication-key 确实有意义，但对于 security-stamp 它不会引入任何价值。正如我在问题中提到的那样，最终用户不应该直接阅读或使用它。在大小方面，base64 更有效。