fix-utf8 改造
INADA Naoki
fixutf8 拡張が SetConsoleOutputCP を使ってcpを変更することで
utf-8を表示しようとしているのですが、WriteConsleWを使って直接
Unicode文字列を出力したほうが綺麗なんじゃないかと思って、branch を
作ってみました。
http://bitbucket.org/methane/hg-fixutf8-jp/
私は普段 Linux で bzr を使っているので、あまり Windows で hg を使う
ことがありません。軽くテストはしたのですが、まだ pull request を出すほど
自信がありません。
fixutf8 ユーザーの方がおられましたら、 cp932の範囲内の文字と範囲外の
文字が混じったファイル名を add したりlog -v したりして問題がおきないか
試してみていただけないでしょうか？
問題が無いようでしたら pull request を出します。
--
Naoki INADA <songof...@gmail.com>
フジワラ
フジワラです。
euc-jp@UNIX, cp932@Windows, utf-8@Mac, iso-2022-jp@mail などと
文字コードマニアな日本ってどーよ？(笑)などと恨みつらみの蓄積する中、
fixutf8 は試そう試そうと思いつつ手付かずでしたが、
これを機会にちょっと試してみようと思います。
プログラマとしては日本語ファイル名なんて使う機会も必要が無いのですが、
業務上日本語ファイルをリポジトリに放り込む必要がある場合って、
確かに少なくないんですよねぇ。
そういう時、これまでは有る文字コードで入れちゃうと、他のプラットフォームでは
取り出せなかったので、結構残念な思いをしておりました。
＃ 特に cp932 って従来の文字列操作関数と相性が悪いですよねぇ(笑)
ただし、今週一杯は 7 月頭の Mercurial 次版リリースに向けて
翻訳系の作業をバタバタとやってしまわないとならないので、
済みませんが私自身の試用は今週末以降になりそうです orz
kuy
コダマです。
日本語関連の問題に取り組んでおられる方がいて心強いです(笑)
早速試してみたのですが、以下のエラーが出てしまいました：
C:\work\これはリポジトリです>hg init
Traceback (most recent call last):
File "hg", line 38, in <module>
File "mercurial\dispatch.pyc", line 16, in run
File "mercurial\dispatch.pyc", line 27, in dispatch
File "mercurial\dispatch.pyc", line 123, in _runcatch
File "mercurial\ui.pyc", line 306, in warn
File "mercurial\extensions.pyc", line 115, in wrap
File "C:\work\hg-fixutf8-jp\fixutf8.py", line 141, in f
win32helper.rawprint(h, arg)
File "C:\work\hg-fixutf8-jp\win32helper.py", line 82, in rawprint
u = s.decode('utf-8')
File "encodings\utf_8.pyc", line 16, in decode
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in
position 85: ordinal not in range(128)
ただ、同様のエラーがオリジナルの fixutf8 を使っても出てしまうので稲田さんの fixutf8 に
対するレポートではないかもしれませんが・・・。
それともう一つ問題がありまして、set LANG=ja で環境変数を設定すると HG の出力が日本語になりますが、
この状態で "hg version" や "hg help" といったコマンドですらエラーで動かなくなってしまいます。
C:\work>set LANG=ja
C:\work>hg version
Traceback (most recent call last):
File "hg", line 38, in <module>
File "mercurial\dispatch.pyc", line 16, in run
File "mercurial\dispatch.pyc", line 27, in dispatch
File "mercurial\dispatch.pyc", line 144, in _runcatch
File "mercurial\ui.pyc", line 306, in warn
File "mercurial\extensions.pyc", line 115, in wrap
File "C:\work\hg-fixutf8-jp\fixutf8.py", line 141, in f
win32helper.rawprint(h, arg)
File "C:\work\hg-fixutf8-jp\win32helper.py", line 82, in rawprint
u = s.decode('utf-8')
File "encodings\utf_8.pyc", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode byte 0x97 in position 3:
unexpected code byte
ところが、この記事
http://witten-note.blogspot.com/2009/07/fixutf8.html
にある通り、HGENCODING 環境変数を utf-8 に設定したところ、"hg version" については
エラーが出なくなりました。
が、依然として "hg init" などはエラーが出てしまいます。
環境は Windows XP SP3 32bit (英語版を日本語ロケールで使用)、Mercurial 1.3、
fixutf8 はどちらも tip リビジョンです。
まだあまり突っ込んだ調査はしていないのですが、何か心当たりはございますでしょうか？
--
Yuki KODAMA
INADA Naoki
手元で少し試してみたのですが、いろいろな部分でダメそうですね。
やっぱり bzr の方が素性が良い(ファイル名をUnicodeとして扱っている)から日本語対応楽だなぁ・・・
> それともう一つ問題がありまして、set LANG=ja で環境変数を設定すると HG の出力が日本語になりますが、
> この状態で "hg version" や "hg help" といったコマンドですらエラーで動かなくなってしまいます。
>
> エラーが出なくなりました。
1. 日本語のヘルプメッセージを utf-8以外にして出力しようとする(多分cp932)
2. hg-fixutf8 がそれを utf-8 でデコードしようとする !! エラー
となっているんだと思います。
decodeに失敗したらそのままWriteFile()するように修正してみたので、pullして再挑戦していただけますか？
> が、依然として "hg init" などはエラーが出てしまいます。
> 環境は Windows XP SP3 32bit (英語版を日本語ロケールで使用)、Mercurial 1.3、
> fixutf8 はどちらも tip リビジョンです。
>
> まだあまり突っ込んだ調査はしていないのですが、何か心当たりはございますでしょうか？
ファイル名を扱うように誤魔化しているんですが、今回のバージョンアップでラップしていないapiを
mercurialが使っている可能性がありますね。
INADA Naoki
> ファイル名を扱うように誤魔化しているんですが、今回のバージョンアップでラップしていないapiを
> mercurialが使っている可能性がありますね。
こちらの手元では init に成功したのですが、試してみていただけますか？
ちなみに、TortoiseHG のシェル拡張は、Windowsの非Unicode系APIを使っている部分がありますね。
全部Unicode系APIにすると、fixutf8との相性がよくなると思います。(fixutf8を導入していない場合も、
Windowsが勝手にUnicodeからcodepageへの変換をしてくれるので問題にはなりません)
Yuki KODAMA
今やってみたところこちらでも "hg init" に成功しました！
ありがとうございます。一歩前進ですね。
次に "hg add" などのコマンドをやってみたところ
C:\work\これはリポジトリです。>hg add 日本語のファイル.txt
中止: リポジトリ 'C:\work\これはリポジトリです。' が見つかりません!
C:\work\これはリポジトリです。>hg add EnglishFile.txt
中止: リポジトリ 'C:\work\これはリポジトリです。' が見つかりません!
とエラーになりました。追加するファイルに関係ないので、
どうやらカレントディレクトリをうまく認識できていないようですね。
> ちなみに、TortoiseHG のシェル拡張は、Windowsの非Unicode系APIを使っている部分がありますね。
> 全部Unicode系APIにすると、fixutf8との相性がよくなると思います。(fixutf8を導入していない場合も、
> Windowsが勝手にUnicodeからcodepageへの変換をしてくれるので問題にはなりません)
根本的な解決をしたわけではないので今一度精査してみます。
シェル拡張の Unicode 化については担当の Adrian からもOKもらってますので。
> hg-fixutf8はいろいろなファイルシステムにアクセスするapiをラップして、cp932の代わりにutf-8で
> ファイル名を扱うように誤魔化しているんですが、今回のバージョンアップでラップしていないapiを
> mercurialが使っている可能性がありますね。
となると本家に API をちゃんと使ってもらうようパッチ送らないとですね。
> やっぱり bzr の方が素性が良い(ファイル名をUnicodeとして扱っている)から日本語対応楽だなぁ・・・
さすがにこれから HG が大幅な設計変更をすることは考えにくいですよね・・・。
HG は使いやすくていいんですけどねぇ。
--
Yuki KODAMA
2009/7/5 INADA Naoki <songof...@gmail.com>:
INADA Naoki
かなり根本的な問題でした。
hg-fixutf8 は mercurial.dispatch._dispatch を wrap しているんですが、
extension が load されるのって _dispatch の中なんですよね・・・
wrapするのが間に合わなくて、cp932のパスでリポジトリのディレクトリが指定されてしまい、
その後 utf-8 に wrap したバージョンの os.path.exists() してもそんなディレクトリ無いって
なってしまってます。
# 前の mercurial は extnsion の読み込みがもっと手前だったんだろうか・・・
とりあえず、wrap済み関数が入力をutf-8でのdecodeに失敗したときはmbcsでdecodeする
ようにしてみました。
もともと強引なhg-fixutf8がさらに凶暴になりましたが（汗
またpullして試してみてください。
>> やっぱり bzr の方が素性が良い(ファイル名をUnicodeとして扱っている)から日本語対応楽だなぁ・・・
>
> さすがにこれから HG が大幅な設計変更をすることは考えにくいですよね・・・。
> HG は使いやすくていいんですけどねぇ。
bzrもコマンド体系はhgやsvnと似ていて使いやすいですよ。（というかgitが特殊すぎ）
現時点では、GUI等の周辺ツールがパスをUnicodeとして扱ってない部分があったりしてパッチを
送りつけまくっている状況です。でもbzr本体で修正が必要な場合はきちんと本体が修正してくれるので、
hgよりも場当たり的じゃない本質的な修正ができるし、パッチの作りがい・送りがいがあります(笑)
bzrはgitやhgに比べて出遅れていた感があり、PythonのDVCS選定でもhgに負けてしまいましたが、
UbuntuのCanonicalがバックについてることもあってかなりの速度で開発が進んでいます。
あと一年も待たないうちに、胸を張って一般人にお勧めできる状態になるかなーと期待しています。
--
Naoki INADA <songof...@gmail.com>
Yuki KODAMA
ありがとうございます。
最初に "hg init" を試したところ以下のトレースバックが出ました：
C:\work\これはリポジトリです。>hg init
** 障害詳細を http://mercurial.selenic.com/bts に報告してください
** ないし merc...@selenic.com に報告してください
** Mercurial - 分散構成管理(バージョン 1.3)
** 読み込み済みエクステンション: extdiff, fixutf8
File "hg", line 38, in <module>
File "mercurial\dispatch.pyc", line 16, in run
File "mercurial\dispatch.pyc", line 27, in dispatch
File "mercurial\dispatch.pyc", line 449, in _dispatch
File "mercurial\dispatch.pyc", line 317, in runcommand
File "mercurial\dispatch.pyc", line 501, in _runcommand
File "mercurial\dispatch.pyc", line 454, in checkargs
File "mercurial\dispatch.pyc", line 448, in <lambda>
File "mercurial\util.pyc", line 370, in check
File "mercurial\commands.pyc", line 1916, in init
File "mercurial\hg.pyc", line 63, in repository
File "mercurial\hg.pyc", line 48, in _lookup
File "mercurial\hg.pyc", line 18, in _local
return fromunicode(orig(*tounicode(args), **kargs))
File "ntpath.pyc", line 286, in isfile
AttributeError: 'function' object has no attribute 'S_ISREG'
英語ロケールでやっても同じエラーでした。
ちなみに "hg version" は問題なく動いています。
念のため 079b6ec56d6f に戻して hg init してみたところ動きました。
> bzrもコマンド体系はhgやsvnと似ていて使いやすいですよ。（というかgitが特殊すぎ）
そうなんですか。ちょっと bzr もいじってみようかな(笑)
> 現時点では、GUI等の周辺ツールがパスをUnicodeとして扱ってない部分があったりしてパッチを
> 送りつけまくっている状況です。でもbzr本体で修正が必要な場合はきちんと本体が修正してくれるので、
> hgよりも場当たり的じゃない本質的な修正ができるし、パッチの作りがい・送りがいがあります(笑)
全ダイアログの HG とのやり取り部分をひたすらチェックする
「一人 Unicode スプリント」の結果、40箇所以上ありましたよ・・・
> bzrはgitやhgに比べて出遅れていた感があり、PythonのDVCS選定でもhgに負けてしまいましたが、
> UbuntuのCanonicalがバックについてることもあってかなりの速度で開発が進んでいます。
> あと一年も待たないうちに、胸を張って一般人にお勧めできる状態になるかなーと期待しています。
bzr は(サイトのレスポンスが悪いけど) 良く出来てる Launchpad がありますしね。
最近は異なるリポジトリでも透過的に扱えるツールの開発も進んでいることもあって、
そのあたりにちょっと期待しています。
INADA Naoki
> File "C:\work\hg-fixutf8-jp\fixutf8.py", line 126, in utf8wrapper
> return fromunicode(orig(*tounicode(args), **kargs))
> File "ntpath.pyc", line 286, in isfile
> AttributeError: 'function' object has no attribute 'S_ISREG'
os.path.stat がモジュールなのに関数と間違えてwrapしてしまっていたのを
修正しました。お手すきの時にまたpullして試してみてください。
でも、こちらでは出ないエラーがなぜ出るんだろう・・・
set LANG=ja しても日本語のメッセージでないし・・・
easy_install したのが間違いだったかな？
> それは楽しみです。bzr の開発力はすごいのはどこかで耳にした気がします。
> bzr は(サイトのレスポンスが悪いけど) 良く出来てる Launchpad がありますしね。
> 最近は異なるリポジトリでも透過的に扱えるツールの開発も進んでいることもあって、
> そのあたりにちょっと期待しています。
Launchpad は、wikiがないのが残念すぎるんですが、その代わりにリポジトリの容量制限が
無かったり、pushするときに（条件がそろえば）勝手に関連リポジトリを探し出して履歴を共有する
形式にしてくれたり、merge requestに対してdiffが見えてコメントが付けられたり、
リポジトリから po ファイルを取り出してWeb上で翻訳できたり、他のプロジェクトから同じ単語を探して
きて翻訳語を提案してくれたり、良い所がいっぱいあります。
bzr はもうすぐ 2.0 が出て、新しい標準のリポジトリフォーマットがデフォルトになるので、
2.0以上が一般的に使われるような状況になったら是非試してみてください。
現時点では、リポジトリフォーマットが乱立していてその互換性問題があるので初心者を
寄せ付けません（笑）
--
Naoki INADA <songof...@gmail.com>
Yuki KODAMA
> os.path.stat がモジュールなのに関数と間違えてwrapしてしまっていたのを
> 修正しました。お手すきの時にまたpullして試してみてください。
すばらしいです！正常に動きました。ありがとうございます。
少しずつ仕組みがわかってきたので私も追っかけてみます。
取り組み始めたのは hg diff の出力に SJIS と UTF-8 の両方が含まれる
場合の対処です。また追って状況を報告したいと思います。
> でも、こちらでは出ないエラーがなぜ出るんだろう・・・
> set LANG=ja しても日本語のメッセージでないし・・・
> easy_install したのが間違いだったかな？
hg version で動かないと言っていたときも英語ロケールなら動作してました。
こちらでも easy_install 版 hg は日本語化されませんねぇ・・・。
> bzr はもうすぐ 2.0 が出て、新しい標準のリポジトリフォーマットがデフォルトになるので、
> 2.0以上が一般的に使われるような状況になったら是非試してみてください。
> 現時点では、リポジトリフォーマットが乱立していてその互換性問題があるので初心者を
> 寄せ付けません（笑）
でもそれだけ開発が活発ということなんですよね。
bzr 2.0 が待ち遠しいです。
フジワラ
全然 fix-utf8 に手を出せてなくて申し訳ありません orz
＃ 週明けには何とか…
On 7月7日, 午前1:14, Yuki KODAMA <yuki.kod...@gmail.com> wrote:
> 取り組み始めたのは hg diff の出力に SJIS と UTF-8 の両方が含まれる
> 場合の対処です。また追って状況を報告したいと思います。
しまうので、Windows 環境での HGENCODING=cp932 とバッティングして、
コミットログとファイル本体内容のコーディングがアレしてしまう、
というケースは私も結構あるのですが、そういったケースでの挙動のこと
でしょうか？
上記のケースでは、一旦 "hg --encoding=EUC-JP" でファイル内容側に
揃えておいて、iconv とかで hg 出力全体を変換、という感じで騙し騙し
使っていますが、なにかと面倒なんですよねぇ。
でも、svn みたいに「メタデータ」とか「content-type」とか持ち出すと、
更に面倒な話になりそうですし…。
> > bzr はもうすぐ 2.0 が出て、新しい標準のリポジトリフォーマットがデフォルトになるので、
> > 2.0以上が一般的に使われるような状況になったら是非試してみてください。
> > 現時点では、リポジトリフォーマットが乱立していてその互換性問題があるので初心者を
> > 寄せ付けません（笑）
>
> リポジトリフォーマットの乱立って・・・(笑)
> でもそれだけ開発が活発ということなんですよね。
> bzr 2.0 が待ち遠しいです。
Python つながりで結構交流があるみたいですが、
舵取りの方針とか路線は結構違うんですね。
Shun-ichi GOTO
On 7月5日, 午後3:07, INADA Naoki <songofaca...@gmail.com> wrote:
> > hg-fixutf8はいろいろなファイルシステムにアクセスするapiをラップして、cp932の代わりにutf-8で
> > ファイル名を扱うように誤魔化しているんですが、今回のバージョンアップでラップしていないapiを
> > mercurialが使っている可能性がありますね。
>
> ためしに os.path.realpath と os.paht.relpath を wrap するようにしてみました。
> こちらの手元では init に成功したのですが、試してみていただけますか？
みあたらないですが。
> ちなみに、TortoiseHG のシェル拡張は、Windowsの非Unicode系APIを使っている部分がありますね。
> 全部Unicode系APIにすると、fixutf8との相性がよくなると思います。(fixutf8を導入していない場合も、
> Windowsが勝手にUnicodeからcodepageへの変換をしてくれるので問題にはなりません)
このMLではhgsubversionの話題がまだ出てないようですが、
相性の話でいうと、fixutf8は hgsubversionと相性もいいと思います。
というのも、hgsubversion は libsvn 経由でアクセスするためutf-8なファイル名を取得し、
hgはファイル名無変換が基本なのでそのままutf-8な名前でストアします。
そのままだとファイルを取り出すした際に、非ASCIIファイル名はバケバケになりなるという
問題があるのですが、utf-8で格納する点はfixutf8と同じなわけであるがゆえに、fixutf8を
有効にしておくとwindowsでもファイル名が正しくとりだせます。やたー！
業務では日本語ファイル名のドキュメントなどもあるしでsubversionを基本にしてるのですが、
自分のPC/NotePCではそれをhg にコンバートして持ち歩き、出先ではhgで修正/コミットを行い、
最後にpushしてメインリポジトリ(subversion)に戻すということを試行中です。
持ち出しに限らず、社内においてもhgsubversionを併用すると hg のもつ rollback, mqによる
管理などができるようになるため、魅力あります。
# いまだにキャンセルしたいようなコミットをしちゃったりしますし。
とはいえ問題がないわけではない(merge/branch/tag/rebase付近)のでまだ万人には勧められ
るとまではいきませんが、注意さえすれば実用になりそうな感触です。
INADA Naoki
> # hg-fixutf8 は使ってますが、hg-fixutf8-jp はまだ手を出していないです
mercurial のバージョンは幾つでしょうか？
古いバージョンのmercurialで、cp932のファイル名しか使わないのであれば、
オリジナルの hg-fixutf8 でも大丈夫だと思います。
>> ためしに os.path.realpath と os.paht.relpath を wrap するようにしてみました。
>> こちらの手元では init に成功したのですが、試してみていただけますか？
>
> os.paht.relpath ってなにものでしょうか？
> みあたらないですが。
間違えました、 os.path.relpath です。
Python 2.6 から導入された関数ですね。Python 2.5 だと wrap しないように修正しないと。。。
--
Naoki INADA <songof...@gmail.com>
Shun-ichi GOTO
>> # hg-fixutf8 は使ってますが、hg-fixutf8-jp はまだ手を出していないです
> mercurial のバージョンは幾つでしょうか？
> 古いバージョンのmercurialで、cp932のファイル名しか使わないのであれば、
> オリジナルの hg-fixutf8 でも大丈夫だと思います。
mercurialは可能な限りcrew (+俺パッチ)です。
日本語以外はまず使わない(えない)です。
でもfixutf8-jpの変更内容も目を通してみます。
>>> ためしに os.path.realpath と os.paht.relpath を wrap するようにしてみました。
>>> こちらの手元では init に成功したのですが、試してみていただけますか？
>>
>> os.paht.relpath ってなにものでしょうか？
>> みあたらないですが。
>
> 間違えました、 os.path.relpath です。
そうだとは思って2.5のlibは探ましたが、2.6からでしたか。
どんどん疎くなってる自分...
> Python 2.6 から導入された関数ですね。Python 2.5 だと wrap しないように修正しないと。。。
wrapnames()にてhasattr()してからwrapしてるのでいまのままで大丈夫ですね。
それはともかく、os.path.relpath()ってどこかで使ってましたか？
それとも単に今後の安全のために入れておいたということでしょうか。
同様のことをしている win32mbcs にもかかわる話でもあるので少々気になります。
--
Shun-ichi GOTO
INADA Naoki
>
> wrapnames()にてhasattr()してからwrapしてるのでいまのままで大丈夫ですね。
お、良かった。
> それはともかく、os.path.relpath()ってどこかで使ってましたか？
> それとも単に今後の安全のために入れておいたということでしょうか。
> 同様のことをしている win32mbcs にもかかわる話でもあるので少々気になります。
いいえ、使っているかどうか調べていません。
もともと、fix-utf8がmercurial1.3で動かない理由の一つがmercurialがos.path.realpath()を
使っていることだと判明して、それを直すときに名前が近いrelpathもついでにwrapして
おいただけです。
その後 os.path の中身を列挙してできる限りの関数をwrapしました。
でも、拡張のロード順の変更とかあって今の方式ではwrapするのが手遅れっぽいので、
hg起動時にhookをかけるようなhg本体へのpatchという形の方がいい気がします。
--
Naoki INADA <songof...@gmail.com>
フジワラ
On 7月7日, 午後2:40, フジワラ <flying.fo...@gmail.com> wrote:
> 全然 fix-utf8 に手を出せてなくて申し訳ありません orz
>
> ＃ 週明けには何とか…
ctypes のモジュール読み込みの失敗で fixutf8 が読み込めません orz
バイナリ版 hg 添付の library.zip を展開したら、見事に ctypes が入っておらず、
fixutf8 の issue 管理を見たら、exe 生成周りで問題があるらしい既出の
障害とのこと。
http://bitbucket.org/stefanrusek/hg-fixutf8/issue/5/ctype-module-not-found
5月時点での最後のコメントによると、crew の夜間ビルドだと動くらしい
のですが、1.3 バイナリ版で駄目ってことは、多分駄目なのかなぁ。
ちなみに、稲田さん／コダマさん／ゴトウさんは、
win ネイティブの Python 環境で hg している、ってことで合ってます？
私は普段は専ら cygwin python で hg なので、win ネイティブの Python って
全然使ったこと無いのですが、やっぱり入れておいた方が良いかなぁ。
何かお勧めのパッケージってあります？
INADA Naoki
コンソール周りはwin32consoleで置き換えられるものの、
GetCommandLineW が無かったり、 GetCurrentDirectoryW どころか
GetCurrentDirectory が無い (GetFullPathName()で代用可能) だったり、
ちょっと厳しそうです。
ていうか、 mercurial.win32 って、Wじゃない CreateFile やら CreateHardLink やら
使ってるんだなぁ・・・。
やっぱり fix-utf8 みたいに拡張モジュールの形ではなくて、mercurialのforkを作って
Unicode対応にしないときちんとした対応は無理そうです。
# bzr-hg に push 機能を追加するほうが早そうだ・・・
> ちなみに、稲田さん／コダマさん／ゴトウさんは、
> win ネイティブの Python 環境で hg している、ってことで合ってます？
はい。
Pythonはposixに依存しないAPIをたくさん持っていて、cygwinのようなposix互換レイヤが
無くても簡単にクロスプラットフォームなプログラムがかけるので便利ですよ。
--
Naoki INADA <songof...@gmail.com>