强制Git读取包含NUL的ANSI文件

如何解决强制Git读取包含NUL的ANSI文件

有很多地方描述了如何“强制” Git读取文本文件。通常，解决方案包括向class mainController(DatagramProtocol): def __init__(self): super().__init__() self.timestamp = datetime.Now().timestamp() def datagramReceived(self,data,addr): receiveTime = datetime.Now().timestamp() print(receiveTime-self.timestamp) self.timestamp = receiveTime 添加过滤器，以将.gitattributes属性应用于文件。示例包括：

text

但是，如果文件包含NUL，则此解决方案似乎不起作用。这是一个示例文件文本文件，具有ANSI编码和尾随空字节：

它完全可以作为文本文件读取，只是Git不能读取。上面的每个示例过滤器都会失败，并且无论如何Git都将标识为“二进制”。我认为这是由于它对前8000个字符（ref）中的NUL进行了硬编码检查。

当然，一旦我将文件转换为UTF-8，Git就会愉快地将其识别为文本。这是转换后的相同文件：

坦率地说，我不介意不使用ANSI编码。我只是想避免在Notepad ++中不断打开文件，只是为了修复文件编码。有没有办法让Git自动处理编码转换？

解决方法

您在这里有几个问题。首先是这些文件肯定是 not 文本文件，因为它们包含NUL字节。没有主要的单字节编码允许NUL字节代表NUL以外的任何其他内容，因为C以该字节终止其字符串，而将其用于其他目的将意味着该编码中的文本将不适合正常的C字符串。因此，POSIX专门将包含NUL字节的文件排除在文本文件之外。

用于将“ ANSI”文件转换为UTF-8的工具实际上是剥离NUL字节，这就是它们起作用的原因。 UTF-8中的NUL字节与单字节编码中的含义完全相同：NUL。之所以如此有效，是因为您的工具正在剥离它们，而不是正确地对其进行转换。

在这种情况下，您还不清楚您要Git做什么。 text属性要求Git执行行尾标准化。但是，如果您的文件包含NUL字节，则Git仍会出于差异和合并的目的而将其视为二进制文件，因为text属性无法控制该文件。您还需要diff和merge属性。

当然，如果您真的不想要或不需要NUL字节，而且这些字节应该是人类可读的，那么最好剥离掉NUL字节并将其转换为UTF-8。在2020年，不再有任何理由使用单字节编码。如果您要这样做，那么可以通过执行以下操作（假设您使用的是Git Bash，WSL或Linux系统）来剥离NUL字节并转换为UTF-8：

$ tr -d '\0' FILENAME | iconv -f WINDOWS-1252 -t UTF-8 > FILENAME.tmp && \
  mv FILENAME.tmp FILENAME

这还假设您使用的“ ANSI”编码实际上是Windows-1252。 IANA（字符集的寄存器）不知道任何称为“ ANSI”的编码，但是Windows-1252是这种方式中最常见的字符集。

最后，如果您绝对必须处理非UTF-8文件，则可以使用working-tree-encoding中的gitattributes值指定工作树编码。但是，那并不能解决您的NUL问题，而UTF-8在几乎所有情况下都是一个更好的选择。