トップページ⇒tech
982コメント325KB

文字コード総合スレ part2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2006/03/26(日) 21:20:39
プログラムにおける各種文字コードの処理について語りましょう♪

■前スレ
文字コード統一スレ 1文字目
http://pc8.2ch.net/test/read.cgi/tech/1109171258/

■関連スレ
文字コードの種類は何故複数あるのでしょうか？
http://pc8.2ch.net/test/read.cgi/tech/1093251312/l50

■参考サイト
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm
0446デフォルトの名無しさん2006/10/28(土) 12:39:08
失礼、中国では「曽」のまんなかを「田」に簡略化はしてなかった。
>>445は上部のソ型とハ型の違いだと思って読んでくれ
0447デフォルトの名無しさん2006/10/28(土) 13:48:47
>>445
そもそも曾(曽)は常用漢字じゃない。
最近になって判例を反映して人名用漢字になった。
で、この二つは異体字の扱い。
0448デフォルトの名無しさん2006/10/28(土) 13:51:46
> そもそも曾(曽)は常用漢字じゃない。
そうだった。コメント元につられた
> で、この二つは異体字の扱い。
日本ではね。
0449デフォルトの名無しさん2006/10/28(土) 15:34:40
>>439
ココで深い話をしている人たちは、そのOSやライブラリーを作る人たちだと思ってみてくれ。
0450デフォルトの名無しさん2006/10/28(土) 18:49:47
昨日は超漢字Vの発売日だったのに見事なまでにスルーされてますね
0451デフォルトの名無しさん2006/10/28(土) 22:27:58
>>450
それ食えんのか？
0452デフォルトの名無しさん2006/10/29(日) 00:21:10
OS作る人にしたって、そもそも各言語ごとの違いを吸収するためのUnicodeな
わけだろうに。
各言語を詳細に把握しないとUnicodeを扱えないんじゃ本末転倒だろう
0453デフォルトの名無しさん2006/10/29(日) 00:43:21
だいたいコンピュータで文字を扱おうなんて発想自体が
恐れ多いことなんだよ。言語ってのは計算機に扱える代物じゃないんだ。
計算機はひたすら２進数で加減剰除算と分岐処理と繰り返し処理をやってれば良かったんだ
0454デフォルトの名無しさん2006/10/29(日) 02:23:08
>>432
OSが縁の下で各言語の違いをがんばって吸収してくれるから
OS使うだけのプログラマは各言語を詳細に把握しなくても扱えるようになってるんだよ
0455デフォルトの名無しさん2006/10/29(日) 02:25:16
これも日本人に特徴的な気がするが
何もできなくなるまでむやみやたらと話を大きくしたがる人が多すぎ
優先順位をつけて物事に当たるという概念はないんだろうか
0456デフォルトの名無しさん2006/10/29(日) 02:31:29
研究者になぜ研究をするんですかと問う人もいるんだよね
0457デフォルトの名無しさん2006/10/29(日) 02:33:31
>何もできなくなるまでむやみやたらと話を大きくしたがる
どういうことだか分からないんだけど。
0458デフォルトの名無しさん2006/10/29(日) 02:58:06
ごちゃごちゃ言ってねーでユニコード使えようんこども
俺様がcjk書ければ他はどーでもいーんだよ、の意
0459デフォルトの名無しさん2006/10/29(日) 03:15:57
俺はSJIS,EUC,JIS,Unicodeに対応する文字列クラスみたいなの作ってるけど
確か、assign,append,isalpha,islower,ischarlen,isbomくらいがそろってれば
別に困ってないけどな。重要なのは可変長の扱いと、終端0が2バイトとか、
あとはbomの読み飛ばしくらいで、文字処理ができれば検索とかは後は同一だし、
なんかそんなに難しいことあるか？
0460デフォルトの名無しさん2006/10/29(日) 08:41:09
はい次
0461デフォルトの名無しさん2006/10/29(日) 13:03:55
俺は困ってないよ？
なんかそんなに難しいことあるか？
0462デフォルトの名無しさん2006/10/29(日) 13:05:43
あなたは無理して話に入らなくてもいいんですよ
0463デフォルトの名無しさん2006/10/29(日) 13:49:07
はい次
0464デフォルトの名無しさん2006/10/29(日) 15:20:17
>>457
LE-talk-jaの過去ログの展開1つ取ってもそう
「現実を見ろ」という当初の志(?)すらどっかに吹っ飛んでる
0465デフォルトの名無しさん2006/10/29(日) 15:53:41
http://pc8.2ch.net/test/read.cgi/win/1153828837/932-933
もうジャストは正しい日本語とか語るな。
日本語ですらこの始末なのにどうしてマトモな外国語処理ができようか(反語
0466デフォルトの名無しさん2006/10/29(日) 16:06:37
なんか話が散漫としてるが、プログラマーの俺としても、459的な
コーディング上の具体的な問題とかの話の方が楽しいな。
0467デフォルトの名無しさん2006/10/29(日) 16:31:53
>>459
そういう文字列処理の仕方は一般的なのでしょうか。

C/C++の話ですが、外部ではマルチバイト文字列でデータを作成して、
ソートや検索のような内部処理をするときはワイド文字列に変換して
使うのが正統派な気がします。変換規則はlocaleのfacetに任せます。

ところでstringとwstringの相互変換ってSTLにあるのでしょうか。
0468デフォルトの名無しさん2006/10/29(日) 17:30:22
Windowsのワイド文字は破綻してるからWindowsではあまり一般的でない希ガス
0469デフォルトの名無しさん2006/10/29(日) 19:43:16
>>467
std::codecvtというものがある。こういう風に使うらしい。
ttp://hw001.gate01.com/eggplant/tcf/cpp/strcnv.hpp

>>468
COMなどワイド文字が強制されることもあるわけで。
0470デフォルトの名無しさん2006/10/29(日) 20:44:16
wide文字はひどい環境になるとISO646だったか、7bit文字以外のサポートは
全く考えていない実装が多くて使えない。
std::basic_stringにuint32_tなんかを入れて使うほうが無難なきがする。
0471デフォルトの名無しさん2006/10/30(月) 00:29:58
>>467
いや、一般的かどうかはわからんがJavaみたいにいちいち入ってくるのを
統一の文字コードにして、また戻すみたいなのがめんどくて・・
Streamに文字コード設定したりとかさ。トラブルの元だし。
WindowsはSJIでUnixはEUCのままやりたかったから。それが正しいとも
思ってないし古いやり方かもね。上みたいに、ワイドにしてstlとか使う方
が今はいいのかもとかも思う。
0472デフォルトの名無しさん2006/10/30(月) 00:38:04
てか今どきみなどうやって解決してるのかよくわかんねー。stlなのかboostなのか
MFCなのかATLなのか自前なのか。まあC/C++以外はお決まりのやり方がありそう
だけど。
0473デフォルトの名無しさん2006/10/30(月) 01:47:31
>>469
ありがとうございます。

実は現在、国際化に関して勉強していたところでした。
以下のページもお勧めですよ。
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/SUNWspro/WS6U2/ja/manuals/stdlib/user_guide/loc_io/index.htm
0474デフォルトの名無しさん2006/10/30(月) 01:57:49
>>472
プラットフォームの独自APIのみ使うのも有効だそうですよ。

しかし、ロケールが不備な環境に移植するなら、std::codecvtから
派生させてエンコーディング法変換用facetを新たに定義する方法が
王道なのでしょうね。
独自の変換APIを作るのと同等の作業量ですけど、locale周りのフレ
ームワークに従うので移植性は高いと思います。
0475デフォルトの名無しさん2006/10/30(月) 02:52:49
>>474 こういういいかげんな奴の相手するなよ。
0476デフォルトの名無しさん2006/10/30(月) 05:08:13
お前がどの程度いいかげんじゃないやり方してるんだかもよくわからんがな
0477デフォルトの名無しさん2006/10/30(月) 05:22:51
もしかして考えすぎているのかもしれないが
文脈からすれば、>>472がいいかげんで、それを>>474に忠告してなんじゃないか？
まぎらわしいけど、たしかにどっちにもとれるな。
0478デフォルトの名無しさん2006/10/30(月) 05:54:10
>だから経験上、
>「普通はBMPでなんとかなる」
>「BMPでなんとかならない場合はBMP外までサポートしてもどうにもならない」
>というのがある。
一理ある。
今まではUnicode、Unicodeうるさい人でも、BMPに対応していれば文句を言われることはなかった。
でも、そろそろBMP外にも対応しないと努力が足りないと怒られる時代が来ている気がする。
# 怒られてBMP外に対応したライブラリの中の人
0479デフォルトの名無しさん2006/10/30(月) 06:12:37
ライブラリはちゃんとしてなきゃまずいだろ
0480デフォルトの名無しさん2006/10/30(月) 09:07:22
>>475
いやだからいった通り別に自分のやり方がいいとなんて思ってないって。
しかし、外人の作ったstlで日本語文字コード関係が全部解決なんてする気も
あんまりしないなあと思う。今のところ文字コード関係は手作業とかOSの
APIをごちゃごちゃと泥臭いことしなきゃいけないのが現実という気がするって
だけだよ。
0481473 4742006/10/30(月) 12:47:13
>>475
すみません。今473で貼ったサイトをみて勉強中ですのでfacetでの
変換は実用的ではないかもしれません。C++の規格上の理想です。

できれば475さんの採用されている方法を聞かせて頂けませんか。
少しでも良いものを吸収したいので。
0482デフォルトの名無しさん2006/10/30(月) 13:39:56
効率度外視で一番まともな方法は
内部UCS4、外部UTF-8だと思う
0483デフォルトの名無しさん2006/10/30(月) 16:53:01
winでUCS4に変換ってMultiByteToWideでできたっけ？
0484デフォルトの名無しさん2006/10/30(月) 17:07:04
できない。
UTF-16と各種マルチバイト（UTF-8含）との相互変換のみ。
0485デフォルトの名無しさん2006/10/30(月) 19:47:17
実際にcodecvtを使ってマルチバイト文字列<=>ワイド文字列
の変換やってみたけど変換に失敗。

環境は
vinelinux3.2
gcc3.3.2
libstdc++3.3.2
glibc2.3.3

std::codecvt::in,outの返り値がerrorになってしまうのです。
ttp://hw001.gate01.com/eggplant/tcf/cpp/strcnv.hpp
の関数を使用しても同様でした。

mbstowcsとかwcstombsは正常に動作するのですけどね。
0486デフォルトの名無しさん2006/10/30(月) 20:32:55
libstdc++がふるすぎます。そのころのは駄目です。
最新はv.6です。
0487デフォルトの名無しさん2006/10/30(月) 22:45:34
んじゃUCS4無理じゃん
0488デフォルトの名無しさん2006/10/30(月) 23:01:04
それだけ環境を選ぶと使えませんね。
libstdc++3.3.2は新しくはないけど、そこまで古くもありませんから。
0489デフォルトの名無しさん2006/10/30(月) 23:59:36
>>483
しかもそこで無理したってOSやCOMとのやり取りでUTF-16に変換せざるを得ないので
あまり意味がない。
Windowsだけの世界なら(内部なんだから当然そうなるはずだが)おとなしくOSの流儀に
したがって他方が無難だと思うよ
0490デフォルトの名無しさん2006/10/31(火) 00:08:15
DOSプロンプトだとlocale::global(locale("C"))に設定しないと
ASCII以外がプロンプトのウィンドウに出力されませんね。
locale::global(locale(""))とすると使用中のロケールが取得さ
れるのですけど(自分の環境ではJapanese_Japan.932)、これだと
何故か駄目なんです。

付け加えるとcoutだけlocale("C")に組み入れても駄目で
locale::global(locale("C"))としないとcoutにASCII以外
を出力したときにDOS窓に文字が出力されないです。

リダイレクトを使うかofstreamでファイルに出力してやる
とASCII以外も正常なのになあ。
DOS窓の問題なんでしょうかね。
0491デフォルトの名無しさん2006/10/31(火) 00:13:12
何の処理系の話なのかくらい書けよ
0492デフォルトの名無しさん2006/10/31(火) 00:27:37
>>491
vc8。
プロンプトから
cl -EHsc ファイル名
でコンパイル。
0493デフォルトの名無しさん2006/10/31(火) 00:29:14
>>489
内部ではコードポイント固定長で扱いたいこともあるだろ。
毎回変換するのも一つの選択肢で、意味は大いにあると思う。
0494デフォルトの名無しさん2006/10/31(火) 00:34:05
内部で固定長で扱いたいだけなら別にUCS4である必要もないと思うが。
むしろ合成が事実上必須のコードなんて扱いづらくて仕方ないだろ
0495デフォルトの名無しさん2006/10/31(火) 00:34:41
>>485
gcc3でC++って悪夢だ。
codecvt以外にも困ること多すぎ。
0496デフォルトの名無しさん2006/10/31(火) 01:06:36
>>490
VC8のバグらしい。
ttp://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=250724&SiteID=7
0497デフォルトの名無しさん2006/10/31(火) 01:13:14
次期バージョンってまさかOrcasまで待てとか?
0498デフォルトの名無しさん2006/10/31(火) 02:07:56
libstdc++のL""はダミーですか？
バージョン上げたら改善するの？
0499デフォルトの名無しさん2006/10/31(火) 03:10:00
>>493,4
内部のコードポイントが外部より少ないんじゃ欠損する訳だし、
UCS4には変換できないし、どうやってやるんだ？という気がするが。
0500デフォルトの名無しさん2006/10/31(火) 03:31:23
Windows で UTF-16 のサロゲートペアの扱いが面倒だなと
思ったので、UTF-8 とかを API で UTF-16 に変換後に
私が勝手に定義した 4 バイト固定版 UTF-16 にさらに変換して
std::basic_string に突っ込んでます。サロゲートペア以外を 0 付加して
4 バイト化するという、Shift JIS を 2 バイト固定化して使う方法と
同じような感覚です。通常の UTF-16 への逆変換なども当然必要です。
0501デフォルトの名無しさん2006/10/31(火) 05:28:59
>>495
kwsk
0502デフォルトの名無しさん2006/10/31(火) 05:32:25
なるほど。そうした場合以下のデメリットが出てくるだろうけど、その辺は
どう考えてるの？
・内部外部変換で２回の変換が入るのは速度面で不利
・４バイト長はメモリ消費が多い
0503デフォルトの名無しさん2006/10/31(火) 08:17:04
内部をどうしようとプログラマの自由。
もっといえばWindowsに合わせる必要もない。
以上。
0504デフォルトの名無しさん2006/10/31(火) 11:36:55
>>502
今時、しかもただでさえWindows自体が計算機資源をだだ漏れのように浪費するのに、
その程度のこと気にしたってしょうがないぞ。
0505デフォルトの名無しさん2006/10/31(火) 18:48:07
>>500
お前の言う4バイト固定版UTF-16とUTF-32の違いを感じない。
自前でUTF-8とUTF-32を変換するルーチンを書いたらどうかと思う。
0506デフォルトの名無しさん2006/10/31(火) 20:00:47
おまいらどうせ実質BMPしか使わないから
UCS2ぶっこんどけばいいんじゃね
0507デフォルトの名無しさん2006/10/31(火) 21:26:20
>>504
いや、気にしようよ
>>505
差がないから手間のかからない方にしたんだろ。それもいいんじゃねーか。
>>506
んなことない。今どきいつサロゲート文字がくるかわからんよ。OSが表示
できねーとかは知ったこっちゃないが、文字が切れるのは困るって。
0508デフォルトの名無しさん2006/10/31(火) 23:05:52
500 です。メモリや速度を気にするなら ASCII 限定でしょう。英語で勝負。
リッチな文字コードを使うのをやめるべきです。ちなみに
API で UTF-16 に一度変換するようにしているのは、UTF-8 以外も
楽して変換対象にしたいからです。手抜き工事ですね

>>505 ビット範囲が同様でも、サロゲートの部分が違うでしょ。
UTF-32 は、サロゲートないんで
0509デフォルトの名無しさん2006/10/31(火) 23:15:44
UCS2 では UTF-16のサロゲート領域にどんな文字が定義されてるの？
05105052006/10/31(火) 23:37:25
>>508
UTF-32と違うのはわかるが、だからこそなぜUTF-32を使わないのかを聞きたい。
0511デフォルトの名無しさん2006/10/31(火) 23:50:35
>>510 バイト数を揃えたいだけで、それ以上の品質を求めている
わけではないというのでは、回答になっていないですか？
UTF-32 は、Windows に食わせるのに都合が良いわけでもないという
思い込みもあります
0512デフォルトの名無しさん2006/11/01(水) 03:25:30
>>509
未定義
0513デフォルトの名無しさん2006/11/01(水) 05:42:58
500の人はUTF-32を知らないのではないだろうか
0514デフォルトの名無しさん2006/11/01(水) 08:00:31
>>506
BMPしか使わなくてもUnicodeの文字表現は可変長だから、区切り位置判定は常に必要
Unicode文字列を任意のcode point位置で分割してはいけない。
0515デフォルトの名無しさん2006/11/01(水) 08:18:51
>>507
気にした結果、何ら問題ない。終わり。
0516デフォルトの名無しさん2006/11/01(水) 08:41:06
515の作ったソフトを使わせられる奴に乾杯
0517デフォルトの名無しさん2006/11/01(水) 08:45:25
素人だろ、ほっとけよ
0518デフォルトの名無しさん2006/11/01(水) 09:36:40
UTF-32の文字集合はUCS-4のサブセットであるは理解して発言せよ。
http://www.unicode.org/unicode/reports/tr19/tr19-9.html
0519デフォルトの名無しさん2006/11/01(水) 13:13:11
>>513
500 です。UTF-32 のメリットを教えてください。一応、UTF-32 については
508 で書いたんですけど。UTF-16 が使いたいけど、バイト数を
揃えたいだけなんです
0520デフォルトの名無しさん2006/11/01(水) 13:34:11
>>519
サロゲートペアだけバイト数を揃えて(?) メリットあるの？

合成とか考えると>>500のやり方でも 4バイト＝1文字は保証されないし。
0521デフォルトの名無しさん2006/11/01(水) 14:39:28
すべてのOSレベルでTronコードが使えるようにすれば解決？
0522デフォルトの名無しさん2006/11/01(水) 15:12:01
>>520 実際にプログラム上で文字を判定したいのは ASCII の範囲だけ
だったりするので、既存のイテレータやループ構造を修正しないで
サロゲートペアを意識しないままのコードにしたいという理由で
バイト数を揃えたいということですが、それだとバグが発生するだろうと
いう指摘なのでしょうか。文字の表示や印刷は OS に任せるので
自分では意識しません(UTF-16 に戻して OS に渡します)
0523デフォルトの名無しさん2006/11/01(水) 15:22:58
>>522
ASCII とくっつく合成もあるからね。U+0041 + U+0308 => U+00C4 とか。

で、合成無視するなら、サロゲート回避だけのために 32bit にするのって
そんなにメリットがあるのか？ って話。
0524デフォルトの名無しさん2006/11/01(水) 15:45:51
メリットはboostやSTLなどがそのまま動作保証できるってコトだろ。
マルチワードだと既存のものにパッチを当てる方向になってしまう。
0525デフォルトの名無しさん2006/11/01(水) 15:51:11
>>524 そういうことです。指摘された合成の考慮は確かに必要でしょうけど
0526デフォルトの名無しさん2006/11/01(水) 15:51:18
合成はサポートしないならそれでいいかも。
サポートするのであれば、UTF-8で全て扱うのと大差ないかも。
0527デフォルトの名無しさん2006/11/01(水) 15:52:27
「UTF-32 の整数値」 = 「Unicode のコードポイント」
つー、最大のメリットを捨ててまで、独自コードにこだわる理由が分からない。

独自の32bit固定長コードにしても、文字情報の取得なんかを行う場合は結局
UTF-16 か、UTF-32 に変換する必要があるわけだから、結局は
UTF-32 に変換しちゃったほうがいいと思うけどな。
0528デフォルトの名無しさん2006/11/01(水) 16:08:54
GCC で生活している人は sizeof(wchar_t) == 4 でいいんだが、
Visual C++ で生活する人は sizeof(wchar_t) == 2 だからね。
独自コードであっても、素性は UTF-16 のままだから
サロゲートのことを忘れて、独自コードのまま ASCII 範囲の判定を
してます。
0529デフォルトの名無しさん2006/11/01(水) 18:22:30
ユニコードって糞だね
0530デフォルトの名無しさん2006/11/01(水) 20:51:43
「Unicode + UTF-8 は優雅でないのでこれを認めない」なんてのもあったな。
0531デフォルトの名無しさん2006/11/01(水) 21:00:41
優雅なものがあったとしても
普及してないから駄目でしょう
0532デフォルトの名無しさん2006/11/01(水) 21:16:22
>>509
サロゲート文字が定義されてるが使用禁止。
そんなのを馬鹿丁寧に厳密に解釈してUTF-16と区別しなければならないなんて
0533デフォルトの名無しさん2006/11/01(水) 21:19:00
UCS-2+(合成が必要なものやBMP外のものは)PUA マジオススメ。
JIS X 0213 NLSもそういう実装だったな。
Windowsのシステムコードページは1〜2バイトDBCS←→2バイトUnicode
の変換にしか対応できないという技術的な都合もあったと思われるが。
0534デフォルトの名無しさん2006/11/01(水) 22:14:32
>>519
UTF-32もお前の独自コードも32ビット固定長だが合成文字には要注意などといった利点欠点は共通だと思う。
なぜなら両者はBMP外の文字（UTF-16でサロゲートペアになる文字）の扱い以外同じに見受けられるから。
だったらたとえ内部処理であっても広く世間で知られているものを使っておいた方が後々良いと思う。
0535デフォルトの名無しさん2006/11/01(水) 22:21:34
>>534
> たとえ内部処理であっても
世の中にはNEC選定IBM拡張文字とIBM拡張文字を区別したくなるかもしれないなんて
あまりありそうにもないことは過剰に心配するわりに内部コードのつもりだったものが
外で使われだすなんて実際に起きてみんな困ってることは絶対にないとか意味不明な
確信を抱いてる人が存在するんですよ。
0536デフォルトの名無しさん2006/11/01(水) 22:26:09
Normalization Form Cでいいやん
0537デフォルトの名無しさん2006/11/01(水) 22:29:39
>>536
互換漢字がすべて統合漢字に統一されてしまうという人名処理では致命的な欠点が
ある。なぜか正規化について語るときはみんな見て見ぬふりをするんだけど。
かと言って正規化を完全に無視すると「ふ」 U+309Aが合成されなくて不便。
JIS X 0213のレパートリをフル実装するならU+309Aを無視するわけにもいかず、
にっちもさっちもいかない。
0538デフォルトの名無しさん2006/11/01(水) 22:39:48
>>536
NFCにNormalizeしても全て１コードポイント＝１文字にはならない。
相変わらず可変長
0539デフォルトの名無しさん2006/11/01(水) 22:43:51
そこでJIS2004 IDEOGRAPHICS EXTENSIONとJAPANESE NON IDEOGRAPHICS
EXTENSIONですよ。合成? 何それおいしいの?
0540デフォルトの名無しさん2006/11/01(水) 22:45:45
漏れはUTF-8を使い続けると決めた。
0541デフォルトの名無しさん2006/11/01(水) 22:53:00
>>540
どうせ可変長ならUTF-8でいいよねえ
0542デフォルトの名無しさん2006/11/01(水) 22:59:58
合成文字機構は全ての文字にアクセントや発音区別符号を加えることができる。
合成文字は、タイ文字や数学植字のエンコード・国際音声字母を使うユーザーなどには必須である。

0543デフォルトの名無しさん2006/11/01(水) 23:03:51
日本語すらまともに取り扱えてないくせに本当にタイ語のテキストなんか扱うつもりなのかと。
ものごとには順序ってものがあるんだってば。
0544￣∨￣￣￣￣￣￣￣￣￣￣￣2006/11/01(水) 23:05:59
　　　　 ∧＿∧
　　　　( ´･ω･`) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ　
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　死ねよ 　　 　 ＼| 　 （　　　　）　
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. 早く病院に逝ってこいよ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/
0545デフォルトの名無しさん2006/11/01(水) 23:07:04
合成をサポートしない実装のレベルは、規格で許容されていると
思うのだが
■ このスレッドは過去ログ倉庫に格納されています