Unicode (utf-8) avec git-bash

Je vais avoir certaines difficultés unicode à travailler pour git-bash (sur windows 7). J'ai essayé beaucoup de choses sans succès. Bien que, je ne suis pas tout à fait sûr de ce qui est responsable pour cette sorte que je pourrais travailler dans la mauvaise direction.

Il semble vraiment ce devrait être possible, car le codage pour cmd.exe peut être modifié en unicode avec "chcp 65001'.

Voici certaines choses que j'ai essayé (en plus de l'évidente de la recherche à travers les options de configuration dans l'interface graphique).

  1. Définition des variables d'environnement dans '.bashrc'. Je suppose que cela a du sens, cela ne fonctionne pas car je pense que c'est un linux chose. Le "locale" de la commande n'existe pas.

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

  2. De départ dans cmd.exe, la modification de l'encodage unicode avec "chcp 65001" et puis le démarrage de git-bash. Cela m'amène à obtenir une autorisation refusée lors de la tentative de chat mon unicode fichier de test. Cependant, cat un fichier sans unicode fonctionne très bien. Comme l'a démontré, de revenir à cmd.exe je peux encore le "chat" du fichier. À l'aide de mon encodage par défaut (437) je peux chat le fichier dans bash (sans permission refusée, mais la sortie est truqués).

    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. À l'aide de l'option /U lors du lancement du shell (logique que cela ne fonctionne pas car ce n'est pas tout à fait ce que c'est pour si-je-comprends-pas correctement, mais il doit le faire avec unicode donc je l'ai essayé).

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

  4. Que je préfère utiliser Console2, j'ai essayé d'ajouter une valeur dword nommée page de Codes avec la valeur 65001 (décimal) pour le registre windows sous [HKEY_CURRENT_USER\Console] ainsi que [HKEY_CURRENT_USER\Console\Git Bash]. Cela semble avoir le même effet que la définition de "chcp 65001' accepter que c'est "automatique". (http://stackoverflow.com/questions/379240/is-there-a-windows-command-shell-that-will-display-unicode-characters)

  5. JPSoft du STC/LE

  6. PowerCMD

  7. stackoverflow

  8. duckduckgo

  9. ixquick /google

Donc, la méthode 2 ne semble pas viable si cette autorisation problème peut être résolu. Cependant, je suis ouvert à presque n'importe quelle solution, bien que je préfère si je peux utiliser Console2 (principalement en raison de c'est chouette la fonction de patte). Peut-être qu'une solution serait d'installer un serveur SSH et ensuite utiliser Putty/Kitty pour vous y connecter, mais c'est tout simplement faux! ; )

PS. Est-il de toute la documentation officielle de git-bash?

  • msysgit 1.7.10 gère l'unicode correctement. Voir cette page pour la documentation officielle
  • I'm open to pretty much any solution: Purger le mal, Installer linux, ???, Le Profit!!! 😛 Désolé
  • Que penser de l'utilisation de Cygwin et rxvt?
  • Merci pour vos réponses et votre modifier CharlesB!
  • Dans le cas où il n'était pas clair, merci à vous aussi KurzedMetal. 😉
  • Le problème avec chcp 65001 est qu'il y a des bugs dans le runtime C (MSVCRT) qui font stdio appels de retour des résultats incohérents lors de l'exécution sous la page de codes 65001. C'est pourquoi 65001 n'est pas disponible pour la cueillir comme une page de codes ANSI à partir des Options Régionales Et Linguistiques liste déroulante. Pour les applications compilées avec d'autres moteurs d'exécution, vous pouvez sortir avec elle, mais la plupart des applications Windows crash et brûler.
  • nkatsar la réponse ci-dessous est celui qui répond à votre question. Vous devriez envisager de changer votre réponse.

InformationsquelleAutor Hannes | 2012-05-18
  1. 36

    J'ai fait face à la même question dans MSYS Git 2.8.0 et comme il s'est avéré, il avait juste besoin de modifier la configuration.

    $ git --version

git version 2.8.0.windows.1

    La configuration par défaut de Git Bash console dans mon système n'a pas montré grec les noms de fichiers.

    $cd ~

$ls

