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

0232229

2006/09/09(土) 02:22:41

原因わかりました。表示文字中に不正な文字が入っていました。
具体的には表示する文の中で、本来全角で書くべきカッコのひとつが
半角になっていたためでした。
これを訂正したところ改善しましたm(_ _)m

0233デフォルトの名無しさん

2006/09/09(土) 02:39:31

>>231
ブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換してる。
Safariで ~ が化けたりするのはその変換テーブルがWindows PCと
一致していないため。

0234デフォルトの名無しさん

2006/09/09(土) 05:36:16

Windowsと一致する必要はない。

0235デフォルトの名無しさん

2006/09/09(土) 09:45:13

ブラウザが送るのはページの文字コードか送るためのボックスに書いてある属性依存。
また、ブラウザによって送る文字コードの種類も変わってくる。

受ける側は自動判別して、文字参照などを駆使して適当な文字コードで保存。

表示するときは、ページの文字コードと同じにする。

俺は表示・入力系はShift_JIS、内部DBはUTF-8が便利だとは思う。
今後ほとんどの環境がUnicodeに切り替わったときに、修正が楽だから。

0236デフォルトの名無しさん

2006/09/09(土) 13:29:53

>>234
Windows「に」歩み寄るべきだとは一言も言ってないんですが。
永遠に文字化けに悩まされたままでかまわない、解消する必要はないってことですか?

0237デフォルトの名無しさん

2006/09/09(土) 17:16:47

文字化けは起こっていないということです

0238デフォルトの名無しさん

2006/09/09(土) 22:44:12

>>236
Windows「に」歩み寄るべきでないとは一言も言ってないんですが。

Windowsと一致するかどうかという問題ではなくて、
テキストShift_JIS変換に、
利用者の意図と違うものがあることの問題。

利用者はTILDE、OVERLINEを同一視(%7E)している。
WAVE DASHではなくて。

0239デフォルトの名無しさん

2006/09/10(日) 03:12:21

>>237
現に文字化けしてるんですが

0240デフォルトの名無しさん

2006/09/10(日) 14:11:11

文字化けは起こっていないということです

0241デフォルトの名無しさん

2006/09/10(日) 16:15:19

あなたの脳内だけで起きてなくても意味がないので
mohtaと一緒にISO-2022-JP-3が登録されてるお花畑の世界にでも逝っててください

0242デフォルトの名無しさん

2006/09/10(日) 19:29:18

そういえば ISO-2022-JP-2004 が IETF に提出されてるね。
http://mail.apps.ietf.org/ietf/charsets/msg01550.html
反応ないけど・・・

0243>>234=>>238だが…

2006/09/11(月) 09:45:30

>>241

>>237と>>240は、
「それは文字化けじゃなくて、変換の問題である」
ということを非常に稚拙な方法で訴えているのではないか?

0244デフォルトの名無しさん

2006/09/11(月) 23:07:09

って世に言う「文字化け」の大半は実質変換の不整合の結果なのでは?

0245デフォルトの名無しさん

2006/09/11(月) 23:49:17

単に間違った文字コードで表示しようとするから変になるんじゃないのか

0246デフォルトの名無しさん

2006/09/12(火) 00:54:08

ほとんどの「文字化け」は、
ドキュメントの文字コードと表示システムが想定する文字コードの
不一致が原因じゃないか?

次は機種依存文字。

変換の問題はかなり少ないような…

0247デフォルトの名無しさん

2006/09/12(火) 00:56:54

変換ミスこそ文字化けであって、
違った文字コードで表示するのはデータ自体に間違いはないわけで
文字化けとは言わない気がする。

0248デフォルトの名無しさん

2006/09/12(火) 01:37:10

その無理矢理な論理、恥ずかしいよ?

0249デフォルトの名無しさん

2006/09/12(火) 03:20:37

人生とは旅であって、

0250デフォルトの名無しさん

2006/09/12(火) 06:56:16

