文字コード総合スレ part3

文字コード総合スレ part3 at TECH

1:デフォルトの名無しさん
07/05/27 16:19:36
プログラムにおける各種文字コードの処理について語りましょう♪

■前スレ
文字コード総合スレ part2
ｽﾚﾘﾝｸ(tech板)

■参考サイト
Unicode Home Page
URLﾘﾝｸ(www.unicode.org)
Java Character Encodings
URLﾘﾝｸ(www.ingrid.org)
euc.JP: tech docs, BeOS tools
URLﾘﾝｸ(euc.jp)
ISO-IR - 2.8.1 Coding systems with Standard return
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
ISO-IR - 2.8.2 Coding Systems without Standard return
URLﾘﾝｸ(www.itscj.ipsj.or.jp)

2:デフォルトの名無しさん
07/05/27 16:31:01
漢字袋
URLﾘﾝｸ(kanji.zinbun.kyoto-u.ac.jp)
池田証寿
URLﾘﾝｸ(homepage3.nifty.com)

3:デフォルトの名無しさん
07/05/27 16:41:09
■過去ログ
※◆ゲイの美容◆※ 01/01/21-01/01/23 <9>
URLﾘﾝｸ(yasai.2ch.net)
ゲイの美容版・・・・・・ 01/07/17-01/07/22 <17>
URLﾘﾝｸ(yasai.2ch.net)
ゲイの美容第３弾！ 01/08/14-01/08/28 <28>
URLﾘﾝｸ(yasai.2ch.net)
ゲイの美容第６弾！ 01/11/21-01/11/27 <7>
URLﾘﾝｸ(yasai.2ch.net)
ゲイの美容 00/09/25-00/12/05 <981>
URLﾘﾝｸ(piza.2ch.net)

4:デフォルトの名無しさん
07/05/28 20:22:23
携帯でJIS X 0213の字使えるようにならないかな?

5:デフォルトの名無しさん
07/05/28 20:30:52
それは絶対無理

6:デフォルトの名無しさん
07/05/29 05:29:15
Shift_JIS-2004実装なら可能なんじゃね?
iモード絵文字つぶしてそんな実装することはありえないと思うけど

7:デフォルトの名無しさん
07/05/29 18:59:37
ASCII廃止されねーかな

8:デフォルトの名無しさん
07/05/31 17:45:05
JIS X 0213を語呂合わせで「おにいさん」と呼んでるのは俺だけでしょうか?

9:デフォルトの名無しさん
07/05/31 17:53:50
>>8
すれ違い。そういうのはこっちで。

UnicodeとUTF-8の違いは？
ｽﾚﾘﾝｸ(tech板)

10:デフォルトの名無しさん
07/05/31 19:42:07
日本のCJK Ext.D Submissionに{魚針}が含まれてる件

11:デフォルトの名無しさん
07/05/31 20:39:41
サヨリだったか？

12:デフォルトの名無しさん
07/05/31 20:40:04
針魚

13:デフォルトの名無しさん
07/06/01 01:02:24
884 名前：デフォルトの名無しさん[] 投稿日：2007/03/23(金) 20:48:30
他にVSで表す包摂扱いの字体差が大きい異体字には
何でよく見るのにJIS X 0213にも拡張Bにも無いんだろうと思ってた「撥」の拡張新字体なんかもあった。
「痙」の拡張新字体もあるがこれは中国簡体字のU+75C9に包摂するべきでは?「径」は中国の簡体字(旁がスの下にエ)と包摂されてるし。
「門」の手書きでよく使われる略字もあるが、これも「門」よりも中国簡体字のU+95E8のほうが近いからそっちの方が良いと思う。
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。

中国ではってレベルじゃねーぞ。
まあU+9FBC～U+9FC2に追加されるはずの7文字もなぜか全部Unicode Submissionに
含まれてたりするからこれから精査して落とすんだろうけど。

14:デフォルトの名無しさん
07/06/01 23:26:30
意味でUnifyしたらだいぶ減るな

15:デフォルトの名無しさん
07/06/02 20:15:29
Unicodeの14面の制御符号って今後増えるのかな?

16:デフォルトの名無しさん
07/06/02 20:31:38
2ちゃんねるVSハンガリー国家！？
一番クリックした国が優勝
ハンガリーではニュース、新聞などによる報道もあり、日本は苦戦を強いられています。
皆さんも、PCひとつで簡単にできますので、ご協力お願いします！
URL貼れないので、VIPにある本スレ(クリックでスレタイ検索)に来ていただけるとありがたいです
理系の方などでクリックツール作成支援者も募集中です！

17:デフォルトの名無しさん
07/06/03 13:17:37
>>15
VSが足りなくなったら増えるんじゃね?

18:デフォルトの名無しさん
07/06/03 14:00:37
KPS 9566-2003の仕様書手に入らねえかなぁ

19:デフォルトの名無しさん
07/06/03 21:16:17
VSが256個で足りなくなったらVS-257～をVS-256の次から追加するとか。
でも一つの文字に256以上異体字があるなんて考えられんな。まあ、漢字で止める払うはねるとか点の向きとか厳しく区別すればすぐパンクするだろうが。
U+E0020～U+E007Eにあるタグ専用の文字も非ASCIIに対応するのが追加されるかも知れん。

URLﾘﾝｸ(www.jagat.or.jp)
ここ見るとルビタグも提案されてたらしい。どうなったかは知らんが。
ひょっとしたらフォント指定とかサイズ指定の為のコードも追加されるかも?

20:デフォルトの名無しさん
07/06/03 22:34:37
色指定とか太さ指定とか傾き指定のコードとか！

21:デフォルトの名無しさん
07/06/04 01:40:27
>>19
渡辺の辺の難しい奴はAJ16ですでに17個あるし文字鏡やGTには60個以上登録されてる
から日本語の人名異体字を含む大規模文字セットがIVDを使おうとか考え始めたら
案外簡単に突破するかも。
千寿とか万寿を符号化するにはVSが1万個必要だし。こんなジョーク文書もあった。
Proposal: Use full plane-13 for the Han variation selector
URLﾘﾝｸ(std.dkuug.dk)
ルビタグはBMPにとっくに入ってる。

22:デフォルトの名無しさん
07/06/04 15:14:08
確か甲骨文字とか変体仮名とかは統合漢字に包摂されてたな。
ならそれらも将来的にはVSで規定されるかも?

23:デフォルトの名無しさん
07/06/05 05:04:35
甲骨文字は、典拠があるものに限って別に収録される予定。すでにIRGにも提出されてる。
ただし統合漢字のコードポイントで表すこと(つまり金文体フォントのようなものを実装すること)
は妨げない

