- 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/
- 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からとかまるで使い物にならんな
- 233 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 02:49:11.61 ]
- ちなみにこのスレッドの dat ファイルのサイズは UTF-8 で 113564 bytes だけど、
UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。
日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・
- 234 名前：デフォルトの名無しさん [2011/02/26(土) 02:58:37.03 ]
- GC付きのスイーツな言語処理系しか触ったことなくて、
文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。
ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ
>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよｗｗ
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよｗｗｗ
- 235 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:06:04.80 ]
- >>234
何でこんな簡単な話を理解出来ない振りをするのか分からんけど、
1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?
それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・
- 236 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:08:47.02 ]
- 5. 元データが CJK 以外の場合だとどうなると思う?
- 237 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:13:01.59 ]
- そもそも、utf-8 vs utf-16 じゃなくて utf-8 or utf-32 vs utf-16 という
話だったと思うんだが。
utf-8 : utf-16 = 1:1.1〜2
utf-16 : utf-32 = 1:1.9〜2
つまり、utf-8とutf-16の効率の差よりも、utf-16とutf-32の差のほうが大きい。
utf-8 < utf-16 << utf-32
utf-8 と utf-16 の差をみてutf-16が非効率だと言うなら、utf-32はもっと
使いものにならない。
- 238 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:16:53.52 ]
- >>237
>>224
ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ
- 239 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:18:52.01 ]
- >>238
utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。
- 240 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:20:38.04 ]
- 横からごめんよ。
よく分からんが、ここで争ってる文字コードは、どこで使う文字コード？
バージョン管理システム内だけで使う文字コードじゃないの？
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話？
- 241 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:21:53.26 ]
- >>240
なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。
- 242 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:23:17.21 ]
- >>239
俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。
UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。
- 243 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:05.29 ]
- >>240
>バージョン管理システム内だけで使う文字コードじゃないの？
つ >>164
- 244 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:40.70 ]
- >>242
この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。
- 245 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:56.41 ]
- >>241
ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか？
- 246 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:28:47.22 ]
- >>244
効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙
- 247 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:29:23.71 ]
- >>243
あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。
- 248 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:30:07.68 ]
- >>247
そう、ぶっちゃけどうでも良いのです。
- 249 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:30:08.18 ]
- つまり、ファイル名をunicodeで扱うかバイト列で扱うかという話に、
何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。
- 250 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:32:09.41 ]
- >>249
そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。
- 251 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:32:49.71 ]
- >>246
効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8
効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。
- 252 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:36:34.42 ]
- ファイル名なんて、システム依存なんだから、
文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて？
- 253 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:39:34.62 ]
- >>251
結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ
- 254 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 04:02:39.82 ]
- utf8もutf16もutf32もサロゲートペア使って表せる範囲は全て同じでしょ？
基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの？
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…？
あぁ、結合文字とかも考えると、もっとめんどくさいのか…
- 255 名前：デフォルトの名無しさん [2011/02/26(土) 06:50:22.82 ]
- utf16で盛り上がっているようですが、NTFSはutf16ではありません。ucs-2です
- 256 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 06:58:56.83 ]
- 何その主張？
utf16じゃなくてutf-16とでも言いたいの？
それともucs-2はunicodeじゃないと言いたいの？
- 257 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:28:10.17 ]
- >>256
hibari.2ch.net/test/read.cgi/tech/1251208950/466-468
466 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:48:00
（略）
むしろ正規化されてないのはNTFSの方で、NTFSでは1つのファイル名でNFCとNFDの混在すら可能。
Windowsの日本語IMEはNFCしか吐かないので、NTFSはNFCで正規化されていると誤解されやすい
んだけど、ファイル名としてNFDな文字列やNFCとNFDが混在した文字列を指定した場合に、NTFS
で保存されるファイル名がNFCに正規化されるような事はない。（これは実際に試せば分かる）
（略）
467 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:57:34
NTFSのそれは (WCHAR)0 を含まない WCHAR列に過ぎないんじゃなかったっけ。
と思ったけど大文字小文字の話が合った。
468 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 22:05:47
WCHARも16ビット、32ビットあって単純じゃないのよね。
NTFSも本当にUTF-16なのか？という疑問もあるらしいし。
jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
- 258 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:30:25.22 ]
- >>256
hibari.2ch.net/test/read.cgi/tech/1251208950/472
472 名前：デフォルトの名無しさん [sage]： 2010/11/28(日) 03:40:53
>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。
- 259 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:31:18.33 ]
- >>257
つ UTF-16 == UCS/Unicode Transformation Format 16
- 260 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:19:28.28 ]
- 内部コードがUTF-いくつなんてどうでもいいだろ。
外から見て差が出るところを話そうぜ……。
- 261 名前：デフォルトの名無しさん [2011/02/26(土) 10:30:56.66 ]
- >>260
うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの？
- 262 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:34:13.89 ]
- bzrのアンチ活動とか不毛すぎるだろ……
- 263 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:37:46.68 ]
- >>262
svn/hgはメッセージ日本語化されているよ
- 264 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:41:05.75 ]
- 自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが
日本語化されていると嬉しいかもしれんなぁ。
- 265 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:55:44.74 ]
- >264
素人がコンソールで使うわけ無いだろ。GUI必須。
- 266 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:55:58.34 ]
- どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
- 267 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 11:13:32.83 ]
- >>266
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
- 268 名前：methane mailto:sage [2011/02/26(土) 12:12:01.68 ]
- >>261
そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
- 269 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 12:42:29.67 ]
- >>268
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？
- 270 名前：methane mailto:sage [2011/02/26(土) 15:15:05.28 ]
- >>269
前者は何とかする予定。
後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
- 271 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 15:23:25.20 ]
- >>270
ということは、bzrのパッチもLinuxではロケール依存なのですね？
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？
- 272 名前：methane mailto:sage [2011/02/26(土) 15:37:40.65 ]
- >>271
何処をどう読めばそうなるんだろう…？
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
- 273 名前：methane mailto:sage [2011/02/26(土) 15:38:21.18 ]
- あ、間違えた。
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
- 274 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 15:42:10.39 ]
- bzrのcmd.exeの標準出力はCP932だよね？
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか？
- 275 名前：methane mailto:sage [2011/02/26(土) 15:46:43.42 ]
- >>274
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
|
 |