昔の文字化けと今の文字化けはあきらかに意味が変わってるね

0251デフォルトの名無しさん

2006/09/12(火) 13:26:17

人の一生は重き荷を背負いて長き

0252デフォルトの名無しさん

2006/09/12(火) 14:38:20

1200ボーのモデムで、文字化けに強いishフォーマットでエロ画像を交換していたオレがやってきましたよ。
ssより、s7のほうが化けにくいですよ。

0253デフォルトの名無しさん

2006/09/12(火) 15:22:46

一発簡単文字化けテクニック

nkf -Sj | nkf -We
後戻りは出来ない

0254デフォルトの名無しさん

2006/09/12(火) 20:55:21

>>247
>変換ミスこそ文字化けであって、
>違った文字コードで表示するのはデータ自体に間違いはないわけで
>文字化けとは言わない気がする。

「変換ミスは文字化けではない」でしょう？

0255デフォルトの名無しさん

2006/09/13(水) 05:18:57

変換ミスと呼ぼうと文字化けと呼ぼうと実際それに日々悩まされていて
対応を要求されたりする事実に何の変わりもないので、
そんな言葉遊びに興味はありません。
対応の仕方とかの建設的な話題だったらいくらでも話したいですが。

0256デフォルトの名無しさん

2006/09/13(水) 05:25:51

ぷ

0257デフォルトの名無しさん

2006/09/13(水) 05:32:22

建設的な質問があれば暇なヤツが応えるだろうさ

0258デフォルトの名無しさん

2006/09/13(水) 15:16:04

ところでこの文字化けの話はどこから始まっているの?

0259デフォルトの名無しさん

2006/09/13(水) 20:51:25

>>162

0260デフォルトの名無しさん

2006/09/20(水) 22:33:26

