Unicode (utf-8) с git - bash

У меня возникли проблемы с работой unicode для работы git - bash (в Windows 7). Я пробовал много вещей без успеха. Хотя, я не совсем уверен, что несет ответственность за это, поэтому я могу работать в неправильном направлении.

Кажется, что это должно быть возможно, так как кодировка cmd.exe может быть изменена на unicode с помощью chcp 65001.

Вот некоторые вещи, которые я пробовал (помимо очевидного просмотра параметров конфигурации в графическом интерфейсе).

Настройка переменных среды в '.bashrc'. Я думаю, это имеет смысл, это не работает, так как я думаю, что это Linux. Команда "locale" не существует.
```
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
```
Запуск в cmd.exe, изменение кодировки в unicode с помощью "chcp 65001", а затем запуск git - bash. Это заставляет меня получить разрешение, отклоненное при попытке загрузить мой тестовый файл в Юникоде. Однако привязка файла без юникода работает отлично. Как продемонстрировано, отбрасывая обратно в cmd.exe, я все еще могу "сшить" файл. Используя мою кодировку по умолчанию (437), я могу записать файл в bash (разрешение не разрешено, но выход выгружается).
```
S:\>chcp 65001
Active code page: 65001
S:\>"C:\Program Files (x86)\Git\bin\sh.exe" --login -i
[email protected] /z
cat /s/unicode.txt
cat: write error: Permission denied
[email protected] /z
cat /s/nounicode.txt
abc
[email protected] /z
L /s/unicode.txt
-rw-r--r--    1 zarac    Administ        7 May 18 10:30 /s/unicode.txt
[email protected] /z
whoami
towelie\zarac
[email protected] /z
exit
Z:\>type S:\unicode.txt
abc£
```
Использование флага /U при запуске оболочки (имеет смысл, что он не работает, потому что это не совсем то, что для if-i-understand-правильно, но имеет отношение к unicode, поэтому я попробовал его).
```
C:\Windows\SysWOW64\cmd.exe /U /C "C:\Program Files (x86)\Git\bin\sh.exe" --login -i
```
Как я предпочитаю использовать Console2, я попытался добавить значение dword с именем CodePage со значением 65001 (десятичное) в реестр Windows в [HKEY_CURRENT_USER\Console], а также [HKEY_CURRENT_USER\Console\ Git Bash]. Это похоже на тот же эффект, что и установка "chcp 65001" признает, что она "автоматическая". (Http://stackoverflow.com/info/379240/is-there-a-windows-command-shell-that-will-display-unicode-characters)
JPSoft TCC/LE
PowerCmd
StackOverflow
DuckDuckGo
ixquick/google

Итак, метод 2 кажется жизнеспособным, если эта проблема разрешена. Тем не менее, я открыт практически для любого решения, хотя я предпочитаю, если я могу использовать Console2 (в основном благодаря его отличной вкладке). Возможно, одним из решений было бы настроить SSH-сервер, а затем использовать Putty/Kitty для подключения к нему, но это просто неправильно!; )

PS. Есть ли официальная документация для 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.
Позвольте быть явным и избежать этой двусмысленности.