您的位置:首页 >C#如何进行Base64编码转换_C#图片与字符串Base64互转【实用】
发布于2026-05-05 阅读(0)
扫一扫,手机访问

说起来,Convert.ToBase64String 和 Convert.FromBase64String 这两个方法用起来看似简单,但真正踩过坑的人都知道,90%的问题都不是方法本身用错了,而是出在“字节转换”这个前置环节——要么被跳过了,要么选错了编码,要么就是输入数据没清理干净。
首先得明确一点:Convert.ToBase64String 只认 byte[],直接把字符串扔给它?编译器第一个不答应。
Encoding.UTF8.GetBytes(“你好”) 拿到字节数组,再交给 Convert.ToBase64String 去处理。Encoding.Default。这个属性依赖系统区域设置,代码一旦部署到Linux服务器,或者换了不同语言的Windows环境,乱码几乎就是必然结果。Encoding.ASCII,但为了杜绝混用时的潜在风险,统一使用UTF-8是最省心的策略。string base64 = Convert.ToBase64String(Encoding.UTF8.GetBytes(“Hello 世界”)); 得到的结果就是 SGVsbG8g5L2g5aW9。Convert.FromBase64String 这个方法,脾气可不小,对输入格式要求极为严格。遇到空格、换行,或者字符串长度不是4的倍数?它会毫不客气地抛出一个 FormatException。
)、空格甚至制表符。解码前,务必先用 .Replace(“ ”, “”).Replace(“”, “”).Replace(“”, “”) 把它们清理干净。- 代替 +,用 _ 代替 /。这时候需要先还原:.Replace(‘-‘, ‘+’).Replace(‘_’, ‘/’)。= 有时会被截断。怎么办?检查字符串长度除以4的余数:余1就补3个 =;余2补2个;余3补1个;正好整除就不用补。一个实用的技巧是使用 .PadRight(len + (4 - len % 4) % 4, ‘=’) 来统一处理。try/catch 把解码逻辑包裹起来。毕竟上游数据不可控,一个异常导致整个流程崩溃就得不偿失了。处理图片、PDF、ZIP这类二进制文件时,关键是要记住它们不是文本。如果错误地用读取文本的方式(比如StreamReader)去处理,字节序列会被破坏,编码出来的Base64再解码回去,文件肯定打不开。
File.ReadAllBytes(@“path.jpg”) 直接获取文件的原始字节流,然后再交给 Convert.ToBase64String。@ 前缀原样字符串,或者双写反斜杠(\\),否则 会被解释为转义字符。ReadAllBytes,因为它会把整个文件一次性读入内存,内存占用会膨胀到文件大小的约133%,很容易引发 OutOfMemoryException。FileStream,每次读取一小块(例如最多3072字节的原始数据,对应4096字节的Base64输出),然后逐步拼接最终的Base64字符串。解码后得到的 byte[],是纯粹的二进制数据,必须原封不动地写入文件。任何试图将其转换为字符串再保存的操作,都会破坏文件结构。
File.WriteAllText(path, Encoding.UTF8.GetString(bytes))。这相当于把图片的二进制数据当成了UTF-8文本去解释和保存,结果就是一张无法打开的“花图”。File.WriteAllBytes(path, Convert.FromBase64String(base64))。一步到位,保持字节原样。data:image/png;base64,iVBORw…),在解码前,必须先用 .Substring() 或者正则表达式把 data:image/png;base64, 这个前缀去掉,只保留后面纯的Base64部分。Directory.CreateDirectory(Path.GetDirectoryName(path)) 可以避免抛出 DirectoryNotFoundException。说到底,Base64只是一种编码,而非加密。所有操作都围绕一个核心前提展开:确保字节流原样进出。一旦在字符串和字节的转换过程中使用了不一致的编码,或者对二进制数据进行了不当的文本化处理,原始内容就再也无法完美还原了。这一点,往往是实践中最容易忽略,也最需要警惕的。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8