我正在努力维护将文件传输到另一个系统的应用程序，并使用结构化文件名来包含包含语言代码的元数据。当前的应用程序使用双字符语言代码和破折号连字符。
实施例。加拿大-EN-PRODNAME-ProdCode.txt
我正在将其转换为使用IETF语言代码，因此破折号分隔符不会执行，需要替换。我正在尝试确定一个分隔符，以避免将来的错误，并考虑到代字号〜。
实施例。加拿大〜烯GB〜PRODNAME〜ProdCode.txt
这仅适用于Windows Sever 2003 +系统。我当然没有想出这个解析文件名来获取元数据的系统。不幸的是，我不能将它包含在文件本身中，并且目标系统期望语言代码使用短划线以IETF格式。
有关在文件名中使用波浪号或使用更好的角色的潜在问题的任何想法？我只是在寻找第二意见，以防我忽略了可能的失败。我相信windows会在将长文件名缩短为8.3格式时使用代字号，但我不认为这是一个问题，因为操作系统可以处理lang文件名。
答案 0 :(得分：3)
波浪号可能很好，但是这个好的旧下划线有什么问题？它在windows或unix上没有特殊含义，并且使名称相对容易阅读。如果没有其他特殊的考虑因素，我会完全避免偏执狂，因为Windows有时会将它用作特殊字符，如你所提到的那样。
答案 1 :(得分：1)
对于任何阅读这个问题的人，我强烈推荐除文件名中的波浪号以外的任何内容，或者至少在测试任何存在的 .NET 路径工作的速度问题时要小心。
我前段时间用它作为文件名分隔符。我不明白为什么简单地从文件夹中获取文件列表要花这么长时间。几年后（编写了大量具有边际优势的加速代码），我发现（至少 .NET 中的 DirectoryInfo(path).name）存在问题，其中波浪号的简单存在是强制底层代码通过很多圈套。
速度明显下降（它是通过网络实现的，所以我一直认为这是带宽/网络问题）
我知道这是一个遗留问题，因为当 Windows 文件可以使用其他短版本的文件名时。
我现在被这些文件名中的波浪号困住了，但是，鉴于问题出在某些 .NET 路径函数中（我实际上不知道它是否仍然存在），我可以通过发现一个波浪号并在它存在时创建我自己的答案，而不是通过它。
如果有任何疑问，只需在文件名中使用和不使用波浪号运行速度测试，例如仅 500-1,000 个文件。