24:デフォルトの名無しさん
07/06/06 00:47:01
ھەرپ ۋە بەلگىگە بىردىن نومۇر بېرى

25:デフォルトの名無しさん
07/06/07 01:59:05
WG2でこれは統合できるだろ、というツッコミが多数来てExt.CがIRGに差し戻されたけど
各国からこれは人名用だ、という反論が多数来てとうとうこんな文書が出てきた
URLﾘﾝｸ(www.cse.cuhk.edu.hk)

26:デフォルトの名無しさん
07/06/08 22:21:49
とあるプログラムが、ASCIIにしか対応していないハズなのですが、
UTF-8Nを渡しても、正常に動いているように見えます。

本稼働用に、動作確認したいのですが
そこで、ASCIIしか考慮してない場合に渡すとまずい
UTF-8Nの文字はありませんか？

27:デフォルトの名無しさん
07/06/08 22:26:37
>>26を試した文字は、
「ソースコード」や「表示」などのSJISではASCIIにすると文字化けになる文字です

28:デフォルトの名無しさん
07/06/08 22:37:55
MSBが立ってる文字に対して特別扱いしてないなら、文字単位の処理さえなければ大丈夫の可能性が高い。(grepとか)
文字列を分割したり途中を切り出してたりしてるプログラムなら、おかしくなり得る。

29:デフォルトの名無しさん
07/06/08 22:47:54
26でUTF-8と言っておきながら、27でShift_JISの文字を例に挙げるとはよくわからない

30:デフォルトの名無しさん
07/06/08 23:19:50
>>28
なるほど、切り出したり特殊な加工をしないかぎりは大丈夫ですか

>>29
いや、たまたま知っていた文字コードを入力してみただけですので・・・

31:デフォルトの名無しさん
07/06/09 00:04:26
>>26
ASCII じゃなくて Latin-1 で大丈夫なプログラムなら、
大抵は問題になる事はないと思われ。

7 ビット ASCII しか考慮してない場合は、
char が符号付きで、その値を unsigned char にキャストすることなしに
int にする処理が書いてあった場合、
8 ビット目のある文字を渡すと負の値になって、
それでおかしくなる可能性はある。
Latin-1 対応なら、このあたりちゃんと処理してるかと。

UTF-8(N) は多バイトの場合全部 8 ビット目が立ってるから、
Shift-JIS みたいに 2 バイト目が \ になるかも・・・とかそういう事は起こらない。
ただ、もちろんこの文字を途中でぶった切るようなことをしたら、変になる可能性はある。

普通の検索は確か問題なかったと思う。
でも、正規表現には、 . が一文字じゃなくて一バイトという扱いになってしまうとか、影響がある。

32:デフォルトの名無しさん
07/06/09 02:18:40
80カラムにそろえるプログラムはおかしくなる。
バイトストリームとして扱うか、文字として扱うかによって違う。

33:デフォルトの名無しさん
07/06/09 02:58:15
日本でメールは76桁で折り返せという慣習になってるのは
ISO-2022-JPのメッセージを80桁の端末に表示してるとき途中に折り返しが入ると
表示がおかしくなる可能性があるからだったな
そういう心配のない欧米ではquoted-printableを使ってた

34:デフォルトの名無しさん
07/06/09 07:20:16
そんな慣習がまかり通っていた頃に、quoted-printableはなかったよ。
大型機がやっているMTAに勝手に折り返すのが昔あったらしい。

35:デフォルトの名無しさん
07/06/09 22:53:13
>>34
RFC1468でquoted-printableに言及してる。それは使わず75桁で折り返せと。
(今読み返したら76じゃなかった)

36:デフォルトの名無しさん
07/06/10 18:39:07
>>31
詳細な解説、参考になりました。

Latin-1対応？というのが気になりますが、8bitを意識していないかどうか、
プログラム次第ということですね。

正規表現が問題あるのは痛いですね。（というか、そりゃそうだわな・・・）

37:デフォルトの名無しさん
07/06/10 20:06:25
/あ.う/ は "あいう" にはマッチしない。
"い" が 3 バイトだから。
/あ...う/ なら引っかかる。
全角文字は大体 3 バイトだから、実用上は困らないかもしれない。
ギリシャ文字やキリル文字みたいに 2 バイトのものもあるけど。
/あ.*う/ は /あいう/ にひっかかるけど、/あえいう/ にも引っかかる。

ただ、/あ.う/ として、. が多バイト文字の 1 バイト目に引っかかることはないはず。
多バイト文字の 2 バイト目以降は、1 バイト目と必ず違うようになってるから。

38:デフォルトの名無しさん
07/06/10 20:16:02
いつも思うんだが、

「75カラム（桁）で」というのはMUAにおける表示の問題だけだと思っていいのかな?
ISO-2022-JPだと制御文字が入るからバイト数的には75を超えてしまうわけだが、
それによって影響を受けるMUA/MTAがあったりするんだろうか?

そもそもカラム（文字列幅?）って概念は明確に定義されてる?

39:デフォルトの名無しさん
07/06/10 21:48:45
>>38
80桁の端末での表示上の問題だから表示されないものはカウントしない
当然プロポーショナルフォントなんて高級なものは想定してない

40:デフォルトの名無しさん
07/06/13 03:27:09
>>26の件ですが、プログラム側にUNICODE対応のモードがありまして、それが無事に動きました。
お騒がせしてしまいました。

プログラムは、Squirrelっていう組み込みのスクリプト言語です。

ちなみに、このプログラムは、非UNICODEの場合でも、UTF-16 BOM付きUTF-8BOM付きの読み込みをサポートしているのですが、
UTF-16だと、読み込み時に wchar_t を charに変換するので、
読み込みで、エラーが出なくても
実質日本語が使えないという、困ったチャンでした。
（困ったチャンというか、その実装なら当り前ですけど）

>>37
なるほど、正規表現だとそういうことになるんですね。

41:デフォルトの名無しさん
07/06/13 08:19:59
>>35
RFC1468って1992年でしょ。
quoted-printableって用語がMIMEだからこれも90年代入ってからだし。
そんな最近の話じゃないよ。

行折り返しが問題になるのは、端末の問題じゃなくて、
ISO-2022-JP(元々JUNETコード)が行末でASCIIに戻すと規定されていたから。
ところが例えば大型で動いているMTAの中には、(BITNETとか)
80カラム以上あると、行を分割したり、切り捨てたりするヤツがいたから、
ISO-2022-JPを考慮しなければ、ISO-2022-JPでなくなってしまう。

