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

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

ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで

Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。

>>239
日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。

>>240
それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……

LANG=Cでもきちんと表示できなかったらだめだって言い切っちゃうの？

>>242
それは日本語使えるロケールじゃないだろ。

つか、例えば仕様書に「ロケールはja_JP.eucjp」って明記してあっても、
utf8で書いてもなんにも問題はないからutf8で書いて、
utf8なら問題なくfopen使えるからutf8でfopen使って、
結果、表示が文字化けしていても、utf8なら問題なく読めるから問題ないって言いきるつもりなのか？

内部的にはutf8使ってもいいけど、必要に応じて変換しないとダメなんじゃないの。

>>241
表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。

「日本語が使える」の定義が知りたい。

>>245
ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。

>>238

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

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

どちらもうまく動いてないといえるけど、その動かない箇所のレイヤーが違うんだよね。
それを同じ土俵で較べ合ってもしょうがないと思うんだが。

>>248
1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
3. なんでそんなにwchar_tに拘ってるの？
　　　>>227
　　　> wchar_tにすることが全てを解決する方法じゃないのは自明。
　　　>>231
　　　> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。

> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ

意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。

>>247
> ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？

何を言いたいのかさっぱりわからん。

fopen(3)はNULLを返さなければ、open(2)は-1を返さなければ正常。

内部的にはutf8使う香具師なんているのか

なぜ内部にこだわる？

>>253
> 内部的にはutf8使う香具師なんているのか
Gtk+

GTKは糞

wchar_tが２バイト４バイト、エンディアンの違いを考えると、
gtkの内部utf-8はマルチプラットフォームって意味では合理的だと思うが。

>>249

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

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

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

その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？

ばかっ。
wchar_tとか不用意に持ち出すと今度はCSI vs UCS Normalizationで不毛な戦火の拡大が……

>>250
eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？

> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。

utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。

>>251
ごめんよー、ファイル名の間違いだわ。

>>260
文字化けするが書けるだろう？

それは違う文字コードでちゃんと書けていることを意味するんだよ。

>>258
>>249の2.には異論ないのかな？
だったら、
fopenがそのまんま使えるには使えるけれども、意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけない
が結論なわけだな。

>>262
それでいいんだったら、utf8自体いらない。
UTF16をbase64エンコーディングしたらASCIIだけで事足りるんだから。

意図した通りってなんだよ。

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

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

逆に言えば、fopenはバイナリ列しか見ておらず
それがEUC-JPかUTF-8なのかは気にしていない。
わざわざ文字コードを変換する機能を入れるのが意図した動作だと？

>>265
そしたら、君は何のためにファイル名に非ASCII文字を使うの？

酷い流れだ。もう結論これでいい？

表示上文字化けしないようにファイル作りたかったら、文字コード変換しろ。
表示上文字化けしてもバイナリ列が保存されていればどうでもいいなら、utf8使っても構わん。

>>266
何のためにじゃなくて、Unixでは'/'と'\0'以外パス名に制限が無いから、
それ以外何を使っても良い、でしょ。

>>268
何使ってもいいけど、そんなキーボードで入力しにくいファイル名使って何がしたいの？

>>268
じゃあ、Windowsじゃutf8でfopenは残念なことになるって思っていい？

>>270
cygwin

>>269
確かにウムラウトとか入力しずらいね。

>>270
はい。残念なことになっています。

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

もはや互換性の無い別物です。

>>272
うん。表示に拘らないのなら、半角英数だけで事足りる。ドットくらいは使うかもしれんが。
実際、人が読む必要がないキャッシュファイルやら一時ファイルはそういう風な名付け方になってることが多い気がする。

WindowsでfopenでUNICODE文字列のファイル名って開けるのか？

http://www.game-create.com/archives/320
>
> よく使う標準関数の UNICODE 対応表を作ってみました。
>
> Windows では UNICODE 対応時と UNICODE 未対応時で
> 呼び出す関数を振り分ける必要がありますが、 _t で始まる
> 標準関数を使っておくことで、コンパイル時に自動的に関数を振り分けることができます。

あー、これは残念だｗ

