- 1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ]
- バージョン管理システムについて語りましょう
●過去スレ
バージョン管理システムについて語るスレ
pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
hibari.2ch.net/test/read.cgi/tech/1283780922/
- 132 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:20:26 ]
- >>130
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
- 133 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:35:28 ]
- qa.debian.org/popcon-graph.php?packages=bzr,git-core,mercurial,subversion&show_installed=on&want_legend=on&from_date=2008-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
- 134 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:49:06 ]
- >>133
一面ではあると思うが参考になったthx。
- 135 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 22:40:17 ]
- 大事なのは、
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
- 136 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 13:50:37.67 ]
- 最近、
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
- 137 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 14:50:33.54 ]
- >>136
文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
- 138 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:47:16.08 ]
- >>137
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が？前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
- 139 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:54:28.95 ]
- Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも
対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
- 140 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:56:36.88 ]
- そりゃ"Double Byte"が3バイト以上だったりしたら困るわな
- 141 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:04:56.51 ]
- 2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・
- 142 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:17:51.15 ]
- >>141
DBCS=MBCSだからCP932用
UTF-16とは関係ない
- 143 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:36:34.15 ]
- UTF-16でサロゲートペア対応だから2byteじゃねーし。
- 144 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 17:29:00.69 ]
- >>142
あー、ごめん、Unicode策定してた連中に言ったつもりだった。
- 145 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 18:04:01.31 ]
- ん？
- 146 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 19:37:32.05 ]
- Windows対応アプリを作る場合は、APIコールの度に毎回UTF-8→UTF-16変換してW版APIを呼ぶのが正道なんだけど
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
- 147 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 23:20:04.23 ]
- >>141
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
- 148 名前：147 mailto:sage [2011/02/23(水) 23:21:23.77 ]
- UTF-16というか、UTF-8以外のUnicode表現。UTF-16決め打ちじゃなくて
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
- 149 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:28:17.70 ]
- 文字としては、さすがにUCS-4で足りるだろうから
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
- 150 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:34:29.78 ]
- >>149
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
- 151 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:36:42.45 ]
- >>150
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
- 152 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:42:06.92 ]
- Javaって今は内部UTF-16でインターフェースは好きにできる感じじゃなかったっけ。
WindowsはUTF-16固定？
- 153 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:46:12.23 ]
- 普通は内部文字コードは UCS4 じゃないの
UTF-16 は負の遺産という認識だったけど
- 154 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:15.38 ]
- UTF-16はサロゲートペアが気持ち悪いのでちょっと・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
- 155 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:40.00 ]
- つうか、後顧の憂いを残さない為には、内外共にUTF-8にしておくのがベストなんじゃ？
- 156 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:54.49 ]
- >>153
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
- 157 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:04.46 ]
- >>155
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
- 158 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:24.00 ]
- >>155
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
- 159 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:55.00 ]
- 内部コードを何にするかが、バージョン管理システムにどう影響するんだ？
いい加減スレ違いだからUnicodeスレに行け。
- 160 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:53:13.04 ]
- ってか、こんな問題の関わりたくないからファイル名はバイナリだ、とかいう割り切りになってんだろうね。
- 161 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:54:28.69 ]
- >>160
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
- 162 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:57:10.63 ]
- >>156
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
- 163 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:13:29.48 ]
- プログラム用のバージョン管理システムが扱う文字の範囲なんて殆ど ascii の範疇なんだから、
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
- 164 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:16:13.76 ]
- 保存用はそりゃUTF-8だろ。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
- 165 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:26:42.61 ]
- 元々はWindowsでファイル名が化ける云々…というのが発端で、
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
- 166 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:33:43.11 ]
- >>165
Windows に限定した話題なら、Unicode APIを使え、でFAだろ。
内部コーディングにUTF-8を使おうがUTF-32を使おうが、Unicode APIを
呼ぶときにUTF-16に変換すれば良い。
Javaが内部ではUTF-16でファイル名を扱ってても、Linuxでファイル名を
指定するときはUTF-8にエンコードしてシステムコール呼ぶのと一緒。
- 167 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 07:25:35.98 ]
- >>166
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
- 168 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 07:56:03.02 ]
- >>167
内部エンコーディングの意味わかってる？
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
- 169 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:05:16.70 ]
- >>168
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね？
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね？
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね？
- 170 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:11:27.04 ]
- >>169
そこがパフォーマンス上ボトルネックになるとでも思っているのか…
- 171 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:18:17.40 ]
- >>170
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ？
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの？
- 172 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:33:17.66 ]
- >>171
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
- 173 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:39:29.22 ]
- >>172
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
３２ビットOSでは動かなくなるよ？
- 174 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:45:24.40 ]
- >>173
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの？
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん？
- 175 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:50:59.41 ]
- >>174
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
- 176 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 09:03:22.14 ]
- >>175
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
- 177 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 09:39:03.80 ]
- >>176
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
- 178 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:03:21.47 ]
- >>177
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
- 179 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:23:05.55 ]
- >>178
うん、bzrの設計はおかしい。
2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
- 180 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:35:36.51 ]
- >>179
> 2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
> Linuxのutf-8ロケールも実用的になっていた。
意味不明。UTF-16 は Unicode のほとんどの文字集合を表現可能で、
UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
さらに言うと、bzrはPythonの unicode 型を使っているだけで、Pythonは
UTF-16とUTF-32を切り替え可能。bzrはPythonの内部エンコーディングに
依存してないし、リポジトリフォーマットではUTF-8を使ってる。
Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
> Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
> 知らなかったとしか思えない。
bzr 開発してるのは Ubuntu Linux の開発してる Canonical で、
少なくともお前よりは Linux の多言語対応について判ってると思うぞ。
- 181 名前：180 mailto:sage [2011/02/25(金) 10:37:41.52 ]
- >UTF-16 は Unicode のほとんどの文字集合を表現可能で、
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の（まだ文字が割り当てられていないコードを含む）ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
- 182 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:38:27.52 ]
- >>180
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
- 183 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:38:56.90 ]
- bzrはどの分散管理よりもマルチ環境で使える
これが全て
他のは日本語環境だと使い物にならない
- 184 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:40:51.98 ]
- そっか。じゃあ俺は Git を使うわ。問題が起きた事無いし。
- 185 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:41:55.69 ]
- 例えばSubversionの場合、
WindowsではUTF-16に変換してUnicode APIを呼ぶ（リポジトリ内部はUTF-8？）
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな？
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない？
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
- 186 名前：180 mailto:sage [2011/02/25(金) 10:49:26.64 ]
- >>185
subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
- 187 名前：180 mailto:sage [2011/02/25(金) 10:50:37.47 ]
- >>182
Unicodeに統一したいの？したくないの？
まったく意味が判らないよ。
- 188 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 11:34:29.81 ]
- ファイル名なんかよりもコミットログ、特にコミットユーザ名が一番重要。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
- 189 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 11:50:50.34 ]
- >>186
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では？
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな？
- 190 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 12:20:48.99 ]
- >>188
全部大事
全部満たしてるのがbzrだけ
- 191 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 12:27:11.43 ]
- >>190
日本人の人名で普通に使われている文字がbzrでは使えないよね？
- 192 名前：methane mailto:sage [2011/02/25(金) 12:40:06.97 ]
- >>191
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
- 193 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 13:25:59.99 ]
- でも・・・正解が欲しいよ・・・ママン・・・
- 194 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 13:43:27.41 ]
- そんなものを求めたら宗教戦争に巻き込まれるだけだと思うぞ
- 195 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 14:51:51.55 ]
- いあ、add時のプラットフォームとエンコーディングをメタ情報に持った上でファイル名自体はバイナリとして保存、
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
- 196 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 14:54:01.19 ]
- >>195
よう、いいだしっぺ
- 197 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:17:44.23 ]
- もうMIMEエンコードして保持しとけよ
- 198 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:17:45.41 ]
- >>195
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの？
- 199 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:21:00.63 ]
- >>198
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか？
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
- 200 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:29:57.73 ]
- >>197
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
- 201 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:33:31.64 ]
- >>199
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
- 202 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:38:53.66 ]
- >>201
Eclipseで使えないと困っちゃうんだよねぇ・・・
- 203 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:50:04.22 ]
- >>201
それってUTF-8対応したCygwinってやつ？
てことは、WindowsでもCygwinなら化けない？
- 204 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 17:15:40.44 ]
- >>203
そうだよ、EUC-JPのファイル名もチェックアウトできるよ
- 205 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 18:45:30.52 ]
- >>180
> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが？
- 206 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 19:21:43.99 ]
- >>201
NTFSがUTF-16なのにどこで保存してるんだ？
セカンドストリーム？
- 207 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 22:31:47.81 ]
- なんか Cygwin についてごっちゃになってるっぽいので整理。
- Cygwin は 1.7 から UTF-8 Cygwin と同じような対応が入ってロケール設定がファイル名(の変換)に効くようになった。
- LANG=ja_JP.EUC-JP するとプログラムから見た場合にファイル名が EUC-JP になってるように見える。
プログラム内で EUC-JP のファイル名渡すと Cygwin API layer で UTF-16 に変換されて Wide API 経由でアクセスされる。
- Windows のファイルシステムで許可されない文字(例えば : とか)は Unicode のプライベートエリアの文字に変換される。
Cygwin 上で見る場合は逆変換されるので普通に見える。
- 208 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 23:10:55.47 ]
- Mercurialのファイル名問題のほんとの理由は、コア開発者の中に、
非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。
- 209 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 23:34:44.37 ]
- >>207
まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑
- 210 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:32:46.22 ]
- >>187
Unicode と言ったら、今は UTF-8 か UTF-32
- 211 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:39:59.28 ]
- >>210
お前の頭の中だけな。
- 212 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:41:32.04 ]
- Unicode が俺の頭の中にあったとは！
でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。
- 213 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:49:19.48 ]
- >>212
WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。
- 214 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:50:59.24 ]
- >>213
Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ
- 215 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 00:55:30.81 ]
- UTF-32（笑）
- 216 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:04:09.03 ]
- >>214
Servlet って Java か？
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。
っていうか、入出力って、外部エンコーディングの話してたの？
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの？
それとも内部エンコーディングっていう単語の意味がわからなかったの？
- 217 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:07:07.26 ]
- >>216
Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ
- 218 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:10:43.62 ]
- >>217
なんで？UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。
- 219 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:15:24.95 ]
- >>218
何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。
今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・
- 220 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:40:59.65 ]
- >>219
文字の符号数が固定でなくても、符号が固定長なのは処理の楽さに影響するよ。
UTF-8を処理する場合は、複数のバイト列から符号位置（序数）をデコードしたあと、
複数の序数を組み合わせて1つの文字を作る。
UTF-16やUTF-32を処理する場合は、16bit/32bitで直接符号位置（序数）が入っているから、
複数の序数を組み合わせて1つの文字を作るだけ。
UTF-8に対してUTF-16は、ASCII文字が大半を占めるときにメモリ効率が下がるという
デメリットと、処理が軽くなるというメリットがある。
ただし、CJKでは下がらないもしくは効率がよくなるケースもある。
これが UTF-16 に対する UTF-32 になると、ほとんどすべてのケースでメモリ効率が
2倍近く悪くなる上に、サロゲートペアの処理は無くなるものの、それ以外の結合文字の
問題はなくならないから処理はほとんど軽くならない。
20世紀に規格が決まったJavaだけでなく、2002年の.NET、2005年のQt4もUTF-16を
選んでいるのは、それなりにメリットがあるから。
- 221 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 01:49:29.33 ]
- >>220
それは今更 UTF-16 を使う理由にはならないよね
何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?
- 222 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:01:08.43 ]
- ご家庭用パソコンにメモリ4GBとかHDD2TBとかいう時代にメモリ効率はないわ〜
文字列が可変長なんだから、文字も可変長になっててどこがいけないのか？
UTF-8マンセー！
- 223 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:01:33.18 ]
- >>221
サロゲートペアを考慮する必要があるケースって、文字単位で処理をしたい
場合だろうけど、UTF-32にしたって結合文字や異字体セレクタを扱う必要が
あるから、サロゲートペアの処理が入っても複雑さは殆ど変わらない。
もともと内部エンコーディングの話だからバイトオーダーの違いは無視できる。
CJKの文字列の中でも数字やアルファベットが多数含まれているが、
UTF-8だと3バイトでUTF-16だと2バイトで済む文字も多数あるので、
CJKでは容量のオーバーヘッドは充分小さい。
そして、UTF-16だとほとんどの文字が2バイトで最悪4バイトなのに対して、
UTF-32だと全部の文字が4バイトなので、2倍近くに容量が膨らむ。
UTF-16は過去の技術じゃない。
あと、なんで内部エンコーディングにそんなに拘るの？
もし bzr を dis るネタにしたいのであれば、FedoraでもUbuntuでもDebianでも
PythonがunicodeをUTF-32で扱ってるから、完全に筋違いだよ？
むしろ、そういった環境で長いファイル名をたくさん使うとメモリ効率が
悪いってdisるべき。
- 224 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:03:50.56 ]
- 「UTF-16 は UTF-8 に比べてここが良いんですよ！」
「え、UTF-8 の方が良い部分がある? いやいや UTF-16 だって UTF-32 に比べたらマシですよ」
「UTF-16 は UTF-32 に比べたらここが良いんですよ！」
「え、UTF-32 の方が良い部分がある? いやいや UTF-16 だって UTF-8 に比べたらマシですよ」
- 225 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:07:14.76 ]
- 肝心の UTF-16 は中途半端なだけで何のメリットも無くて残念
- 226 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:12:39.15 ]
- >>222
俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。
practical-scheme.net/gauche/memo-str-j.html
- 227 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:20:15.47 ]
- >>224
俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。
- 228 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:22:47.15 ]
- いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。
CJKの当事者としてもうちょっと勉強しようぜ。
- 229 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:22:50.71 ]
- >>227
拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ
- 230 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:26:01.13 ]
- >>228
『1コードポイントは固定長』という便利な表現をこのスレで学んだからな
- 231 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:45:02.44 ]
- とりあえずUTF-8なCygwinなら化けないようなので、
hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ？ そうでもない？
IDEからCygwinのコマンド使ってもらえばオールオッケー？
- 232 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:46:54.04 ]
- cygwinからとかまるで使い物にならんな
|
 |
