web-dev-qa-db-fra.com

Unicode (utf-8) avec git-bash

J'ai du mal à faire fonctionner unicode pour git-bash (sous Windows 7). J'ai essayé beaucoup de choses sans succès. Bien que je ne sois pas tout à fait responsable de cela, je peux donc travailler dans la mauvaise direction.

Il semble vraiment que cela devrait être possible car l'encodage de cmd.exe peut être changé en unicode avec 'chcp 65001'.

Voici quelques choses que j'ai essayées (en plus de l'évidence de regarder à travers les options de configuration dans l'interface graphique).

  1. Définition des variables d'environnement dans '.bashrc'. Je suppose qu'il est logique que cela ne fonctionne pas car je pense que c'est une chose Linux. La commande "locale" n'existe pas.

    export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

  2. Commencer dans cmd.exe, changer l'encodage en unicode avec 'chcp 65001' puis lancer git-bash. Cela m'oblige à refuser une autorisation lorsque j'essaie de capturer mon fichier de test Unicode. Cependant, la capture d'un fichier sans unicode fonctionne très bien. Comme démontré, en redescendant vers cmd.exe, je peux toujours "cat" le fichier. En utilisant mon encodage par défaut (437), je peux attraper le fichier en bash (aucune autorisation refusée mais la sortie est truquée).

    S:\>chcp 65001
Active code page: 65001
S:\>"C:\Program Files (x86)\Git\bin\sh.exe" --login -i
zarac@TOWELIE /z
cat /s/unicode.txt
cat: write error: Permission denied
zarac@TOWELIE /z
cat /s/nounicode.txt
abc
zarac@TOWELIE /z
L /s/unicode.txt
-rw-r--r--    1 zarac    Administ        7 May 18 10:30 /s/unicode.txt
zarac@TOWELIE /z
whoami
towelie\zarac
zarac@TOWELIE /z
exit
Z:\>type S:\unicode.txt
abc£

  3. Utiliser l'indicateur/U lors du démarrage du shell (il est logique que cela ne fonctionne pas parce que ce n'est pas tout à fait ce que c'est si-je-comprends-correctement, mais cela a à voir avec l'unicode, donc je l'ai essayé).

    C:\Windows\SysWOW64\cmd.exe /U /C "C:\Program Files (x86)\Git\bin\sh.exe" --login -i

  4. Comme je préfère utiliser Console2, j'ai essayé d'ajouter une valeur dword nommée CodePage avec la valeur 65001 (décimal) au registre Windows sous [HKEY_CURRENT_USER\Console] ainsi que [HKEY_CURRENT_USER\Console\Git Bash]. Cela semble avoir le même effet que le réglage 'chcp 65001' accepte qu'il soit "automatique". (http://stackoverflow.com/questions/379240/is-there-a-windows-command-Shell-that-will-display-unicode-characters)

  5. TCC/LE de JPSoft

  6. PowerCMD

  7. stackoverflow

  8. duckduckgo

  9. ixquick/google

Ainsi, la méthode 2 semble viable si ce problème d'autorisation peut être résolu. Cependant, je suis ouvert à presque toutes les solutions, même si je préfère utiliser Console2 (principalement en raison de sa fonctionnalité d'onglets astucieuse). Une solution serait peut-être de configurer un serveur SSH puis d'utiliser PuTTY/Kitty pour s'y connecter, mais c'est tout simplement faux! ; )

PS. Existe-t-il une documentation officielle pour git-bash?

windowsbashunicodeutf-8git-bash
40
Hannes

Comme CharlesB l'a dit dans un commentaire, msysgit 1.7.10 gère correctement l'unicode. Il y a encore quelques problèmes mais je peux confirmer que la mise à jour a résolu le problème que j'avais.

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

7
Hannes

J'ai rencontré le même problème dans MSYS Git 2.8.0 et il s'est avéré qu'il suffisait de modifier la configuration.

$ git --version

git version 2.8.0.windows.1