TCHAR 型ってｗｗｗ
http://www.ruche-home.net/?%A5%D7%A5%ED%A5%B0%A5%E9%A5%DF%A5%F3%A5%B0%2F%BE%AE%A5%CD%A5%BF%BD%B8%2FUnicode%C2%D0%B1%FE%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0

>>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のバックスラッシュ問題にコンパイラが対応してるか、ユーザが小細工してるか。
それによって別の文字になるので調整しないといけないが、うまくすれば読める。

>>270
CP_UTF8ってのがあるよ。

>>278
なんでファイル名にUNICODE使えるのかの話で
cp932を持ち出してるの？

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楽だよ。

>>280
>>278を読んだのにその疑問が沸いたのなら、君でも分かるように説明するのはあまりに面倒だ。

>>281
で、Linuxに関しては>>267でいいの？　あと>>274にも異論は無い？

_Tマクロとか_TEXTマクロとかWindowsのマクロの種類は何故複数あるのでしょうか？

TEXT("hoge") もあったな

文字コード処理の種類はCSI方式とUCS normalization方式と何故複数あるのでしょうか？

それは対になるものなのか?

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

あっちがうさげならばこっちはよそ？

インテリジェント昆布

略して iconv

文字コード総合スレ part6
http://pc12.2ch.net/test/read.cgi/tech/1278923059/

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

ローマ字では日本語を読みにくいからじゃないかしら

世界は広いからだよ

バベルの塔を作り始めたからです

肉フライ

略してnkf

>>295
正式にはnettowa-ku kanji firuta-の略だっけ。

nurupo
kimuchi-E
fack

>>296
nkf Network Kanji Filter
http://sourceforge.jp/projects/nkf/
まさかのgit。
http://git.sourceforge.jp/view?p=nkf/nkf.git

ﾜﾛﾀ 本になっていたのね。

斎藤秀紀「構造化4バイトコードによる多言語漢字の符号化」
http://www.amazon.co.jp/gp/product/4898273009/

これでしょ。
http://www.horagai.com/www/moji/int/saito.htm

>>299
ここも隔離スレっぽいよ。

コードの種類は何故複数あるのでしょうか？
ストレートとクロスの見分けが付きません。

ソースといえばブルドック？おたふく？
あなたはどちら？

買ったらすぐにシール貼っとけよ

>>301
両端のコネクタを並べてみて、色が同じ順ならストレート、違う順ならクロス。

>>302
イカリソース

>>302
カゴメ

>>302
中部地方はコーミソースに決まってんだよ。ブルドッグ何それ。

俺のホワイトソースでも飲んでろ
馬鹿どもめ

ソースの種類は何故複数あるのでしょうか？
ソースを買ってくるように頼まれてソイソースを買ってきたら怒られました。

そりゃ醤油はソースとは認められないからな。
次はちゃんとソースを買ってくるんだぞ。

>>283 自分用メモ
WindowsSDKレベルではではTCHARとTEXTか__TEXTのみ有効
その他はCランタイムのもので混用すべきではない

UNICODEがSDK用で_UNICODEがCRT用だっけ

L()はどれだっけ

そんなマクロあったっけ

L""ならリテラルじゃね

それは言語機能でMSは関係ないな
もっともMS以外ではワイド文字がUTF-16とは限らないけど

もっとも、 <windows.h>の中のどこかのヘッダで以下のような旨の記述があり、
「_UNICODEとUNICODEのどちらか一方は定義してあるけど、もう片方は定義されていない」
という状況を排除しているので、_TとTEXTを混在させても問題ない。
#ifdef UNICODE
#ifndef _UNICODE
#define _UNICODE
#endif
#endif

#ifdef _UNICODE
#ifndef UNICODE
#define UNICODE
#endif
#endif

>>302
どろソース

そーすね

>>302
オリバー

>>302
イカリが多かったがカープも使う

CP932の完成度は異常。

同じ文字でコードが何種類もあるものが完全とな。

スレ全体検索したけど完全なんて文字は>>323しかない件

森鴎外の「鴎」は正しくは「鷗」である。
草なぎ剛
草�g剛

北朝鮮に文字コードは割り振られているのか？

マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと
懇願されたが拒否したらしいが。直接北から要求しなかった。
北は南と文字が異なっているのか。

