Ошибка SVN: невозможно преобразовать строку из собственной кодировки в 'UTF-8' - PullRequest
40 голосов
/ 22 января 2010

У меня есть скрипт ловушки после фиксации, который выполняет SVN-обновление рабочей копии, когда коммиты сделаны в хранилище.

Когда пользователи фиксируют репозиторий со своих компьютеров Windows, используя TortoiseSVN, они получают следующую ошибку:

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

Файл, о котором идет речь выше: Teneriffa-Süd.jpg обратите внимание на ударение u. Это потому, что сайт на немецком языке, а файлы написаны на немецком языке.

При выполнении обновления рабочей копии в командной строке Linux ошибок не обнаружено. Вышеуказанная ошибка существует, только когда ловушка post-commit выполняется через фиксацию клиентом Windows SVN.

Вопросы:

  1. Почему SVN пытается изменить кодировку файла?
  2. Разрешено ли в именах файлов содержать символы, которые не входят в стандартные символы ASCII Windows?

Обновление:

Оказывается, что имя файла, о котором идет речь, правильно отображается как Teneriffa-Süd.jpg при просмотре с компьютера Windows (через Samba), но когда я просматриваю имя файла с сервера Linux (используя SSH и PuTTY), где находится файл, я получаю Teneriffa-Süd.jpg

Ответы [ 11 ]

0 голосов
/ 11 января 2013

У меня возникла похожая проблема при запуске «svn add» в каталоге, но решение было другим. Я не мог видеть шестнадцатеричные цифры с помощью printf (фактически svn не показывал шестнадцатеричный вывод), но эта команда позволила мне увидеть результаты и исправить это:

LC_ALL=C svn add probealign

Я думаю, что в общем случае вставка LC_ALL = C до того, как ваша команда позволит вам увидеть испорченные файлы ... и это намного проще, чем вставка во многие файлы \ x72 (которые, очевидно, могут быть недоступны).

...