EUCボクメツ委員会

1 ：01/10/16 〜 最終レス ：2013/04/14

Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

2 ：

EUCでもSJISでもUNICODEでもいいから
はよ統一して欲しいね。

3 ：

みんなutf-8に移行したら幸せになれます

4 ：

シフト JIS 氏ネ。欠陥コンコーディング。

5 ：

現在の会員数 ：３人

6 ：

そうそう、SJISが死んでeuc or JISになればよい。

7 ：

SJISアボーンに一票。

8 ：

jis x 0208
jis x 0201
ISO-2022-jp/kr

9 ：

UTF-8 は言わば文字コードの一枚岩カーネル。世界中の文字をひとつの体系に。
EUC は言わばマイクロカーネル。言語ごとにモジュール化。
SJIS は言わば日本語だけの一枚岩。日本語と英数字が世界のすべて。

10 ：

>>1はﾋｯｷｰ

11 ：

>>9
中国語(繁体字)はUTF-8で網羅できるんだっけ？

12 ：

>>9
日本そのものって感じだね＞SJIS

13 ：

どうでも良いけどSJISはメーカや環境ごとに違うので糞です。
>>1はWindowsだけずっと使ってください。

14 ：

オレが特に強調したいのは SJIS は「切り替え」の余地が残されてないこと。
UTF-8 もそうだから根強い反論がある。

15 ：

