我有兴趣尝试分布式版本控制系统。 git听起来很有希望，但我在git的Windows端口看到了一条说“不要使用非ASCII文件名”的注释。我现在找不到，但有this link。它现在让我脱离git，但我不知道其他选项是否更好。
支持非ASCII文件名对我的日本公司至关重要。我正在寻找一个内部存储文件名为Unicode的文件，而不是依赖于平台的编码，这会导致无休止的悲伤。所以：
答案 0 :(得分：9)
见issue 80 in the same repository。 2009年，讨论了Git邮件列表（例如1，2），其中Git维护者Junio Hamano就此提出了一些问题。我没有在这里。通过以建设性的方式加入线程，您可以帮助解决问题。
在Java实现JGit中，我们在创建文本元数据和文件名时总是使用UTF-8。这是唯一的方法，但有一些事情需要考虑。
答案 1 :(得分：8)
Bazaar VCS在内部使用unicode文件名。它在Linux和Windows上都非常支持unicode。
答案 2 :(得分：8)
在Linux上，我认为Mercurial只是编码系统的编码（如果我错了，请纠正我）。因此，最好将Linux设置为UTF-8以实现跨平台兼容性。这是许多现代发行版的默认设置。
在Windows上，Mercurial（由于Python的字节串处理）使用系统代码页。这只是为了保证非ASCII字符的跨平台互操作性不好。
外部创建的名为fixutf8的Mercurial扩展可以正确处理所有Unicode字符（甚至是当前代码页之外的字符），并在Mercurial存储库中将文件名编码为UTF-8。因此，只要Linux使用UTF-8编码，就可以实现与Linux的互操作。我上周尝试在我的Windows设置上启用它，并且在安装时遇到了一些问题。从那以后，一个问题得到解决。现在唯一的问题是二进制Mercurial发行版是用Python 2.4构建的，而fixutf8要求使用Python 2.5或更高版本构建Mercurial来加载fixutf8。我希望这会在不久的将来得到解决。
fixutf8似乎与Mercurial 2.0及更高版本不兼容。有关未来解决方案的详细信息，请参阅fixutf8。我不确定这是什么时候可以实施的。
答案 3 :(得分：8)
2009年8月：
msysgit项目正在忙于修复Windows上对Git的UTF-8支持。它可能会在下一个版本中修复。
2012年2月更新
UTF-8即将推出msysgit，commits like this one "Update less settings for UTF-8 "
从Git for Windows Google+页面：
Karsten Blees用于Windows的Git的UTF-8补丁现已合并为“
devel”。 这意味着即将发布的版本将支持Unicode文件名！
2012年4月更新
现已发布于mSysGit 1.7.10。
答案 4 :(得分：2)
Windows 1.7.10上的Git现在使用UTF-8作为文件名，无论用户的语言环境如何。
答案 5 :(得分：0)
根据this页面：Bazaar，Codendi，CVSNT，Monotone，Perforce，Rational Team Concert，Subversion，Surround SCM，Synergy。但该页面上有很多“未知数”。
答案 6 :(得分：0)
这是一个非常棘手的问题。之所以出现这样的问题，是因为任何一种工具在不确定编码时会尝试解释文件名，或者因为它们会被翻译，而是转换为无法处理所有情况的表单（例如ASCII或UTF-16）。主要的3个操作系统都没有就文件名的编码方式达成一致，这使得事情变得更加困难。
为了更好地理解我建议阅读Mercurial encoding strategy页面的问题。它描述了各种平台的变化，以及Mercurial选择其战略的原因。
如果你真的需要这样做，那么最基本的事情是所有系统需要设置为使用UTF-8文件名，而不是许多日语代码页之一。这说起来容易做起来难，但一旦完成，任何系统都不需要将文件名转换为其他任何内容。
没有翻译，没有问题。
*：是的，我知道您可以使用默认的系统编码，但这与文件系统编码不同。当多个系统访问文件系统或在系统之间物理移动文件系统时会发生什么？