linux - tortoise - svn windows
Error de SVN: no se puede convertir una cadena de codificación nativa a ''UTF-8'' (11)
- No cambia la codificación del archivo. Cambia la codificación del nombre del archivo (a algo que todos los clientes pueden entender).
- Permitido por quien? NTFS utiliza puntos de código de 16 bits, y Windows puede exponer los nombres de los archivos en varias codificaciones, en función de cómo lo solicite (intentará convertirlos a la codificación que usted solicite). Ahora ... Ese bit (cómo lo preguntas) depende del cliente svn específico que uses. A mí me suena como un error en TortoiseSVN.
Editar para agregar:
Ugh. No entendí los síntomas. el servidor svn almacena todo en utf-8 (y parece que lo hizo con éxito).
El enganche post-commit es el bit que no puede convertir desde UTF-8. Si entiendo lo que está diciendo correctamente, el enganche post-commit en el servidor desencadena una actualización de svn a una unidad compartida (el servidor svn por lo tanto, inicia un cliente svn a sí mismo ...)? Esto significa que la configuración que necesita ser arreglada es la del cliente en el servidor . Compruebe LANG / LC_ALL en el entorno que ejecuta el servidor svn. . Como sucede, los ganchos se ejecutan en un entorno de vacío (consulte la Sugerencia). Entonces debería establecer la variable en el gancho.
Consulte también esta página para obtener información sobre cómo svn maneja la localización
Tengo un script de enlace post-commit que realiza una actualización SVN de una copia de trabajo cuando se realizan confirmaciones en el repositorio.
Cuando los usuarios se comprometen con el repositorio desde sus máquinas con Windows usando TortoiseSVN, reciben el siguiente error:
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
El archivo en cuestión arriba es: Teneriffa-Süd.jpg note el acentuado u. Esto se debe a que el sitio es alemán y los archivos se han escrito en alemán.
Al ejecutar una actualización en la copia de trabajo en la línea de comandos de Linux, no se encontraron errores. El error anterior solo existe cuando el enlace post-commit se ejecuta a través de un commit por un cliente SVN de Windows.
Preguntas:
- ¿Por qué SVN intentaría cambiar la codificación de un archivo?
- ¿Se permite que los nombres de archivo contengan caracteres que están fuera de los estándares ASCII de Windows?
Actualizar:
Resulta que el archivo en el nombre de archivo de la pregunta se visualiza correctamente como Teneriffa-Süd.jpg cuando se ve desde una máquina Windows (a través de Samba) pero cuando veo el nombre de archivo del servidor Linux (usando SSH y PuTTY) donde reside el archivo obtengo Teneriffa-Süd.jpg
Cambia la codificación a una codificación de ubicación neutral en caso de que alguien con una codificación diferente la verifique.
Por supuesto. Pero no es ASCII "Windows" (Windows realmente usa una codificación extraña como CP1251 más o menos).
La mejor manera de solucionar esto es asegurarse de que su sistema use UTF-8 siempre que sea posible (marque $LANG ).
En mi caso, tuve la configuración en ~ / .subversion / config como a continuación log-encoding = ...
Comentando que funcionó.
No te olvides de generar esas configuraciones regionales en tu sistema
(como raíz)
ejemplo para Ru
locale-gen ru_RU.CP1251
locale-gen ru_RU.UTF-8
dpkg-reconfigure locales
Obtuve un problema similar al ejecutar "svn add" en un directorio, pero la solución era diferente. No pude ver los dígitos "hexadecimales" con printf (en realidad, svn no mostró salida hexadecimal), pero este comando me permitió ver los resultados y corregirlos:
LC_ALL=C svn add probealign
Creo que, en general, pegar LC_ALL = C antes de su comando le permite ver los archivos ofensivos ... y es mucho más fácil que pegar en muchas cosas / x72 (que aparentemente no están disponibles).
Otro ejemplo más:
$ 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
(... y todo está bien ahora)
Para obtener información, obtuve este error al confirmar la native encoding to ''UTF-8'' con un svn de tortuga cliente de Windows,
cuando mi URL del repositorio era:
Cambié mi URL de repositorio por:
svn: // xxxx / myrepos
y ahora todo es perfecto
Creo que esta información será útil para algunos.
Parece que todos los elementos de red_ LC necesitan .UTF8 al final. Por ejemplo, tuve LC_ALL, LC_TIME y LC_CTYPE definidos. Después de configurar LC_CTYPE, el problema no se resolvió, así que también tuve que escribir LC_ALL y luego funcionó:
LC_ALL=en_US.UTF-8
LC_TIME=en_DK.UTF-8
LC_CTYPE=en_US.UTF-8
Para evitar nuevamente el problema, copié el archivo a un nombre diferente, eliminé el anterior de svn, agregué uno nuevo a svn y le envié un mensaje a un colaborador para que no lo hiciera.
Si el error es -
[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)
Entonces haz esto.
[abc@288832-web3 public_html]$ printf "/x46/x65/x6e/x65/x72/x62/x61/x68/n"
Fenerbah
(Esto significa que el sistema tiene un nombre de archivo que comienza con "Fenerbah" en esa carpeta).
[abc@288832-web3 public_html]$ cd images
[abc@288832-web3 images]$ rm -rf Fenerbahçe+Forma+2.jpg
Entonces puede ver que hay un carácter especial en el nombre y SVN no lo admite.
Simplemente use la siguiente línea en su secuencia de comandos antes de ejecutar cualquier comando svn. Códigos de idioma apropiados para el usuario, en el siguiente ejemplo utilicé japonés
export LC_ALL=ja_JP.UTF8
pon esto en tu LANG de exportación post-commit = xxxxx (tu lengua)