文字コードの種類は何故複数あるのでしょうか？
- 1 デフォルトの名無しさん
-
1つにしてくれればPGが苦労することはなくて
、ミンナうれしいはずなのに。
- 3 デフォルトの名無しさん
-
>>1
アニメの世界であれば、そういう迷惑なことをするのは悪の組織ですよね？
現実の社会ではどうでしょう？
クリーンなイメージのあの組織も、もしかすると悪の組織なのかもしれませんね。
私は、大義名分を振りかざすこと、常に勝つことが重要であると考えています。
- 4 デフォルトの名無しさん
-
>>1
それが資本主義。
- 8 デフォルトの名無しさん
-
なら、>>1 が新しい統一した文字コードを作れ。
- 37 デフォルトの名無しさん
-
>>1
すべて Unicode Consortium が悪い。
そうに決まってる。
- 137 デフォルトの名無しさん
-
>>1
なんで人の言葉は複数あるんでしょうか？
- 203 デフォルトの名無しさん
-
>>1
日本が世界を統一できなかったから
- 9 デフォルトの名無しさん
-
>>8
また増えるからもういいよ
- 11 デフォルトの名無しさん
-
？
おまえら、まだ文字コード使ってるの？
俺はだいぶ前から文字しか使ってないよ。
- 12 デフォルトの名無しさん
-
あめれか人が悪いに決まってるだ
- 14 デフォルトの名無しさん
-
>>12
欧米人は頭足りないからな
- 27 デフォルトの名無しさん
-
hhttp://satosan.jp/ClangStudy.html
> 遠隔地同士の通信手段としてテレタイプ(通信機能をもった
> タイプライター) が使われていた頃は、ヘッドが行の端まで
> 行ったとき次の行の先頭に戻るま で、2文字分通信するのと
> 同じ時間がかかった。
> そこで改行の文字コードをCR(復帰：キャリッジリターン ' ')と
> LF(改行： ラインフィード ' ')の2つに割り当てた。
- 41 デフォルトの名無しさん
-
XMLの仕様書に書かれてる3-4-1-2や2-1-4-3って実在したのか
>>37
ワロス
- 51 デフォルトの名無しさん
-
>>41
3-4-1-2ってのは、最小アクセス単位が16 bitでbig-endianなCPU
(3-4)-(1-2) 別名middle endian
wordにpackするとこの形になった。(Cの先祖のBCPL、初期のpascal等)
>>27
それは嘘。(そもそも復帰は物凄く時間がかかる)
タイプライター時代から、(行先頭に)復帰して文字を進めて重ね打ち、例えば _ を、
ってのがあって、それをプリンタにも持ち込んだのが最初。
- 49 デフォルトの名無しさん
-
どうか教えてください。
[1] 授業単元：プログラム概論
[2] 問題文(含コード&リンク)：
シフトJISからEUCへの文字コード変換プログラムを作りたい（余裕があればその逆も）
hhttp://tokyo.cool.ne.jp/kuonnnokizunanbalivetehe/programming/prog1.txt
[3] 環境
[3.1] OS： WindowsXP,NT Solaris2.0
[3.2] コンパイラ(バージョン)：富士通fcc,Cygwin(gcc)
[3.3] 言語：Ｃ
[4] 期限：2005年2月28日12:00まで
[5] その他の制限： この問題文の意図だと引数をunsigned int型にするべきかどうか分からない
- 50 デフォルトの名無しさん
-
>>49
#include <stdlib.h>
main()
{
return system("nkf -e from > to");
}
つーかスレ違い
- 52 デフォルトの名無しさん
-
>>50
ワラ
幾らなんでもそれはないから
> return system("iconv -f shift_jis -t euc-jp < from > to");
でどうだ?
- 75 デフォルトの名無しさん
-
UTF-8でいいんでしょ？〜とか①とか大丈夫なんでしょ？
- 76 デフォルトの名無しさん
-
>>75
いまのWord、ExcelはUCS-2だから、その世界に収まっている
仕事ならUTF-8でおけですよ。
でもオヤクソとかは…
- 78 デフォルトの名無しさん
-
>>76
じゃあUCS-4でいいから今すぐ統一して（ ノ＞＜）ノ
- 83 デフォルトの名無しさん
-
「龍」の点の向きのこと？
そんなもん包摂の範囲内だしどっちだっていいやん。
表外漢字字体表にがちがちにあわせたJIS X 0213:2004のほうが異常。
- 87 デフォルトの名無しさん
-
いま試しに数えてみたら24個くらいあった
- 88 デフォルトの名無しさん
-
>>87 夜に数えると増えてるよ。
うちの家の階段も昼間は12段だけど
夜数えると13段ある。
- 157 デフォルトの名無しさん
-
>>157
日本は何にするの？
- 159 デフォルトの名無しさん
-
>>157
JIS_X201で。
- 197 デフォルトの名無しさん
-
文字コード総合スレ part5
hhttp://pc11.2ch.net/test/read.cgi/tech/1236529563/l50
作ってきた。
即死回避に、だれか頼む。
あと、テンプレがまだ（４０行）残ってるので。現在連投規制（5回）で書き込めないのを何とかしないといけない。
- 200 デフォルトの名無しさん
-
>>197
乙
どんだけ書けば即死回避するんだっけ
- 211 デフォルトの名無しさん
-
結局争点はなんだったのだろう？
- 212 デフォルトの名無しさん
-
>>211
俺、utf8非万能説についてた人だが、俺の争点はそこだったんだが、相手の争点はそこじゃなかった気がするんだ。
一体何が争点だったのか、当事者にも分からない。
- 219 デフォルトの名無しさん
-
>>211
争点は、UTF8はUTF16やUTF32よりも優れている。
特にASCIIとの互換性に優れており、
既存のソフト・・・多くはASCIIやEUC-JPなどの
ASCII互換用として作られているソフトや
そこで使われているライブラリの互換性がよく
ほとんど修正無しに動く。
UTF16やUTF32だと修正のコストが膨大になる。
ということ。
- 227 デフォルトの名無しさん
-
この話は続ける必要はない。落ちたスレで既に話は終わっていたのだから。
999 名前：デフォルトの名無しさん [sage]： 2010/06/26(土) 22:19:28
>>972
>UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
そんな奴いたか？ wchar_tにすれば何もかもうまくいくよ派は居たけど。
---
UTF-8にすると何もかも上手くいくよ派がいないのなら、
>>212が争点にしてたことは、元々誰も否定してなかったことだし、
>>219が争点にしてたことは、元々誰も言っていなかったこと。
wchar_tにすることが全てを解決する方法じゃないのは自明。
結論は既に出ていた。
- 220 デフォルトの名無しさん
-
wchar_tとロケールとファイルシステム(fopen)がごっちゃになってた気がするんだが。
- 222 デフォルトの名無しさん
-
>>219
それは争点じゃなくて、君の意見。
そしてUTF16,UTF32に拘りすぎ。
それを最初に持ち出した人(同一人物かは知らんが)は、
UTF8でも修正コストが膨大だと主張していて、UTF16は別にどうでもいい感じだった。
>>220
その通り。ファイルシステムどころかOSの仕様まで混ざってきて、複雑になるばかりの泥仕合。
- 223 デフォルトの名無しさん
-
>>222
お前の意見も、「君の意見」でしかないよ。
鏡見ろ
- 226 デフォルトの名無しさん
-
>>222
文字コードを変えるのにOSの仕様まで出てくるってこと自体が、
文字コード変えるのがいかに難しいかを示しているんだけどなぁ。
- 225 デフォルトの名無しさん
-
>>223
俺は争点について話してない。>>219は争点について話しているはずなのに、君の意見しか入ってない。
自分の考え方に囚われるな。
- 232 デフォルトの名無しさん
-
さっさと次スレ立てろよボケ
- 239 デフォルトの名無しさん
-
> ・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
> と認識しているが。
ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで
- 240 デフォルトの名無しさん
-
Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。
- 241 デフォルトの名無しさん
-
>>239
日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。
>>240
それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……
- 245 デフォルトの名無しさん
-
>>241
表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。
- 247 デフォルトの名無しさん
-
>>245
ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。
- 251 デフォルトの名無しさん
-
>>247
> ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？
何を言いたいのかさっぱりわからん。
- 249 デフォルトの名無しさん
-
>>248
1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
3. なんでそんなにwchar_tに拘ってるの？
>>227
> wchar_tにすることが全てを解決する方法じゃないのは自明。
>>231
> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
- 258 デフォルトの名無しさん
-
>>249
>1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
結果で見ればそうだけど、ここはプログラム板。
システムで採用されているロケールの文字を使う限り文字化けはしないわけでしょ。
ASCIIでもShift_JISでもUTF-8でも。
それらに対してprintfはそのまんま使える汎用性がある。
wchar_tの場合は、そこまで汎用性が持たせられない。というかそこまで汎用的に
使える標準関数が整備されていない。
その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？
- 250 デフォルトの名無しさん
-
> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。
- 260 デフォルトの名無しさん
-
>>250
eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？
> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。
- 261 247
-
utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。
>>251
ごめんよー、ファイル名の間違いだわ。
- 253 デフォルトの名無しさん
-
内部的にはutf8使う香具師なんているのか
- 255 デフォルトの名無しさん
-
>>253
> 内部的にはutf8使う香具師なんているのか
Gtk+
- 254 デフォルトの名無しさん
-
なぜ内部にこだわる？
- 263 デフォルトの名無しさん
-
>>258
>>249の2.には異論ないのかな？
だったら、
fopenがそのまんま使えるには使えるけれども、意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけない
が結論なわけだな。
- 262 デフォルトの名無しさん
-
>>260
文字化けするが書けるだろう？
それは違う文字コードでちゃんと書けていることを意味するんだよ。
- 264 デフォルトの名無しさん
-
>>262
それでいいんだったら、utf8自体いらない。
UTF16をbase64エンコーディングしたらASCIIだけで事足りるんだから。
- 265 デフォルトの名無しさん
-
意図した通りってなんだよ。
ファイル名が「テスト」だとしてEUC-JPで書き込んだ場合と
UTF-8で書き込んだ場合、文字コードが違うのだから
それをあらわすバイナリ列も違う。
だから違うファイル名として扱うのが意図した動作だが？
逆に言えば、fopenはバイナリ列しか見ておらず
それがEUC-JPかUTF-8なのかは気にしていない。
わざわざ文字コードを変換する機能を入れるのが意図した動作だと？
- 266 デフォルトの名無しさん
-
>>265
そしたら、君は何のためにファイル名に非ASCII文字を使うの？
- 268 デフォルトの名無しさん
-
>>266
何のためにじゃなくて、Unixでは'/'と' '以外パス名に制限が無いから、
それ以外何を使っても良い、でしょ。
- 267 デフォルトの名無しさん
-
酷い流れだ。もう結論これでいい？
表示上文字化けしないようにファイル作りたかったら、文字コード変換しろ。
表示上文字化けしてもバイナリ列が保存されていればどうでもいいなら、utf8使っても構わん。
- 269 デフォルトの名無しさん
-
>>268
何使ってもいいけど、そんなキーボードで入力しにくいファイル名使って何がしたいの？
- 270 デフォルトの名無しさん
-
>>268
じゃあ、Windowsじゃutf8でfopenは残念なことになるって思っていい？
- 272 デフォルトの名無しさん
-
>>269
確かにウムラウトとか入力しずらいね。
- 271 デフォルトの名無しさん
-
>>270
cygwin
- 273 デフォルトの名無しさん
-
>>270
はい。残念なことになっています。
fopenはワイド文字を扱う場合は、_wfopenを使うようにと
一時期は使えない関数とされ、今は一応使えるようになりましたが、
標準を満たしていない独自の引数をとるようになりました。
もはや互換性の無い別物です。
- 279 デフォルトの名無しさん
-
>>270
CP_UTF8ってのがあるよ。
- 274 デフォルトの名無しさん
-
>>272
うん。表示に拘らないのなら、半角英数だけで事足りる。ドットくらいは使うかもしれんが。
実際、人が読む必要がないキャッシュファイルやら一時ファイルはそういう風な名付け方になってることが多い気がする。
- 275 デフォルトの名無しさん
-
WindowsでfopenでUNICODE文字列のファイル名って開けるのか？
- 278 デフォルトの名無しさん
-
>>275
言葉自体が曖昧。
まず、Windowsは内部ではファイル名をutf-16で管理してる。
そして、fopenは実装依存。とりあえずVC++のfopenで、日本語ロケールでの使用を想定する。
つまりfopenはcp932(sjisのMS拡張と思ってよし)でエンコードされたchar*をとって、内部でutf-16に変換してる。
そういう意味で、全ファイル名がUNICODE文字列であって、fopenではcp932を経由してUNICODE文字列のファイル名を開ける、と言える。
あるいは、cp932入れるべきところに強引にUNICODE文字列をねじこんで、
それをWindowsが内部でcp932のつもりでutf-16に変換したもの、という意味なら。
まず、それがファイル名として妥当なものになるのか(つまり、そんなファイル作れない。ないものは読めない)というのがひとつ。
次に、UNICODE文字列とはutf8か16か32か(あるいは7か...)。
16,32ならNULを含むことになって作れないだろうなぁ。
8なら、sjisのバックスラッシュ問題にコンパイラが対応してるか、ユーザが小細工してるか。
それによって別の文字になるので調整しないといけないが、うまくすれば読める。
- 280 デフォルトの名無しさん
-
>>278
なんでファイル名にUNICODE使えるのかの話で
cp932を持ち出してるの？
- 281 デフォルトの名無しさん
-
WindowsではfopenにASCII非互換のSJISなどを
認めてしまったため、ASCII互換のものならなんでも受け付けられる
なんて変更は出来なかった。
そのためUNICODEに対応するには、fopenではない
別の関数を使うしかない。それが_wfopen（MS独自関数）ただし
これはUNICODE(UTF-16)限定のためWin9xでは動かない。
そのために_tfopenというマクロが作られた。これを使っていると
define定数でfopen、_wfopenどちらを使うか自動的に変更できる。
これは関数だけではなく、文字列も一緒で、L”文字列"なんて書き方をすると
自動的に変換してくれるがなんか_Tマクロとか_TEXTマクロとかいろいろあって
誰か、きれいにまとめて書いてくれ。
めちゃくちゃすぎてわからん。あぁ、fopenだけでUTF-8で
もEUC-JPにもなんにでも対応できるLinux楽だよ。
- 282 デフォルトの名無しさん
-
>>280
>>278を読んだのにその疑問が沸いたのなら、君でも分かるように説明するのはあまりに面倒だ。
>>281
で、Linuxに関しては>>267でいいの？ あと>>274にも異論は無い？
- 295 デフォルトの名無しさん
-
肉フライ
略してnkf
- 296 デフォルトの名無しさん
-
>>295
正式にはnettowa-ku kanji firuta-の略だっけ。
- 298 デフォルトの名無しさん
-
>>296
nkf Network Kanji Filter
hhttp://sourceforge.jp/projects/nkf/
まさかのgit。
- 361 358
-
2010年11月30日
常用漢字表改定
196字追加、5字削除、2136字となる。
1881年とは時代が違う社会が違う、という事か、JIS第2水準の字も多く追加された。
第3、第4水準の字すら入っている。
もしJISの83改定がなければ殆ど第2水準で済んでいた。
元スレ
http://echo.2ch.net/test/read.cgi/tech/1093251312
