Unicode (utf-8) с git - bash

Ответ 1

Как заметил CharlesB в комментарии, msysgit 1.7.10 корректно обрабатывает unicode. Есть еще несколько проблем, но я могу подтвердить, что обновление действительно решило проблему, которую я имел.

Смотрите: https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support

Ответ 2

Я столкнулся с той же проблемой в MSYS Git 2.8.0, и, как оказалось, просто нужно было изменить конфигурацию.

$ git --version

git version 2.8.0.windows.1

Стандартная конфигурация консоли Git Bash в моей системе не отображала греческие имена файлов.

$cd ~

$ls

AppData/
'Application Data'@
Contacts/
[email protected]
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'@
NTUSER.DAT
.
.
.
''$'\316\244\316\261'' '$'\316\255\316\263\316\263\317\201\316\261\317\206\316\254'' '$'\316\274\316\277\317\205'@

В последней строке должен отображаться "Τα έγγραφά μου", греческий перевод "Мои документы". Чтобы исправить это, я выполнил следующие шаги:

• Проверьте существующую конфигурацию локали

  $locale
  
  LANG=en
  LC_CTYPE="C"
  LC_NUMERIC="C"
  LC_TIME="C"
  LC_COLLATE="C"
  LC_MONETARY="C"
  LC_MESSAGES="C"
  LC_ALL=
  

  Как показано выше, в моем случае это был не UTF-8

• Измените языковой стандарт на кодировку UTF-8. Щелкните значок в левой части строки заголовка MINGW, выберите "Параметры", а в категории "Текст" выберите "Набор символов UTF-8". Вы также должны выбрать шрифт Юникода, например, "Консоль Lucida" по умолчанию. Моя конфигурация выглядит следующим образом:

• Измените язык для текущего окна (не нужно делать это в будущих окнах, так как они будут созданы с настройками шага 2)

   $ LANG='C.UTF-8'
  

• Теперь команда ls должна отображаться правильно

  AppData/
  'Application Data'@
  Contacts/
  [email protected]
  Desktop/
  Documents/
  Downloads/
  Favorites/
  Links/
  'Local Settings'@
  NTUSER.DAT
  .
  .
  .
  'Τα έγγραφά μου'@
  

Ответ 3

Проверьте, сохраняется ли проблема с Git 2.1 (август 2014 г.).
См. commit 617ce96 или зафиксировать 1c950a5 Karsten Blees (kblees)

Win32: поддержка вывода консоли Unicode

WriteConsoleW кажется единственным способом надежной печати юникода в консоль (без странных преобразований кодовой страницы).

Также перенаправляет vfprintf в версию winansi.c.

Win32: добавьте функции преобразования Unicode

Добавьте функции преобразования Юникода для преобразования между кодировкой UTF-16LE для Windows в UTF-8 и обратно.

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

Скорее всего, это порт чего-то уже интегрированного в msysgit, но, по крайней мере, это означает, что версия Git для Windows не должна расходиться/исправляться с основного исходного кода Git, чтобы включить эти улучшения.

Ответ 4

Я вижу, что есть некоторые проблемы с кодировкой символов с git bash для окон. Меньше для работы с git и инструментами, с которыми он поставляется (завиток, кошка, grep и т.д.). Я не сталкивался с проблемами с ними в течение многих лет кодирования символов.

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

echo "ä"

Быстро проверить, поддерживается ли UTF-8 и на каком уровне. Обходной путь состоит в том, чтобы написать байтовые последовательности восьмеричные:

$ echo -e "\0303\0244"
ä

Все еще проблемы, которые возникают у меня при выполнении моего двоичного файла windows php.exe для вывода текста:

$ php -r 'echo "\xC3\xA4";'
ä

Это не дает "ä" в терминале, но вместо этого выводит "ä". Обходной путь, который у меня есть для этого, заключается в том, что я завершаю команду php в bash - script, которая обрабатывает вывод через cat:

#!/bin/bash

{ php.exe "[email protected]" 2>&1 1>&3 | cat 1>&2; } 3>&1 | cat

^{ref. рег. stdout + stderr cat}

Затем это волшебство снова заставляет php работать:

