X

文字コードの種類は何故複数あるのでしょうか？

0178デフォルトの名無しさん
垢版 |
2009/02/23(月) 23:33:42
> 今後は「出典をすべてscanデータで出すべし」という方針に。
> だが、律儀に守っているのは日本と中国ぐらい。。
> 未提出多数とか、「人名だから」出さずじまいとか、出典非明示→取り下げ、とか。
UCSがゴミまみれになるのを防ぐことに一定の効果を上げてるわけだな。いいことだ。
0181デフォルトの名無しさん
垢版 |
2009/03/03(火) 22:09:24
U+1B000がKATAKANA LETTER ARCHAIC E(片仮名「衣」由来のア行の「エ」)になってた。
名前がORIGINAL E(元々の「エ」)からARCHAIC E(古代の「エ」)に変更されてた。
平仮名ヤ行の「え」と違ってBMP外になってしまうけどしょうがないか。
Historic KanaというブロックでU+1B000から256文字分予約されたけど今後変体仮名とか重要な昔の仮名をU+1B001以降にも追加していくつもりなのかな?
0182デフォルトの名無しさん
垢版 |
2009/03/04(水) 00:21:44
256で足りるのｗ？
そこら辺の文字はよく知らないけど512から1024くらいあってもいいような。
0183デフォルトの名無しさん
垢版 |
2009/03/04(水) 00:29:59
変体かなは良く分からないけど、ここのページを見る限り、平仮名だけでも軽く600以上ありそう。
ttp://www10.plala.or.jp/koin/koinhentaigana.html
0184デフォルトの名無しさん
垢版 |
2009/03/04(水) 12:43:59
住基仮名だけなら256で足りるがな。
0185デフォルトの名無しさん
垢版 |
2009/03/05(木) 07:38:01
１バイト目に文字種を表すもんだけいれて後は可変でよろしくやればいいと思った
最低２バイト〜な感じで
0186デフォルトの名無しさん
垢版 |
2009/03/05(木) 17:50:02
欧米人にはそれが理解できんのですよ。

たとえば、”うまれつき目の見えないひと” を想像してみてください。
その人に「海は青い」という事を、いったいどうやって教えればいいのか。
そのひとには、赤も青も黄色も無いんです。色という概念が全く無いんです。
だから理解不可能です。

３次元の世界で生活している我々が４次元の世界を理解できないのと同じく
１文字１バイト圏で生活している欧米人には、１文字が２バイト、３バイトになるのが
理解できんのです。ヤツらにとってマルチバイト文化は４次元の世界なのです。
0188デフォルトの名無しさん
垢版 |
2009/03/05(木) 19:19:15
文字コード総合の次スレはここでござるな？　しからば過去スレを貼り。

【UTF8】文字コード変換【SJIS】
http://pc5.2ch.net/test/read.cgi/tech/1063177450/
文字コード統一スレ 1文字目
http://pc8.2ch.net/test/read.cgi/tech/1109171258/
文字コード総合スレ part2
http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3
http://pc11.2ch.net/test/read.cgi/tech/1180250376/
0190デフォルトの名無しさん
垢版 |
2009/03/05(木) 21:44:14
>>184
たとえば「安」から「あ」へ連続的に変化していく過程の文字の数々にどうやって包摂規準を
設定するのか、とか考えると住基仮名のようなclosed setしかありえない気がする
0191デフォルトの名無しさん
垢版 |
2009/03/07(土) 02:01:46
変体でも「あ」なら「あ」なのだから、「あ」に対して異体字セレクタの対応を決めればいいだけなんじゃね？
256種類まで対応できるんだから、多分足りるでしょ。
足りなきゃ、異体字セレクタの方を増やせばいい。
0193デフォルトの名無しさん
垢版 |
2009/03/07(土) 15:36:34
それよりアラビア文字みたいに前後の文字で字形を変えるのを
サポートする必要があるんじゃないか
0194デフォルトの名無しさん
垢版 |
2009/03/07(土) 19:27:11
・縦書き
・前後の状況で字形を変える必要がある
・異体字セレクタに対応が必要
それなんてモンゴル文字?
0202デフォルトの名無しさん
垢版 |
2009/08/11(火) 15:28:27
　 　　 　 ∧＿∧
　　　　　（ ･∀･ ）つ
　　　　　（　つ　/
　　　　　｜ （⌒）どどど・・・
.　　 　 　 し' 三