42:デフォルトの名無しさん
07/06/13 21:46:04
>>41
ということは、もしその手のMTAのことを今でも考慮するとしたら80「桁」以内じゃなくて
「バイト」以内で折り返さないとまずいということになるんですかね?
特にISO-2022-JPだとエスケープシーケンスが入るから前者と後者は明らかに
違うわけですが。

個人的にとあるMUAに関わっているんですが、非日本人の開発者／ユーザも
もいるので（てゆうか彼らがメインだったりしてw) この手の処理をどうするか
悩ましかったりします。

43:デフォルトの名無しさん
07/06/15 05:39:20
>>41
行末でASCIIに戻るのは原因と結果が逆のような。
そういう動作をする端末だかMTAだかが存在したからそう規定されたんでしょ

44:デフォルトの名無しさん
07/06/15 08:31:30
規定されれば、次はそれが何かの原因になることもあるだろ？

45:デフォルトの名無しさん
07/06/16 20:51:50
そのために「慣用的な利用との互換性を目的としてだけ」とか但し書きが付くわけだが
(RFC1468には付いてないけど)読まない奴はいるしな

46:デフォルトの名無しさん
07/06/17 07:39:20
>>42
今はMIMEに従えばいいじゃん。
MUAが行を折り返すのは、余計なお世話だな。

47:デフォルトの名無しさん
07/06/18 18:23:23
>>46
>今はMIMEに従えばいいじゃん。
えっと具体的にはMIMEの何に従うということですか?

>MUAが行を折り返すのは、余計なお世話だな。
自分も個人的には改行は手で入れたい派なんですが、
ユーザーからの要望で自動改行機能を付けていたりします。

48:デフォルトの名無しさん
07/06/18 18:33:39
OpenOfficeの最新バージョン(2.2)ではサロゲートペアにほぼ完全に対応してた。
(これ迄のバージョンではBMP外の文字は送り幅が変だったりもっと昔のバージョンでは保存したとき消失したりしてた。)

49:デフォルトの名無しさん
07/06/18 19:07:29
自動折り返しを実装するなら、まともな挙動にしてほ
しい。
こんな滅茶苦茶な改行には、ほとほとうんざりしてい
る。

50:デフォルトの名無しさん
07/06/18 19:10:28
そんなの未だいいじゃん
。こんな改行された日に
ゃ……誰かの台詞じゃ
ないけれど、「泣ける
」。

51:デフォルトの名無しさん
07/06/19 00:26:43
>>49
あれ、この処理じゃ駄目ですか?

>>50
要は禁則処理が必須ってことですか。
国際化されたMUAでそれをちゃんとやろうとすると自明じゃないですね。
文字コードスレの範疇を超えてるかもw

52:デフォルトの名無しさん
07/06/19 18:11:09
禁則処理はDTP（もしくはエディタ）のレベルでそ

53:デフォルトの名無しさん
07/06/19 22:30:59
Windows Vistaの文字コードについて質問なのですが。
「VistaはShift_JIS-2004に対応」って記事を見かけるんですが、
これは「JIS X 0213:2004」の字体がUnicodeから使えるという意味であって、
Shift_JIS-2004の文字コードでの編集や保存に対応してるということではないですよね？
業務用のテキスト処理のソフトをつくるのに確認したいのですが、実機がなくて。

54:デフォルトの名無しさん
07/06/19 22:32:33
いや買ってこいよ

55:デフォルトの名無しさん
07/06/19 22:54:35
じゃあ、お金くださいよ

56:デフォルトの名無しさん
07/06/19 23:00:55
業務用開発でそんな金すら出ないってなんだよ

57:デフォルトの名無しさん
07/06/20 00:06:16
>>53
> 「VistaはShift_JIS-2004に対応」
その記事書いた奴が何か勘違いしてるか
その記事を読んだおまえが何か勘違いしてる

58:デフォルトの名無しさん
07/06/20 00:16:39
ちょっと板違いかもしれませんが文字コードっぽいスレを
みつけられなかったのでここで失礼します。

だれかがsvnにcommitしたファイルが、英文字が全部