La configuration par défaut de la console Git Bash dans mon système n'affichait pas les noms de fichiers grecs.

$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'@

La dernière ligne devrait afficher "Τα έγγραφά μου", la traduction grecque de "Mes documents". Afin de le réparer, j'ai suivi les étapes ci-dessous:

  1. Vérifiez votre configuration locale existante

    $locale

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

    Comme indiqué ci-dessus, dans mon cas, ce n'était pas UTF-8

  2. Modifiez les paramètres régionaux en un codage UTF-8. Cliquez sur l'icône sur le côté gauche de la barre de titre MINGW, sélectionnez "Options" et dans la catégorie "Texte" choisissez le jeu de caractères "UTF-8". Vous devez également choisir une police unicode, comme la "Lucida Console" par défaut. Ma configuration se présente comme suit: MinGW locale configuration

  3. Changer la langue de la fenêtre actuelle (pas besoin de le faire sur les futures fenêtres, car elles seront créées avec les paramètres de l'étape 2)

     $ LANG='C.UTF-8'

  4. La commande ls devrait maintenant s'afficher correctement

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

Vérifiez si le problème persiste avec Git 2.1 (août 2014).
Voir commit 617ce96 ou commit 1c950a5 par Karsten Blees (kblees)

Win32: prend en charge la sortie de la console Unicode

WriteConsoleW semble être le seul moyen d'imprimer de manière fiable unicode sur la console (sans conversions de page de code étranges).

Redirige également vfprintf vers winansi.c version.

Win32: ajouter des fonctions de conversion Unicode

Ajoutez des fonctions de conversion Unicode pour convertir entre le codage UTF-16LE natif de Windows en UTF-8 et inversement.

Pour prendre en charge les référentiels avec des noms de fichiers encodés hérités, la fonction de conversion UTF-8 vers UTF-16 essaie de créer des noms de fichiers uniques et valides même pour des séquences d'octets UTF-8 invalides, afin que ces référentiels puissent être extraits sans erreur.

Il est probable qu'il s'agisse d'un portage de quelque chose déjà intégré dans msysgit, mais au moins cela signifie que la version Windows de Git n'aura pas à diverger/patcher du code source principal du dépôt Git pour inclure ces améliorations.

5
VonC

Je peux voir qu'il y a des problèmes avec l'encodage de caractères avec git bash pour Windows. Moins pour le travail avec git lui-même et les outils avec lesquels il est livré (curl, cat, grep etc.). Je n'ai pas rencontré de problèmes avec ceux-ci au fil des ans liés à l'encodage des caractères.

Normalement, à chaque nouvelle version, les problèmes sont mieux résolus. Par exemple. avec la version d'il y a un an, je ne pouvais pas entrer de caractères comme "ä "dans le Shell, il n'a donc pas été possible d'écrire

echo "ä"

Pour tester rapidement si UTF-8 est pris en charge et à quel niveau. Une solution de contournement consiste à écrire les séquences d'octets octales:

$ echo -e "\0303\0244"
ä

Toujours des problèmes que j'ai quand j'exécute mon binaire windows php.exe pour sortir du texte:

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

Cela ne donne pas le "ä "dans le terminal, mais il génère" ├ñ "à la place. La solution de contournement que j'ai pour cela est que j'encapsule la commande php dans un script bash qui traite la sortie via cat:

#!/bin/bash

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

réf. rég. stdout + stderr cat

Comme par magie, php fonctionne à nouveau:

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

S'applique à

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

Je dois admettre que je ne comprends pas mieux pourquoi c'est ainsi. Mais je suis finalement heureux d'avoir trouvé une solution de contournement pour utiliser php dans git bash avec le support UTF-8.

4
hakre

Trouvé cette réponse ailleurs:

chcp.com 65001

Git bash chcp windows7 encoding issue

C'est ce qui l'a réellement résolu pour moi.

3
TravisChambers

Le problème avec chcp 65001 est qu'il y a des bogues dans le runtime C (MSVCRT) qui font que les appels stdio retournent des résultats incohérents lorsqu'ils sont exécutés sous la page de codes 65001.

Cela devrait être mieux avec Git 2.23 (Q3 2019)

Voir commit 090d1e8 (03 juil.2019) par Karsten Blees (kblees) .
(Fusionné par Junio ​​C Hamano - gitster - in commit 0328db , 11 juillet 2019)

gettext: utilisez toujours UTF-8 sur Windows natif

Sur Windows natif, Git utilise exclusivement UTF-8 pour la sortie de la console (à la fois avec MinTTY et la console Win32 native).

Gettext utilise setlocale() pour déterminer l'encodage de sortie du texte traduit, cependant, setlocale() de MSVCRT ne prend pas en charge UTF-8. Par conséquent, le texte traduit est codé dans le codage système (selon GetAPC()) et les caractères non ASCII sont modifiés dans la sortie de la console .

Note latérale: Il existe en fait une page de codes pour UTF-8: 65001.
En pratique, cela ne fonctionne pas comme prévu au moins sur Windows 7, donc nous ne pouvons pas l'utiliser dans Git. En outre, si nous avons outrepassé la page de codes, tout processus généré à partir de Git hériterait de cette page de codes (par opposition à la page de codes configurée pour l'utilisateur actuel), ce qui pourrait très probablement se briser, par exemple diff ou fusionner des aides. Nous ne pouvons donc vraiment pas remplacer la page de codes.