unicodeに北文字あったか？存在するなら規格票、文献を提示してくれ。

＞マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと
＞懇願されたが拒否したらしいが。直接北から要求しなかった。
＞北は南と文字が異なっているのか。


日本語勉強しろよゴミカスが

マジでゴミなんだな

　　　　　 ∩＿＿＿∩
　　　　　 | ノ　　　　　 ヽ
　　　　　/　　●　　　● |
　　　　 |　　　　( _●_)　 ミ
　　　　彡､　 　丶 ノ　　､｀
　　　/　＿＿/ ⌒｀＼／⌒/
　　　(＿＿＿）　 .　 /　　(　)
　　　　|　　　⌒｀＼/／⌒
　　　 入＿ へ 　＼_ へ　 ＼_
　@三三三三 （_＿__)三（_＿__)三三)

>>325
金正日を意味する特殊な文字が追加されてるらしいんだな。漢字で言うと「朕」みたいなもんだろ。

斎藤、斉藤、齋藤、齊藤
おまえら少しは反省しろ

「そ」を１筆で書くのか２筆で書くのかくらいの違いはある

>>329
何を？

山崎、山嵜、山�ｱ
やまざき？　やまさき？

　　　　 ∧＿∧
　ﾋﾟｭｰ (　　＾＾ ） ＜これからも山崎を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉

>>1
一番単純な答えは、JISの出来が悪かったから、というものだと思う。

日本語の文字コードがいくつもある理由
http://qpon.at.webry.info/201112/article_14.html

IVSというかUnicodeに見る日本政府のダメな感じ
ttp://wontfix.blogspot.com/2011/05/ivsunicode.html

この人の文字コードに対する理解力がダメな感じ

IVSは同一字形でも包摂しない、という原則じゃなかったっけ？というか同一字形かどうか
わからないから、だったかも。そもそもIVSで区別されているのはグリフであって文字ではないわけで。

>>322
・文字集合はIBMホストコードに合わせてあって
・符号の順序はJIS順になっていて
・1978年版、1983年版、1990年版をそつなくこなし
・JISの水準外の文字はJISの区点内にも区点外のどちらにもある
とどめに
・半角カタカナと一緒に使える
ってことだな

空揚げ

そんなこんなで本スレが落ちてしまったわけだが

文字コード総合スレ part8
http://toro.2ch.net/test/read.cgi/tech/1354248962/
文化の数だけ文字がある

>>345
乙

あげ

★2ch勢いランキングサイトリスト★

☆ +ニュース板
・ 2NN
・ 2chTimes
☆ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ ニュース板他
・ Desktop2ch
・ 記者別一覧
・ スレッドランキング
☆ 全板
・ 全板縦断勢いランキング
・ 2勢
・ READ2CH
・ i-ikioi

※ 要サイト名検索

http://www.buzzword.jp/img/face10.png

ㄘんㄘんㄟ⁰ㄋㄟ⁰ㄋㄜㄝㄋ

だいたい１バイトのアスキーコードを、２バイトにして日本語を
表示できるようにしたり、それをさらに、３バイトとか４バイトに
増やすとか、チマチマそんなことしてきたから、いろんな文字コード
作られてワケワカメになったんだろ。
もうこの際、全ての言語や記号など全部表せるように、
文字コードは１文字１６バイトくらいにして、
全ての文書にこのコードを使う事を強制すればいい。
１６バイトもあれば、困ることは無いだろう。

ㄘωㄘωㄟ⁰ㄋㄟ⁰ㄋㄜㄝㄋ

>>351
これ、釣りなのかな。

(｡☉౪ ⊙｡)
(｡◕ฺˇε ˇ◕ฺ｡）
(｡◕ิ_◕ิ｡)
(｡◕ˇдˇ​◕｡)
(｡◕ˇ_ˇ◕｡)
(｡╹ω╹｡)
(｡╹ω╹｡)
(｡≖ิ‿≖ิ);
(｡•́︿•̀｡)
(｡ó .̫ ò｡)
(｡´ސު｀｡)
色々あるんやね

>>351
データ容量が無駄

将来ジャミング暗号化に使われそうなアルゴリズムだな