Erreur SVN: impossible de convertir la chaîne de l'encodage natif en 'UTF-8'
J'ai un script de hook post-commit qui effectue une mise à jour SVN d'une copie de travail lorsque des commits sont effectués dans le référentiel.
Lorsque les utilisateurs s'engagent dans le référentiel à partir de leurs machines Windows à l'aide de TortoiseSVN, ils obtiennent l'erreur suivante:
post-commit hook failed (exit code 1) with output:
svn: Error converting entry in directory '/home/websites/devel/website/guides/Images' to UTF-8
svn: Can't convert string from native encoding to 'UTF-8':
svn: Teneriffa-S?\195?\188d.jpg
Le fichier en question ci-dessus est: Teneriffa-Süd.jpg remarquez le u accentué. En effet, le site est allemand et les fichiers ont été orthographiés en allemand.
Lors de l'exécution d'une mise à jour sur la copie de travail sur la ligne de commande Linux, aucune erreur n'est rencontrée. L'erreur ci-dessus existe uniquement lorsque le hook post-commit est exécuté via une commit par un client Windows SVN.
Des questions:
- Pourquoi SVN essaierait-il de changer l'encodage d'un fichier?
- Les noms de fichiers sont-ils autorisés à contenir des caractères en dehors du standard Windows ASCII ceux?
Mise à jour:
Il s'avère que le nom de fichier du fichier en question s'affiche correctement comme Teneriffa-Süd.jpg lorsqu'il est visualisé à partir d'une machine Windows (via Samba) mais lorsque je visualise le nom de fichier depuis le serveur Linux (en utilisant SSH et PuTTY) où réside le fichier, j'obtiens Teneriffa-Süd.jpg
- Cela ne change pas l'encodage du fichier. Il modifie l'encodage du nom de fichier (en quelque chose que chaque client peut, espérons-le, comprendre).
- Autorisé par qui? NTFS utilise des points de code 16 bits et Windows peut exposer les noms de fichiers dans différents encodages, en fonction de la façon dont vous le demandez (il essaiera de les convertir en l'encodage que vous demandez). Maintenant ... Ce bit (comment vous le demandez) dépend du client svn spécifique que vous utilisez. Cela me semble être un bug dans TortoiseSVN.
Modifier pour ajouter:
Pouah. J'ai mal compris les symptômes. le serveur svn stocke tout dans utf-8 (et il semble qu'il l'ait fait avec succès).
Le hook post-commit est le bit qui ne parvient pas à convertir depuis UTF-8. Si je comprends bien ce que vous dites, le hook post-commit sur le serveur déclenche une mise à jour svn vers un lecteur partagé (le serveur svn démarre donc lui-même un client svn ...)? Cela signifie que la configuration à corriger est celle du client sur le serveur . Vérifiez le LANG/LC_ALL sur l'environnement exécutant le serveur svn.. En l'occurrence, les crochets sont exécutés dans un environnement sous vide (voir Astuce). Vous devez donc définir la variable dans le crochet lui-même.
Voir aussi cette page pour plus d'informations sur la façon dont svn gère la localisation
Encore un autre exemple:
$ svn update
svn: Error converting entry in directory '.' to UTF-8
svn: Can't convert string from native encoding to 'UTF-8':
$ export LC_CTYPE=en_US.UTF-8
$ svn update
(... et tout va bien maintenant)
Si l'erreur est -
[abc@288832-web3 public_html]$ svn update
svn: Error converting entry in directory 'images' to UTF-8
svn: Valid UTF-8 data
(hex: 46 65 6e 65 72 62 61 68)
followed by invalid UTF-8 sequence
(hex: e7 65 2b 46)
Alors fais ça.
[abc@288832-web3 public_html]$ printf "\x46\x65\x6e\x65\x72\x62\x61\x68\n"
Fenerbah
(Cela signifie que le système a un nom de fichier commençant par "Fenerbah" dans ce dossier.)
[abc@288832-web3 public_html]$ cd images
[abc@288832-web3 images]$ rm -rf Fenerbahçe+Forma+2.jpg
Vous pouvez donc voir qu'il y a un caractère spécial dans le nom et qu'il n'est pas pris en charge par SVN.
mettez ceci dans votre export post-commit LANG = xxxxx (votre langue)
Utilisez simplement la ligne suivante dans votre script avant d'exécuter une commande svn. Codes de langue appropriés à l'utilisateur, dans l'exemple suivant, j'ai utilisé le japonais
export LC_ALL=ja_JP.UTF8
N'oubliez pas de générer ces paramètres régionaux dans votre système
(en tant que root)
exemple pour Ru
locale-gen ru_RU.CP1251
locale-gen ru_RU.UTF-8
dpkg-reconfigure locales
Il modifie l'encodage en un encodage indépendant de l'emplacement au cas où quelqu'un avec un encodage différent le vérifierait.
Bien sûr. Mais ce n'est pas "Windows" ASCII (Windows utilise en fait un encodage étrange comme CP1251 ou plus).
La meilleure façon de résoudre ce problème est de vous assurer que votre système utilise UTF-8 autant que possible (vérifiez $LANG).
Il semble que toutes les variables LC_ aient besoin de .UTF8 à la fin. Par exemple, il se trouve que LC_ALL, LC_TIME et LC_CTYPE ont été définis. Après avoir défini LC_CTYPE, le problème n'a pas été résolu, j'ai donc dû également saisir LC_ALL, puis cela a fonctionné:
LC_ALL=en_US.UTF-8
LC_TIME=en_DK.UTF-8
LC_CTYPE=en_US.UTF-8
Afin d'éviter à nouveau le problème, j'ai copié le fichier sous un autre nom, supprimé l'ancien de svn, ajouté un nouveau à svn et envoyé un message à un collaborateur pour ne pas le faire.
J'ai eu un problème similaire lors de l'exécution de "svn add" sur un répertoire, mais la solution était différente. Je ne pouvais pas voir les chiffres "hex" en utilisant printf (en fait, aucune sortie hexadécimale n'était affichée par svn), mais cette commande m'a permis de voir les résultats et de le corriger:
LC_ALL=C svn add probealign
Je pense qu'en général, coller LC_ALL = C avant votre commande vous permet de voir les fichiers incriminés ... et est beaucoup plus facile que de coller dans beaucoup de\x72 (qui ne sont apparemment pas disponibles).
Dans mon cas, j'avais le paramètre dans ~/.Subversion/config comme ci-dessous log-encoding = ...
Commentant cela a fonctionné.
Pour plus d'informations, j'ai obtenu cette erreur lors de la validation native encoding to 'UTF-8'avec un client Windows tortue svn,
lorsque mon URL de référentiel était:
J'ai changé mon URL de référentiel pour:
svn: //x.x.x.x/myrepos
et maintenant tout est parfait.
Je pense que cette information sera utile à certains.