よく考えてみると
Shift-JIS - Windows,Dos,OS/2,Mac
JIS - TRON?
EUC - Linux,HP-UX,Solaris,AS/*,FreeBSD,BSD/OS,NetBSD
どれが多いだろうか？
あと、>>13の言う通り。

16 ：

Windows は特に NT 系で UTF-8 に統一されつつある傾向だがな。
1 はそれを知ってるのかな。

17 ：

同じくSJISｱﾎﾞｰﾝに一票。
俺はeucでｲｲ。

18 ：

Java も UTF-8 だぞ。
何で 1 みたいなのが Linux 板にいるんだ。

19 ：

>>18
ソースとかリソースのことじゃないの？

20 ：

>Windows は特に NT 系で UTF-8 に統一されつつある
UCS2でしょ。COleStringの内部で盛んにUCS2.
将来、負の遺産になりそ。

21 ：

tron-codeってのはどーだ？
出ない字がないんだろ？たしか

22 ：

SJIS なんつーメンドーなエンコーディングはステ

23 ：

>>21
同じ文字とは何か？定義してないから、
databaseやgrepで困ると思われ

24 ：

>同じ文字とは何か？定義してないから、
>databaseやgrepで困ると思われ
２ちゃん見てるとわかるけど、富士通→富士痛といった
あえて検索性の悪い表現を狙って行うのが人間というも
のだろう。政治家の「善処する」が「何もしない」を意
味する国の人間としてはおそらく逸脱の速度が定義の作
業スピードを追い越すだろうと思われる。

25 ：

>>24
＞２ちゃん見てるとわかるけど、富士通→富士痛といった
＞あえて検索性の悪い表現を狙って行うのが人間というも
ただのあほ。

26 ：

>>24
それは単なる２ちゃん用語だろ

27 ：

そもそもなんで Shift_JIS なんつー
うざいものができたんだ？
誰か教えてくれ。

28 ：

半角カナ使いたかったから。

29 ：

>>27
EUCとJISに欠陥があるからって言ってた気がする。

30 ：

つーかEUCにしろSHIFT_JISにしろ、計算機資源の乏しかった
ころの規格だろ。
富豪的コンピューティングでTRONでいいじゃん。
UNICODEもステだな。

31 ：

っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？
理想を求めるならTRON-CODE
今現に多く使われているという現状を追認するならS-JIS
EUCにはどっちの利点も無い。

32 ：

むずかしいことイイからよ
shift_jisバリバリのLinuxあっても良いんじゃねーか？
shift_jisのUnix使ってると連携わりーんだよな実際。

33 ：

>>31
人生に妥協は必要だよ。

34 ：

>>31
> っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？
m17nに有利だからだろ。

35 ：

>>29
ﾊｧ? 逆だろ。
まず ISO-2022-JP があって、モード付きのエンコーディングだと
プログラムが書きにくいから ShiftJIS が作られた。
でも ShiftJIS は半角カナを 1 バイトの領域に入れてしまったために
一部の記号と日本語のコードがダブってしまって、それを例外として
処理する必要があった。
その辺を教訓として EUC-JP が作られたから、日本語と英数字の
領域は完全に分離されていて最も扱いやすく、I18N に有利である。

36 ：

結果、半角カナは2バイトで、外字は3バイトである。
文字コードの何たるかを考えた事もない
ヘタレプログラマにはただただうっと惜しいだけであった。

37 ：

>>35
なんか違うぞ
ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード
(ISO-2022にそこそこ準拠)を、fj.* と Internet Mail で使うものとして、
制限つけてRFCとして書き起こしたものだ。名前に反して実は ISO-2022 に
正確には準拠してないのは有名だ。7bit JIS としてなら歴史はあるが、
まとまったのは一番新しい。
まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。
それなら正しい。
ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、
半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせた
もんだ。変態的な変換で気持ち悪いことと、当時既にあった国際規格の
ISO-2022を全部無視したこと以外はそんなに悪いコードじゃない。
いってる通り、不幸の文字があるので、ASCII処理前提でかかれていた
コードは全部書き直しの憂き目にあったのはそのとおり。
んで、EUC-JP は別にそのあたりを教訓にしたのではなくて、
UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022
の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを
作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが
細部が異なってたのを統一する形でつくられた。
ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。
でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的
には有利/不利の差は存在しない。
ただ、世の中には、「ascii依存」なソースがあまりに多い。で、EUC-JP の
場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が
壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のが
やりやすいのは確か。
ちなみにこの条件は UTF-8 も同じだ。だから、最近のあちらさんの
アプリケーションはこれで処理したがってる。ソースをあんまり
修正しなくて良いってことね。
UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたら
パフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥
(漢字は6byteになる)。まあ、マシンパワーの向上が全て解決すると
いわれればそこまでやね。

38 ：

>>23
＞同じ文字とは何か？定義してないから、
＞databaseやgrepで困ると思われ
これは運用の問題だろ？
斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
しかし37読むとEUC-JPかUTFがいいような気がする

39 ：

不治痛だろ？

40 ：

結局のところ、マルチバイトキャラクタな状態ってのは、
文字の区切りがよくわからんところが最大の問題で、SJIS で \ を
誤認してしまうのもこれによる。EUCも、結局頭からおいかけないと、
文字の区切りはやっぱりわからん。
てっとりばやくこれを処理するには、ワイドキャラクタ化してから処理
してしまえばよいことになる。この場合、EUCだろうがSJISだろうが関係なくなる
ただ、これをするにはアプリケーションを全部 wchar 用に書き直す必要が
あって、めんどくさがられてる。その点、UTFは、EUCとかと違って、文字の
区切りが一発でわかるようなエンコーディングなんだな。
今見てる場所から、「前の文字」「次の文字」がわかるようになっている。
基本は char のままで、文字処理するとこだけ細工いれればよいので好まれるわけ。
ちなみにこれには罠があって、Unicode がホントに Unicode なら
問題なかったんだけど、Unicode　って Unicodeだけでマルチバイト文字
になるので (UCS2/UTF-8 で複数のコードで1文字になる複合文字がある)
そういった文字を扱おうとすると一瞬で破綻してマルチバイト時代に逆戻り。
まあ、欧米の人はこれでこまらんのだ。そんな複合文字なんてつかわんから。
日本人は無縁じゃないぞ。濁音は、処理次第では2つのコードに分離するのだ…

41 ：

マルチバイト文字なんか使ううちらが悪い。
外人から見れば英語最高！で国際化なんかやってらんないよ
外人に感謝しよう

42 ：

SJISを完全に捨てているVineは糞。
って今はどうなの?
PJEの頃は少しましだった気がするが..

43 ：

>>41は微妙にスレ違いだな・・・
>>42
完全に捨てているというtと、具体的には？

44 ：

>>41
誇りを持て

45 ：

情報交換符合と内部表現、
文字セットとエンコーディング、
コードとグリフ、
区別してしゃべってくれ。

46 ：

>>37 が微妙に無知だと思うのは俺だけ？

47 ：

>>46
ただの「言ってみるテスト」か?
そう思うなら、違ってるところを指摘しろよ。

48 ：

>マルチバイト文字なんか使ううちらが悪い。
>外人から見れば英語最高！で国際化なんかやってらんないよ
漏れもそう思う。で、外人に日本語を入力してもバグの出ない
ソフトを書かせるためにはクラスライブラリでワイド、UCS4を
積極的に使用するのがおすすめ。
ソフトはクラスの定義と入出力関数だけ変更して、
処理ロジックはそのままで手を触れない。
これ日本語や中国語を知らん外人が楽なので現実的な解。

49 ：

1byte=32bitにすれば、全世界で幸せになれるよなー

50 ：

外人が楽できるように外人に合わせるノカー。
みんなガンバレヨ！

51 ：

IPv6みたいに当分大丈夫だと思われる広大な領域を取った文字コードが
出てきてもいいと思う。
Unicodeみたいに word単位なんぞケチくさいことは言わずに、
qword ぐらい固定長で占有。これで宇宙人と出くわしても大丈夫。
すべてのプログラマに痛みがともなうが、構造改革なので許せ。

52 ：

>>51
それってUTF-32か?
普通の目的には4バイトじゃなくても
サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。
個人的にはUTF-8でいいかなと思うけど、
ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ
と思うので我慢する、と。

53 ：

>>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、
> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。
> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。
> しかし37読むとEUC-JPかUTFがいいような気がする
だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。

54 ：

>>51
いや、複数byte列が必要な時点で終ってる。
結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。
例えば、プログラミング言語を作るにしたって、わざわざ
マルチバイトのハンドリングをして「hogecode対応！」なぞと
するより、単一byteを相手にした方が楽に決まってる。
だから、単一byteのビット数を上げるしか道はないんだ！！！

55 ：

>だから、単一byteのビット数を上げるしか道はないんだ！！！
bit増やしても、自分の国で使われることしか考えない奴は
減らないので一緒。
昔よくいたよね下位7bitでマスクかけちゃう奴。

56 ：

そんな事より1よ、聞いてくれよ、
昨日、www.unicode.org 行ったんです。www.unicode.org。
そしたらなんかファイルがめちゃくちゃでかくてダウンロード終わんないんです。
で、13MB もある PDF ファイルよく見たら、なんかみんな漢字ばっかりなんです。
もうね、アホかと。馬鹿かと。
お前らな、９万字入りのフォント如きで長々文字表打ち出すために
Unicode 3.1 作ってんじゃねーよ、ボケが。
９万字だよ、９万字。
２バイト固定を信じて作ったアプリもあるのに、よく平気で文字増やせるな。
おめでてーな。
むりやり２万字にＣＪＫまとめながら４万字とか足してるの。もう見てらんない。
お前らな、中華大字典やるからそのコードポイント空けろと。
Unicode ってのはな、漢字は Unify するべきなんだよ。
「桟」の横画が２本か３本かで分けてるのに「浅」は統合されてもおかしくない、
刺すか刺されるか、そんな雰囲気なんだよな。
字を知らなくて単なるデザイン差もわからねーような奴は、すっこんでろ。
で、やっと探してる文字を見つけたかと思ったら、隣のワードと、前のと併せて
１文字なんですよ。
そこでまたぶち切れですよ。
あのな、空き領域でシフトコードなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、UTF-16 だ。
お前は本当に Extension B の字が読み書きできるのかと問いたい。問い詰めたい。
小１時間問い詰めたい。
お前、surrogate したいだけちゃうんかと。
多漢字通の俺から言わせてもらえば今、多漢字通の間での最新流行はやっぱり、
今昔文字鏡、これだね。
今昔文字鏡 単漢字10万字版。これが通の頼み方。
文字鏡ってのは漢字が多めに入ってる。そん代わりラテン文字が少なめ。これ。
で、それに西夏文字、梵字。これ最強。
しかしこれを使うとフォントに依存するから文字鏡買わないとデータが編集
できないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前ら初心者は、Mac OS X で JIS X 0213 でも使ってなさいってこった。

57 ：

>>46
何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ?
完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。
あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を
列挙しといてくれるとうれしい。
>>56
なにげに通やね(笑)

58 ：

>>56
ﾖｼｷﾞｭｳﾈﾀﾜﾗﾀ!

59 ：

emacs で iso-2022-7bit 使って多国語やってますが, これって
国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ
Unicode 作ったのは, escape 入れなくても一文字見たら何だか
わかるようにするため?

60 ：

>>59
ISO 2022 のフル実装は無理というアメリカ人の妄想のため。

61 ：

>>48
支那人も外人なんだけど

62 ：

つか、EUCよかS-JISのが腐ってるだろ。
なんだよ、半角かなって。腐ってるじゃねーか。
WinがJISなりUnicodeなりに文字コードをかえればすむこと。

63 ：

あ、ちなみにEUCとJISは1ビット違うだけなので上の発言には含めてないだけね。
M$ってEUCしそうにないし。

64 ：

>>62
ハァ？
文字集合とエンコーディングを区別しろ。アホか。

65 ：

> iso-2022 で多言語やらないでわざわざ
> Unicode 作ったのは, escape 入れなくても一文字見たら何だか
> わかるようにするため?
それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良
かったわけだろ。
DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、
Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪
いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい
だよ。

66 ：

>>56
ネタに乗せてかなりコアなことを、かなりうならせられるのう
TORONコードをxfsなどで配信できたら良いと思うのだが
実際、古文書を解析している方々は超漢字を愛用しているそうな（w

67 ：

すべての文書を画像の形式でやりとりするようになれば、
文字コードなどというものは必要なくなる。
ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。
とうぜんソースコードは全部手書きね。

68 ：

　　 ＠ノハ＠ 三○ ｱﾀﾀ!
　　 （　‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で
　　　　　　　　三○

69 ：

>>68 いや、67 はいいセン行ってる。
TRON がおバカなのは文字じゃないモノまで文字として扱ってる所。

70 ：

>>67
絵がヘタな私は、永久にファイルのコピーもできそうにありません...

71 ：

>>67
面白いね!!
で、仮名漢字変換やｿｰﾄはどうするの?

72 ：

ひそかにいいかなと思ってるのは CID だな。
adobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。
新しいコードの追加もそれなりにできる。
コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。
内部コードとしてはちょっと複雑すぎる気がするが。

73 ：

>>56
> お前、surrogate したいだけちゃうんかと。
ｺﾚ ﾜﾗﾀ.

74 ：

手っ取り早く済ます仕事には今も EUC 使っちまうよ。

75 ：

結局 iso-2022 で多国語というのはすたれゆく運命ですか?
僕は Unicode よりイイと思ってるんだけど.

76 ：

mb/WCの区別をしなくてよくなるのならUnicodeがイイ！に決まってるが、
それは幻想だったことが決定してるので2022でよい(よかった)。

77 ：

>>75
内部コードとしては一定以上高度な多言語処理ではどっちも使わん
でしょ。Emacs もオリジナルだし。
プログラマの苦労は結局かわらんので、76のいってる通り
2022でよい(よかった)ではあるんだけど、サポートの現状を考
えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が
とりあえず読み書きできる環境を持つ人はもうざらだから。
専門用途ではオリジナルコードも十分ありと思われ。というか、
実際、現在のDTPでは、最終的には adobe のコードが物を言うし。

78 ：

現実の話、UTFとかワイドキャラクターの導入って
あくまでもクラスライブラリとか
ウインドウシステムのインターフェースとか
ファイルシステムのファイル名の内部形式とか
そこら辺の話に終始してる。
ディスク上のテキストに関しては移行できる
と考えている人はあんまりいない。
ISO-2022が妥当だろう。

79 ：

UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
>ディスク上のテキストに関しては移行できる
>と考えている人はあんまりいない。
XML文書は?普通UTF-8で書くと思うのだが。
>ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。

80 ：

>>79
改行抜けた。mozillaたんしっかりしてくれハァハァ…
>ISO-2022が妥当だろう。
ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。

81 ：

>UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
Ruby

82 ：

うお、rubyか。じゃ結構普通のことなのかな？
すみません。

83 ：

>>79
次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。

84 ：

そりゃ、(EUC-JPと同じく)UTF-8は、ASCIIで済む人はASCIIと変わらんdata量で、
過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。
Unique "wchar_t"は幻想だったという事で。

85 ：

名スレ化あげ

86 ：

>>84
でもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？
質問age

87 ：

>>86
処理系内部で使うprintf(3)からRuby用にかき直すんかい?
2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。

88 ：

>>87
ごめん、ちょっと意味がわからない。
（なんでprintfが使えることが重要なのか？という点が）
もし暇なら説明をお願いしたいです。

89 ：

87じゃないけど…
基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」
ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが
パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。
それから「アプリケーションの互換性重要」ってのが背景にある。
printfとかに代表される標準Cライブラリの昔からあるものってのは、
ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
本来これを避けるための Wide Character なんだけど、残念ながら、
この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
使うとしたらかなり書き直しに陥るはめになる。
そうなると、選択肢としては、なんとか char のまま、普通の libc で
扱えるようにしちゃおうって考えが浮上してくるわけだ
(技術的には逃げなので退化)
必要要件は
　1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ
　2. 文字区切りが確実容易なほうがイイ！
3. 何か標準に沿ってるほうがイイ！
こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。
やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、
UCSだろうがオリジナルだろうが好きなのを採用すればよろし。

90 ：

>>78
79もいってるけど、「非多言語対応」なら、ISO-2022系が
妥当だろう。実際そっちのが多いと思うし。
話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか)
をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって
のがオレの指摘。
今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも
書くのもできるからね > UTF-8

91 ：

>>45
> 情報交換符合と内部表現、
> 文字セットとエンコーディング、
> コードとグリフ、
これらの区別が説明されているサイトはありますか？
出来れば日本語ｄ

92 ：

欧米の人たちが ASCII や ISO-8859-x で足りてるなんてのは
わりと誤解で、文字をもっと増やしたいと思っている人が多いです。
XFree86 で強硬に Unicode を推進している人たちはそんな感じ。
JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると
羨ましがられるよ。

93 ：

>>15
Solaris や NetBSD は SJIS ろけーるもあったかと。
Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。
Linux (つーか glibc) は内部 Unicode なんだっけ?

94 ：

>>93
linuxでもできる。KondaraではUTF-8なロケール使って、
X上でximを切り替えてCJK混在な文書とかも作れたはず。
Debian sid でもutf-8なロケール作ってやればできるでしょ？
まあアプリ全てがちゃんと動くわけではないが。
(ATOK X のメニューが化けて鬱だった記憶が）
ほかのディストリとかは知らない。

95 ：

>>91
そんなに難しい話じゃないよ。
「文字」の定義が甘いのをとりあえず横に置いとけば。
文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき
エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法
情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング
内部表現：OS やアプリケーションでの文字の内部表現
コード：数字。文字コードね。
グリフ：形。目に見えるものね。
この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。

96 ：

>printfとかに代表される標準Cライブラリの昔からあるものってのは、
>ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
>エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
>本来これを避けるための Wide Character なんだけど、残念ながら、
>この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
だから俺はCやめざろう得なかった。
Standard C++ならば標準ライブラリは全部マクロなんで
自動的に展開されて解決。
C++を嫌うならばKylixがある。
KylixはCのようなポインター操作もできるし、
GUIなしのデーモンプロセスも書ける。
ヘッダーさえなんとかすればドライバも書ける可能性あり。
Cユーザーにとって、字面以外は抵抗なしに受け入れられる。
>ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
>使うとしたらかなり書き直しに陥るはめになる。
過去の資産に関しては同意。

97 ：

へ？？
>Standard C++ならば標準ライブラリは全部マクロなんで
>自動的に展開されて解決。
ここだけでいいから、なにが解決されるのか具体的に書いて。

98 ：

C++のstringというのはbasic_string<char>という
テンプレートマクロ。
ワイドはbasic_string<wchar_t>とするだけ。
そうすると、stringと同一の機能をwstirngが受け継ぐ。
printf("%s%d\n", s, d)は
cout << s << d << endl;
wcout << ws << d << endl;
型の定義だけでほとんどを解決し、ロジックはいじらない。
うまくいくと変数の宣言文を触れるだけで全部解決。

99 ：

>>98
ああそういう意味か。了解。
でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。
#個人的にはふつ〜のアプリはWC使って書くのが好きですが。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

LINUXを流行らせる方法 (267)
CompizFusionで究極の操作性を追求するスレ (118)
メインフレーム最高 (133)
こんなディストリビューションは嫌だ その3 (321)
新？UIは必要かGnome3、Unity、Win8 (118)
LINUXの国内組織が普及を阻害している (142)
--log9.info------------------
機動戦士ガンダムオンライン　S鯖晒しスレ50機目 (1001)
【ECO】エミルクロニクル晒しスレ84 (573)
【ｸﾘﾄﾘｽ】ROSE Online Vega 晒しｽﾚ Part22【ｸﾗｯｼｭ】 (407)
【CF】クロスファイア晒しスレpart70【CROSSFIRE】 (514)
Mabinogi Heroesーマビノギ英雄伝ー晒しスレ Part70 (899)
【ﾊﾞｰｹﾞﾝﾀﾞｯﾂ】あさみの自分磨き詐称部屋7【ﾘﾝｸﾞﾈ】 (526)
【闇の粘着王】信on統一晒しスレ8【天下御免】 (391)
【ﾏｸﾛｸﾗﾌﾞ】TalesWeaverｸﾛﾃｨｱｽﾚ85【storehouse】 (579)
【吟玉】翡翠･十六夜･高橋14盗作目【個人情報搾取】 (387)
ドラゴンネスト　バルナック闘技場大部屋晒しスレ10 (231)
【PSO2】PHANTASY STAR ONLINE2 晒しスレ part45 (977)
Miiverse晒しスレ【ミーバース】 Part5 (249)
【FEZ】ﾌｧﾝﾀｼﾞｰｱｰｽｾﾞﾛ ｹﾞﾌﾞﾗﾝﾄﾞK鯖Vol.23 (852)
ヤマカンこと山本寛(ゆたか)を見守るスレ98 (427)
【隠蔽の】3Dカスタム少女ヲチスレ・14【恥部ｶｽ】 (1001)
サイキックハーツby富岡4 オチスレ10 (324)
--log55.com------------------
☆★今日の勝ち負けを報告するスレッド part273☆★
XM質問厨隔離スレ
FXしくじり先生 俺みたいにはなるな11【暴挙編】
金融資産1000万円以上の人達の日常４
cis6558 次々と賛同され許された男【白川禁】
XM (XEMarkets)　part67 ★３
未来技術への投資/プレ・シンギュラリティ６
一目均衡表を極めます