Подтвердить что ты не робот

Ошибка SVN: невозможно преобразовать строку из исходной кодировки в 'UTF-8'

У меня есть крюк post-commit script, который выполняет обновление 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.

Вопросы:

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

Update:

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

4b9b3361

ОТВЕТЫ

Ответ 1

  • Он не меняет кодировку файла. Он изменяет кодировку имени файла (на то, что каждый клиент может с пониманием сказать).
  • Разрешено кем? NTFS использует 16-битные кодовые точки, и Windows может выставлять имена файлов в разных кодировках, основываясь на том, как вы ее попросите (он попытается преобразовать их в кодировку, которую вы просите). Теперь... Этот бит (как вы спрашиваете) зависит от конкретного клиента svn, который вы используете. Это звучит для меня как ошибка в TortoiseSVN.

Изменить для добавления:

Тьфу. Я неправильно понял симптомы. сервер svn хранит все в utf-8 (и кажется, что он сделал это успешно).

Крюк post-commit - это бит, который не может конвертировать из UTF-8. Если я понимаю, что вы говорите правильно, крюк post-commit на сервере запускает обновление svn на общий диск (поэтому svn-сервер запускает svn-клиент для себя...)? Это означает, что конфигурация, которая должна быть исправлена, является той, которая предназначена для клиента на сервере. Проверьте LANG/LC_ALL в среде, выполняющей сервер svn.. Как это бывает, крючки запускаются в вакуумной среде (см. Совет). Поэтому вы должны установить переменную в самом крючке.

См. также эту страницу для получения информации о том, как svn обрабатывает локализацию

Ответ 2

Еще один пример:

$ 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

(... и теперь все нормально)

Ответ 3

Если ошибка -

[[email protected] 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)

Тогда сделайте это.

[[email protected] public_html]$ printf "\x46\x65\x6e\x65\x72\x62\x61\x68\n"
Fenerbah

(Это означает, что у системы есть имя файла, начинающееся с "Fenerbah" в этой папке.)

[[email protected] public_html]$ cd  images
[[email protected] images]$ rm -rf Fenerbahçe+Forma+2.jpg

Итак, вы можете видеть, что в имени есть специальный символ, и он не поддерживается SVN.

Ответ 4

поместите это в свой пост-фиксацию экспорт LANG = xxxxx (ваш язык)

Ответ 5

Не забудьте создать эти локали в своей системе
(как root)

пример для Ru 

locale-gen ru_RU.CP1251
locale-gen ru_RU.UTF-8
dpkg-reconfigure locales

Ответ 6

  • Он изменяет кодировку на нейтральную по отношению к местоположению кодировку, если кто-то с другой кодировкой проверяет ее.

  • Конечно. Но это не "Windows" ASCII (Windows действительно использует какую-то странную кодировку, например CP1251).

Лучший способ исправить это - убедиться, что ваша система использует UTF-8, когда это возможно (проверьте $LANG).

Ответ 7

Просто используйте следующую строку в script перед выполнением любой команды svn. Пользовательские коды языков, в следующем примере я использовал japanese

export LC_ALL=ja_JP.UTF8

Ответ 8

Кажется, что все LC_-переменные нуждаются в .UTF8 в конце. Например, у меня были определенные LC_ALL, LC_TIME и LC_CTYPE. После установки LC_CTYPE проблема не была решена, поэтому мне также нужно было набрать LC_ALL, а затем это сработало:

LC_ALL=en_US.UTF-8
LC_TIME=en_DK.UTF-8
LC_CTYPE=en_US.UTF-8

Чтобы снова избежать проблемы, я скопировал файл на другое имя, удалил старый из svn, добавил новый в svn и отправил сообщение сотруднику, чтобы этого не сделать.

Ответ 9

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

LC_ALL=C svn add probealign

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

Ответ 10

Для получения информации, я получил эту ошибку при фиксации native encoding to 'UTF-8' с помощью черепахи svn клиента Windows,

когда мой URL-адрес репозитория:

http://x.x.x.x/svn/myrepos

Я изменил URL-адрес репозитория для:

SVN://x.x.x.x/myrepos

и теперь все это perferct.

Я думаю, что эта информация будет полезна для некоторых.

Ответ 11

В моем случае у меня была настройка в ~/.subversion/config, как показано ниже log-encoding = ...

Комментарий о том, что это сработало.