Unicode (utf-8) with git-bash

Question

I\'m having some trouble getting unicode to work for git-bash (on windows 7). I have tried many things without success. Although, I\'m not quite sure what is responsible to

Answer 1

Check if the issue persists with Git 2.1 (August 2014).
See commit 617ce96 or commit 1c950a5 by Karsten Blees (kblees)

Win32: support Unicode console output

WriteConsoleW seems to be the only way to reliably print unicode to the console (without weird code page conversions).

Also redirects vfprintf to the winansi.c version.

Win32: add Unicode conversion functions

Add Unicode conversion functions to convert between Windows native UTF-16LE encoding to UTF-8 and back.

To support repositories with legacy-encoded file names, the UTF-8 to UTF-16 conversion function tries to create valid, unique file names even for invalid UTF-8 byte sequences, so that these repositories can be checked out without error.

It is likely to be a port of something already integrated in msysgit, but at least that means the Windows version of Git won't have to diverge/patch from the main Git repo source code in order to include those improvements.

Answer 2

I faced the same issue in MSYS Git 2.8.0 and as it turned out it just needed changing the configuration.

$ git --version

git version 2.8.0.windows.1

The default configuration of Git Bash console in my system did not show Greek filenames.

$cd ~

$ls

AppData/
'Application Data'@
Contacts/
Cookies@
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'@

The last line should display "Τα έγγραφά μου", the greek translation of "My Documents". In order to fix it I followed the below steps:

1. Check your existing locale configuration

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

   As shown above, in my case it was not UTF-8

2. Change the locale to a UTF-8 encoding. Click the icon on the left side of MINGW title bar, select "Options" and in the "Text" category choose "UTF-8" Character set. You should also choose a unicode font, such as the default "Lucida Console". My configuration looks as following:

3. Change the language for the current window (no need to do this on future windows, as they will be created with the settings of step 2)

    $ LANG='C.UTF-8'
   

4. The ls command should now display properly

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

Answer 3

I can see that there are some problems with character encoding with git bash for windows. Less for the work with git itself and the tools it ships with (curl, cat, grep etc.). I didn't run into problems with these over the years character encoding related.

Normally with each new version problems get better resolved. E.g. with the version from a year ago, I couldn't enter characters like "ä" into the shell, so it was not possible to write

echo "ä"

To quickly test if UTF-8 is supported and at which level. A workaround is to write the byte-sequences octal:

$ echo -e "\0303\0244"
ä

Still issues I do have when I execute my windows php.exe binary to output text:

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

This does not give the the "ä" in the terminal, but it outputs "ä" instead. The workaround I have for that is, that I wrap the php command in a bash-script that processes the output through cat:

#!/bin/bash

{ php.exe "$@" 2>&1 1>&3 | cat 1>&2; } 3>&1 | cat

^{ref. reg. stdout + stderr cat}

This magically then makes php working again:

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

Applies to

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

I must admit I miss deeper understanding why this is all the way it is. But I'm finally happy that I found a workaround to use php in git bash with UTF-8 support.

Answer 4

Found this answer elsewhere:

chcp.com 65001

Git bash chcp windows7 encoding issue

That's what actually solved it for me.

Answer 5

The problem with chcp 65001 is that there are bugs in the C runtime (MSVCRT) that make stdio calls return inconsistent results when run under code page 65001.

That should be better with Git 2.23 (Q3 2019)

See commit 090d1e8 (03 Jul 2019) by Karsten Blees (kblees).
^{(Merged by Junio C Hamano -- gitster -- in commit 0328db0, 11 Jul 2019)}

gettext: always use UTF-8 on native Windows

On native Windows, Git exclusively uses UTF-8 for console output (both with MinTTY and native Win32 Console).

Gettext uses setlocale() to determine the output encoding for translated text, however, MSVCRT's setlocale() does not support UTF-8. As a result, translated text is encoded in system encoding (as per GetAPC()), and non-ASCII chars are mangled in console output.

Side note: There is actually a code page for UTF-8: 65001.
In practice, it does not work as expected at least on Windows 7, though, so we cannot use it in Git. Besides, if we overrode the code page, any process spawned from Git would inherit that code page (as opposed to the code page configured for the current user), which would quite possibly break e.g. diff or merge helpers. So we really cannot override the code page.

In init_gettext_charset(), Git calls gettext's bind_textdomain_codeset() with the character set obtained via locale_charset(); Let's override that latter function to force the encoding to UTF-8 on native Windows.

In Git for Windows' SDK, there is a libcharset.h and therefore we define HAVE_LIBCHARSET_H in the MINGW-specific section in config.mak.uname, therefore we need to add the override before that conditionally-compiled code block.

Rather than simply defining locale_charset() to return the string "UTF-8", though, we are careful not to break LC_ALL=C: the ab/no-kwset patch series, for example, needs to have a way to prevent Git from expecting UTF-8-encoded input.

And:

See commit 697bdd2 (04 Jul 2019), and commit 9423885, commit 39a98e9 (27 Jun 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 0a2ff7c, 11 Jul 2019)}

mingw: use Unicode functions explicitly

Many Win32 API functions actually exist in two variants: one with the A suffix that takes ANSI parameters (char * or const char *) and one with the W suffix that takes Unicode parameters (wchar_t * or const wchar_t *).

The ANSI variant assumes that the strings are encoded according to whatever is the current locale.
This is not what Git wants to use on Windows: we assume that char * variables point to strings encoded in UTF-8.

There is a pseudo UTF-8 locale on Windows, but it does not work as one might expect. In addition, if we overrode the user's locale, that would modify the behavior of programs spawned by Git (such as editors, difftools, etc), therefore we cannot use that pseudo locale.

Further, it is actually highly encouraged to use the Unicode versions instead of the ANSI versions, so let's do precisely that.

Note: when calling the Win32 API functions without any suffix, it depends whether the UNICODE constant is defined before the relevant headers are #include'd.
Without that constant, the ANSI variants are used.
Let's be explicit and avoid that ambiguity.

Answer 6

As CharlesB said in a comment, msysgit 1.7.10 handles unicode correctly. There are still a few issues but I can confirm that updating did solve the issue I was having.

See: https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support