Mercurial ＆ TortoiseHgでの日本語パスと日本語ファイル名対応
Hidetoshi Kamata
Mercurial、 TortoiseHgともに、Windows環境で日本語のパス名と日本語ファイル名には対応できていない状況だと考えている
のですが、StableのRev.9115でShun-ichi GOTOさんが行った修正(win32mbcs)で、対応状況が改善すると考えていい
のでしょうか？改善ではなく、解決するのでしょうか？
また、この修正が含まれるTortoiseHgの次回リリース次期の目安などはあるのでしょうか？
フジワラ
On 9月18日, 午後12:31, Hidetoshi Kamata <hidetoshi.kam...@gmail.com>
wrote:
> Mercurial、 TortoiseHgともに、Windows環境で日本語のパス名と日本語ファイル名には対応できていない状況だと考えている
> のですが、StableのRev.9115でShun-ichi GOTOさんが行った修正(win32mbcs)で、対応状況が改善すると考えていい
> のでしょうか？改善ではなく、解決するのでしょうか？
日本語 Windows 環境で、日本語(cp932 符号化)のファイル名を
制限無く使用することができる
というのがゴール、「解決」の定義は「ゴールに到達」、
「改善」の定義は「道半ば」、という前提で進めます。
Mercurial(hg コマンド)に関しては、この問題を「解決」するためには
win32mbcs エクステンションを使用すればよかったのですが、
1.3 版リリースで win32mbcs が使用できなくなる障害が取り込まれてしまった
ことで、一時的に「解決」できない状況がありました。
しかし、1.3.1 で障害に対処した模様ですので、1.3 以外のリリース版であれば、
win32mbcs エクステンションを有効にすることで、問題は「解決」します。
詳細は「Windowsにてwin32mbcsを有効にして～」のスレッドをご覧ください。
http://groups.google.com/group/mercurial-ja/browse_frm/thread/59c4fe5b7409e509
TortoiseHG に関しては、状況を把握してないので、ご存知の方フォローお願いします。
＃ 主にコダマさんをあてにしてます(笑)
> また、この修正が含まれるTortoiseHgの次回リリース次期の目安などはあるのでしょうか？
これまたコダマさんあたりのフォローをあてにしてます(笑)
ちなみに、「ゴール」の定義にこだわるのは:
ファイル名の内部表現(.hg/store 配下含む)を unicode で統一し、
作業領域 update の際には任意の符号化で取り出せるようにして欲しい
という要望がなかなか本家に取り入れてもらえないもどかしさを感じており、
「日本語ファイル名を使える」＝「ファイル名符号化問題が解決する」が
最終ゴールだよね？というのが少なからぬ利用者の認識であるためなので、
まぁ、適当に、ふ～ん、と流してください(笑)。
Shun-ichi GOTO
ちょうど別メールで藤原さんが『いけると思う』と話したすぐ後で恐縮ですが
TortoiseHg-0.8.2-hg-1.3.1-1444a42f6052.exe を使ってみたところ、最新の
win32mbcs を使っても 0x5c '\' を含むファイル名での問題はまだ解決しきれて
ないようです。 hgtkのどこかで fn.split(os.sep) や fn.replace('\\', '/')の
ような変換が残ってるんだと思いますが、そーすはまだ見切れてません。
同じディレクトリで hg.exe だと問題無いのですが。
なわけで試しに hg crew の win32mbcs.py に対して修正を行ってみると
TortoiseHGでもうまくいったぽいです。修正後の win32mbcs.py を添付して
おきます。また添付の画像はコミット後のthg での log 表示です。
修正の内容は、通常の decode に加え、失敗した場合にさらに努力してみると
いうもの。
(1) win32mbcsが有効になる前に算出された hgroot のように、末尾の 0x5c が
削られた文字列を救ってみる
(とはいえリポジトリパス名の対応はまだ不完全)
(2) string.split() など、正しくない方法でパス分解をしてしまいそれを
'/' で結合したようなファイル名を、'/' から '\\' に戻してみることで
救ってみる。
(これが今回のカンドコロ)
いずれも推測に基づく加工を施すことになるので、ちょっと怪しい面を含んでる
わけですが、なんとなく使えそうなので、人柱希望の人は使ってみて下さい。
うまくいかないケースがあればこのMLで教えて下さい。
既知の問題としては、0x5c で終る漢字ディレクトリ(ex. "～表") に作った
リポジトリはいろいろとまずいです。
--
Shun-ichi GOTO
Yuki KODAMA
>
> フジワラです。
>
> On 9月18日, 午後12:31, Hidetoshi Kamata <hidetoshi.kam...@gmail.com>
> wrote:
>
>> Mercurial、 TortoiseHgともに、Windows環境で日本語のパス名と日本語ファイル名には対応できていない状況だと考えている
>> のですが、StableのRev.9115でShun-ichi GOTOさんが行った修正(win32mbcs)で、対応状況が改善すると考えていい
>> のでしょうか？改善ではなく、解決するのでしょうか？
>
> 「改善」「解決」は、どこをゴールにするかで認識が違ってきてしまいますが:
>
> 日本語 Windows 環境で、日本語(cp932 符号化)のファイル名を
> 制限無く使用することができる
>
> というのがゴール、「解決」の定義は「ゴールに到達」、
> 「改善」の定義は「道半ば」、という前提で進めます。
>
> Mercurial(hg コマンド)に関しては、この問題を「解決」するためには
> win32mbcs エクステンションを使用すればよかったのですが、
> 1.3 版リリースで win32mbcs が使用できなくなる障害が取り込まれてしまった
> ことで、一時的に「解決」できない状況がありました。
>
> しかし、1.3.1 で障害に対処した模様ですので、1.3 以外のリリース版であれば、
> win32mbcs エクステンションを有効にすることで、問題は「解決」します。
>
> 詳細は「Windowsにてwin32mbcsを有効にして～」のスレッドをご覧ください。
>
> http://groups.google.com/group/mercurial-ja/browse_frm/thread/59c4fe5b7409e509
>
> TortoiseHG に関しては、状況を把握してないので、ご存知の方フォローお願いします。
>
> ＃ 主にコダマさんをあてにしてます(笑)
>
>> また、この修正が含まれるTortoiseHgの次回リリース次期の目安などはあるのでしょうか？
>
> これまたコダマさんあたりのフォローをあてにしてます(笑)
結論から言いますと、TortoiseHg が対応する可能性はありますが、
今いっぱいいっぱいなのでその時間を捻出できるかどうかが問題です・・・。
また 0.8 系でのリリースは難しいため11月1日リリースの 0.9 になります。
タイムリミットは約4週間後のコードフリーズ、10月15日です。
もともと TortoiseHg では win32mbcs による回避には対応しない方針だったのですが、
それは当時 (hg 1.3?) 手元で win32mbcs を有効にしても回避できなかったのが原因なので、
まだ試していない hg 1.3.1 でうまくいけば対応を試みます。
ただ、TortoiseHg は徐々に Windows 以外の環境でも使われ始めていまして、
非 Windows 環境では邪魔しないようにしなければならないのが気がかりですね。
やりとしたら win32mbcs 拡張機能がロードされているかどうかで判定します。
> ちなみに、「ゴール」の定義にこだわるのは:
>
> ファイル名の内部表現(.hg/store 配下含む)を unicode で統一し、
> 作業領域 update の際には任意の符号化で取り出せるようにして欲しい
>
> という要望がなかなか本家に取り入れてもらえないもどかしさを感じており、
> 「日本語ファイル名を使える」＝「ファイル名符号化問題が解決する」が
> 最終ゴールだよね？というのが少なからぬ利用者の認識であるためなので、
> まぁ、適当に、ふ～ん、と流してください(笑)。
本当に根本解決してくれないかなーと願っております！ ←願うだけ
--
Yuki KODAMA
INADA Naoki
>>
>> ファイル名の内部表現(.hg/store 配下含む)を unicode で統一し、
>> 作業領域 update の際には任意の符号化で取り出せるようにして欲しい
>>
>> という要望がなかなか本家に取り入れてもらえないもどかしさを感じており、
>> 「日本語ファイル名を使える」＝「ファイル名符号化問題が解決する」が
>> 最終ゴールだよね？というのが少なからぬ利用者の認識であるためなので、
>> まぁ、適当に、ふ～ん、と流してください(笑)。
>
> 本当に根本解決してくれないかなーと願っております！ ←願うだけ
このへんはBazaarが理想的で、内部ではファイル名を全部Unicodeで扱っていて、
リポジトリとの入出力、ファイルシステムとの入出力で変換している（Windowsの場合は
Unicodeファイル名をそのままUnicodeAPIに渡している）んですよね。
現在TortoiseBZRのメンテナンスをしているのですが、GUIもTortoiseBZRも含めて完璧に
Unicodeファイル名を扱えています。
以前 fixutf8 拡張にも手を出してみたんですが、やはり内部でUnicodeを基本にしないと
外部から根本解決するのは難しく、TortoiseHGとの連携も出来ないままで手を離して
しまいました。
根本解決するには本家からforkして、Bazaarのように内部をUnicodeにするしかないかも
しれません。
--
Naoki INADA <songof...@gmail.com>
Shun-ichi GOTO
>
>>> ちなみに、「ゴール」の定義にこだわるのは:
>>>
>>> ファイル名の内部表現(.hg/store 配下含む)を unicode で統一し、
>>> 作業領域 update の際には任意の符号化で取り出せるようにして欲しい
>>>
>>> という要望がなかなか本家に取り入れてもらえないもどかしさを感じており、
>>> 「日本語ファイル名を使える」＝「ファイル名符号化問題が解決する」が
>>> 最終ゴールだよね？というのが少なからぬ利用者の認識であるためなので、
>>> まぁ、適当に、ふ～ん、と流してください(笑)。
>>
>> 本当に根本解決してくれないかなーと願っております！ ←願うだけ
>
> このへんはBazaarが理想的で、内部ではファイル名を全部Unicodeで扱っていて、
> リポジトリとの入出力、ファイルシステムとの入出力で変換している（Windowsの場合は
> Unicodeファイル名をそのままUnicodeAPIに渡している）んですよね。
> 現在TortoiseBZRのメンテナンスをしているのですが、GUIもTortoiseBZRも含めて完璧に
> Unicodeファイル名を扱えています。
このあたりは CVSで学んだことを活かしてSubversion が成功している
事実がありますし、あるべき姿の代表のようになっていますね。
ましてや unix ではよくても Windowsでは raw byte でファイル名を
扱うのは無理があるので。
# ついでにいえばテキストファイルの行末変換の話も、svn のようなやりかた
# が望まれてて、最近火が着いてますし。
ただし、Mattの言い分も若干わからないでもないです。
自分の理解するところの彼の主張の要旨は
(1) 無闇にファイル名変換をしてしまいたくはない。というのも
Unicode にしたからといって全てが解決するわけではないからだ。
(ex. 最近の例では Mac での Unicode NFD 問題)
裏を返せば、やるならばきっちり検討した上で、という意味ではないかと。
(2) ファイル名が変わることによりよく使われるツールチェインが機能しなくなる
のはやだ。
Makefile に記述されるファイル名やinclude のようなソース/スクリプト中の
のファイル名の話。Ant などでは逆に変換して欲しいだろうけど。
これはSCMのファイル名変換に『煩わされる』のを嫌ってのことかと。
実際のところ Matt の主張には反論も多数でてはいますが、単に内部を
Unicode にしようよ！それが正しい道だよ! Windows では困るんだよ！ と説いた
だけでは彼の意見は変わらないと思います。
実際内部をunicode にするとなればかなーりの部分の書き換えが必要そうですし。
逆をいえば、彼が主張するような現状の動作を実現しつつ、希望する人には
ファイル名変換を提供できるような修正デザインを提示できれば採用される
可能性はあるだろうと思ってます。
自分が思い描く方向としては、encoding 情報をリポジトリに付与できるように
して、リポジトリ間のclone ではその情報を伝搬することができるようにして、
そのうえで 内部はUnicode ではなくバイト列(ASCIIだったり変換されたUTF-8
だったり)で処理し、状況に応じて外部(file や ui)との変換のON/OFFが
行なわれるといった方向が良いのではないかなと思ってます。
つまりは大雑把には fixutf8 の本体へのマージ + 切替え + リポジトリ
プロパティみたいな感じ。
--
Shun-ichi GOTO
INADA Naoki
> (1) 無闇にファイル名変換をしてしまいたくはない。というのも
> Unicode にしたからといって全てが解決するわけではないからだ。
> (ex. 最近の例では Mac での Unicode NFD 問題)
> 裏を返せば、やるならばきっちり検討した上で、という意味ではないかと。
=> 相互運用性を確保するには、きちんと正規化の方法を決めてそれを守る。
> (2) ファイル名が変わることによりよく使われるツールチェインが機能しなくなる
> のはやだ。
> Makefile に記述されるファイル名やinclude のようなソース/スクリプト中の
> のファイル名の話。Ant などでは逆に変換して欲しいだろうけど。
> これはSCMのファイル名変換に『煩わされる』のを嫌ってのことかと。
=> Unicodeファイル名に対応していないツールチェインが扱うファイル名に非ASCII
文字を使わない使ってはいけない
> 自分が思い描く方向としては、encoding 情報をリポジトリに付与できるように
> して、リポジトリ間のclone ではその情報を伝搬することができるようにして、
> そのうえで 内部はUnicode ではなくバイト列(ASCIIだったり変換されたUTF-8
> だったり)で処理し、状況に応じて外部(file や ui)との変換のON/OFFが
> 行なわれるといった方向が良いのではないかなと思ってます。
> つまりは大雑把には fixutf8 の本体へのマージ + 切替え + リポジトリ
> プロパティみたいな感じ。
ここら辺、BazaarのデザインはPythonの方向性（Python3から文字列は基本Unicodeに）
とRubyの方向性（文字列はバイト列のまま、エンコーディング情報を付加）の違いに見えて
面白いですね。
# PythonのSCMに選ばれたのがPythonの方向性に反する方という（笑）
--
Naoki INADA <songof...@gmail.com>
Shun-ichi GOTO
> ちょうど別メールで藤原さんが『いけると思う』と話したすぐ後で恐縮ですが
> TortoiseHg-0.8.2-hg-1.3.1-1444a42f6052.exe を使ってみたところ、最新の
> win32mbcs を使っても 0x5c '\' を含むファイル名での問題はまだ解決しきれて
> ないようです。 hgtkのどこかで fn.split(os.sep) や fn.replace('\\', '/')の
> ような変換が残ってるんだと思いますが、そーすはまだ見切れてません。
> 同じディレクトリで hg.exe だと問題無いのですが。
これは TortoiseHg 側のせいではなく、 win32mbcs でのラップ忘れでした。
ついこないだの修正で util.pconvert() をラップしたさいに
「windows.pconvert()はらっぷしていんじゃね？」ということで
対象から外してしまったために util.normpath()の挙動がダメになって
しまってました。
以下の修正で治ります。それを使えば 先ほどのメールと同様、
TortoiseHg でもうまく行きました。念のため新しい版も添付します。
diff -r 22315a285d3b hgext/win32mbcs.py
--- a/hgext/win32mbcs.py Fri Sep 18 15:06:45 2009 +0900
+++ b/hgext/win32mbcs.py Fri Sep 18 20:41:37 2009 +0900
@@ -123,7 +123,7 @@
funcs = '''os.path.join os.path.split os.path.splitext
os.path.splitunc os.path.normpath os.path.normcase os.makedirs
mercurial.util.endswithsep mercurial.util.splitpath mercurial.util.checkcase
- mercurial.util.fspath mercurial.util.pconvert'''
+ mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath'''
# codec and alias names of sjis and big5 to be faked.
problematic_encodings = '''big5 big5-tw csbig5 big5hkscs big5-hkscs
--
Shun-ichi GOTO
Yuki KODAMA
> これは TortoiseHg 側のせいではなく、 win32mbcs でのラップ忘れでした。
> ついこないだの修正で util.pconvert() をラップしたさいに
> 「windows.pconvert()はらっぷしていんじゃね？」ということで
> 対象から外してしまったために util.normpath()の挙動がダメになって
> しまってました。
>
> 以下の修正で治ります。それを使えば 先ほどのメールと同様、
> TortoiseHg でもうまく行きました。念のため新しい版も添付します。
修正ありがとうございます。私の方でも早速試してみますが、
うまくいけば TortoiseHg は特別な対応をせずに済みそうでホッとしています(笑)
TortoiseHg におけるエンコーディング以外の問題としては文字列加工操作
(配列の添字とかによる分割など)を str 型のまま直接やってる部分があります。
現在、こういったコードを行儀良く unicode 型に変換してから加工するように
コツコツを直しています。
--
Yuki KODAMA
Yuki KODAMA
> 2009/9/18 Shun-ichi GOTO <shunic...@gmail.com>:
>> これは TortoiseHg 側のせいではなく、 win32mbcs でのラップ忘れでした。
>> ついこないだの修正で util.pconvert() をラップしたさいに
>> 「windows.pconvert()はらっぷしていんじゃね？」ということで
>> 対象から外してしまったために util.normpath()の挙動がダメになって
>> しまってました。
>>
>> 以下の修正で治ります。それを使えば 先ほどのメールと同様、
>> TortoiseHg でもうまく行きました。念のため新しい版も添付します。
>
> 修正ありがとうございます。私の方でも早速試してみますが、
> うまくいけば TortoiseHg は特別な対応をせずに済みそうでホッとしています(笑)
添付されたwin32mbcsとTortoiseHg 0.8.2で、以前うまくいかなかったリポジトリや
ファイル名を試してみましたが、今のところ問題なく使えています。
ゴトウさんありがとうございます。
逆に全滅なのは右クリックメニューやアイコンオーバーレイのシェル拡張です。
Mercurial 1.3.2 が出ると同時に TortoiseHg 0.8.3 をリリースする予定ですが、
それに間に合うかどうかちょっとわかりません。
またdefaultブランチ(バージョン0.9)でエンコーディング関連の問題がいくつか
見つかりましたので、それについては早々に修正したいと思います。
--
Yuki KODAMA
Hidetoshi Kamata
質問を投げておきながら、返信もせずにすみませんでした。
素早いチェック＆対応を頂き、喜んでおります。
次のリリースで、このディスカッションで加えられた
win32mbcsの修正が取り込まれれば、
Windows環境のみでMercurial＋TortoiseHgを使う分には、
日本語パス、ファイル名も概ね大丈夫だと理解しました。
#リリース前にビルドしてチェックしたいのですが、
#ISMS関係で通常業務外のソフトウェアをインストールするのがしんどいのです…
ところで、以下の件が気になったのですが、
具体的にはどのような問題が起こるのでしょうか？
On 9月20日, 午後12:20, Yuki KODAMA <yuki.kod...@gmail.com> wrote:
> 2009/9/18 Yuki KODAMA <yuki.kod...@gmail.com>:
Yuki KODAMA
> 具体的にはどのような問題が起こるのでしょうか？
>
> On 9月20日, 午後12:20, Yuki KODAMA <yuki.kod...@gmail.com> wrote:
>> 2009/9/18 Yuki KODAMA <yuki.kod...@gmail.com>:
>>
>> 逆に全滅なのは右クリックメニューやアイコンオーバーレイのシェル拡張です。
>> Mercurial 1.3.2 が出ると同時に TortoiseHg 0.8.3 をリリースする予定ですが、
>> それに間に合うかどうかちょっとわかりません。
まずダメ文字を含むファイルにはアイコンオーバーレイが表示されません。
それ以外の日本語ファイルでは正常に表示されます。
加えてダメ文字を含むファイルをエクスプローラの右クリックメニューから
直接操作できません。つまり "View Changelog"、"Add Files"、"Remove Files"、
"Revert Files"、"Annotate Files" のような操作です。
こちらも通常の日本語ファイルであれば機能します。
ただ、これらの操作は右クリックメニュー以外からも可能です。
例えば "View Changelog" や "Annotate Files" はチェンジログビューアを開いて、
そのファイルが変更されたチェンジセットを選択してから、左下のファイル一覧の
右クリックメニュー "file history" または "annotate file" を選択します。
"Add Files"、"Remove Files"、"Revert Files" はステータスダイアログや
コミットダイアログから同等の操作が可能です。
--
Yuki KODAMA
Hidetoshi Kamata
コダマさん。詳しくありがとうございます。
2009年9月24日11:20 Yuki KODAMA yuki....@gmail.com:
> まずダメ文字を含むファイルにはアイコンオーバーレイが表示されません。
> 加えてダメ文字を含むファイルをエクスプローラの右クリックメニューから
> 直接操作できません。つまり "View Changelog"、"Add Files"、"Remove Files"、
> "Revert Files"、"Annotate Files" のような操作です。
私はほとんどの操作をフォルダの右クリックで、
View File Status、View Changelog, HG Commit辺りからやっているので、
個人的にはそんなに問題がなさそうです。
Mercurial 1.3.2 & TortoiseHg 0.8.3 を心待ちにしています。
Hidetoshi Kamata
10月8日付けでTortoiseHg 0.8.3 with Mercurial 1.3.1+7cea12e70129がリリースされていたような
ので、
今まで不具合のあったSJISダメ文字を含むフォルダ及びファイルのチェックをしてみました。
コダマさんも既に把握しているように、
パス又はファイル名にSJISダメ文字を含んでいる場合、
アイコンオーバーレイはNGです。
View File Status、View Changelog, HG Commit辺りからの
リポジトリ操作自体は問題無いようです。
特に新しい情報はありませんが報告まで。
ありがとうございました。
#もちろん、Windows環境のみでの確認です。