为什么不能直接用长文件名或含非法字符的文件名做存储路径
Windows 对路径总长度限制为
MAX_PATH（默认 260 字符），超长路径即使启用长路径支持，底层 API（如
File.Copy、
Directory.CreateDirectory）仍可能抛
PathTooLongException。更隐蔽的问题是文件名含
: " / \ | ? *或控制字符（如
\0、
\r），会导致
IOException或被文件系统拒绝创建。
Base64 编码不是万能解，但适合做文件名安全化映射
Base64 本身不压缩长度，反而会让原始字符串膨胀约 33%；但它能确保输出只含
A–Z a–z 0–9 + / =（标准 Base64）或
A–Z a–z 0–9 _ -（URL 安全变体），完全避开 Windows/Linux 文件系统非法字符。关键点在于：它只是「编码」，不是「加密」或「哈希」，必须可逆还原才能查回原文件名。 用
Convert.ToBase64String(Encoding.UTF8.GetBytes(fileName))编码，注意 UTF-8 是必须的——中文等 Unicode 字符若用 ASCII 编码会丢字 标准 Base64 含
+、
/、
=，在 URL 或路径中需额外处理；推荐改用 URL 安全 Base64：
Convert.ToBase64String(...).Replace('+', '-').Replace('/', '_').TrimEnd('=')
还原时要补回等号（Base64 长度必须是 4 的倍数）：base64 = base64.PadRight((base64.Length + 3) / 4 * 4, '='); base64 = base64.Replace('-', '+').Replace('_', '/');
实际存储时别只靠 Base64 编码，加一层保护逻辑
纯 Base64 编码后的文件名仍可能因过长触发路径限制（比如原始名 200 字符 → Base64 后约 268 字符）。真实项目中建议组合使用：
先截断原始文件名（保留扩展名），例如取前 100 字符 +_+
Guid.NewGuid().ToString("N").Substring(0, 8)，再 Base64 —— 避免不同文件撞码
把原始完整文件名存进数据库或 JSON 元数据文件，Base64 名只作磁盘路径标识，读取时查表还原
若需兼容大小写敏感文件系统（Linux），Base64 结果本身已全小写/大写无关，但要注意还原后大小写是否需保持一致（UTF-8 编码下大小写是保留的）
一个最小可用的封装示例
public static class SafeFileName
{
public static string ToSafeName(string original)
{
if (string.IsNullOrWhiteSpace(original)) return "unnamed";
var bytes = Encoding.UTF8.GetBytes(original);
var base64 = Convert.ToBase64String(bytes)
.Replace('+', '-')
.Replace('/', '_')
.TrimEnd('=');
return base64.Length > 200 ? base64.Substring(0, 200) : base64;
}
<pre class="brush:php;toolbar:false;">public static string FromSafeName(string safeName)
{
if (string.IsNullOrEmpty(safeName)) return "unnamed";
var padded = safeName.PadRight((safeName.Length + 3) / 4 * 4, '=');
var fixedBase64 = padded.Replace('-', '+').Replace('_', '/');
var bytes = Convert.FromBase64String(fixedBase64);
return Encoding.UTF8.GetString(bytes);
}}
注意：这个示例没加冲突处理和长度兜底，上线前务必加单元测试覆盖空值、超长、含 BOM、混合 emoji 等边界情况。真正的难点不在编码本身，而在「何时该截断」「如何保证唯一性」「元数据与文件名的同步一致性」——这些比 Base64 调用多十倍工作量。
