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

Question

У меня есть скрипт ловушки после фиксации, который выполняет 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

Answer 1

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

$ 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

(... и теперь все в порядке)

Answer 2

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

Изменить, чтобы добавить:

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

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

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

Answer 3

Если ошибка -

[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)

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

[abc@288832-web3 public_html]$ printf "\x46\x65\x6e\x65\x72\x62\x61\x68\n"
Fenerbah  

(Это означает, что в этой системе есть имя файла, начинающееся с "Фенербах").

[abc@288832-web3 public_html]$ cd  images
[abc@288832-web3 images]$ rm -rf Fenerbahçe+Forma+2.jpg

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

Answer 4

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

Answer 5

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

export LC_ALL=ja_JP.UTF8

Answer 6

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

пример для Ru

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

Answer 7

1. Изменяет кодировку на кодировку, не зависящую от местоположения, в случае, если кто-то с другой кодировкой проверяет ее.

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

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

Answer 8

Кажется, что все LC_ varables нуждаются в .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 и отправил сообщение соавтору не делать этого.

Answer 9

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

Комментируя это сработало.

Answer 10

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

когда мой URL хранилища был:

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

Я изменил свой URL хранилища на:

СВН: //x.x.x.x/myrepos

и теперь все идеально.

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