Dans init_gettext_charset(), Git appelle bind_textdomain_codeset() de gettext avec le jeu de caractères obtenu via locale_charset(); Remplaçons cette dernière fonction pour forcer le codage en UTF-8 sur Windows natif.

Dans le SDK de Git pour Windows, il y a un libcharset.h Et donc nous définissons HAVE_LIBCHARSET_H Dans la section spécifique à MINGW dans config.mak.uname, Donc nous devons ajouter la substitution avant cela conditionnellement -bloc de code compilé.

Plutôt que de simplement définir locale_charset() pour renvoyer la chaîne "UTF-8", Nous veillons toutefois à ne pas casser LC_ALL=C: La série de correctifs ab/no-kwset, Par exemple, doit avoir un moyen d'empêcher Git de s'attendre à une entrée encodée en UTF-8.

Et:

Voir commit 697bdd2 (04 juil.2019), et commit 9423885 , commit 39a98e9 (27 juin 2019) par Johannes Schindelin (dscho) .
(Fusionné par Junio ​​C Hamano - gitster - in commit 0a2ff7c , 11 juillet 2019)

mingw: utiliser explicitement les fonctions Unicode

De nombreuses fonctions de l'API Win32 existent en fait en deux variantes: une avec le suffixe A qui prend les paramètres ANSI (char * Ou const char *) Et une avec le suffixe W qui accepte les paramètres Unicode (wchar_t * ou const wchar_t *).

La variante ANSI suppose que les chaînes sont codées en fonction des paramètres régionaux actuels.
Ce n'est pas ce que Git veut utiliser sous Windows: nous supposons que les variables char * Pointent vers des chaînes encodées en UTF-8.

Il existe une pseudo locale UTF-8 sous Windows, mais cela ne fonctionne pas comme on pourrait s'y attendre. De plus, si nous surpassions les paramètres régionaux de l'utilisateur, cela modifierait le comportement des programmes générés par Git (tels que les éditeurs, les outils diff, etc.), nous ne pouvons donc pas utiliser ce pseudo-paramètre régional.

De plus, il est en fait fortement encouragé d'utiliser les versions Unicode au lieu des versions ANSI, alors faisons exactement cela.

Remarque: lors de l'appel des fonctions de l'API Win32 sans tout suffixe, cela dépend si la constante UNICODE est définie avant que les en-têtes appropriés soient # inclus.
Sans cette constante, les variantes ANSI sont utilisées.
Soyons explicites et évitons cette ambiguïté.

0
VonC