Git, msys git, акценты, utf-8, окончательные ответы

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

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

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

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

ОТВЕТЫ

Ответ 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 года: commit d813ab9 (Торстен Бёгерсхаузен (tboegi )) добавляет поддержку Unicode 6.3
(Git 1.9.2):

Юникод 6.3 определяет больше кодовых точек в виде сочетания или акцентов.
Например, символ "ö" может быть выражен как "o", за которым следует U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above).
Мы должны учитывать, что такая последовательность из двух кодовых точек занимает один столбец отображения для целей выравнивания, и для этого 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

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

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

Обновление апрель 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 repo на GitHub, включая Обновить меньше настроек для UTF-8.

В разделе git для Windows + страницы:

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

Май 2011

Я полагаю, что проблема msysgit 80 имеет самую последнюю информацию об этой ошибке.
Также описано в issue 376.

Например:

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

  • git в Windows работает с именами файлов и обрабатывает их по существу как потоки байтов. В вашем случае потоки - это кодированный текст в формате UTF8.

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

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

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

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

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

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

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