　　 　 　 ∧＿∧
　　　 ⊂（ ･∀･ ）
.　　　　 ヽ　⊂　）
　　　　　（⌒） ｜どどどどど・・・・・
　 　 　 　 三 `Ｊ

　　　 メ＼,_　　　　　　　　,メﾞ＼､
　　 .メ′ .ﾞﾞｱhr　　　　_,zl||y,_　.ﾞ∨
　　 .″　　　　　　　.y!^⌒　¨＼ .,,,,,,__　
　　　　　.,yr=¬z　 .l|　　◎　　《 .￣ﾞﾞ^へu,
　,メ″,z厂◎　　l|　 ￥　　　　 il!　　　　　 ﾞミ
il「　　ﾐy　　　..,ilﾄ　 ﾞﾐy_　ｱ ,メ　　　　　　 .∨
.ll′　　 干=冖″　　　　　　　,,,yyyyy.　　　l|　　　　／￣￣￣￣￣
.l|　　　　 ,,,yvr=冖''''|ﾘ|||》巛》ﾐ冖'li厂.l|　　 .,l!　　＜　　薄型？！！！
.l!　　　　 《vvvr=冖¨￣　　　　　　.ﾞ干l!　 .,メ′　　　＼＿＿＿＿＿
.l|　　　　 .l|　　　.,,yrrvy_　　 ,,,,,,_　　 .《yrl″
＼_　　　,l|.,yzl^^ﾞﾞ^冖《《||7厂｀ﾞﾘu_　.l|
　 .ﾞ＼､ .r《l厂　　　　　　.¨ﾞ冖=vu,ﾌhrﾄ
0203デフォルトの名無しさん
垢版 |
2009/12/12(土) 15:53:19
>>1
日本が世界を統一できなかったから
0205デフォルトの名無しさん
垢版 |
2010/04/08(木) 01:34:54
もし、織田信長が生きていたら、日本が世界を支配するとか、テレビってマジ、アホだな。
あそこに出てた専門家も恥ずかしくないんだろうか?
(ひょっとして自称専門家かな)
0206デフォルトの名無しさん
垢版 |
2010/06/27(日) 00:46:08
UTF8最強
ASCIIとの互換性は伊達じゃない。
0212デフォルトの名無しさん
垢版 |
2010/07/02(金) 23:59:40
>>211
俺、utf8非万能説についてた人だが、俺の争点はそこだったんだが、相手の争点はそこじゃなかった気がするんだ。
一体何が争点だったのか、当事者にも分からない。
0217デフォルトの名無しさん
垢版 |
2010/07/03(土) 11:57:49
コードもスレも統合出来ないお馬鹿さんたちwww
0219デフォルトの名無しさん
垢版 |
2010/07/03(土) 12:41:21
>>211
争点は、UTF8はUTF16やUTF32よりも優れている。
特にASCIIとの互換性に優れており、
既存のソフト・・・多くはASCIIやEUC-JPなどの
ASCII互換用として作られているソフトや
そこで使われているライブラリの互換性がよく
ほとんど修正無しに動く。
UTF16やUTF32だと修正のコストが膨大になる。
ということ。
0221デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:01:26
全部charをwchar_tに置き換えるだけでOKとかいう
能天気やろうもいたしな。

それが全ソースコード修正＆再テストという
意味だというのを気づいていない。

その膨大さに気づいていないから、
置き換えるだけにコストがかかるというんですか？
なんてことを平気でいえてしまう。
0222デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:06:11
>>219
それは争点じゃなくて、君の意見。

そしてUTF16,UTF32に拘りすぎ。
それを最初に持ち出した人(同一人物かは知らんが)は、
UTF8でも修正コストが膨大だと主張していて、UTF16は別にどうでもいい感じだった。

>>220
その通り。ファイルシステムどころかOSの仕様まで混ざってきて、複雑になるばかりの泥仕合。
0225デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:08:47
>>223
俺は争点について話してない。>>219は争点について話しているはずなのに、君の意見しか入ってない。
自分の考え方に囚われるな。
0226デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:10:12
>>222
文字コードを変えるのにOSの仕様まで出てくるってこと自体が、
文字コード変えるのがいかに難しいかを示しているんだけどなぁ。
0227デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:17:19
この話は続ける必要はない。落ちたスレで既に話は終わっていたのだから。

999 名前：デフォルトの名無しさん [sage]： 2010/06/26(土) 22:19:28
>>972

>UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん

そんな奴いたか？　wchar_tにすれば何もかもうまくいくよ派は居たけど。

---

UTF-8にすると何もかも上手くいくよ派がいないのなら、
>>212が争点にしてたことは、元々誰も否定してなかったことだし、
>>219が争点にしてたことは、元々誰も言っていなかったこと。
wchar_tにすることが全てを解決する方法じゃないのは自明。

結論は既に出ていた。
0229デフォルトの名無しさん
垢版 |
2010/07/03(土) 13:30:08
じゃあここは「文字コード総合スレ」がなぜ立たないのか、立てた場合のテンプレの話のスレにする？
0233デフォルトの名無しさん
垢版 |
2010/07/03(土) 15:13:49
>>231
> >>228
> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
>
WindowsかJavaしか知らなくて、Unixのロケールを知らなければそういう発想になるかも。
0236デフォルトの名無しさん
垢版 |
2010/07/03(土) 15:26:22
>>234
> >>233
> 意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
fopenのwchar_tは規格化されていない、から泥仕合が始まったのだが。
0237デフォルトの名無しさん
垢版 |
2010/07/03(土) 15:28:13

知らないことは誰だってあるけど、いいやんとか言って違いも調べず思考停止するやつは向上心もう少し持とうぜ
0238デフォルトの名無しさん
垢版 |
2010/07/03(土) 15:43:18
>>236
・fopenの話が出たことと、wchar_tにすれば何もかもうまくいくという人がいたことは関係がない
・fopenが出てくる前から、どうせ泥試合だった
・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
と認識しているが。
0239デフォルトの名無しさん
垢版 |
2010/07/03(土) 16:01:26
> ・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
> と認識しているが。

ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで
0240デフォルトの名無しさん
垢版 |
2010/07/03(土) 17:02:38
Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。
0241デフォルトの名無しさん
垢版 |
2010/07/03(土) 17:47:51
>>239
日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。

>>240
それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……
0244デフォルトの名無しさん
垢版 |
2010/07/03(土) 19:41:28
つか、例えば仕様書に「ロケールはja_JP.eucjp」って明記してあっても、
utf8で書いてもなんにも問題はないからutf8で書いて、
utf8なら問題なくfopen使えるからutf8でfopen使って、
結果、表示が文字化けしていても、utf8なら問題なく読めるから問題ないって言いきるつもりなのか？

内部的にはutf8使ってもいいけど、必要に応じて変換しないとダメなんじゃないの。
0245デフォルトの名無しさん
垢版 |
2010/07/03(土) 19:44:47
>>241
表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。
0247デフォルトの名無しさん
垢版 |
2010/07/03(土) 20:34:28
>>245
ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。
0248デフォルトの名無しさん
垢版 |
2010/07/03(土) 20:38:42
>>238

>・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
>と認識しているが。

それはそうだけど、fopenの機能としてはちゃんと動作するよね。
wchar_tの渡した場合、fopenが正しく機能しない・・・というか渡せない　つまりfopenでは動作しない

どちらもうまく動いてないといえるけど、その動かない箇所のレイヤーが違うんだよね。
それを同じ土俵で較べ合ってもしょうがないと思うんだが。
0249デフォルトの名無しさん
垢版 |
2010/07/03(土) 20:52:48
>>248
1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
3. なんでそんなにwchar_tに拘ってるの？
　　　>>227
　　　> wchar_tにすることが全てを解決する方法じゃないのは自明。
　　　>>231
　　　> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
0250デフォルトの名無しさん
垢版 |
2010/07/03(土) 20:59:31
> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ

意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。
0251デフォルトの名無しさん
垢版 |
2010/07/03(土) 21:01:10
>>247
> ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？

何を言いたいのかさっぱりわからん。
0257デフォルトの名無しさん
垢版 |
2010/07/03(土) 21:47:40
wchar_tが２バイト４バイト、エンディアンの違いを考えると、
gtkの内部utf-8はマルチプラットフォームって意味では合理的だと思うが。
0258デフォルトの名無しさん
垢版 |
2010/07/03(土) 22:45:00
>>249

>1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩

結果で見ればそうだけど、ここはプログラム板。
システムで採用されているロケールの文字を使う限り文字化けはしないわけでしょ。
ASCIIでもShift_JISでもUTF-8でも。
それらに対してprintfはそのまんま使える汎用性がある。

wchar_tの場合は、そこまで汎用性が持たせられない。というかそこまで汎用的に
使える標準関数が整備されていない。

その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？
0259デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:17:42
ばかっ。
wchar_tとか不用意に持ち出すと今度はCSI vs UCS Normalizationで不毛な戦火の拡大が……
0260デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:33:30
>>250
eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？

> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。
0261247
垢版 |
2010/07/03(土) 23:36:12
utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。

>>251
ごめんよー、ファイル名の間違いだわ。
0262デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:37:59
>>260
文字化けするが書けるだろう？

それは違う文字コードでちゃんと書けていることを意味するんだよ。
0263デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:38:59
>>258
>>249の2.には異論ないのかな？
だったら、
fopenがそのまんま使えるには使えるけれども、意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけない
が結論なわけだな。
0264デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:41:19
>>262
それでいいんだったら、utf8自体いらない。
UTF16をbase64エンコーディングしたらASCIIだけで事足りるんだから。
0265デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:42:31
意図した通りってなんだよ。

ファイル名が「テスト」だとしてEUC-JPで書き込んだ場合と
UTF-8で書き込んだ場合、文字コードが違うのだから
それをあらわすバイナリ列も違う。

だから違うファイル名として扱うのが意図した動作だが？

逆に言えば、fopenはバイナリ列しか見ておらず
それがEUC-JPかUTF-8なのかは気にしていない。
わざわざ文字コードを変換する機能を入れるのが意図した動作だと？
0267デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:50:03
酷い流れだ。もう結論これでいい？

表示上文字化けしないようにファイル作りたかったら、文字コード変換しろ。
表示上文字化けしてもバイナリ列が保存されていればどうでもいいなら、utf8使っても構わん。
0268デフォルトの名無しさん
垢版 |
2010/07/03(土) 23:52:27
>>266
何のためにじゃなくて、Unixでは'/'と'\0'以外パス名に制限が無いから、
それ以外何を使っても良い、でしょ。
0273デフォルトの名無しさん
垢版 |
2010/07/04(日) 00:17:36
>>270
はい。残念なことになっています。

fopenはワイド文字を扱う場合は、_wfopenを使うようにと
一時期は使えない関数とされ、今は一応使えるようになりましたが、
標準を満たしていない独自の引数をとるようになりました。

もはや互換性の無い別物です。
0274デフォルトの名無しさん
垢版 |
2010/07/04(日) 00:33:55
>>272
うん。表示に拘らないのなら、半角英数だけで事足りる。ドットくらいは使うかもしれんが。
実際、人が読む必要がないキャッシュファイルやら一時ファイルはそういう風な名付け方になってることが多い気がする。
0276デフォルトの名無しさん
垢版 |
2010/07/04(日) 00:36:42
http://www.game-create.com/archives/320
>
> よく使う標準関数の UNICODE 対応表を作ってみました。
>
> Windows では UNICODE 対応時と UNICODE 未対応時で
> 呼び出す関数を振り分ける必要がありますが、 _t で始まる
> 標準関数を使っておくことで、コンパイル時に自動的に関数を振り分けることができます。

あー、これは残念だｗ
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況