git, msysgit, accents, utf-8, les réponses définitives

Question

J'ai lu à certains endroits qu'il y avait des problèmes avec git (ou juste msysgit ?) et le codage des caractères - je croire c'est seulement un problème dans les noms de fichiers.

J'aimerais obtenir des informations "définitives" (ou du moins faisant autorité) sur.. :

1. Quels sont exactement les "problèmes" ? (Les symptômes)
2. Quelles en sont les causes ? (Brièvement)
3. Dans quels scénarios cela constitue-t-il un obstacle ?
4. Y a-t-il une résolution en vue, ou à défaut des solutions de contournement ?

J'espère que cette question n'est pas trop vague, je pense qu'il serait bon d'avoir toutes ces informations en un seul endroit pour pouvoir y diriger les gens...

Answer 1

Mise à jour fév. 2017 (Git 2.12) : Le tableau des largeurs de caractères a été mis à jour pour correspondre aux Unicode 9.0 .
Le site update_unicode.sh est l'a déplacé dans contrib/update-unicode : voir son README .

Mise à jour août 2014 (git 2.1) : commettre a67c821 ( Torsten Bögershausen (tboegi) ) ajoute la prise en charge d'Unicode 7.0.

Mise à jour d'avril 2014 : commettre d813ab9 ( Torsten Bögershausen (tboegi) ) ajoute le support pour Unicode 6.3
(git 1.9.2) :

Unicode 6.3 définit un plus grand nombre de points de code comme étant des combinaisons ou des accents. .
Par exemple, le caractère " ö "pourrait être exprimé sous la forme d'un " o "suivi de U+0308 COMBINING DIARESIS (aussi appelé tréma, double point).
Nous devons considérer qu'une telle séquence de deux codepoints occupe une colonne d'affichage pour les besoins de l'alignement, et pour cela, git_wcwidth() devrait retourner 0 pour eux.

Les points de code affectés sont :

U+0358..U+035C
U+0487
U+05A2, U+05BA, U+05C5, U+05C7
U+0604, U+0616..U+061A, U+0659..U+065F

Les normes unicode antérieures les avaient définis comme "réservés".

Seule la gamme 0..U+07FF a été vérifié pour voir quels points de code doivent être marqués comme étant de largeur 0 lors de la préparation de cette livraison ; d'autres mises à jour peuvent être nécessaires.

---

Mise à jour avril 2012 : Le support Unicode est disponible dans la version 1.7.10. Voir cette page pour les notes et les paramètres que vous devez définir.

A savoir :

git config [--global] core.quotepath off
git config [--global] i18n.logoutputencoding utf8
git config [--global] i18n.commitencoding utf8
git config [--global] --unset svn.pathnameencoding

Le site recodetree check parcourt l'historique complet d'un dépôt git et imprime tous les noms de fichiers non ASCII. Si la sortie est vide, aucune migration n'est nécessaire.

---

Mise à jour de février 2012 : les correctifs pour le support de l'UTF-8 sont en cours dans la branche 'devel' du site. repo msysgit sur GitHub dont Mise à jour des paramètres de less pour UTF-8 .

La page Google+ de Git pour Windows mentionne :

Les correctifs UTF-8 de Karsten Blees pour Git pour Windows ont été fusionnés dans le fichier " devel '.
Cela signifie que la prochaine version supportera les noms de fichiers Unicode !

---

Mai 2011

Je crois que le msysgit issue 80 a les dernières nouvelles sur ce bug.
Également décrit dans numéro 376 .

Par exemple :

C'est ce qui se passe :

1. git sous Windows opère sur les noms de fichiers et les traite essentiellement comme des flux d'octets. Dans votre cas, les flux sont des textes encodés en UTF8.

2. git sous Windows demande au runtime de créer un fichier, et lui transmet le flux d'octets.

3. Puisqu'en interne, sous Windows, tout est Unicode, le runtime convertit le flux d'octets en UTF16 en utilisant la locale actuellement définie. en UTF16 en utilisant la locale actuellement définie (alias "codepage").
   C'est-à-dire qu'il interprète effectivement le flux d'octets comme un texte codé CP949 (coréen).
   Apparemment, certaines des séquences d'octets UTF8 sont des séquences CP949 invalides, et la conversion échoue ("Argument invalide") ; ou si les séquences UTF8 sont des séquences CP949 correctes, le résultat est (très probablement) un caractère différent.

La vraie solution devrait être sur MingW cependant :

Il me vient à l'esprit qu'une solution serait la suivante : résoudre le problème au niveau du run-time C de GCC de la bibliothèque d'exécution C de GCC.
En d'autres termes, pour la bibliothèque d'exécution GCC mingw sous Windows, il faut rendre possible, par le biais d'options de construction, d'être dans un mode où les paramètres de la ligne de commande (passés à l'option main() ) et les fonctions d'entrée/sortie de fichiers utilisent les appels sous-jacents de l'API Unicode de Windows, et traduisent le codage UTF-8 dans les API de fonctions standard de C qui utilisent les chaînes d'octets.
Cela fonctionnerait "juste" pour git peut-être, et pourrait être utile pour d'autres projets open source d'origine Linux fonctionnant dans l'environnement Windows.

ak2 commentaires que MingW n'est pas le bon endroit pour cette réparation :

"Les compilateurs MinGW donnent accès aux fonctionnalités du moteur d'exécution Microsoft C et de certains moteurs d'exécution spécifiques à un langage.
MinGW, étant minimaliste, ne tente pas, et ne tentera jamais, de fournir un environnement d'exécution POSIX pour le déploiement d'applications POSIX sur MS-Windows.
Si vous souhaitez déployer des applications POSIX sur cette plate-forme, envisagez plutôt Cygwin."

Des travaux sont en cours sur un variante de msysgit pour supporter l'unicode .