Git，Msysgit，重音符号，UTF-8，最终答案

Question

Git，Msysgit，重音符号，UTF-8，最终答案

gitutf-8msysgit

48

我在某些地方看到有人提到git（或只是msysgit？）与字符编码存在问题 - 我相信这只是文件名的问题。

我想要的是一些“权威”的信息，至少要说明：

1. 到底有什么“问题”？（症状是什么） 2. 原因是什么？（简要说明） 3. 在哪些情况下会成为拦路虎？ 4. 是否有任何解决方案或变通方法？

希望我的问题不太模糊，我认为将所有这些信息放在一个地方供人们参考是很好的...

- Benjol

3

UTF-8即将应用于msysgit。请查看我的更新答案。 - VonC

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

更新于2023年10月：随着Git 2.43（2023年第四季度）的发布，Unicode字符的显示宽度表已更新至Unicode 15.1。

请参阅commit 872976c（2023年9月25日），作者为Beat Bolli（bbolli）。
^{（由Junio C Hamano -- gitster --在commit 64b2419中合并，2023年10月4日）}

`unicode`：将宽度表更新至Unicode 15.1

^{签名：Beat Bolli}

Unicode 15.1已于2023年9月12日宣布发布，因此将字符宽度表更新至新版本。

2023年4月更新：随着Git 2.41（2023年第二季度），Unicode字符宽度表（用于输出对齐）已经更新。

请参见提交 b10cbda（2023年3月30日），作者为Beat Bolli（bbolli）。
^{（由Junio C Hamano -- gitster --合并于提交 5ae4bd1，2023年3月31日）}

unicode：将宽度表更新至Unicode 15

^{签署者：Beat Bolli}

Unicode 15版本于2022年9月发布，我们迄今为止忽视了更新宽度表的工作。
现在进行更新。

更新于2021年10月：随着Git 2.34（2021年第四季度）的发布，Unicode字符宽度表（用于输出对齐）已经更新。

请参阅提交 187fc8b（2021年9月17日），作者为Carlo Marcelo Arenas Belón（carenas）。
^{（由Junio C Hamano -- gitster --在提交 3d875f9中合并，2021年9月28日）} 更新宽度表至Unicode 14。

更新于2017年2月（Git 2.12）：字符宽度表已更新以匹配Unicode 9.0。 update_unicode.sh已被移动到contrib/update-unicode：请参阅其README。

2014年8月更新（git 2.1）：commit a67c821（Torsten Bögershausen (tboegi)）增加了对Unicode 7.0的支持。

2014年4月更新：commit d813ab9（Torsten Bögershausen (tboegi)）增加了对Unicode 6.3的支持（git 1.9.2）。

Unicode 6.3 defines more code points as combining or accents.
For example, the character "ö" could be expressed as an "o" followed by U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above).
We should consider that such a sequence of two codepoints occupies one display column for the alignment purposes, and for that, git_wcwidth() should return 0 for them.

Affected codepoints are:
U+0358..U+035C
U+0487
U+05A2, U+05BA, U+05C5, U+05C7
U+0604, U+0616..U+061A, U+0659..U+065F
Earlier unicode standards had defined these as "reserved".

Only the range 0..U+07FF has been checked to see which codepoints need to be marked as 0-width while preparing for this commit; more updates may be needed.

更新于2012年4月：版本1.7.10中发布了Unicode支持。请参阅此页面以获取相关说明和应设置的选项。

具体而言：

git config [--global] core.quotepath off
git config [--global] i18n.logoutputencoding utf8
git config [--global] i18n.commitencoding utf8
git config [--global] --unset svn.pathnameencoding

recodetree check命令会扫描整个git仓库的历史记录，并打印出所有非ASCII文件名。如果输出为空，则无需进行迁移。

2012年2月更新：UTF-8支持的补丁正在GitHub上的msysgit仓库的'devel'分支中进行中，包括更新UTF-8的less设置。

Git for Windows的Google+页面提到：

Karsten Blees的Git for Windows的UTF-8补丁现已合并到'devel'分支。
这意味着即将发布的版本将支持Unicode文件名！

2011年5月

我相信msysgit issue 80上有关于那个bug的最新信息。
也在issue 376中有描述。

例如：

发生的情况如下：

Windows上的git操作的是文件名，并将其视为字节流。在你的情况下，这些流碰巧是UTF8编码的文本。

Windows上的git要求运行时创建一个文件，并将字节流传递给它。

由于Windows内部一切都是Unicode，运行时使用当前设置的区域设置（也称为“代码页”）将字节流转换为UTF16。
也就是说，它将字节流有效地解释为CP949（韩文）编码的文本。
显然，一些UTF8字节序列是无效的CP949序列，转换失败（“无效参数”）；或者如果UTF8序列碰巧是正确的CP949序列，结果就是（很可能）一个不同的字符。

真正的解决方案应该在MingW上：

我想到了一个解决方案：在GCC C运行时库层面解决它。
也就是说，对于Windows上的mingw GCC运行时库，通过构建时选项，使其能够在一种模式下，命令行参数（传递给main()）和文件I/O函数使用底层的Windows Unicode API调用，并在C的标准函数API中将其转换为/从使用字节字符串的UTF-8编码。
这对于git可能会“正常工作”，并且对于在Windows环境下运行的其他Linux源开源项目也可能会有用。

ak2评论说MingW不是这个问题的正确解决地点：

“MinGW编译器提供对Microsoft C运行时和一些特定语言运行时功能的访问。
MinGW是极简主义的，不会也永远不会试图为在MS-Windows上部署POSIX应用程序提供POSIX运行时环境。
如果您想在此平台上部署POSIX应用程序，请考虑使用Cygwin。”

有一些正在进行中的工作，旨在支持Unicode的msysgit变体。

Git，Msysgit，重音符号，UTF-8，最终答案

unicode：将宽度表更新至Unicode 15.1

unicode：将宽度表更新至Unicode 15

`unicode`：将宽度表更新至Unicode 15.1

`unicode`：将宽度表更新至Unicode 15