- 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/
- 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からとかまるで使い物にならんな
- 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 の範囲では固定長だから処理がし易いと言ってるのと同じ
|
 |