AppData/
'Application Data'@
Contacts/
Cookies@
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'@
NTUSER.DAT
.
.
.
''$'6461'' '$'65636371617664'' '$'646775'@

    La dernière ligne doit afficher "Τα έγγραφά μου", la traduction en grec de "Mes Documents". Pour régler ce problème, j'ai suivi les étapes ci-dessous:

    1. Vérifier vos paramètres régionaux existants configuration

      $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 c'était pas en UTF-8

    2. Modifier les paramètres régionaux à un encodage UTF-8. Cliquez sur l'icône sur le côté gauche de MINGW barre de titre, sélectionnez "Options" et dans la catégorie "Texte" choisir "UTF-8" jeu de Caractères. Vous devez également choisir une police de caractères unicode, comme la valeur par défaut "Lucida Console". Ma configuration ressemble comme suit:
      Unicode (utf-8) avec git-bash

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

       $ LANG='C.UTF-8'

    4. La commande ls devraient maintenant s'afficher correctement

      AppData/
'Application Data'@
Contacts/
Cookies@
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'@
NTUSER.DAT
.
.
.
'Τα έγγραφά μου'@
    • Juste en ajoutant à cela. Tous ces paramètres sont stockés dans ~/.minttyrc
    • Vous êtes le seul qui a répondu à la question.
    • Heureux de savoir que je pouvais être d'une aide
    InformationsquelleAutor nkatsar
  2. 7

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

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

    • Comment l'activer? J'utilise Git Bash 2.11, et ce n'est pas en UTF-8 sur Windows 8 ou Windows 10. Mes sorties sont souvent polluées par des caractères incorrects, et je voudrais supprimer le problème.
    • Après la mise à niveau à partir de Git 2.9.2 à 2.15.0 juste maintenant, j'ai trouvé qu'il avait essentiellement régressé, montrant l'encodage UTF-8 (par exemple <E2><80><99> pour ’) dans le sens inverse soulignant (qui est, en noir sur blanc plutôt que le blanc sur noir) plutôt que sur le caractère qu'il avait jadis fait. Je l'ai corrigé en définissant la variable d'environnement LC_ALL=en_AU.utf8 à l'échelle mondiale. Notez que j'utilise chcp 65001 (le pseudo-UTF-8 page de codes pour conhost). C'est assez semblable à ce que le haut-voté réponse à cette question, a dit de le faire.
    InformationsquelleAutor Hannes
  3. 5

    Vérifier si le problème persiste avec Git 2.1 (août 2014).

    Voir s'engager 617ce96 ou s'engager 1c950a5 par Karsten Blees (kblees)

    Win32: prise en charge d'Unicode sortie de la console

    WriteConsoleW semble être le seul moyen fiable d'impression unicode à l'
    console (sans bizarre code de conversions de page).

    Redirige également vfprintf à la winansi.c version.

    Win32: ajouter des fonctions de conversion Unicode

    Ajouter des fonctions de conversion Unicode pour convertir entre natifs de Windows UTF-16LE le codage UTF-8 et à l'arrière.

    À l'appui des référentiels avec l'héritage codé les noms de fichiers, l'UTF-8, UTF-16 fonction de conversion essaie de créer valide, un nom de fichier unique, même pour de l'UTF-8 non valide les séquences d'octets, de sorte que ces dépôts peut être vérifié sans erreur.

    Il est susceptible d'être un port de quelque chose de déjà intégré dans msysgit, mais au moins, cela signifie que la version Windows de Git n'aurez pas à diverger/patch à partir du Git de pensions de code source afin d'inclure ces améliorations.

    • Comment activer UTF-8? J'utilise Git Bash 2.11, et ce n'est pas en UTF-8 sur Windows 8 ou Windows 10. Mes sorties sont souvent polluées par des caractères incorrects, et je voudrais supprimer le problème.
    InformationsquelleAutor VonC
  4. 4

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

    Normalement avec chaque nouvelle version de problèmes, obtenir de meilleurs résolu. E. g. avec la version d'il y a un an, je ne pouvais pas saisir des caractères comme "ä" dans la coque, de sorte qu'il n'était pas possible d'écrire

    echo "ä"

    Tester rapidement si l'UTF-8 est prise en charge et à quel niveau. Une solution de contournement consiste à écrire l'octet-séquences octal:

    $ echo -e "0344"