esc ( J "hoge" esc ( B

みたいにiso-2022みたいなエスケープでかこまれてしまい、
diffが取れなくなって困ってるのですが(他にもemacsで
C-sで検索が利かなくなったりとか)、

1. これは何というコードでしょうか？
2. どうやったら元に戻せますか？
(ascii文字セットで表現できる範囲はasciiに)
3. いったい何をどうやったらこんなふうになるんでしょうか？

諸賢のアドバイスをお願いします。また、もっと良いスレがあったら
誘導お願いします。

59:デフォルトの名無しさん
07/06/20 00:23:00
ESC ( J は JIS X 0201-Roman だな。
きっと backslash のかわりに円記号が使いたかったんだろう。

60:デフォルトの名無しさん
07/06/20 00:25:50
もしくは tilde の代わりに overline 使いたかったか。

61:デフォルトの名無しさん
07/06/20 00:52:12
ありがとん。
結局一旦日本語部分はEUCにして、残ったescape sequenceを
scriptでがっさり削って解決しました。

62:デフォルトの名無しさん
07/06/20 21:51:46
>>59-60
HTMLエディタには ESC ( J を使うものが多いらしい
しかしURLの中の 0x7E は tilde のつもりだし
JavaScriptのエスケープも backslash のつもりらしい

63:デフォルトの名無しさん
07/06/22 09:26:11
　すいません、はげしく既出だと思うんですが過去ログとか読めなかった
ので質問させてください。
　C++上でUTF8をbasic_stringのように扱えるクラスかテンプレートで
フリーで使える奴ご存知の方いらっしゃいませんか？
　コンストラクタでUTF8の文字列をchar配列みたいな感じで受け取って、
[index]や*単項演算子でデコードした文字コード出てくる感じのがある
とベストなんですが・・・。

64:デフォルトの名無しさん
07/06/22 09:39:38
lib.locale.codecvt + basic_string<wchar_t>

65:デフォルトの名無しさん
07/06/22 17:28:50
すみません。教えてください。
あるプログラムに
0xB4 0xC1 0xBB 0xFA
のEUC-JP文字列("漢字")を渡すと、
0xC2 0xB4 0xC3 0x81 0xC2 0xBB 0xC3 0xBA
のようになってしまいます。
自分で見たてでは 0xC2が横につく,または,0x40を引いて0xC3を横につける
という感じみたいなのですが、
何故こうなるのでしょうか。またその他の規則があるのでしょうか。

66:デフォルトの名無しさん
07/06/22 18:22:49
あるプログラムって？

67:デフォルトの名無しさん
07/06/22 19:15:09
tidy-libを使ったプログラムです。rawで読み込みさせてます。

68:デフォルトの名無しさん
07/06/22 22:18:07
バベルのとーにすんでいるー

69:デフォルトの名無しさん
07/06/23 06:55:12
>>65

Latin-1 から UTF-8 への変換がかかってるだけ。

70:デフォルトの名無しさん
07/06/23 08:08:04
ほんとだ、iconv -f latin1 -t utf-8したら再現した。

71:デフォルトの名無しさん
07/06/23 08:10:19
バビル二世現る

72:65
07/06/23 08:57:50
>>69
> Latin-1 から UTF-8 への変換がかかってるだけ。

おお、ありがとうございます。

>>70
iconvでたしかめたところ再現しました。

libiconvを使ってやるといけそうです。ありがとうございました。

73:デフォルトの名無しさん
07/06/24 21:48:41
Unicode 吉野屋コピペを Flash 化してみた。
URLﾘﾝｸ(www5a.biglobe.ne.jp)
超古いネタですまん。

74:デフォルトの名無しさん
07/06/25 20:38:37
ポイント制で文字コードを判別するアルゴリズムってどんなライセンスなんですか？

75:デフォルトの名無しさん
07/06/25 20:47:26
>>74
アルゴリズムとライセンスは別の話だろ？　いったいおまいさんはなにを訊きたいんだ？

76:デフォルトの名無しさん
07/06/25 21:25:04
アルゴリズムの特許が認められているので、
アルゴリズムにライセンスがある場合はある。
アルゴリズムにはコピーライトがない。
プログラムにはコピーライトがある。
>>74が何を聞きたいか分からない。

77:74
07/06/26 01:03:32
じゃ、大幅に言い換えて

sakuraエディッタのソースを参考に文字コード判別モジュールを作ったんですが
これを含んだプログラムを素知らぬ顔で配布しちゃったらなんかやばい事になりますか？　または
作者さんに配布の是非を問えば「No」とか「金払え」みたいな回答が高い確率で返ってくるでしょうか？

78:デフォルトの名無しさん
07/06/26 01:33:59
>>77
sakuraエディッタとやらのライセンスを読めよ、馬鹿。　以上、終了。

はい、次の患者さんどうぞ。

79:デフォルトの名無しさん
07/06/26 01:37:53
>>77
URLﾘﾝｸ(sakura_editor.at.infoseek.co.jp)

80:デフォルトの名無しさん
07/06/26 01:39:19
まずはsakuraのライセンス確認したら？

81:デフォルトの名無しさん
07/06/26 02:09:25
つーか「参考に」だけでどの程度類似してるか判断できると思ってんのか

82:デフォルトの名無しさん
07/06/26 06:56:15
文字コード関係ないやん。
nkfのコードならコピーライト表示するだけでコピー自由。

83:デフォルトの名無しさん
07/06/28 09:37:25
>>73
ワロッシュw

84:デフォルトの名無しさん
07/07/01 12:25:27
C/C++言語で　UTF-8　の文字コードを読み込みたいのですが
対応する型は　wchar　でよかったでしょうか？

85:デフォルトの名無しさん
07/07/01 12:28:01
charやunsigned　charなど
あえてsinged　charでも悪くないｗ。

86:デフォルトの名無しさん
07/07/01 12:32:29
>>84
よくなかったでしょうか？

87:デフォルトの名無しさん
07/07/01 12:41:14
>>84
char: charが符号ありの場合はunsigned charにキャストが必要なケースあり
unsigned char: C++の場合は大量にreinterpret_castが必要になることを覚悟汁
wchar_t: よかったでしょうか？

88:84
07/07/01 12:55:56
>>87
wchar_t　でしたありがとうございます
TCHAR型を知っていると幸せになれますよ
MS専用かもわかりませんが・・・

まだコードを書く前の　分からないことの整理中でして
じっくりやりこんでいきます。

89:デフォルトの名無しさん
07/07/01 13:10:30
wchar_tがUTF-8って絶対にありえないと言えない
（wchar_tがUTF-16な実装が存在するくらいだ）けど、
普通wchar_tと言ったらUCS-2、-4やUTF-16、-32とかだろう。

90:デフォルトの名無しさん
07/07/01 14:26:47
UTF-8 は unsigned char だな。
wchar_t は有り得ない。

91:デフォルトの名無しさん
07/07/01 14:30:35
>>90
string.hの関数とかに渡す時に
いちいちreinterpret_cast<char*>すんの超うざくね？

92:デフォルトの名無しさん
07/07/01 19:56:53
そんな関数は使わない

93:デフォルトの名無しさん
07/07/01 22:25:14
char で操作して、必要な所で unsigned char にキャストかな。

94:デフォルトの名無しさん
07/07/01 22:32:33
変換関数を用意しとけってmeyerﾀｿが言ってた

95:デフォルトの名無しさん
07/07/01 22:45:24
char* と unsigned char* の間に暗黙変換があればなあ。

96:デフォルトの名無しさん
07/07/02 01:06:05
「読み込む」とは何をしたいのかによるよな。
データとしてUCS-2になって欲しいのか、UTF-8のままでいいのか。

97:デフォルトの名無しさん
07/07/21 17:05:03
漢字の拡張Cが正式に決定するのはいつ頃かな?

98:デフォルトの名無しさん
07/07/22 13:06:00
早くて来年

99:デフォルトの名無しさん
07/07/23 01:21:00
Windows Vista での「IME パッド - 文字一覧」の「JIS X 0213 （1面）」で，
例えば 1-4-87 の「か゜」にマウスカーソルを合わせると

Unicode: U+FD61809A
UTF-16: 0x304B 0x309A
Shift JIS: -
JIS213: 1-04-87

と出てくるんですが，この「U+FD61809A」ってどういう意味なんでしょう？
Unicode も ISO/IEC 10646 も今のところ U+10FFFF までしかありませんよね？

100:デフォルトの名無しさん
07/07/23 10:54:46
サロゲートペア？

101:デフォルトの名無しさん
07/07/23 13:13:34
>>99
U+304B, U+309A はサロゲートペアじゃないんだけど、

この2つをサロゲートペアに見立てて、
サロゲートペアからコードポイントを引き出す計算を
無理やり適用したら U+FD61809A になるんじゃね？

いまやったけど
((0x304B - 0xD800) << 10) + (0x309A - 0xDC00) + 0x10000
が 0xFD61809A になる。

102:デフォルトの名無しさん
07/07/23 13:56:31
こりゃ恥ずかしいバグだな。ベータ段階で誰も指摘しなかったのも...

103:デフォルトの名無しさん
07/07/23 20:24:48
>>101
なるほど，

　　0x10000 + (0x304B − 0xD800) × 0x400 + (0x309A − 0xDC00)
　= −0x29E7F66
　= 0xFD61809A − 0x100000000

という計算の結果，こうなるわけですか。

安易な計算による似たようなバグとして，
「IME パッド - 文字一覧」の Windows-31J 一覧（「シフト JIS」一覧）で
0x81FF にマウスカーソルを合わせると
面区点コードが「1-02-97」と出てきてしまうのもありますね。

104:デフォルトの名無しさん
07/07/24 09:02:41
合成文字ってやつか。

105:デフォルトの名無しさん
07/07/27 03:11:31
Extension Dに「たいと」の提案キタコレ

106:デフォルトの名無しさん
07/07/27 08:09:30
kwsk

107:デフォルトの名無しさん
07/07/27 08:40:09
あんなの要るのか？w

108:デフォルトの名無しさん
07/07/28 05:55:10
>>106
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
50MBほどあるので注意

109:デフォルトの名無しさん
07/07/28 06:07:05
と思ったら取り下げられてた。
URLﾘﾝｸ(www.cse.cuhk.edu.hk)

110:デフォルトの名無しさん
07/07/28 07:51:46
Extension Zくらいになったら提案する頃合だと思おう。

111:デフォルトの名無しさん
07/07/28 09:55:46
まあなあ。あんなの入れてもしゃーないわ。

112:デフォルトの名無しさん
07/08/17 19:13:21
質問

●（日本語２バイトでの、黒い丸）
を、アメ公の環境、US-asciiとかで表示するために
実体参照、もしくは数字文字参照で
表したいのですが、実体参照はまず存在しないようで、
数値文字参照でも、ユニコードの文字番号が不明です。
文字番号がもしあるならそれのWEBページのURLを、
あるいはそれ以外の方法があるなら、それを教えてください。

113:デフォルトの名無しさん
07/08/17 19:19:48
>>112
は自己解決した
●だった
ページはURLﾘﾝｸ(code.cside.com)

114:デフォルトの名無しさん
07/08/17 19:33:23
なんでおなじ数値文字参照を入力するのに、
10進と16進と二つのやり方があるんだ？

115:デフォルトの名無しさん
07/08/17 19:55:10
便利だから。そしてその質問はスレ違い。

116:デフォルトの名無しさん
07/08/22 22:03:34
携帯用のWebサイト作ってるんですが、あちらの世界ではシフトJIS/半角カナが
常用されてるみたいです。で、元データはEUC/全角(?)カナのため
EUC=>Shift_JISに変換しつつ、ついでに全角カナ=>半角カナに変換してくれるような
素敵なツールはありませんか？

使うのはkshスクリプトのCGIで、今はnkfだけ通しています。jcode使うとできそう
なのですが、変換のためだけにperlを動かすのも何だかなぁと…。

117:デフォルトの名無しさん
07/08/22 23:38:46
元データをEUC/半角かなにしておいたらいいんじゃない？

118:デフォルトの名無しさん
07/08/22 23:39:16
SJIS/半角かなか

119:デフォルトの名無しさん
07/08/23 01:07:52
2バイトかな→1バイト系かな変換をsedでやればいいだけっしょ。

120:デフォルトの名無しさん
07/08/28 21:42:23
>>116
nkf に全角=>半角パッチでも送りつけたら？

121:デフォルトの名無しさん
07/08/28 22:01:56
半角カナ→全角カナならともかく、その逆をやりたがる奴がいるとはな

122:デフォルトの名無しさん
07/08/28 22:47:59
携帯用Webサイト作るときには必要らすい。

123:デフォルトの名無しさん
07/08/28 22:55:51
いつの時代の話だよ

124:デフォルトの名無しさん
07/08/28 23:02:03
クライアントはいまだにそう信じてるんだよ･･･

125:デフォルトの名無しさん
07/08/29 00:08:22
客に恥をかかせないように正すのも仕事だろうに
何段もの丸投げの下層か？

126:デフォルトの名無しさん
07/08/29 00:37:33
正しいことを言えば通ると信じられるってのは幸せだよな。

127:デフォルトの名無しさん
07/08/29 00:55:13
下層は可哀想だな
俺は幸せだ

128:デフォルトの名無しさん
07/08/29 01:10:07
言いたいことも言えないこんな世の中じゃ

129:116
07/08/30 00:59:43
結局、kc15に全=>半の変換を組み込んで、nkfと置き換えることにしました。
シェルスクリプト内の埋込みやサーバ内で扱うデータにShift_JISや半角カナ使いたくないという
単なる個人的趣味のため、最後に変換する形にしました。ちなみにこれは業務じゃないです。
まぁそういう要望もあるってことで。

130:デフォルトの名無しさん
07/08/30 05:35:00
どうやらSubmissionからやり直す模様
URLﾘﾝｸ(www.unicode.org)
前回ツッコミ損ねた人はガンガンコメントしよう

131:デフォルトの名無しさん
07/09/01 04:50:42
前回のドラフトに関してこのスレで突っ込まれてたことはおおむね修正されてる模様

132:デフォルトの名無しさん
07/09/06 23:28:55
字体差の大きい異体字は削除されたね。
やっぱ包摂扱いにしないことにして拡張Dに提案か?

133:デフォルトの名無しさん
07/09/07 22:51:53
漢字用異体字セレクタ正式決定するのだいぶ後になりそうだな。2010年以降かも?
拡張CやDもそのくらいになるかも?

134:デフォルトの名無しさん
07/09/08 04:51:26
拡張CとかDへ正式に突っ込むのは結構面倒だから
UROの最後に付け足しでね?

135:デフォルトの名無しさん
07/09/08 21:24:32
漢字のVSは中台韓越と話し合って決めた方がいいと思う。

136:デフォルトの名無しさん
07/09/09 00:34:33
必要だと主張する人が勝手に登録申請する方式です。
中台韓越が必要だと思ってるなら申請するはずです

137:デフォルトの名無しさん
07/09/09 11:00:12
漢字はVS-1～16を使わないのは何でだろ?
俺的には各国の規格の現在および過去の例示字体、康煕字典体、表外漢字字体表、3部首許容などはVS-1～16にして、
その他の異体字(俗字など)はVS-17～にした方がいいと思うのだが。

138:デフォルトの名無しさん
07/09/09 15:55:56
Adobe-Japan1の非漢字は追加しないのかな?
まだUnicodeで規定されてないものが沢山あった筈。
丸付き文字など複数のコードの組み合わせで表せるものもあるけど。

139:デフォルトの名無しさん
07/09/09 18:39:15
>>137
前スレだったかの説によればBMPのVS奪い合いを未然に防ぐためだそうだが
真偽の程は知らん
あるいはそういう使い方が将来できるように空けてるのかも
>>138
数字が2桁以上のとき合成が曖昧にならないか?
JIS X 0213の丸付き数字が収録を認められたのは合成では不可能だからという
理由があったはず

140:デフォルトの名無しさん
07/09/09 23:55:27
ひらがなに○とかはU+3042 U+20DDとかでいいけどな。
問題は○51とかだな。全部単体のコードとして追加するのもいいが、2字以上に一緒に合成用記号を付ける方法も定義しておいた方がいいかも。
あとAdobe-Japan1の文字を見てると合成用黒丸や黒四角も必要だな。縦書き用のグリフを選択するタグも。
MacJapaneseをUnicodeにエンコーディングされる際に使用されるPUAのタグと同じ機能のものをPUAでない符号位置に正式なUnicodeとして追加するべきかも。

141:デフォルトの名無しさん
07/09/10 00:04:14
合成とかいらねーじゃんかよめんどくさい
有限である文字を割り振るだけなのに何年かかってんだよボンクラども
小出しにチマチマ変更するんじゃねえよ！アホか！

142:デフォルトの名無しさん
07/09/10 01:39:53
中国とか台湾だと、名前を付けるときに漢字を新規に創作する人も
いる、と聞いたんだが、マジ? いまでもそれってアリなの?

143:デフォルトの名無しさん
07/09/10 02:56:48
>>142
人名は知らないけど、元素なんかでは新しい字を作ってるとか聞いたことがある。

144:デフォルトの名無しさん
07/09/10 06:10:17
>>143
金属元素には金偏とかそんな感じだっけ?

145:デフォルトの名無しさん
07/09/10 15:08:03
㍻㍼㍽㍾

146:デフォルトの名無しさん
07/09/10 15:57:39
マルチバイト文字の最下位１バイトが、
x0Ahやx0Dhなどの改行コードと重なるケースって
ありますか？

147:デフォルトの名無しさん
07/09/10 17:28:05
>>146
さすがに、制御コードと重なるようなエンコーディングは聞いたことないですね。
UTF-16を1オクテット単位で見ると出てくるけど。

148:デフォルトの名無しさん
07/09/10 17:46:09
>>147
ありがとうございます。
マルチバイト文字列をbyte単位でバッファリングして
操作しようと思ってるんですが、
対象エンコーディングがSJIS,EUC,UTF-8なので、
それなら問題無さそうですね。

149:デフォルトの名無しさん
07/09/10 21:36:53
>>142
中国はマジらしい。台湾もかな?
だが、近い将来制限する方針みたい。
>>143-144
90年代以降に正式名称が決定した超アクチノイド元素(104番以降)の為に新しい漢字が造られた。
Rf(104)={金盧}、Db(105)={金杜}、Sg(106)={金喜}、Bh(107)={金波}、Hs(108)={金黑}、Mt(109)={金麥}
{金盧}と{金麥}はCJK統合漢字の無印と拡張Aに全く同じ字形の漢字があったのでそれを使うことになったが、
105～108番元素を表す漢字は無かったので拡張Bに追加された。これらは俺らが生まれた後に造られた新しい漢字と言えよう。
最近正式名の決定した110番元素(Ds)、111番元素(Rg)にも漢字が当てられそれぞれ{金達}、{金侖}となった。
これらはCJK統合漢字の無印に既にある字と同形になった。これはもうこれ以上新しい漢字を造らない方針になって既にある字から選んだという事なのかな?それとも偶然かな?
あと超アクチノイド元素を示す漢字は何故かUnicodeには繁体字のみが定義され簡体字は未だ定義されてない。
何でだ?まさか統合してるってこたぁねぇよな?

150:デフォルトの名無しさん
07/09/10 23:51:25
日本だって人名漢字で制限する前は好きな漢字作ってたよ。
金偏の名前は名古屋人と大工は多いとか聞いた気がする。

151:デフォルトの名無しさん
07/09/11 00:11:39
>>149
統合するのかと思ったけどAdobe Japan1の割り当て見直したことから考えると
簡体字と繁体字の統合はなさそうだからやっぱり登録申請するんじゃね

152:デフォルトの名無しさん
07/09/11 23:47:24
西夏文字と女書の提案キター
URLﾘﾝｸ(std.dkuug.dk)
URLﾘﾝｸ(std.dkuug.dk)

153:デフォルトの名無しさん
07/09/12 21:51:43
台湾では辞書に載ってる漢字ならOKと書いてあるのをどっかで見た。
どの辞書を指してるのかなど詳しい規則については知らんが。
だが、画数最大で有名な龍×4（U+2A6A5）はOKらしくこの字2つの名前の人がいるらしい。
下の名だけで128画になる。名前書く時大変そうだな。

154:デフォルトの名無しさん
07/09/12 22:04:04
龍龍
龍龍
↑こいつですな。9ptぐらいで印刷したらつぶれて読めないだろうな。

155:デフォルトの名無しさん
07/09/12 23:54:59
URLﾘﾝｸ(www.unicode.org)

Windows Vista だが、表示されるとは思わなかった…。

156:デフォルトの名無しさん
07/09/13 02:49:34
>>153
日本も既存の名字は「辞書に載ってる漢字ならOK」で辞書は明示してなかったような
URLﾘﾝｸ(internet.watch.impress.co.jp)
>>155
VistaはExtension Bまですべて入ってる
(ただしCJK Compatibility Ideographs Supplementは全部そろってない)

157:デフォルトの名無しさん
07/09/14 23:59:10
やっぱり字体差の大きい字を統合すると問題あるよな。
例えば「日玉」は一般的に「曜」の略字だけど、似ている「旺」の異体字として使われる事もあるかも知れんし。
同じ字形の字が「曜」でも「旺」でもない全く別の字として実は存在する(した)って事になるかも知れんし。

158:デフォルトの名無しさん
07/09/15 01:13:54
AnnexSと矛盾するのが致命的
せっかくこんな努力をしてるのがぶちこわしになるし
URLﾘﾝｸ(kanji-database.sourceforge.net)

159:デフォルトの名無しさん
07/09/15 01:16:27
UTR#37には統合できない文字をVSで表すようなことをしてはいけないと
明記されてるから実にまっとうな方向の改訂案

160:デフォルトの名無しさん
07/09/16 22:21:49
「門」の手書き等で使われる略字は簡体字(U+95E8)と統合する事になったんだね。
そっちの方がいいわな。

161:デフォルトの名無しさん
07/09/16 23:05:18
そういうわけで前回ここで指摘された点はほぼ改善されてる。
別にここ見てたわけじゃなくてAnnex Sから常識的に判断すれば
必然的にそうなるってことだろうな

162:デフォルトの名無しさん
07/09/18 22:48:48
悉曇十八章まだー？

163:デフォルトの名無しさん
07/09/20 02:07:49
Siddham scriptは草案らしきものが出てるけど
まだ正式には提案されていない

164:デフォルトの名無しさん
07/09/22 00:29:00
北朝鮮の将軍様専用ハングルはUnicodeには追加されないのかな?

165:デフォルトの名無しさん
07/09/23 01:35:53
U+2E28とU+2E29に二重括弧を入れようとしてるみたい。
JIS X 0213の1-2-54と1-2-55との対応について更に混乱しそうだな。

166:デフォルトの名無しさん
07/10/03 07:25:50
>>164
KPS 9566をソースに提案されたことがあるけど
蹴られたから新たな展開がない限りは収録されないと思われ

167:デフォルトの名無しさん
07/10/05 21:20:58
もし追加されるとなると互換文字としてU+Fxxxの領域に割り当てられるだろうな。
ハングル音節ブロックの余ってるU+D7A4～U+D7AFに追加でもいいかもしんない。このままだとそこ永久に埋まりそうにないし。

168:デフォルトの名無しさん
07/10/06 04:03:43
>>167
ブロックの割り当ては16文字単位だからHangul Jamo Extended Bでも使ってないのか

169:デフォルトの名無しさん
07/10/06 05:37:35
TUF16文字列をUTF-8に変換した場合、
4バイト以上はまず来ないと思っていいですか？

170:デフォルトの名無しさん
07/10/06 05:38:39
UTF16

171:デフォルトの名無しさん
07/10/06 05:53:53
サロゲートに対応していない馬鹿なUTF-8コンバータだったら
6バイトのものを送ってくるかも

172:デフォルトの名無しさん
07/10/06 05:53:57
>>169 なぜそうなる？

173:デフォルトの名無しさん
07/10/06 06:39:33
UTF-16ではU+10FFFFまでしか表せないからじゃね?

174:デフォルトの名無しさん
07/10/06 10:18:53
>>169
6バイト

175:デフォルトの名無しさん
07/10/06 11:20:14
>>174
>>171以外ならそんな入力の場合に6バイトになるのかkwsk

176:デフォルトの名無しさん
07/10/06 11:20:34
×そんな入力
○どんな入力

177:デフォルトの名無しさん
07/10/06 11:23:48
ｽﾚﾘﾝｸ(tech板)

178:デフォルトの名無しさん
07/10/06 15:19:26
Javaは3バイトまで

179:デフォルトの名無しさん
07/10/06 17:15:03
ドイツ語圏は、ドイツ語を使う国々が集まって、表記法を統一する会議を何年かおきに
やっている。
なんで、東アジア、漢字を統一できなかったのか、残念。

180:デフォルトの名無しさん
07/10/06 17:25:36
U+10000からU+10FFFFまでは4バイト

181:デフォルトの名無しさん
07/10/06 17:27:11
>>179
ドイツ人は制定マニアだから。
そういうことが難しいからこそ、漢字圏なんじゃないのか?

182:デフォルトの名無しさん
07/10/06 17:56:29
ドイツ語圏はドイツ語圏だけど
漢字圏は中文圏じゃないし

日本語とかの別言語でも漢字を使っているからね

183:デフォルトの名無しさん
07/10/06 18:20:18
>>179 中国だって統一王朝が立つと文字の整理をやってるぞ

184:デフォルトの名無しさん
07/10/06 18:35:31
MySQLのUTF8は3バイト文字までしか対応していない

185:デフォルトの名無しさん
07/10/06 19:35:22
>>184
ありゃりゃ。みんなどうしてんの？

186:デフォルトの名無しさん
07/10/06 20:07:40
>>183
毛沢東もやった死ね

187:デフォルトの名無しさん
07/10/06 21:51:16
じゃあ漢字の統合のために台湾併合だな

188:デフォルトの名無しさん
07/10/06 23:34:15
日本もね

189:デフォルトの名無しさん
07/10/06 23:57:53
康熙字典体に統一で桶。

190:デフォルトの名無しさん
07/10/07 02:48:55
中国は文献がほとんどかえりみられなくなっては
日本から逆輸入というのを定期的に繰り返しているし。
文字の統一なんて掛け声以前の問題じゃなかろうか。

191:デフォルトの名無しさん
07/10/07 03:38:26
>>189
Unicodeはそういう方針だな。GB7589とGB7590は繁体字で入ってるし
並び順も康煕字典の部首画数順だし

192:デフォルトの名無しさん
07/10/07 05:22:31
80年代後半から90年代前半って
台湾の方が電子化進んでたよね

193:デフォルトの名無しさん
07/10/07 08:48:37
いまや日本＝秋葉原でHENTAI ANINEの国という認識だろ。
文字なんて「萌え」が残ってればおｋなんじゃね？
と秋葉帰りの外人から思われてるに違いない。

194:デフォルトの名無しさん
07/10/07 13:30:02
>>191 Unicode の康煕字典ベースは、Unicode の原典主義からの帰結やね。
並び順の、康煕字典の部首画数順はもしかして漢字文化圏のグローバルスタンダード?

>>193 向こうの濃いオタ連中は20年ぐらい前から現代日本風アイテムとして漢字を
認識してるから、それはない。

195:デフォルトの名無しさん
07/10/07 13:37:21
請け負ったWebの仕事で、UTF-8で作成してたんだが、
Shift-jisしか受け付けないサーバーだと完成間際で判明して
１から変換しなおし。何とか事なきを得たんだが、次回に
どうしてもクライアントがやりたがってる事をAjaxでやろうと
すると、どうしてもUTF-8を採用せざる負えない結果に…orz

javascriptでShift-jisからUTF-8に変換して表示させる事はできないでしょうか？
向こうのサーバー事情でPHPやらPerlは一切使わせて貰えない状況です。
何とかお助けくださいませ。。。。。。。。。。。。

196:デフォルトの名無しさん
07/10/07 14:15:38
ググレカス

197:デフォルトの名無しさん
07/10/07 14:40:15
>>194
CJKのどこからも文句の出ない並び順が康煕字典順しかなかったってことだろう
現代中国はにくづきとふなづきを統合したりしたまったく異なる部首を使ってるし
発音順は国によって全く異なるし

198:デフォルトの名無しさん
07/10/14 20:13:05
sjis,EUC,UTF8,16,32の判別ソフトをCで作っています。
UCS2も対応させたいのですが、何処か参考になるサイトは無いでしょうか
すみません、どなたか教えて下さいm(_ _)m

199:デフォルトの名無しさん
07/10/14 20:21:10
>>198
URLﾘﾝｸ(www.google.co.jp)

200:デフォルトの名無しさん
07/11/03 16:03:56
【日台中韓】韓・中・日・台が漢字の字体統一へ[11/03]
ｽﾚﾘﾝｸ(news4plus板)

201:デフォルトの名無しさん
07/11/03 19:20:21
字体統一って中国以外にメリットあるの？

202:デフォルトの名無しさん
07/11/03 19:22:45
日本すら未だに統一できてないのに秒速で漢字が増えてゆく国が統一とは

203:デフォルトの名無しさん
07/11/12 17:13:15
>>200
ウソだったらしい。もうなにがなんだか。

【日台中韓】「中・日・韓・台の漢字統一」報道を否定！簡体字使用の変更は不可能[11/12]
ｽﾚﾘﾝｸ(news4plus板)

204:デフォルトの名無しさん
07/11/12 18:23:49
ヨタ記事をいちいち貼るなよ。

205:デフォルトの名無しさん
07/11/17 15:44:45
IMEパッドの文字の上にマウスを持っていくとでるバルーンヘルプの内容が取得できるライブラリ(関数)をしりませんか？

in:jisX0213:2004 1面, 1区, 1点
out:ucs, utf-8, Shift_JIS

見たいな、、、

206:デフォルトの名無しさん
07/11/18 00:29:36
超漢字検索の情報ウィンドウの内容を取得できるライブラリもほしい

207:デフォルトの名無しさん
07/11/20 23:35:37
JIS X 0213 面区点番号とunicodeのマッピングを
機械的に求めることはできますか？

208:デフォルトの名無しさん
07/11/21 11:39:36
テーブル引く

...というのは機械的だろうか？

209:デフォルトの名無しさん
07/11/21 13:03:01
ドイツ語は定期的にspellをドイツ語圏で統一するように会議をしているね。ま、向こうは意味まで
同じなのだが。形だけ揃えても意味ないし、朝鮮半島はハングルで統一されている。CKJで統一
する意味はないと思うのだがね。

210:デフォルトの名無しさん
07/11/21 19:13:46
perlで作ったcgiに一番ｵﾇﾇﾒなコードｋｗｓｋ

211:デフォルトの名無しさん
07/11/21 21:09:46
perlはなんでもいいよ。
Encode使えば割りとw何でもできるから。
好きなのにしな。

まあ今ならutf-8がいいだろうけど。
formにUnicodeな文字入力する奴もいるし。

212:デフォルトの名無しさん
07/11/24 02:48:07
なんかさ、gccのワイドリテラルの扱いってへんてこな感じね。
gcc3.4よか前だと単に1Byteを4Byteに展開するだけで何の文字コードでもなく、
3.4以上だとUTF-32LEになってるかのような動き。
さらにvc(UTF-16LE)とのクロスでの開発を考えると頭が痛くなるなあ・・
Win/Linuxのクロスでやってる人って内部コードってなににしてる？

213:デフォルトの名無しさん
07/11/24 02:52:40
>>212
ワイド文字をリテラルでは使わない。
UTF-8から変換。

214:デフォルトの名無しさん
07/11/24 03:07:35
ま、そだよね。基本的にはリテラルに日本語入れなきゃ円満なんだよね。
3.4以降はexec-charsetでどうとでもできそうだけど、古いのは・・
ソースをUTF-8にすればなんとか日本語入れてもコンパイルはできるか。
あぁ、でもvc7とかはUTF-8のソース確か受け付けなかったような。
ソースくらいは変換するべきか。面倒だな・・いろいろ。

215:デフォルトの名無しさん
07/11/24 04:02:12
全部\uxxxxで書いちゃえ。

216:デフォルトの名無しさん
07/11/24 04:22:36
うほ、なげやり
でもそれすらgccいけるけどvcは\u使えないとか罠があったり。。
いろいろ実験して、バッドノウハウだけ増えたな・・
vc,gccともソースがUTF-16系は不可、vcはシグニチャなしUTF-8ソース不可、
逆にgccはシグニチャありUTF-8ソース不可・・

217:デフォルトの名無しさん
07/11/24 04:45:06
いや、やっぱvcはUTF-8はBOMありなしどっちもだめだなぁ。ソースによる
みたいだ。最低だなsjisしか受け付けないのか・・。vc8なら平気かもしれないけど
vc ソースsjis 内部UTF-16LE(コンパイル時L変換)
gcc3.3以下ソースsjis(リテラルに"表"とかだめ) 内部UTF-8(実行時iconv変換)
gcc3.4以上ソースsjis 内部UTF-8(input-charset=cp932でgccでコンパイル時変換)
こんなしか選択肢がないような。あぁ、CVSで変換するとかならソースはもっと
自由度あるか。だりーな、Unicode対応・・。もうsjis/eucでいい気がしてきた。

218:デフォルトの名無しさん
07/11/24 15:53:48
vcがutf-8ダメだってのは、何がだめだっての？

219:デフォルトの名無しさん
07/11/24 17:14:21
vc7で、UTF-8のソースだと
#define XX "あ"
とかあるとだめだけど
#define XX "ああ"
だと平気。たぶんsjisとして処理してるから日本語リテラルが奇数バイト
だとだめみたいな感じ。

220:デフォルトの名無しさん
07/11/24 23:51:33
vc8使え。終了

221:デフォルトの名無しさん
07/11/25 10:34:26
00h～1Fh　制御文字
20h～7Fh　各国共通（1バイト文字）
80h～FFh　各国自由（1／2バイト文字）

16ビットPCを出すときに思い切って半角カナを廃止して
80h以降は日本では2バイト文字専用にすれば良かった
つーか70年代末期の最初のPCを出すときに80h以降は
予約領域かPCG領域にすれば良かったんだよな

222:デフォルトの名無しさん
07/11/25 10:36:33
あとからならどうとでも言える

カタカナだけでもいいから1バイトで処理したいという要求がどれだけ当時は切実だったことか

次ページ