$ php -r 'echo "\xC3\xA4";'
ä

Относится к

$ git --version
git version 1.9.4.msysgit.1

Я должен признать, что я не понимаю, почему это так. Но я, наконец, доволен тем, что нашел способ обхода использования php в git bash с поддержкой UTF-8.

Ответ 5

Нашел этот ответ в другом месте:

chcp.com 65001

Git Bash CHCP Windows7 проблема с кодировкой

Вот что на самом деле решило это для меня.

Ответ 6

Проблема с chcp 65001 состоит в том, что во время выполнения C (MSVCRT) есть ошибки, которые заставляют вызовы stdio возвращать противоречивые результаты при запуске под кодовой страницей 65001.

Это должно быть лучше с Git 2.23 (Q3 2019)

См. Коммит 090d1e8 (03 июля 2019 г.) Карстена Блиса (kblees).
^{(Объединено Junio C Hamano - gitster - в коммите 0328db0, 11 июля 2019 г.)}

gettext: всегда используйте UTF-8 на родной Windows

В родной Windows Git использует исключительно UTF-8 для вывода на консоль (как с MinTTY, так и с родной консолью Win32).

Gettext использует setlocale() для определения выходной кодировки переведенного текста, однако MSVCRT setlocale() не поддерживает UTF-8. В результате переведенный текст кодируется в системной кодировке (согласно GetAPC()), а символы, не входящие в ASCII, искажаются в выводе консоли.

Примечание: на самом деле есть кодовая страница для UTF-8: 65001.
На практике он не работает должным образом, по крайней мере, в Windows 7, поэтому мы не можем использовать его в Git. Кроме того, если мы переопределим кодовую страницу, любой процесс, созданный в Git, унаследует эту кодовую страницу (в отличие от кодовой страницы, настроенной для текущего пользователя), что вполне может привести к поломке, например, diff или помощников слияния. Поэтому мы действительно не можем переопределить кодовую страницу.

В init_gettext_charset() Git вызывает gettext bind_textdomain_codeset() с набором символов, полученным с помощью locale_charset(); Позвольте переопределить эту последнюю функцию для принудительного кодирования в UTF-8 на родной Windows.

В Git для Windows SDK есть libcharset.h и поэтому мы определяем HAVE_LIBCHARSET_H в специфичном для config.mak.uname разделе в config.mak.uname, поэтому нам нужно добавить переопределение перед этим условно скомпилированным блоком кода.

Вместо того, чтобы просто определять locale_charset() для возврата строки "UTF-8", мы стараемся не нарушать LC_ALL=C: например, в серии патчей ab/no-kwset должен быть способ предотвратить Git от ожидая UTF-8-кодированный вход.

А также:

См. Коммит 697bdd2 (04 июля 2019 г.) и коммит 9423885, коммит 39a98e9 (27 июня 2019 г.) Йоханнеса dscho (dscho).
^{(Объединено Junio C Hamano - gitster - в коммите 0a2ff7c, 11 июля 2019 г.)}

mingw: использовать функции Unicode явно

Многие функции Win32 API фактически существуют в двух вариантах: один с суффиксом A который принимает параметры ANSI (char * или const char *), и один с суффиксом W который принимает параметры Unicode (wchar_t * или const wchar_t *).

Вариант ANSI предполагает, что строки кодируются в соответствии с текущей локалью.
Это не то, что Git хочет использовать в Windows: мы предполагаем, что переменные char * указывают на строки, закодированные в UTF-8.

В Windows существует псевдо-UTF-8, но он не работает, как можно было ожидать. Кроме того, если мы переопределим языковой стандарт пользователя, это изменит поведение программ, созданных Git (таких как редакторы, difftools и т.д.), Поэтому мы не сможем использовать этот псевдо-языковой стандарт.

Кроме того, на самом деле настоятельно рекомендуется использовать версии Unicode вместо версий ANSI, поэтому давайте сделаем именно это.

Примечание: при вызове функций Win32 API без суффикса зависит, определена ли константа UNICODE до того, как соответствующие заголовки # include'd.
Без этой константы используются варианты ANSI.
Позвольте быть явным и избежать этой двусмысленности.