У вас тут пара проблем. Во-первых, это определенно не текстовые файлы, поскольку они содержат байт NUL. Никакая основная однобайтовая кодировка не позволяет байтам NUL представлять что-либо, кроме NUL, потому что C завершает свои строки этим байтом, и использование его для другой цели означало бы, что текст в этой кодировке не помещается в обычную строку C. По этой причине POSIX специально исключает файлы, содержащие байты NUL, из текстовых файлов.
Инструмент, который вы используете для преобразования файлов «ANSI» в UTF-8, на самом деле удаляет байты NUL, поэтому они работают. Байт NUL в UTF-8 означает то же самое, что и в вашей однобайтовой кодировке: NUL. Так что это работает, потому что ваш инструмент удаляет их, а не конвертирует должным образом.
Также неясно, что вы просите Git сделать в этом случае. Атрибут text
просит Git выполнить нормализацию конца строки. Однако, если ваш файл содержит байты NUL, Git все равно будет думать, что это двоичный файл для целей сравнения и слияния, потому что атрибут text
не контролирует это. Вам также понадобятся атрибуты diff
и merge
.
Конечно, если вы действительно не хотите или не нуждаетесь в байтах NUL, и они должны быть удобочитаемыми для человека, тогда вам действительно лучше просто удалить байты NUL и преобразовать в UTF-8. В 2020 году больше нет веских причин использовать однобайтовую кодировку. Если это то, что вы хотите сделать, вы можете удалить байты NUL и преобразовать в UTF-8, выполнив следующие действия (при условии, что вы используете Git Bash, WSL или систему Linux):
$ tr -d '\0' FILENAME | iconv -f WINDOWS-1252 -t UTF-8 > FILENAME.tmp && \
mv FILENAME.tmp FILENAME
Это также предполагает, что используемая вами кодировка «ANSI» на самом деле является Windows-1252. IANA (реестр наборов символов) не знает никаких кодировок, называемых «ANSI», но Windows-1252 является наиболее распространенным набором символов, упоминаемым таким образом.
Наконец, вы можете указать кодировку рабочего дерева со значением working-tree-encoding
в gitattributes
, если вам абсолютно необходимо обрабатывать файлы, отличные от UTF-8. Однако это не решит вашу проблему с NUL, а UTF-8 — лучший выбор почти во всех ситуациях.
person
bk2204
schedule
18.09.2020