SVNエラー：文字列をネイティブエンコーディングから「UTF-8」に変換できません
リポジトリにコミットが行われると、作業コピーの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 ones？）以外の文字を含めることができますか？
更新：
問題のファイルのファイル名はTeneriffa-Süd.jpg（Samba経由で）Windowsマシンから表示すると、ファイルが存在するLinuxサーバー（SSHおよびPuTTYを使用）からファイル名を表示すると、Teneriffa-Süd.jpg
- ファイルのエンコーディングは変更されません。ファイル名のエンコーディングを変更します（すべてのクライアントがうまく理解できるものに）。
- 誰に許可されていますか？ NTFSは16ビットコードポイントを使用し、Windowsは要求に応じてさまざまなエンコーディングでファイル名を公開できます（要求するエンコーディングに変換しようとします）。さて...そのビット（あなたが尋ねる方法）は、使用する特定のsvnクライアントに依存します。 TortoiseSVNのバグのように思えます。
追加して編集：
あー私は症状を誤解しました。 svnサーバーはすべてをutf-8に保存します（そして、それはうまくいったようです）。
コミット後フックは、UTF-8からの変換に失敗するビットです。あなたが言っていることを正しく理解している場合、サーバーのコミット後フックは共有ドライブへのsvn更新をトリガーします（したがってsvnサーバーはそれ自体に対してsvnクライアントを起動します...）？これは、修正が必要な構成がサーバー上のクライアントの構成であることを意味します。 Svnサーバーを実行している環境でLANG/LC_ALLを確認します。。それが起こると、フックは 真空環境 で実行されます（ヒントを参照）。したがって、フック自体に変数を設定する必要があります。
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でサポートされていないことがわかります。
これをコミット後のエクスポートLANG = xxxxx（ご使用のlang）に入れます
Svnコマンドを実行する前に、スクリプトで次の行を使用してください。ユーザーに適切な言語コード、次の例では日本語を使用しました
export LC_ALL=ja_JP.UTF8
システムでこれらのロケールを生成することを忘れないでください
（ルートとして）
Ruの例
locale-gen ru_RU.CP1251
locale-gen ru_RU.UTF-8
dpkg-reconfigure locales
differentエンコーディングを持つ誰かがチェックアウトした場合に備えて、エンコーディングをロケーション中立エンコーディングに変更します。
もちろん。しかし、これは「Windows」ではありませんASCII（Windowsは実際にはCP1251などのような奇妙なエンコーディングを使用します）。
これを修正する最良の方法は、可能な限りシステムがUTF-8を使用するようにすることです（$LANGを確認してください）。
すべての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に新しいファイルを追加し、これを行わないように協力者にメッセージを送信しました。
ディレクトリで「svn add」を実行すると同様の問題が発生しましたが、解決策は異なりました。 printfを使用して「16進数」の数字を見ることができませんでした（実際にはsvnによって16進数の出力は表示されませんでした）が、このコマンドで結果を確認して修正できました。
LC_ALL=C svn add probealign
一般的に、コマンドの前にLC_ALL = Cを付けると、問題のあるファイルを見ることができます...そして、多くの\ x72のもの（明らかに利用できないかもしれない）を貼り付けるよりもずっと簡単です。
私の場合、次のように〜/ .Subversion/configに設定がありましたlog-encoding = ...
コメントは機能しました。
詳細については、コミット時にこのエラーが発生しましたnative encoding to 'UTF-8'windowsクライアント亀svn、
リポジトリのURLが次の場合：
リポジトリのURLを変更しました：
svn：//x.x.x.x/myrepos
そして今、すべてが完璧です。
この情報は一部の人に役立つと思います。