これはひどい
http://www.chokanji.com/webp/soft.html
今どきはしご高やたて崎を例に出すなんて、進歩してないのは
Windowsじゃなくて超漢字関係者の頭の中じゃねーの。
つーかT書体フォントマダー? (AAry
せめてExtension Cに提案されてる寿司屋のメニューに出てきそうな漢字とかを
例に出すくらいの芸は見せてほしいもんだ。
http://www.cse.cuhk.edu.hk/~irg/irg/irg26/IRG26.htm
つーか日本のEvidenceの力の入りようと他国の手抜きっぷりの違いがスゴス
日本は「片割れが入りそうにないからもう片方も削除を提案します」とか言ってるのに
中国はこの期に及んで千字以上追加しろとか言ってるし。
やっぱり(寿司屋のメニューとか人名地名以外では)一部の
古文書や仏典の研究者しか興味なさそうなレア漢字ばっかりになってきた
(そして実際の戸籍システムではJISともUnicodeとも関係ない外字システムの
再発明を続ける)日本と
現実に戸籍システムでGB18030を運用する必要に迫られてる中国の温度差
なんだろうな。

0261デフォルトの名無しさん

2006/09/20(水) 23:54:25

＞Extension Cに提案されてる寿司屋のメニューに出てきそうな漢字
これはひどい

0262デフォルトの名無しさん

2006/09/22(金) 22:04:20

他に少しでも一般人が興味持てそうな例あるか?

0263デフォルトの名無しさん

2006/09/22(金) 22:39:08

その内、人名、固有名詞の「高」は全部はしご高になる日が来そうな気がする。

どの高橋さんも、ちょっと捜せば自分の名前か家族の名前がはしご高で書かれた
手紙の一通や二通は見つかるだろうし。

なんで活字と手書き文字の区別がつけられなくなっちゃったんだろう。

0264デフォルトの名無しさん

2006/09/22(金) 23:05:36

教科書体至上主義の戦後の漢字教育のせいだと思う

0265デフォルトの名無しさん

2006/09/23(土) 09:57:42

フォントの切り替えが、
手書き文字の機能の一部を担ってきたように、
文字集合も手書き文字の機能の極一部を担ってくるようになったと考えては?
全部担うことになるとさすがに困るんだけど。

0266デフォルトの名無しさん

2006/09/23(土) 19:34:24

http://slashdot.jp/comments.pl?sid=333447&op=&threshold=1&commentsort=3&mode=thread&pid=1022939#1022963
なんかは「おもしろおかしい」が付いてるけどさ、
音声ファイルに関しては「テキストファイル」方式(MIDI)はすっかり廃れたよね。
文書ファイルに関しても同様なことが起きたりはしないのかな。
アウトライン化したPDFか何かばかりになって将来のGoogle先生はデジタルデータに
OCRみたいな処理をするのが当たり前、みたいな。

0267デフォルトの名無しさん

2006/09/23(土) 22:17:14

MIDIは、音楽再生形式としてはあまり使われてないだけで、
全然廃れてない。(デジタル化)ミュージシャンの間では現役。

0268デフォルトの名無しさん

2006/09/23(土) 22:21:43

そりゃWeb上のフルカラー画像はほとんど.jpgだけど編集段階で劣化する
フォーマットを使うわけないわな。圧縮音楽もしかり
で、将来のGoogle先生は最終出力を相手にしないわけにはいかないでしょ

0269デフォルトの名無しさん

2006/09/23(土) 22:25:34

＞音声ファイルに関しては「テキストファイル」方式(MIDI)はすっかり廃れたよね。
いいえ、MIDIはテキストファイルじゃありませんし、そもそも音声を表すためのデータでもありません。
「楽譜」と「音声」の区別ができない人にとっては、「文字」と「画像」の区別がつかないのかもしれませんが、
＞文書ファイルに関しても同様なことが起きたりはしないのかな。
なんてことは有り得ないから安心してください。

0270デフォルトの名無しさん

2006/09/23(土) 22:43:07

MIDIプレーヤーで使う音色データのことをサウンドフォントって言うでしょ?
> じゃありませんし、
> でもありません。
言葉尻をとらえられないように逃げるのがお上手ですね。
> 「楽譜」と「音声」の区別ができない人にとっては、
> 「文字」と「画像」の区別がつかないのかもしれませんが、
Web上で「楽譜」を配る習慣がなくなったように「文字」を配る習慣がなくなる
んじゃね? って言ってるだけですが何がそんなに気にくわないのですか?

0271デフォルトの名無しさん

2006/09/23(土) 23:08:40

たとえばMSXとか何かで、MMLで、音楽書いてた人じゃない？
「MML」はテキストデータ。それをコンパイルして、「標準MIDIファイル」。

MIDIのネットでのやり取り、昔に比べたら、確かに廃れたけどね…。
でも、DTM板やら作曲板やらでは、まだまだ現役。

0272デフォルトの名無しさん

2006/09/23(土) 23:32:56

>>270
だから、楽譜を配る習慣はなくなってないだろ。
尤も、楽譜は一般人は見る機会が少ないから目立たないわけで、
それを言うなら一般人が文字を見る機会が少なくなるとは思えんが。

0273デフォルトの名無しさん

2006/09/24(日) 01:04:05

MIDIが廃れたのはJASRACの影響が大きいかと　スレ違いsage

0274デフォルトの名無しさん

2006/09/24(日) 17:10:58

これからはoggの時代

0275デフォルトの名無しさん

2006/09/24(日) 22:24:57

MODてのもあったな
文字情報もベクトルフォント込みになって
文字列比較も類似性で行なうようになるのか?

0276デフォルトの名無しさん

2006/09/25(月) 08:06:28

>>270

MIDIデータをCDやmp3等のような音楽観賞用のデータだと
勘違いしているから、そういった誤解も生まれるんだよな。

MIDIデータは、楽器を鳴らすためのデータであって、音楽を
作成する人にとっては、いまでも現役。

昔はPCの能力（mp3エンコード時間）や回線の細さなどの問題
から、観賞用にもファイルサイズが小さくてすむMIDIデータ
形式での配布が多かっただけで、それが元に戻っただけ。

昔はGPLなソフトは、ほとんどソースでしか配布されてなかったけど
いまは普通にバイナリも配布されているのと似ている。

0277デフォルトの名無しさん

2006/09/25(月) 08:10:34

>>273
それは mp3とかも同じだと思うよ。

逆に他音源からのリッピングなどが多いmp3と比べて、自分で打ち込むMIDIのほうが
著作権処理は楽。

0278デフォルトの名無しさん

2006/09/27(水) 01:27:29

メールに使われている文字はJISコードでemacsというかUNIXで使われているのは
EUCなのに文字化けせずにコピペできるっていうのは内部で変換されているのでしょうか?
それかまったく違うことをしているのか

0279デフォルトの名無しさん

2006/09/27(水) 01:38:33

>>278
ケース1
メールソフトはEUCに変換してからGUIに表示してもらっている。
コピー要求に対しても、EUCに変換済みの文字を渡している。

ケース2
メールソフトは変換せずにGUIに変換して表示してもらっている。
コピー要求に対しても変換せずに渡し、後はGUI側に任せている。

たまに臍曲がりなGUIとアプリケーションの組み合わせで文字化けが発生するのは
例えばケース1で表示には変換済みを渡すのにコピーには未変換を渡すようなことをしているから。
その場合でも、GUI側が自動変換するなりペースト側アプリが自動変換するなりすれば化けずに済むが。

0280デフォルトの名無しさん

2006/09/27(水) 02:00:43

>>278
Emacsの内部は独自コード。

Emacs外とのやり取りでは外の事情に合わせた文字コードを使うことができる。
つまり変換する。

コピペはX11とのやりとりになるが、
X11はC-TEXT(compound text)を使う。

0281デフォルトの名無しさん

2006/09/27(水) 02:18:27

279>>
280>>
なるほど。GUIやアプリ両方でやってるんですね。。。
勉強してきます。ありがとうございました。

0282デフォルトの名無しさん

2006/09/30(土) 07:44:48

ISO/IEC 10646:2003の無償化キター
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
U+29FCEの字形は古いままなのでAmendmentは含まれていない模様

0283デフォルトの名無しさん

2006/10/05(木) 11:31:53

libiconv がサポートしている文字コードの一覧を得るための
関数って、 libiconv 自体には用意されていますか？

0284デフォルトの名無しさん

2006/10/05(木) 11:40:11

iconv.h 眺めてると iconvlist() つー関数があるみたいですね。

0285デフォルトの名無しさん

2006/10/08(日) 07:33:00

プラットフォーム依存の話になりますが MS のコードページ一覧によると
http://windowssdk.msdn.microsoft.com/en-us/library/ms776446.aspx
20000 x-Chinese_CNS CNS Taiwan; Chinese Traditional (CNS)
20002 x_Chinese-Eten Eten Taiwan; Chinese Traditional (Eten)
となっています。しかし .NET Framework 2.0 で各コードページについて
EncodingInfo.Name を取得すると上記はそれぞれ x-Chinese-CNS,
x-Chinese-Eten となり "_" と "-" が一致しません。いずれも
x- ですから IANA には登録されていません。エンコード名として
何が正しいのでしょうか？何に依拠すべきでしょうか？

0286デフォルトの名無しさん

2006/10/08(日) 09:26:16

IANA未登録のエンコーディング名称に付けるのは"x-"ということになってる。
"x_"ではない。実際に取れるものも"x-"ならそれでいいんじゃないの。

0287デフォルトの名無しさん

2006/10/08(日) 10:21:04

一方はそれでいいとして、

0288デフォルトの名無しさん

2006/10/08(日) 13:37:26

MIMEなんかで使う時には、

X-x_Chinese-Eten

としなければ仕方ないだろ。

0289デフォルトの名無しさん

2006/10/12(木) 11:23:10

locale -m で表示される charset 一覧の文字コード名って、
何を元にして生成されているんですか？
特に Linux (Debian GNU/Linux, Fedora Core 5) を想定しています。

iconv や ICU で受付可能な文字コード一覧と照合したいんですが、
ポータブルに書くために特定のマシンの locale -m の出力を
ハードコーディングすると言うことは避けたいと思っています。

0290デフォルトの名無しさん

2006/10/12(木) 11:59:18

/usr/share/i18n/charmaps/*とか
詳しくはlocaleコマンドのソース読め。

0291デフォルトの名無しさん

2006/10/12(木) 20:44:29

IBMのICUについて語りたいんですが
どこのスレに行けばいいですか？

0292デフォルトの名無しさん

2006/10/13(金) 02:37:33

>>291
2chじゃなくてもいいならcppllにでも逝け。

0293デフォルトの名無しさん

2006/10/13(金) 12:24:40

>>291
遠慮なくここで語ってくれたまえ。

0294デフォルトの名無しさん

2006/10/17(火) 03:56:06

vine3.2 gcc 3.3.2
の環境で以下のソースをコンパイルして、ターミナルで実行しても
何も出力されません。

#include <iostream>
#include <locale>

using namespace std;

int main()
{
locale jp("japanese");
wstring str = L"漢字";
wcout.imbue(jp);
wcout << str << endl;

return 0;
}

eucjpに変換された"漢字"が出力されるのかと思ったのですけど。

0295294

2006/10/17(火) 05:04:44

windowsXPだと正しく動作するのですけどね。

0296デフォルトの名無しさん

2006/10/17(火) 05:36:40

Vine3.2のwchar_tってUnicodeなの? EUC fixed widthだったりしない?
Windowsばかり使ってるとwchar_t=Unicodeと思い込みがちだけど

0297デフォルトの名無しさん

2006/10/17(火) 14:41:14

>>296
確かに、Vine3.2は未だ内部コードにEUCJPを使っています。
それは私も知っていました。
しかし、wchar_tがUCS2(もしくはUTF16)でないとは。

今までASCIIしか使っていなかったので知りませんでした。
仕様ではwchar_tが2バイト文字だとしか言及されていないのですね。

扱いづらいような・・・・・。

0298デフォルトの名無しさん

2006/10/17(火) 16:04:06

sizeof(wchar_t)くらい実行してみろ。

0299デフォルトの名無しさん

2006/10/17(火) 18:31:44

>297
wchar_tが2バイトということすら規定されていない。
いずれかの整数型と等しいと規定されているだけ。

現実にはUTF-16かUTF-32（或いはUCS2/UCS4）の実装が多いと俺は思っているけど。

0300デフォルトの名無しさん

2006/10/17(火) 20:22:48

> 現実にはUTF-16かUTF-32（或いはUCS2/UCS4）の実装が多いと俺は思っているけど。
最近はLinuxもUTF-8ロケールが増えつつあるしおおむねそういう手抜きができるように
なってきたと思うけど一昔前の日本語UNIX環境ではまったく正しくなかった。
ちなみにUCSであることを保証したければ__STDC_ISO_10646__というマクロがある。

0301297

2006/10/17(火) 22:53:36

linuxだとwchar_tは4バイトなんですね。
そういえば以前にD言語をいじったときに知ったのでした。
それにしても、wstring::findの返り値も実装ごとに違うよ
うですし、ワイド文字の扱いって大変そうですね。
指針がないかちょっと調べてみます。

もし参考になるサイト等ございましたら教えて頂ければ幸
いです。

0302297

2006/10/17(火) 23:12:24

早速参考になるサイトを発見しました。
http://eside.homeip.net/columns/i18n.html

プラットフォームの違いを吸収するような方法は無いということですか。
古い記事ですが。

0303デフォルトの名無しさん

2006/10/20(金) 12:06:10

>>294
libstdc++はimbueに対応していないっぽい。
代わりに大域ロケールをセットすれば良い。
それから、"japanese"というロケールは普通ないので、
"ja_JP.eucJP"とか""とかを使う。

#include <iostream>
#include <locale>

using namespace std;

int main()
{
locale::global(locale(""));
wstring str = L"漢字";
wcout << str << endl;

return 0;
}

0304デフォルトの名無しさん

2006/10/20(金) 12:40:56

codecvtクラス使ってくれ。@libstdc++

0305デフォルトの名無しさん

2006/10/20(金) 20:16:14

そもそもワイドキャラの定義ってなんだったっけ？
ワイドキャラ=UCS2&UTF-16のBMPでいいんだっけ？

0306デフォルトの名無しさん

2006/10/20(金) 20:25:53

実装依存。
WindowsではUTF-16だしglibcではUTF-32(UCS-4だったか？)。

0307デフォルトの名無しさん

2006/10/20(金) 23:12:01

TRONコード入れてたり、JISコード入れてたり、なんでもありだね。

0308デフォルトの名無しさん

2006/10/20(金) 23:16:36

>>305
>>299
C/C++のwchar_tはいずれかの整数型と互換であるということが定められているだけ。

0309デフォルトの名無しさん

2006/10/20(金) 23:33:46

しかし、実装毎にワイドキャラの文字コードはなにかっていうのは
定められてないとまずいよね？じゃないとisalphaとかの実装は文字コードに
依存してるからまずそうだし。
つーと当面はWinのワイドキャラ=UTF-16、Linuxのワイドキャラ=UTF-32
で想定してればOK?
でも、Linux上でUTF-16のisalphaみたいなのは変換するか、実装するかしか
ないということか。。

0310デフォルトの名無しさん

2006/10/20(金) 23:40:41

>>309
wchar_tの中身のエンコーディングが何であるかは
処理系が知っていればいいことであって、
プログラマが関知すべきことではない。
wchar_tのエンコーディングに依存するコードは
書くべきではない。原則的にはな。

実用上はWindows:UTF-16、Linux:UTF-32と考えてまあよし。

0311デフォルトの名無しさん

2006/10/20(金) 23:41:12

みんな -fshort-wchar しちゃえばいいのに

0312デフォルトの名無しさん

2006/10/21(土) 00:36:58

>>310
うーん、そしたらさ、isalphaはAsciiコードに依存してるのと同じで
iswalphaはUTF-16というコードに依存してる(Winの場合)ということにならない？

0313デフォルトの名無しさん

2006/10/21(土) 00:51:09

>>312
iswalphaの実装は文字コードに依存していてもいいじゃん。
Ｃランタイムライブラリの一部なんだから。
プログラマが、wchar_tで使われている文字コードを仮定した
コードを書くべきでないということ。

0314デフォルトの名無しさん

2006/10/21(土) 01:25:02

>>313
Winでwchar_tが将来4バイトに拡張されたときにもプログラムは正しく
動くことが理想ってことだよね。
そうすると、UTF-16のファイルをwchar_tに収めるってのもまずいことになる？
あれ、なんかよくわかんなくなってきたな。

0315デフォルトの名無しさん

2006/10/21(土) 01:30:16

将来的にも、もしくはWin/LinuxのクロスでUTF-16を処理する方法って
何が正しいことになるんだ?wchar_tのサイズが未定義ってのが問題なのかな。
なんとなくchar*で持って、結局is系とかは自前で実装というはめになりそう
な気がするが。。

0316デフォルトの名無しさん

2006/10/21(土) 05:17:55

イムブエって
何の略で
あんな
名前？

0317デフォルトの名無しさん

2006/10/21(土) 05:39:59

>>310
FreeBSDは今でもCoding System Independentな実装になってるな
>>315
処理系依存の方法しかない。
>>316
略語じゃなくて染める、吹き込むという意味の英単語

0318デフォルトの名無しさん

2006/10/21(土) 09:15:44

wとか16とか32とか固定と勘違いしそうな名前付けるからいかんのだよ。
char_xp とかUTFVista とかつけとけばよかったんだ。

0319デフォルトの名無しさん

2006/10/21(土) 10:17:34

>>318
何だその無駄に重たそうな名前は(w

0320デフォルトの名無しさん

2006/10/21(土) 11:14:18

じゃあ char_podとか、char_DSとか

0321デフォルトの名無しさん

2006/10/21(土) 11:31:00

なにがおもしろいんだ
馬鹿

0322デフォルトの名無しさん

2006/10/21(土) 12:37:04

>>314
それが理想なんだけど、実際はそうなっていない。
whar_tの表現は内部エンコーディング(プログラムの実行中にその内部処理用と
してだけ使われるべきもの)であるべきだけど、コンパイラが生成する
オブジェクトファイルがwchar_tの表現に依存してしまっているので、
外部に露出してしまっている。
それはオブジェクトファイル内のワイド文字列リテラルのエンコーディングも
そうだし、プログラム内でwchar_tを直接触る部分もやはりwchar_tのサイズに
依存したコードにコンパイルされるというのもある。

これを防ぐにはワイド文字・ワイド文字列へのアクセスを全てAPI経由にし
文字列リテラルも、UTF-8等の外部エンコーディングで入れておいて
プログラムの初回参照時に変換するようにしていれば、
将来の拡張や変更にも耐えられたんだけど。
今から見ればどうってことない方式だけど、当時、しかもC言語の人間に
とってはコスト過多に思えて採用しがたかったかも。

せめてwchar_tが十分大きければwchar_tを直接触るのを許してもエンコーディング
の変更や拡張に耐えられたけど、2byteじゃやはり駄目だね。

>>317
しかしgccがFreeBSDやNetBSDのwchar_t表現に(たしか)対応していない罠……

0323デフォルトの名無しさん

2006/10/21(土) 12:49:19

もうchar*にUTF-8入れとけばいいよ。
ワイド文字は幻想だったのさ。

0324デフォルトの名無しさん

2006/10/21(土) 13:36:37

> それはオブジェクトファイル内のワイド文字列リテラルのエンコーディングも
> そうだし、
ソースファイルのエンコーディングと処理系が扱うエンコーディングは
別じゃなかったっけ? 少なくとも仕様上は。
> wchar_tのサイズに依存した
サイズに依存しちゃいけないのはwchar_tに限った話じゃないような。
C99ではサイズを明示した整数型が追加されたけど。
> もうchar*にUTF-8入れとけばいいよ。
しかしWindowsが対応してない罠

0325デフォルトの名無しさん

2006/10/21(土) 20:34:42

>>324
ソースコードじゃなくてコンパイラが作るオブジェクトファイルの話なんだけど。

0326デフォルトの名無しさん

2006/10/21(土) 20:35:38

> 処理系が扱うエンコーディングは

0327デフォルトの名無しさん

2006/10/21(土) 20:41:27

UCS2まんまぶち込んで置けばそれなりに使えるんじゃね？
API呼ぶ時に変換しなきゃいけないだろうけど

0328デフォルトの名無しさん

2006/10/21(土) 21:47:30

文字集合とエンコーディングってのは、ごっちゃになりやすいのかねぇ
内部表現は UCS-4、外部表現は UTF8 ってのが普及して欲しい
んで、適宜 SJIS や EUCJ への変換もサポートすると

0329デフォルトの名無しさん

2006/10/21(土) 21:55:02

JavaとかC#はその点いいよね。やっぱり、言語の設計段階から
文字列の扱いについて考慮しとかないといかんよな。
後追いだと、Pythonのようにunicodeオブジェクトを導入するくらいしか
ないのでは。

0330デフォルトの名無しさん

2006/10/21(土) 22:23:05

意味不明

0331デフォルトの名無しさん

2006/10/21(土) 23:06:02

Solarisが大昔から文字コードに何を指定してもisalpha()が働くような実装持ってるがな。

■ このスレッドは過去ログ倉庫に格納されています