Мерзавец, msysgit, акценты, utf-8, окончательные ответы

Я читал в некоторых местах, что есть проблемы с git (или просто msysgit?) И кодировкой символов - я считаю, что это только проблема с именами файлов.

То, что я хотел бы, это некоторая "окончательная" (или, по крайней мере, авторитетная) информация о:

  1. Какие именно "проблемы"? (Симптомы)
  2. Каковы причины? (Кратко)
  3. В каких случаях это шоу-стоппер?
  4. Есть ли какое-либо разрешение в поле зрения, или нет, что обходные пути?

Я надеюсь, что этот вопрос не слишком расплывчатый, я думаю, что было бы хорошо иметь всю эту информацию в одном месте, чтобы иметь возможность указать людям на нее...

Источник

1 ответ

Решение

Обновление февраль 2017 г. (Git 2.12): таблица ширины символов обновлена ​​в соответствии с Unicode 9.0.
update_unicode.sh перемещается в contrib/update-unicode: увидеть его README.

Обновление от августа 2014 г. (git 2.1): коммит a67c821 ( Torsten Bögershausen (tboegi)) добавляет поддержку Unicode 7.0.

Обновление апрель 2014: в коммите d813ab9 ( Torsten Bögershausen (tboegi)) добавлена ​​поддержка Unicode 6.3
(git 1.9.2):

Unicode 6.3 определяет больше кодовых точек как объединение или акценты.
Например, персонаж ö "может быть выражено как" o " с последующим U+0308 COMBINING DIARESIS (иначе умлаут, двойная точка сверху).
Мы должны учитывать, что такая последовательность из двух кодовых точек занимает один столбец отображения для целей выравнивания, и для этого, git_wcwidth() должен вернуть 0 для них.

Затронутые кодовые точки:

U+0358..U+035C
U+0487
U+05A2, U+05BA, U+05C5, U+05C7
U+0604, U+0616..U+061A, U+0659..U+065F

Ранее стандарты Unicode определяли их как "зарезервированные".

Только ассортимент 0..U+07FF был проверен, чтобы увидеть, какие кодовые точки должны быть помечены как 0-width при подготовке к этой фиксации; может потребоваться больше обновлений.

Обновление апрель 2012: поддержка Unicode выпущена в версии 1.7.10. Смотрите эту страницу для заметок и настроек, которые вы должны установить.

А именно:

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 года: исправления для поддержки UTF-8 поступают в ветку 'devel' репозитория msysgit на GitHub, включая Обновление без настроек для UTF-8.

Страница Git для Windows Google+ упоминает:

Karsten Blees: патчи UTF-8 для Git для Windows теперь объединены с devel".
Это означает, что следующий выпуск будет поддерживать имена файлов Unicode!

Май 2011

Я полагаю, что в выпуске msysgit 80 есть последняя ошибка.
Также описано в выпуске 376.

Например:

Вот что происходит:

  1. Git в Windows работает с именами файлов и обрабатывает их, по существу, как байтовые потоки. В вашем случае потоки представляют собой текст в кодировке UTF8.

  2. git в Windows просит среду выполнения создать файл и передает ему поток байтов.

  3. Поскольку внутри Windows все работает в Unicode, среда выполнения преобразует поток байтов в UTF16, используя текущую установленную локаль (так называемая "кодовая страница").
    То есть он эффективно интерпретирует поток байтов как текст в кодировке CP949 (корейский).
    По-видимому, некоторые из байтовых последовательностей UTF8 являются недопустимыми последовательностями CP949, и преобразование не выполняется ("Неверный аргумент"); или если последовательности UTF8 оказываются правильными последовательностями CP949, результатом является (скорее всего) другой символ.

Истинное исправление хотя должен быть на MingW :

Мне приходит в голову, что одно решение будет следующим: решить его на уровне библиотеки времени выполнения GCC.
То есть для библиотеки времени выполнения mingw GCC в Windows, с помощью опций времени сборки, можно находиться в режиме, в котором параметры командной строки (передаются в main()) и файловые функции ввода / вывода используют базовые вызовы Windows Unicode API и переводят в / из кодировки UTF-8 в стандартных API функций C, которые используют строки байтов.
Это, возможно, "просто работает" для git и может быть полезно для других проектов Linux с открытым исходным кодом, работающих под управлением среды Windows.

ak2 отмечает, что MingW не подходящее место для этого исправления:

"Компиляторы MinGW предоставляют доступ к функциональности среды выполнения Microsoft C и некоторым языковым средам исполнения.
MinGW, будучи минималистом, не пытается и никогда не будет пытаться предоставить среду выполнения POSIX для развертывания приложений POSIX в MS-Windows.
Если вы хотите развернуть приложение POSIX на этой платформе, рассмотрите Cygwin."

В настоящее время ведется работа над вариантом msysgit для поддержки юникода.

Источник
Другие вопросы по тегам