Ошибка 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
Ответы
Ответ 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 = ...
Комментарий о том, что это сработало.