SVN错误：无法将string从本机编码转换为“UTF-8”
我有一个post-commit钩子脚本，在对仓库进行提交时执行工作副本的SVN更新。
当用户使用TortoiseSVN从他们的Windows机器提交到存储库时，他们得到以下错误：
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命令行上对工作副本执行更新时，不会遇到任何错误。 上述错误仅在通过Windows SVN客户端提交执行后提交挂钩时才存在。
问题：
- 为什么SVN会尝试更改文件的编码？
- 是否允许文件名包含Windows标准ASCII字符之外的字符？
更新：
事实certificate，当从Windows机器（通过Samba）查看时，问题文件的文件名正确显示为Teneriffa-Süd.jpg ，但是当我从Linux服务器（使用SSH和PuTTY）查看文件所在的文件名时，我得到Teneriffa-Süd.jpg
- 它不会更改文件的编码。 它改变了文件名的编码（每个客户都希望能理解的东西）。
- 谁允许？ NTFS使用16位代码点，Windows可以根据您的要求（它会尝试将它们转换为您要求的编码）以各种编码公开文件名。 现在…这一点（你怎么问）取决于你使用的特定的svn客户端。 这听起来像在TortoiseSVN中的一个错误。
编辑添加：
啊。 我误解了症状。 svn服务器将所有内容存储在utf-8中（似乎是成功的）。
提交后的钩子是无法从UTF-8转换的位。 如果我明白你说的是正确的，服务器上的post-commit钩子触发svn更新到共享驱动器（svn服务器因此启动一个svn客户端到自己…）？ 这意味着需要解决的configuration是服务器上客户端的configuration 。 检查执行svn服务器的环境中的LANG / LC_ALL。 。 碰巧，钩子在真空环境中运行（见提示）。 所以你应该在钩子本身设置variables。
有关svn如何处理本地化的信息，另请参阅此页面
还有一个例子：
$ 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
（…现在一切都很好）
如果错误是 –
[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
（这意味着系统在该文件夹中有一些以“Fenerbah”开头的文件名。）
[abc@288832-web3 public_html]$ cd images [abc@288832-web3 images]$ rm -rf Fenerbahçe+Forma+2.jpg
所以你可以看到名称中有一个特殊的字符，SVN不支持。
把这个在你的post-commit export LANG = xxxxx（你的lang）
不要忘记在系统中生成这些语言环境
（作为根）
Ru的例子
locale-gen ru_RU.CP1251 locale-gen ru_RU.UTF-8 dpkg-reconfigure locales
-
它会将编码更改为与位置无关的编码，以防使用不同编码的人将其检出。
-
当然。 但它不是“Windows”ASCII（Windows实际上使用一些奇怪的编码，如CP1251左右）。
解决这个问题的最好方法是确保你的系统尽可能使用UTF-8（检查$LANG ）。
在执行任何svn命令之前，只需在脚本中使用以下行即可。 用户适当的语言代码，在下面的例子中，我用日语
export LC_ALL=ja_JP.UTF8
看来所有的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中添加了一个新的名字，然后发送一个消息给协作者。
在一个目录下运行“svn add”时遇到了类似的问题，但是解决方法不同。 我看不到使用printf的“hex”数字（实际上svn没有显示hex输出），但是这个命令允许我看到结果并解决它：
LC_ALL=C svn add probealign
我认为，一般来说，坚持LC_ALL = C之前，你的命令可以让你看到有问题的文件…并且比粘贴很多东西（显然可能不可用）容易很多。
有关的信息，我得到了提交native encoding to 'UTF-8'与Windows客户端乌龟svn这个错误，
当我的存储库的URL是：
HTTP：// XXXX / SVN / myrepos
我更改了我的存储库URL：
SVN：// XXXX / myrepos
现在都是很好的
我认为这些信息对一些人有用。
在我的情况下，我有〜/ .subversion / config中的设置如下log-encoding = ...
评论它的工作。