ä

    Encore des questions je dois quand j'execute mon windows php.exe binaire à la sortie de texte:

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

    Cela ne donne pas le le "ä" dans le terminal, mais il renvoie "├ñ" à la place. La solution de contournement pour moi, c'est que j'enveloppe le php commande dans un bash-script qui traite la sortie à travers cat:

    #!/bin/bash

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

    réf. reg. stdout + stderr chat

    Magiquement, puis fait php de travailler à nouveau:

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

    S'applique à

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

    Je dois avouer que je m'ennuie de plus profond, de comprendre pourquoi tout cela est la façon dont il est. Mais je suis enfin heureux que j'ai trouvé une solution de contournement pour utiliser le php dans git bash avec le support UTF-8.

    • Belle addition à d'autres réponses. J'ai eu à utiliser cette solution de contournement pour les scripts PHP, même maintenant - git version 2.8.2.windows.1.
    InformationsquelleAutor hakre
  5. 3

    Trouvé cette réponse ailleurs:

    chcp.com 65001

    Git bash rssa windows7 problème de codage de

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

    InformationsquelleAutor TravisChambers
  6. 0

    Le problème avec chcp 65001 est qu'il y a des bugs dans le runtime C (MSVCRT) qui font stdio appels de retour des résultats incohérents lors de l'exécution sous la page de codes 65001.

    Qui devrait être mieux avec Git 2.23 (T3 2019)

    Voir s'engager 090d1e8 (03 Juillet 2019) par Karsten Blees (kblees).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager 0328db0, le 11 Juillet 2019)

    gettext: toujours utiliser de l'UTF-8 sur Windows natif

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

    Gettext utilise setlocale() pour déterminer l'encodage de sortie pour le texte traduit, cependant, MSVCRT de setlocale() ne supporte pas l'UTF-8. En conséquence, le texte traduit est codé dans le système de codage (comme par GetAPC()), et de la non-ASCII les caractères sont
    mutilé dans la console de sortie    .

    Note de côté: Il est en fait une page de code pour de l'UTF-8: 65001.

    Dans la pratique, il ne fonctionne pas comme prévu, au moins sur Windows 7, cependant, de sorte que nous ne pouvons l'utiliser dans Git. En outre, si nous avons changé le code de la page, tous les processus générés à partir de Git hériter de cette page de code (par opposition à la page de code configuré pour l'utilisateur actuel), ce qui serait tout à fait peut-elle casser par exemple, diff ou de fusionner des aides. Donc, nous avons vraiment ne peut pas remplacer le code de la page.

    Dans init_gettext_charset(), Git appels gettext est bind_textdomain_codeset() avec le jeu de caractères obtenus par locale_charset(); nous allons remplacer cette dernière fonction pour forcer l'encodage en UTF-8 sur Windows natif.

    Dans Git pour Windows SDK, il y a un libcharset.h et, par conséquent, nous définissons HAVE_LIBCHARSET_H dans le MINGW-section spécifique dans config.mak.uname, donc nous avons besoin d'ajouter le remplacer avant que de façon conditionnelle compilé bloc de code.

    Plutôt que de définir simplement locale_charset() de retourner la chaîne "UTF-8", cependant, nous faisons attention à ne pas casser LC_ALL=C: le ab/no-kwset patch de la série, par exemple, doit avoir un moyen pour empêcher Git de s'attendre à des codé en UTF-8 d'entrée.

    Et:

    Voir s'engager 697bdd2 (04 Juillet 2019), et s'engager 9423885, s'engager 39a98e9 (27 Juin 2019) en Johannes Schindelin (dscho).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager 0a2ff7c, le 11 Juillet 2019)

    mingw: utiliser les fonctions Unicode explicitement

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

    L'ANSI variante suppose que les chaînes de caractères sont codés selon quelle que soit la localisation en cours.

    Ce n'est pas ce que Git veut l'utiliser sur Windows: nous supposons que char * variables point de chaînes de caractères encodés en UTF-8.

    Il y a un pseudo UTF-8 sur Windows, mais il ne fonctionne pas comme on pourrait s'y attendre. En outre, si nous l'emportaient sur les paramètres régionaux de l'utilisateur, qui permettrait de modifier le comportement des programmes lancés par Git (comme les éditeurs, difftools, etc), donc on ne peut pas utiliser ce pseudo locale.

    En outre, il est effectivement conseillé d'utiliser les versions Unicode
    au lieu de la version ANSI, nous allons donc faire exactement cela.

    Remarque: lors de l'appel des fonctions de l'API Win32 sans un suffixe, cela dépend si le UNICODE constante est définie dans les en-têtes sont #include avais.

    Sans cette constante, la norme ANSI variantes sont utilisées.

    Nous allons être explicite et éviter cette ambiguïté.

    InformationsquelleAutor VonC