welcome shalab.net

原因は、システムに入っている aprutil は libiconv にリンクされていないためです。

(´・ω・｀) 手をぬいてインストールしようとしたからだよね。

aprutil の xlate/xlate.c で apr_xlate_open() では configure 実行時に決定されるマクロによって、 apr-iconv か libiconv のどちらかを呼び出すラッパーとして機能しますが、どちらも指定されていないときには、 APR_ENOTIMPL を返す関数となります。
このため、subversion は、UTF-8の内部コードをローケル指定するエンコードに変換することができず、non-ascii な文字を全て ascii printable な文字に置き換えて出力します。
(subversion の 直接の部分は、subversion/libsvn_subr/utf.c ですが、これのxlate_alooc_handle() がapr_xlate_open() を呼びます。 これが APR_ENOTIMPL を返すと、 xlate_handle_node_t の hanlde に NULL を指定します。 xlate_handle_node_t *node -> handle = NULL の状態で呼び出された convert_cstring() は、 最初の if 文 node->handle の 条件にひっかかって、check_non_ascii() で UTF-8 の内部コードをローケルの指定するエンコードに変換できない ということで、文字のエスケープ処理に入ります。この結果文字が化けているように見えるということになります。 (正確には 非ASCII 文字をエスケープ処理した結果 ASCII 文字を出力してるので、文字が化けているように見えている）

問題の影響を考えるに、これはあらゆるiconv の呼び出し つまり、文字コード変換が失敗することを意味するので、 レポジトリの文字コード変換も、影響を受けると考えられるため、（未調査） LANG=C 指定で、文字化けが直ったわーいというのは、少々マズイ気がします。

解決策としては、 apr-util の configure 時に --with-iconv=/usr/local をつけてコンパイルする（これはコンパイル時指定なので、 環境変数とかで変えられません。）。そして、そのコンパイルした apr-util を使用する。

svn の コンパイルは少しめんどくさいので、シェルスクリプトに起こしておきました。

subversion_install.sh 注意：絶対にそのまま実行しないこと

$HOME/tmp/subversion に ソースコードをダウンロードして、コンパイル後 $HOME/local へインストール という動作を APR,APR-UTIL,OpenSSL,scons,serf,subversion に対して行います。完全にやっつけ仕事なので、俺のところでは動く程度クオリティです。 動作確認はこれからします。

(追記：2014/04/11 openssl のバージョンアップに伴い 1.0.1g でコンパイルするように変更 subversion 1.8.8へのバージョンアップ)

今日知りました。PATHの設定は、 .login_conf できます。 ssh でリモート実行するときにPATHの指定とかLANGの指定とかしたいなぁと

# $FreeBSD: src/share/skel/dot.login_conf,v 1.2.2.1 2002/01/05 16:10:01 phantom Exp $
#
# see login.conf(5)
#
#me:\
#       :charset=iso-8859-1:\
#       :lang=de_DE.ISO8859-1:

me:\
        :path=/bin /usr/bin /usr/local/bin ~/local/bin ~/bin:\
        :charset=UTF-8:\
        :lang=ja_JP.UTF-8: