【问题标题】:What DVCS support Unicode filenames?哪些 DVCS 支持 Unicode 文件名?
【发布时间】:2010-10-24 04:49:46
【问题描述】:

我有兴趣尝试分布式版本控制系统。 git 听起来很有希望,但我在某个地方看到了一个关于 git 的 Windows 端口的注释,上面写着“不要使用非 ASCII 文件名”。我现在找不到,但是有this link。它让我暂时离开了 git,但我不知道其他选项是否更好。

对我的日本公司来说,支持非 ASCII 文件名是必不可少的。我正在寻找一种在内部将文件名存储为 Unicode,而不是依赖于平台的编码,这种编码会导致无尽的悲伤。所以:

  1. 哪些 DVCS 支持 Unicode 文件名?
  2. 在 Windows 和 Linux 中?
  3. 理想情况下,可以在 Windows 和 Linux 机器之间传输存储库而问题最少?

【问题讨论】:

标签: git unicode mercurial dvcs bazaar


【解决方案1】:

issue 80 in the same repository。 2009 年,Git 邮件列表(例如12)上进行了一次讨论,Git 维护者 Junio Hamano 对此提出了一些问题。我这里没有。通过以建设性的方式加入主题,您可能有助于解决问题。

在 Java 实现 JGit 中,我们在创建文本元数据和文件名时总是使用 UTF-8。这是唯一的方法,但有一些事情需要考虑。

【讨论】:

    【解决方案2】:

    Bazaar VCS 在内部使用 unicode 文件名。它在 Linux 和 Windows 上都对 unicode 有很好的支持。

    【讨论】:

    • 在他们的网站上有一个关于 Bazaar 的 Unicode 支持的页面:bazaar-vcs.org/UnicodeSupport
    • 该页面更多的是开发人员规范,而不是用户文档,而且有点过时了。
    • 我在 Windows 上对 Bazaar 进行了一些基本测试,并确认它可以添加和合并文件,即使它们的文件名字符超出当前系统代码页。好东西。稍后我将在 Linux 机器上尝试该存储库,看看它是否可以正确分支它。
    • 我在 Windows 上对 Bazaar 做了一些进一步的测试,发现虽然命令行工作正常,但 GUI 无法提交对包含当前系统代码页之外的文件名字符的文件的更改。
    • 克雷格,感谢您的评论。这实际上是所有基于 Python 的程序的问题。我已经在命令行中提交了有关当前系统代码页之外的 unicode 字符的错误:bugs.launchpad.net/bzr/+bug/375934。很快就会修复。
    【解决方案3】:

    混帐

    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 中发布。

    查看页面Git for Windows Unicode Support

    【讨论】:

    • Johan:如果他们确实修复了它,请回来更新您的帖子。我相信有人会觉得它很有用。
    • 直到知道 (9/2010) 它还没有修复!
    • 从 msysgit 1.7.6 开始,它仍然没有修复。 :(
    • 我正在使用 Git-1.7.10-preview20120409.exe,现在可以正确识别 unicode 文件名。
    【解决方案4】:

    水银

    在 Linux 上,我认为 Mercurial 只是以系统的编码方式进行编码(如果我错了,请纠正我)。因此最好将 Linux 设置为 UTF-8 以实现跨平台兼容性。这是许多现代发行版的默认设置。

    在 Windows 上,Mercurial(由于 Python 的字节字符串处理)使用系统代码页。这几乎可以保证非 ASCII 字符的跨平台互操作性差。

    fixutf8 Windows 扩展(Mercurial 2.0 之前)

    有一个名为 fixutf8 的 Windows 外部创建的 Mercurial 扩展,它可以正确处理所有 Unicode 字符(即使是当前代码页之外的字符)并将文件名编码为 Mercurial 存储库中的 UTF-8。因此,只要 Linux 使用 UTF-8 编码,它就可以与 Linux 进行互操作。上周我尝试在我的 Windows 设置上启用它,但在安装时遇到了一些问题。从那时起,一个问题得到了解决。现在唯一的问题是二进制 Mercurial 发行版是使用 Python 2.4 构建的,而 fixutf8 需要使用 Python 2.5 或更高版本构建 Mercurial 才能加载 fixutf8。我希望这将在不久的将来得到解决。

    用于 Windows 的 Mercurial 2.0 及更高版本

    根据fixutf8 网页,fixutf8 似乎与 Mercurial 2.0 及更高版本不兼容。有关未来解决方案的详细信息,请参阅WindowsUTF8Plan。我不确定预计何时实施。

    【讨论】:

    • 当我查看 Mercurial 代码时,我没有发现任何对文件名的 unicode 支持。
    • 我维护 fixutf8 扩展,并每天将其与 HG 的二进制构建一起使用。提交错误bitbucket.org/stefanrusek/hg-fixutf8,我很乐意看看。
    • 谢谢斯特凡。既然我已经成功安装了 fixutf8 并发现它运行良好,我已经对这个答案进行了大量编辑。我被你在过去几天里修复的一个错误拖住了。
    • fixutf8 不适用于最新版本的 mercurial(例如 2.5)
    • -1 因为这不再有效。截至 2012 年 12 月,Mercurial 不是 支持 Unicode 的 DVCS,并且在未来几年内可能会受到不好的支持,因为出于某种奇怪的原因,他们决定将文件名视为“二进制 blob”,而不是“文本”(为了记录,这是因为 Unix 也将文件名视为二进制 blob 而不是文本)。
    【解决方案5】:

    Windows 1.7.10 上的 Git 现在使用 UTF-8 作为文件名,无论用户的语言环境如何。

    【讨论】:

      【解决方案6】:

      根据this 页面:Bazaar、Codendi、CVSNT、Monotone、Perforce、Rational Team Concert、Subversion、Surround SCM、Synergy。但是那个页面上有很多“未知数”。

      【讨论】:

        【解决方案7】:

        这是一个非常棘手的问题。问题的出现是因为工具在不确定编码时尝试解释文件名,或者因为它们翻译但翻译成无法处理所有情况的形式(例如 ASCII 或 UTF-16)。三个主要操作系统都没有就文件名的编码方式达成一致,这让事情变得更加困难。

        为了更好地理解这些问题,我建议阅读 Mercurial 的 encoding strategy 页面。它描述了各种平台的差异,以及 Mercurial 选择其策略的原因。

        如果您真的需要这样做,那么最基本的事情是需要将 所有 系统设置为使用 UTF-8 文件名,而不是众多日文代码页之一。虽然说起来容易做起来难,但是一旦完成,系统就不需要将文件名翻译成其他任何东西。

        没有翻译,没有问题。


        *:是的,我知道您可以使用默认系统编码,但这与文件系统编码不同。当一个文件系统被多个系统访问或在系统之间物理移动时会发生什么?

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2019-04-08
          • 1970-01-01
          • 1970-01-01
          • 2012-07-03
          • 2012-12-20
          • 1970-01-01
          • 2012-10-22
          • 1970-01-01
          相关资源
          最近更新 更多