Convert.ToBase64String和Convert.FromBase64String是C#中最直接、轻量的Base64编解码方法，适用于内存中byte[]数据，需注意UTF-8编码转换、非标准字符串清理、大文件流式处理及URL/JSON兼容性问题。
用
和
最直接
这两个静态方法是 C# 中最常用、最轻量的 Base64 编解码方式，适用于内存中已有的
数据。不需要额外引用，
命名空间自带。
编码
：把
字节
数组转成 Base64 字符串，结果不含换行、无空格，纯 ASCII
解码：必须传入合法的 Base64 字符串，否则抛出
注意：输入字符串需是 UTF-8 编码的原始文本时，要先用
转成字节数组再编码
处理非标准 Base64 字符串（含换行、空格、URL 不友好字符）
HTTP 查询参数或文件内容里常出现带换行、空格或用
/
替代
/
的变体（即 Base64Url 编码），
会直接报错。
先清理：用
去掉空白
Base64Url 场景：需手动替换
→
、
→
，再补足等号（长度需是 4 的倍数）
补等号逻辑：计算当前长度 % 4，缺几位就补几个
；例如长度 31 → 补 1 个
大文件或流式数据别一次性读进内存
对几 MB 以上的文件直接用
+
容易触发 GC 压力甚至
。应改用流式处理。
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
下载
编码大文件：用
读原文本块，逐段转
再编码，拼接字符串（注意不要用
）
更稳妥方案：用
配合
/
，但它们已标记为 [Obsolete]，仅限 .NET Framework
.NET 5+ 推荐：用
+ 自定义缓冲区，或借助第三方库如
的
编码后字符串长度和 URL/JSON 兼容性问题
Base64 编码会使体积膨胀约 33%（每 3 字节 → 4 字符），且默认含
、
、
，在 URL 或 JSON 中需额外处理。
URL 场景：必须做 Base64Url 编码（
→
，
→
，去掉末尾
）
JSON 场景：虽然
/
合法，但某些旧解析器会误判；建议统一用 Base64Url 变体
长度校验：解码前可快速检查字符串长度是否为 4 的倍数，以及是否只含 Base64 字符集（A–Z a–z 0–9 + / =），避免异常爆炸
真正容易被忽略的是：不同平台对 Base64 填充等号的容忍度不一，有些库允许省略，有些强制要求。生产环境建议始终补全并验证格式，而不是依赖“看起来差不多”。
Convert.ToBase64StringConvert.FromBase64Stringbyte[]SystemFormatExceptionEncoding.UTF8.GetBytes()string original = "Hello 世界";
byte[] bytes = Encoding.UTF8.GetBytes(original);
string encoded = Convert.ToBase64String(bytes); // "SGVsbG8g5L2g5aW9"
byte[] decodedBytes = Convert.FromBase64String(encoded);
string decoded = Encoding.UTF8.GetString(decodedBytes); // "Hello 世界"
-_+/Convert.FromBase64String.Replace(" ", "").Replace("\r", "").Replace("\n", "")-+_/==string urlSafe = "SGVsbG8g5L2g5aW9"; // 普通 Base64
// 若是 Base64Url："SGVsbG8g5L2g5aW9" → 实际可能写成 "SGVsbG8g5L2g5aW9"
string padded = urlSafe.PadRight(urlSafe.Length + (4 - urlSafe.Length % 4) % 4, '=');
byte[] result = Convert.FromBase64String(padded);File.ReadAllBytesConvert.ToBase64StringOutOfMemoryExceptionStreamReaderbyte[]+=System.Security.Cryptography.CryptoStreamFromBase64TransformToBase64TransformSystem.IO.StreamMicrosoft.Toolkit.HighPerformanceBase64.EncodeToUtf8+/=+-/_=+/