文字コード総合スレ part3

1 ：デフォルトの名無しさん：2007/05/27(日) 16:19:36

プログラムにおける各種文字コードの処理について語りましょう♪

■前スレ
文字コード総合スレ part2
http://pc11.2ch.net/test/read.cgi/tech/1143375639/

■参考サイト
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

2 ：デフォルトの名無しさん：2007/05/27(日) 16:31:01

漢字袋
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/
池田証寿
http://homepage3.nifty.com/shikeda/zatsubun.htm

3 ：デフォルトの名無しさん：2007/05/27(日) 16:41:09

■過去ログ
※◆ゲイの美容◆※ 01/01/21-01/01/23 <9>
http://yasai.2ch.net/gay/kako/980/980019809.html
ゲイの美容版・・・・・・ 01/07/17-01/07/22 <17>
http://yasai.2ch.net/gay/kako/995/995353433.html
ゲイの美容第３弾！ 01/08/14-01/08/28 <28>
http://yasai.2ch.net/gay/kako/997/997765965.html
ゲイの美容第６弾！ 01/11/21-01/11/27 <7>
http://yasai.2ch.net/gay/kako/1006/10063/1006327106.html
ゲイの美容 00/09/25-00/12/05 <981>
http://piza.2ch.net/gay/kako/969/969815437.html

4 ：デフォルトの名無しさん：2007/05/28(月) 20:22:23

携帯でJIS X 0213の字使えるようにならないかな?

5 ：デフォルトの名無しさん：2007/05/28(月) 20:30:52

それは絶対無理

6 ：デフォルトの名無しさん：2007/05/29(火) 05:29:15

Shift_JIS-2004実装なら可能なんじゃね?
iモード絵文字つぶしてそんな実装することはありえないと思うけど

7 ：デフォルトの名無しさん：2007/05/29(火) 18:59:37

ASCII廃止されねーかな

8 ：デフォルトの名無しさん：2007/05/31(木) 17:45:05

JIS X 0213を語呂合わせで「おにいさん」と呼んでるのは俺だけでしょうか?

9 ：デフォルトの名無しさん：2007/05/31(木) 17:53:50

>>8
すれ違い。そういうのはこっちで。

UnicodeとUTF-8の違いは？
http://pc11.2ch.net/test/read.cgi/tech/1177930957/

10 ：デフォルトの名無しさん：2007/05/31(木) 19:42:07

日本のCJK Ext.D Submissionに{魚針}が含まれてる件

11 ：デフォルトの名無しさん：2007/05/31(木) 20:39:41

サヨリだったか？

12 ：デフォルトの名無しさん：2007/05/31(木) 20:40:04

針魚

13 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/06/01(金) 23:26:30

意味でUnifyしたらだいぶ減るな

15 ：デフォルトの名無しさん：2007/06/02(土) 20:15:29

Unicodeの14面の制御符号って今後増えるのかな?

16 ：デフォルトの名無しさん：2007/06/02(土) 20:31:38

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

17 ：デフォルトの名無しさん：2007/06/03(日) 13:17:37

>>15
VSが足りなくなったら増えるんじゃね?

18 ：デフォルトの名無しさん：2007/06/03(日) 14:00:37

KPS 9566-2003の仕様書手に入らねえかなぁ

19 ：デフォルトの名無しさん：2007/06/03(日) 21:16:17

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

ttp://www.jagat.or.jp/story_memo_view.asp?StoryID=563
ここ見るとルビタグも提案されてたらしい。どうなったかは知らんが。
ひょっとしたらフォント指定とかサイズ指定の為のコードも追加されるかも?

20 ：デフォルトの名無しさん：2007/06/03(日) 22:34:37

色指定とか太さ指定とか傾き指定のコードとか！

21 ：デフォルトの名無しさん：2007/06/04(月) 01:40:27

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

22 ：デフォルトの名無しさん：2007/06/04(月) 15:14:08

確か甲骨文字とか変体仮名とかは統合漢字に包摂されてたな。
ならそれらも将来的にはVSで規定されるかも?

23 ：デフォルトの名無しさん：2007/06/05(火) 05:04:35

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

24 ：デフォルトの名無しさん：2007/06/06(水) 00:47:01

ھەرپ ۋە بەلگىگە بىردىن نومۇر بېرى

25 ：デフォルトの名無しさん：2007/06/07(木) 01:59:05

WG2でこれは統合できるだろ、というツッコミが多数来てExt.CがIRGに差し戻されたけど
各国からこれは人名用だ、という反論が多数来てとうとうこんな文書が出てきた
http://www.cse.cuhk.edu.hk/~irg/irg/irg28/IRGN1327SeparateArea.doc

26 ：デフォルトの名無しさん：2007/06/08(金) 22:21:49

とあるプログラムが、ASCIIにしか対応していないハズなのですが、
UTF-8Nを渡しても、正常に動いているように見えます。

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

27 ：デフォルトの名無しさん：2007/06/08(金) 22:26:37

>>26を試した文字は、
「ソースコード」や「表示」などのSJISではASCIIにすると文字化けになる文字です

28 ：デフォルトの名無しさん：2007/06/08(金) 22:37:55

MSBが立ってる文字に対して特別扱いしてないなら、文字単位の処理さえなければ大丈夫の可能性が高い。(grepとか)
文字列を分割したり途中を切り出してたりしてるプログラムなら、おかしくなり得る。

29 ：デフォルトの名無しさん：2007/06/08(金) 22:47:54

26でUTF-8と言っておきながら、27でShift_JISの文字を例に挙げるとはよくわからない

30 ：デフォルトの名無しさん：2007/06/08(金) 23:19:50

>>28
なるほど、切り出したり特殊な加工をしないかぎりは大丈夫ですか

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

31 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/06/09(土) 02:18:40

80カラムにそろえるプログラムはおかしくなる。
バイトストリームとして扱うか、文字として扱うかによって違う。

33 ：デフォルトの名無しさん：2007/06/09(土) 02:58:15

日本でメールは76桁で折り返せという慣習になってるのは
ISO-2022-JPのメッセージを80桁の端末に表示してるとき途中に折り返しが入ると
表示がおかしくなる可能性があるからだったな
そういう心配のない欧米ではquoted-printableを使ってた

34 ：デフォルトの名無しさん：2007/06/09(土) 07:20:16

そんな慣習がまかり通っていた頃に、quoted-printableはなかったよ。
大型機がやっているMTAに勝手に折り返すのが昔あったらしい。

35 ：デフォルトの名無しさん：2007/06/09(土) 22:53:13

>>34
RFC1468でquoted-printableに言及してる。それは使わず75桁で折り返せと。
(今読み返したら76じゃなかった)

36 ：デフォルトの名無しさん：2007/06/10(日) 18:39:07

>>31
詳細な解説、参考になりました。

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

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

37 ：デフォルトの名無しさん：2007/06/10(日) 20:06:25

/あ.う/ は "あいう" にはマッチしない。
"い" が 3 バイトだから。
/あ...う/ なら引っかかる。
全角文字は大体 3 バイトだから、実用上は困らないかもしれない。
ギリシャ文字やキリル文字みたいに 2 バイトのものもあるけど。
/あ.*う/ は /あいう/ にひっかかるけど、/あえいう/ にも引っかかる。

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

38 ：デフォルトの名無しさん：2007/06/10(日) 20:16:02

いつも思うんだが、

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

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

39 ：デフォルトの名無しさん：2007/06/10(日) 21:48:45

>>38
80桁の端末での表示上の問題だから表示されないものはカウントしない
当然プロポーショナルフォントなんて高級なものは想定してない

40 ：デフォルトの名無しさん：2007/06/13(水) 03:27:09

>>26の件ですが、プログラム側にUNICODE対応のモードがありまして、それが無事に動きました。
お騒がせしてしまいました。

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

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

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

41 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/06/13(水) 21:46:04

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

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

43 ：デフォルトの名無しさん：2007/06/15(金) 05:39:20

>>41
行末でASCIIに戻るのは原因と結果が逆のような。
そういう動作をする端末だかMTAだかが存在したからそう規定されたんでしょ

44 ：デフォルトの名無しさん：2007/06/15(金) 08:31:30

規定されれば、次はそれが何かの原因になることもあるだろ？

45 ：デフォルトの名無しさん：2007/06/16(土) 20:51:50

そのために「慣用的な利用との互換性を目的としてだけ」とか但し書きが付くわけだが
(RFC1468には付いてないけど)読まない奴はいるしな

46 ：デフォルトの名無しさん：2007/06/17(日) 07:39:20

>>42
今はMIMEに従えばいいじゃん。
MUAが行を折り返すのは、余計なお世話だな。

47 ：デフォルトの名無しさん：2007/06/18(月) 18:23:23

>>46
>今はMIMEに従えばいいじゃん。
えっと具体的にはMIMEの何に従うということですか?

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

48 ：デフォルトの名無しさん：2007/06/18(月) 18:33:39

OpenOfficeの最新バージョン(2.2)ではサロゲートペアにほぼ完全に対応してた。
(これ迄のバージョンではBMP外の文字は送り幅が変だったりもっと昔のバージョンでは保存したとき消失したりしてた。)

49 ：デフォルトの名無しさん：2007/06/18(月) 19:07:29

自動折り返しを実装するなら、まともな挙動にしてほ
しい。
こんな滅茶苦茶な改行には、ほとほとうんざりしてい
る。

50 ：デフォルトの名無しさん：2007/06/18(月) 19:10:28

そんなの未だいいじゃん
。こんな改行された日に
ゃ……誰かの台詞じゃ
ないけれど、「泣ける
」。

51 ：デフォルトの名無しさん：2007/06/19(火) 00:26:43

>>49
あれ、この処理じゃ駄目ですか?

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

52 ：デフォルトの名無しさん：2007/06/19(火) 18:11:09

禁則処理はDTP（もしくはエディタ）のレベルでそ

53 ：デフォルトの名無しさん：2007/06/19(火) 22:30:59

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

54 ：デフォルトの名無しさん：2007/06/19(火) 22:32:33

いや買ってこいよ

55 ：デフォルトの名無しさん：2007/06/19(火) 22:54:35

じゃあ、お金くださいよ

56 ：デフォルトの名無しさん：2007/06/19(火) 23:00:55

業務用開発でそんな金すら出ないってなんだよ

57 ：デフォルトの名無しさん：2007/06/20(水) 00:06:16

>>53
> 「VistaはShift_JIS-2004に対応」
その記事書いた奴が何か勘違いしてるか
その記事を読んだおまえが何か勘違いしてる

58 ：デフォルトの名無しさん：2007/06/20(水) 00:16:39

ちょっと板違いかもしれませんが文字コードっぽいスレを
みつけられなかったのでここで失礼します。

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

esc ( J "hoge" esc ( B

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

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

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

59 ：デフォルトの名無しさん：2007/06/20(水) 00:23:00

ESC ( J は JIS X 0201-Roman だな。
きっと backslash のかわりに円記号が使いたかったんだろう。

60 ：デフォルトの名無しさん：2007/06/20(水) 00:25:50

もしくは tilde の代わりに overline 使いたかったか。

61 ：デフォルトの名無しさん：2007/06/20(水) 00:52:12

ありがとん。
結局一旦日本語部分はEUCにして、残ったescape sequenceを
scriptでがっさり削って解決しました。

62 ：デフォルトの名無しさん：2007/06/20(水) 21:51:46

>>59-60
HTMLエディタには ESC ( J を使うものが多いらしい
しかしURLの中の 0x7E は tilde のつもりだし
JavaScriptのエスケープも backslash のつもりらしい

63 ：デフォルトの名無しさん：2007/06/22(金) 09:26:11

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

64 ：デフォルトの名無しさん：2007/06/22(金) 09:39:38

lib.locale.codecvt + basic_string<wchar_t>

65 ：デフォルトの名無しさん：2007/06/22(金) 17:28:50

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

66 ：デフォルトの名無しさん：2007/06/22(金) 18:22:49

あるプログラムって？

67 ：デフォルトの名無しさん：2007/06/22(金) 19:15:09

tidy-libを使ったプログラムです。rawで読み込みさせてます。

68 ：デフォルトの名無しさん：2007/06/22(金) 22:18:07

バベルのとーにすんでいるー

69 ：デフォルトの名無しさん：2007/06/23(土) 06:55:12

>>65

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

70 ：デフォルトの名無しさん：2007/06/23(土) 08:08:04

ほんとだ、iconv -f latin1 -t utf-8したら再現した。

71 ：デフォルトの名無しさん：2007/06/23(土) 08:10:19

バビル二世現る

72 ：65：2007/06/23(土) 08:57:50

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

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

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

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

73 ：デフォルトの名無しさん：2007/06/24(日) 21:48:41

Unicode 吉野屋コピペを Flash 化してみた。
ttp://www5a.biglobe.ne.jp/~tmurakam/Flash/Unicode.html
超古いネタですまん。

74 ：デフォルトの名無しさん：2007/06/25(月) 20:38:37

ポイント制で文字コードを判別するアルゴリズムってどんなライセンスなんですか？

75 ：デフォルトの名無しさん：2007/06/25(月) 20:47:26

>>74
アルゴリズムとライセンスは別の話だろ？　いったいおまいさんはなにを訊きたいんだ？

76 ：デフォルトの名無しさん：2007/06/25(月) 21:25:04

アルゴリズムの特許が認められているので、
アルゴリズムにライセンスがある場合はある。
アルゴリズムにはコピーライトがない。
プログラムにはコピーライトがある。
>>74が何を聞きたいか分からない。

77 ：74：2007/06/26(火) 01:03:32

じゃ、大幅に言い換えて

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

78 ：デフォルトの名無しさん：2007/06/26(火) 01:33:59

>>77
sakuraエディッタとやらのライセンスを読めよ、馬鹿。　以上、終了。

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

79 ：デフォルトの名無しさん：2007/06/26(火) 01:37:53

>>77
http://sakura_editor.at.infoseek.co.jp/faq.html

80 ：デフォルトの名無しさん：2007/06/26(火) 01:39:19

まずはsakuraのライセンス確認したら？

81 ：デフォルトの名無しさん：2007/06/26(火) 02:09:25

つーか「参考に」だけでどの程度類似してるか判断できると思ってんのか

82 ：デフォルトの名無しさん：2007/06/26(火) 06:56:15

文字コード関係ないやん。
nkfのコードならコピーライト表示するだけでコピー自由。

83 ：デフォルトの名無しさん：2007/06/28(木) 09:37:25

>>73
ワロッシュw

84 ：デフォルトの名無しさん：2007/07/01(日) 12:25:27

C/C++言語で UTF-8 の文字コードを読み込みたいのですが
対応する型は wchar でよかったでしょうか？

85 ：デフォルトの名無しさん：2007/07/01(日) 12:28:01

charやunsigned charなど
あえてsinged charでも悪くないｗ。

86 ：デフォルトの名無しさん：2007/07/01(日) 12:32:29

>>84
よくなかったでしょうか？

87 ：デフォルトの名無しさん：2007/07/01(日) 12:41:14

>>84
char: charが符号ありの場合はunsigned charにキャストが必要なケースあり
unsigned char: C++の場合は大量にreinterpret_castが必要になることを覚悟汁
wchar_t: よかったでしょうか？

88 ：84：2007/07/01(日) 12:55:56

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

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

89 ：デフォルトの名無しさん：2007/07/01(日) 13:10:30

wchar_tがUTF-8って絶対にありえないと言えない
（wchar_tがUTF-16な実装が存在するくらいだ）けど、
普通wchar_tと言ったらUCS-2、-4やUTF-16、-32とかだろう。

90 ：デフォルトの名無しさん：2007/07/01(日) 14:26:47

UTF-8 は unsigned char だな。
wchar_t は有り得ない。

91 ：デフォルトの名無しさん：2007/07/01(日) 14:30:35

>>90
string.hの関数とかに渡す時に
いちいちreinterpret_cast<char*>すんの超うざくね？

92 ：デフォルトの名無しさん：2007/07/01(日) 19:56:53

そんな関数は使わない

93 ：デフォルトの名無しさん：2007/07/01(日) 22:25:14

char で操作して、必要な所で unsigned char にキャストかな。

94 ：デフォルトの名無しさん：2007/07/01(日) 22:32:33

変換関数を用意しとけってmeyerﾀｿが言ってた

95 ：デフォルトの名無しさん：2007/07/01(日) 22:45:24

char* と unsigned char* の間に暗黙変換があればなあ。

96 ：デフォルトの名無しさん：2007/07/02(月) 01:06:05

「読み込む」とは何をしたいのかによるよな。
データとしてUCS-2になって欲しいのか、UTF-8のままでいいのか。

97 ：デフォルトの名無しさん：2007/07/21(土) 17:05:03

漢字の拡張Cが正式に決定するのはいつ頃かな?

98 ：デフォルトの名無しさん：2007/07/22(日) 13:06:00

早くて来年

99 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/07/23(月) 10:54:46

サロゲートペア？

101 ：デフォルトの名無しさん：2007/07/23(月) 13:13:34

>>99
U+304B, U+309A はサロゲートペアじゃないんだけど、

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

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

102 ：デフォルトの名無しさん：2007/07/23(月) 13:56:31

こりゃ恥ずかしいバグだな。ベータ段階で誰も指摘しなかったのも...

103 ：デフォルトの名無しさん：2007/07/23(月) 20:24:48

>>101
なるほど，

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

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

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

104 ：デフォルトの名無しさん：2007/07/24(火) 09:02:41

合成文字ってやつか。

105 ：デフォルトの名無しさん：2007/07/27(金) 03:11:31

Extension Dに「たいと」の提案キタコレ

106 ：デフォルトの名無しさん：2007/07/27(金) 08:09:30

kwsk

107 ：デフォルトの名無しさん：2007/07/27(金) 08:40:09

あんなの要るのか？w

108 ：デフォルトの名無しさん：2007/07/28(土) 05:55:10

>>106
http://www.itscj.ipsj.or.jp/domestic/sc02/irg-files/CJK_D_attributes/IRG1277_attachment.zip
50MBほどあるので注意

109 ：デフォルトの名無しさん：2007/07/28(土) 06:07:05

と思ったら取り下げられてた。
http://www.cse.cuhk.edu.hk/~irg/irg/irg27/IRGN1250_Japan_Withdrawal_from_D.pdf

110 ：デフォルトの名無しさん：2007/07/28(土) 07:51:46

Extension Zくらいになったら提案する頃合だと思おう。

111 ：デフォルトの名無しさん：2007/07/28(土) 09:55:46

まあなあ。あんなの入れてもしゃーないわ。

112 ：デフォルトの名無しさん：2007/08/17(金) 19:13:21

質問

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

113 ：デフォルトの名無しさん：2007/08/17(金) 19:19:48

>>112
は自己解決した
●だった
ページはhttp://code.cside.com/3rdpage/jp/utf-8/Geometric_Shapes.html

114 ：デフォルトの名無しさん：2007/08/17(金) 19:33:23

なんでおなじ数値文字参照を入力するのに、
10進と16進と二つのやり方があるんだ？

115 ：デフォルトの名無しさん：2007/08/17(金) 19:55:10

便利だから。そしてその質問はスレ違い。

116 ：デフォルトの名無しさん：2007/08/22(水) 22:03:34

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

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

117 ：デフォルトの名無しさん：2007/08/22(水) 23:38:46

元データをEUC/半角かなにしておいたらいいんじゃない？

118 ：デフォルトの名無しさん：2007/08/22(水) 23:39:16

SJIS/半角かなか

119 ：デフォルトの名無しさん：2007/08/23(木) 01:07:52

2バイトかな→1バイト系かな変換をsedでやればいいだけっしょ。

120 ：デフォルトの名無しさん：2007/08/28(火) 21:42:23

>>116
nkf に全角=>半角パッチでも送りつけたら？

121 ：デフォルトの名無しさん：2007/08/28(火) 22:01:56

半角カナ→全角カナならともかく、その逆をやりたがる奴がいるとはな

122 ：デフォルトの名無しさん：2007/08/28(火) 22:47:59

携帯用Webサイト作るときには必要らすい。

123 ：デフォルトの名無しさん：2007/08/28(火) 22:55:51

いつの時代の話だよ

124 ：デフォルトの名無しさん：2007/08/28(火) 23:02:03

クライアントはいまだにそう信じてるんだよ･･･

125 ：デフォルトの名無しさん：2007/08/29(水) 00:08:22

客に恥をかかせないように正すのも仕事だろうに
何段もの丸投げの下層か？

126 ：デフォルトの名無しさん：2007/08/29(水) 00:37:33

正しいことを言えば通ると信じられるってのは幸せだよな。

127 ：デフォルトの名無しさん：2007/08/29(水) 00:55:13

下層は可哀想だな
俺は幸せだ

128 ：デフォルトの名無しさん：2007/08/29(水) 01:10:07

言いたいことも言えないこんな世の中じゃ

129 ：116：2007/08/30(木) 00:59:43

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

130 ：デフォルトの名無しさん：2007/08/30(木) 05:35:00

どうやらSubmissionからやり直す模様
http://www.unicode.org/ivd/pri/pri108/index.html
前回ツッコミ損ねた人はガンガンコメントしよう

131 ：デフォルトの名無しさん：2007/09/01(土) 04:50:42

前回のドラフトに関してこのスレで突っ込まれてたことはおおむね修正されてる模様

132 ：デフォルトの名無しさん：2007/09/06(木) 23:28:55

字体差の大きい異体字は削除されたね。
やっぱ包摂扱いにしないことにして拡張Dに提案か?

133 ：デフォルトの名無しさん：2007/09/07(金) 22:51:53

漢字用異体字セレクタ正式決定するのだいぶ後になりそうだな。2010年以降かも?
拡張CやDもそのくらいになるかも?

134 ：デフォルトの名無しさん：2007/09/08(土) 04:51:26

拡張CとかDへ正式に突っ込むのは結構面倒だから
UROの最後に付け足しでね?

135 ：デフォルトの名無しさん：2007/09/08(土) 21:24:32

漢字のVSは中台韓越と話し合って決めた方がいいと思う。

136 ：デフォルトの名無しさん：2007/09/09(日) 00:34:33

必要だと主張する人が勝手に登録申請する方式です。
中台韓越が必要だと思ってるなら申請するはずです

137 ：デフォルトの名無しさん：2007/09/09(日) 11:00:12

漢字はVS-1～16を使わないのは何でだろ?
俺的には各国の規格の現在および過去の例示字体、康煕字典体、表外漢字字体表、3部首許容などはVS-1～16にして、
その他の異体字(俗字など)はVS-17～にした方がいいと思うのだが。

138 ：デフォルトの名無しさん：2007/09/09(日) 15:55:56

Adobe-Japan1の非漢字は追加しないのかな?
まだUnicodeで規定されてないものが沢山あった筈。
丸付き文字など複数のコードの組み合わせで表せるものもあるけど。

139 ：デフォルトの名無しさん：2007/09/09(日) 18:39:15

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

140 ：デフォルトの名無しさん：2007/09/09(日) 23:55:27

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

141 ：デフォルトの名無しさん：2007/09/10(月) 00:04:14

合成とかいらねーじゃんかよめんどくさい
有限である文字を割り振るだけなのに何年かかってんだよボンクラども
小出しにチマチマ変更するんじゃねえよ！アホか！

142 ：デフォルトの名無しさん：2007/09/10(月) 01:39:53

中国とか台湾だと、名前を付けるときに漢字を新規に創作する人も
いる、と聞いたんだが、マジ? いまでもそれってアリなの?

143 ：デフォルトの名無しさん：2007/09/10(月) 02:56:48

>>142
人名は知らないけど、元素なんかでは新しい字を作ってるとか聞いたことがある。

144 ：デフォルトの名無しさん：2007/09/10(月) 06:10:17

>>143
金属元素には金偏とかそんな感じだっけ?

145 ：デフォルトの名無しさん：2007/09/10(月) 15:08:03

㍻㍼㍽㍾

146 ：デフォルトの名無しさん：2007/09/10(月) 15:57:39

マルチバイト文字の最下位１バイトが、
x0Ahやx0Dhなどの改行コードと重なるケースって
ありますか？

147 ：デフォルトの名無しさん：2007/09/10(月) 17:28:05

>>146
さすがに、制御コードと重なるようなエンコーディングは聞いたことないですね。
UTF-16を1オクテット単位で見ると出てくるけど。

148 ：デフォルトの名無しさん：2007/09/10(月) 17:46:09

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

149 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/09/10(月) 23:51:25

日本だって人名漢字で制限する前は好きな漢字作ってたよ。
金偏の名前は名古屋人と大工は多いとか聞いた気がする。

151 ：デフォルトの名無しさん：2007/09/11(火) 00:11:39

>>149
統合するのかと思ったけどAdobe Japan1の割り当て見直したことから考えると
簡体字と繁体字の統合はなさそうだからやっぱり登録申請するんじゃね

152 ：デフォルトの名無しさん：2007/09/11(火) 23:47:24

西夏文字と女書の提案キター
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3297.pdf
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3287.pdf

153 ：デフォルトの名無しさん：2007/09/12(水) 21:51:43

台湾では辞書に載ってる漢字ならOKと書いてあるのをどっかで見た。
どの辞書を指してるのかなど詳しい規則については知らんが。
だが、画数最大で有名な龍×4（U+2A6A5）はOKらしくこの字2つの名前の人がいるらしい。
下の名だけで128画になる。名前書く時大変そうだな。

154 ：デフォルトの名無しさん：2007/09/12(水) 22:04:04

龍龍
龍龍
↑こいつですな。9ptぐらいで印刷したらつぶれて読めないだろうな。

155 ：デフォルトの名無しさん：2007/09/12(水) 23:54:59

http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2A6A5

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

156 ：デフォルトの名無しさん：2007/09/13(木) 02:49:34

>>153
日本も既存の名字は「辞書に載ってる漢字ならOK」で辞書は明示してなかったような
http://internet.watch.impress.co.jp/www/column/ogata/special3.htm
>>155
VistaはExtension Bまですべて入ってる
(ただしCJK Compatibility Ideographs Supplementは全部そろってない)

157 ：デフォルトの名無しさん：2007/09/14(金) 23:59:10

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

158 ：デフォルトの名無しさん：2007/09/15(土) 01:13:54

AnnexSと矛盾するのが致命的
せっかくこんな努力をしてるのがぶちこわしになるし
http://kanji-database.sourceforge.net/housetsu.html

159 ：デフォルトの名無しさん：2007/09/15(土) 01:16:27

UTR#37には統合できない文字をVSで表すようなことをしてはいけないと
明記されてるから実にまっとうな方向の改訂案

160 ：デフォルトの名無しさん：2007/09/16(日) 22:21:49

「門」の手書き等で使われる略字は簡体字(U+95E8)と統合する事になったんだね。
そっちの方がいいわな。

161 ：デフォルトの名無しさん：2007/09/16(日) 23:05:18

そういうわけで前回ここで指摘された点はほぼ改善されてる。
別にここ見てたわけじゃなくてAnnex Sから常識的に判断すれば
必然的にそうなるってことだろうな

162 ：デフォルトの名無しさん：2007/09/18(火) 22:48:48

悉曇十八章まだー？

163 ：デフォルトの名無しさん：2007/09/20(木) 02:07:49

Siddham scriptは草案らしきものが出てるけど
まだ正式には提案されていない

164 ：デフォルトの名無しさん：2007/09/22(土) 00:29:00

北朝鮮の将軍様専用ハングルはUnicodeには追加されないのかな?

165 ：デフォルトの名無しさん：2007/09/23(日) 01:35:53

U+2E28とU+2E29に二重括弧を入れようとしてるみたい。
JIS X 0213の1-2-54と1-2-55との対応について更に混乱しそうだな。

166 ：デフォルトの名無しさん：2007/10/03(水) 07:25:50

>>164
KPS 9566をソースに提案されたことがあるけど
蹴られたから新たな展開がない限りは収録されないと思われ

167 ：デフォルトの名無しさん：2007/10/05(金) 21:20:58

もし追加されるとなると互換文字としてU+Fxxxの領域に割り当てられるだろうな。
ハングル音節ブロックの余ってるU+D7A4～U+D7AFに追加でもいいかもしんない。このままだとそこ永久に埋まりそうにないし。

168 ：デフォルトの名無しさん：2007/10/06(土) 04:03:43

>>167
ブロックの割り当ては16文字単位だからHangul Jamo Extended Bでも使ってないのか

169 ：デフォルトの名無しさん：2007/10/06(土) 05:37:35

TUF16文字列をUTF-8に変換した場合、
4バイト以上はまず来ないと思っていいですか？

170 ：デフォルトの名無しさん：2007/10/06(土) 05:38:39

UTF16

171 ：デフォルトの名無しさん：2007/10/06(土) 05:53:53

サロゲートに対応していない馬鹿なUTF-8コンバータだったら
6バイトのものを送ってくるかも

172 ：デフォルトの名無しさん：2007/10/06(土) 05:53:57

>>169 なぜそうなる？

173 ：デフォルトの名無しさん：2007/10/06(土) 06:39:33

UTF-16ではU+10FFFFまでしか表せないからじゃね?

174 ：デフォルトの名無しさん：2007/10/06(土) 10:18:53

>>169
6バイト

175 ：デフォルトの名無しさん：2007/10/06(土) 11:20:14

>>174
>>171以外ならそんな入力の場合に6バイトになるのかkwsk

176 ：デフォルトの名無しさん：2007/10/06(土) 11:20:34

×そんな入力
○どんな入力

177 ：デフォルトの名無しさん：2007/10/06(土) 11:23:48

http://pc11.2ch.net/test/read.cgi/tech/1177930957/

178 ：デフォルトの名無しさん：2007/10/06(土) 15:19:26

Javaは3バイトまで

179 ：デフォルトの名無しさん：2007/10/06(土) 17:15:03

ドイツ語圏は、ドイツ語を使う国々が集まって、表記法を統一する会議を何年かおきに
やっている。
なんで、東アジア、漢字を統一できなかったのか、残念。

180 ：デフォルトの名無しさん：2007/10/06(土) 17:25:36

U+10000からU+10FFFFまでは4バイト

181 ：デフォルトの名無しさん：2007/10/06(土) 17:27:11

>>179
ドイツ人は制定マニアだから。
そういうことが難しいからこそ、漢字圏なんじゃないのか?

182 ：デフォルトの名無しさん：2007/10/06(土) 17:56:29

ドイツ語圏はドイツ語圏だけど
漢字圏は中文圏じゃないし

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

183 ：デフォルトの名無しさん：2007/10/06(土) 18:20:18

>>179 中国だって統一王朝が立つと文字の整理をやってるぞ

184 ：デフォルトの名無しさん：2007/10/06(土) 18:35:31

MySQLのUTF8は3バイト文字までしか対応していない

185 ：デフォルトの名無しさん：2007/10/06(土) 19:35:22

>>184
ありゃりゃ。みんなどうしてんの？

186 ：デフォルトの名無しさん：2007/10/06(土) 20:07:40

>>183
毛沢東もやった死ね

187 ：デフォルトの名無しさん：2007/10/06(土) 21:51:16

じゃあ漢字の統合のために台湾併合だな

188 ：デフォルトの名無しさん：2007/10/06(土) 23:34:15

日本もね

189 ：デフォルトの名無しさん：2007/10/06(土) 23:57:53

康熙字典体に統一で桶。

190 ：デフォルトの名無しさん：2007/10/07(日) 02:48:55

中国は文献がほとんどかえりみられなくなっては
日本から逆輸入というのを定期的に繰り返しているし。
文字の統一なんて掛け声以前の問題じゃなかろうか。

191 ：デフォルトの名無しさん：2007/10/07(日) 03:38:26

>>189
Unicodeはそういう方針だな。GB7589とGB7590は繁体字で入ってるし
並び順も康煕字典の部首画数順だし

192 ：デフォルトの名無しさん：2007/10/07(日) 05:22:31

80年代後半から90年代前半って
台湾の方が電子化進んでたよね

193 ：デフォルトの名無しさん：2007/10/07(日) 08:48:37

いまや日本＝秋葉原でHENTAI ANINEの国という認識だろ。
文字なんて「萌え」が残ってればおｋなんじゃね？
と秋葉帰りの外人から思われてるに違いない。

194 ：デフォルトの名無しさん：2007/10/07(日) 13:30:02

>>191 Unicode の康煕字典ベースは、Unicode の原典主義からの帰結やね。
並び順の、康煕字典の部首画数順はもしかして漢字文化圏のグローバルスタンダード?

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

195 ：デフォルトの名無しさん：2007/10/07(日) 13:37:21

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

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

196 ：デフォルトの名無しさん：2007/10/07(日) 14:15:38

ググレカス

197 ：デフォルトの名無しさん：2007/10/07(日) 14:40:15

>>194
CJKのどこからも文句の出ない並び順が康煕字典順しかなかったってことだろう
現代中国はにくづきとふなづきを統合したりしたまったく異なる部首を使ってるし
発音順は国によって全く異なるし

198 ：デフォルトの名無しさん：2007/10/14(日) 20:13:05

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

199 ：デフォルトの名無しさん：2007/10/14(日) 20:21:10

>>198
http://www.google.co.jp/search?q=universalchardet

200 ：デフォルトの名無しさん：2007/11/03(土) 16:03:56

【日台中韓】韓・中・日・台が漢字の字体統一へ[11/03]
http://news21.2ch.net/test/read.cgi/news4plus/1194067861/

201 ：デフォルトの名無しさん：2007/11/03(土) 19:20:21

字体統一って中国以外にメリットあるの？

202 ：デフォルトの名無しさん：2007/11/03(土) 19:22:45

日本すら未だに統一できてないのに秒速で漢字が増えてゆく国が統一とは

203 ：デフォルトの名無しさん：2007/11/12(月) 17:13:15

>>200
ウソだったらしい。もうなにがなんだか。

【日台中韓】「中・日・韓・台の漢字統一」報道を否定！簡体字使用の変更は不可能[11/12]
http://news21.2ch.net/test/read.cgi/news4plus/1194847769/

204 ：デフォルトの名無しさん：2007/11/12(月) 18:23:49

ヨタ記事をいちいち貼るなよ。

205 ：デフォルトの名無しさん：2007/11/17(土) 15:44:45

IMEパッドの文字の上にマウスを持っていくとでるバルーンヘルプの内容が取得できるライブラリ(関数)をしりませんか？

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

見たいな、、、

206 ：デフォルトの名無しさん：2007/11/18(日) 00:29:36

超漢字検索の情報ウィンドウの内容を取得できるライブラリもほしい

207 ：デフォルトの名無しさん：2007/11/20(火) 23:35:37

JIS X 0213 面区点番号とunicodeのマッピングを
機械的に求めることはできますか？

208 ：デフォルトの名無しさん：2007/11/21(水) 11:39:36

テーブル引く

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

209 ：デフォルトの名無しさん：2007/11/21(水) 13:03:01

ドイツ語は定期的にspellをドイツ語圏で統一するように会議をしているね。ま、向こうは意味まで
同じなのだが。形だけ揃えても意味ないし、朝鮮半島はハングルで統一されている。CKJで統一
する意味はないと思うのだがね。

210 ：デフォルトの名無しさん：2007/11/21(水) 19:13:46

perlで作ったcgiに一番ｵﾇﾇﾒなコードｋｗｓｋ

211 ：デフォルトの名無しさん：2007/11/21(水) 21:09:46

perlはなんでもいいよ。
Encode使えば割りとw何でもできるから。
好きなのにしな。

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

212 ：デフォルトの名無しさん：2007/11/24(土) 02:48:07

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

213 ：デフォルトの名無しさん：2007/11/24(土) 02:52:40

>>212
ワイド文字をリテラルでは使わない。
UTF-8から変換。

214 ：デフォルトの名無しさん：2007/11/24(土) 03:07:35

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

215 ：デフォルトの名無しさん：2007/11/24(土) 04:02:12

全部\uxxxxで書いちゃえ。

216 ：デフォルトの名無しさん：2007/11/24(土) 04:22:36

うほ、なげやり
でもそれすらgccいけるけどvcは\u使えないとか罠があったり。。
いろいろ実験して、バッドノウハウだけ増えたな・・
vc,gccともソースがUTF-16系は不可、vcはシグニチャなしUTF-8ソース不可、
逆にgccはシグニチャありUTF-8ソース不可・・

217 ：デフォルトの名無しさん：2007/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 ：デフォルトの名無しさん：2007/11/24(土) 15:53:48

vcがutf-8ダメだってのは、何がだめだっての？

219 ：デフォルトの名無しさん：2007/11/24(土) 17:14:21

vc7で、UTF-8のソースだと
#define XX "あ"
とかあるとだめだけど
#define XX "ああ"
だと平気。たぶんsjisとして処理してるから日本語リテラルが奇数バイト
だとだめみたいな感じ。

220 ：デフォルトの名無しさん：2007/11/24(土) 23:51:33

vc8使え。終了

221 ：デフォルトの名無しさん：2007/11/25(日) 10:34:26

00h～1Fh　制御文字
20h～7Fh　各国共通（1バイト文字）
80h～FFh　各国自由（1／2バイト文字）

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

222 ：デフォルトの名無しさん：2007/11/25(日) 10:36:33

あとからならどうとでも言える

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

223 ：デフォルトの名無しさん：2007/11/28(水) 12:10:33

80年代前半は漢字が表示できないマシンがごろごろしてたし
1987年ごろのパソ通でも、漢字を使うと表示できないマシンが
あるから、カナ以外禁止というところもあったね。

224 ：デフォルトの名無しさん：2007/11/28(水) 14:01:29

テキストVRAMで漢字もOK、なPC9801も初期はJIS第2水準はオプションだったしなあ

225 ：デフォルトの名無しさん：2007/11/28(水) 18:40:35

>>224
初代は第1水準もオプション

226 ：デフォルトの名無しさん：2007/11/28(水) 18:44:17

テキストVRAMが歯抜けだったからね。＜無印PC-9801
オプションの漢字ROMボードを入れるとその隙間を埋めるRAMもついてきたってわけ。

227 ：デフォルトの名無しさん：2007/11/29(木) 21:02:51

おまえらいくつだよ・・おっさんばっかだな
まあ若い人は文字コードになんか興味ないか

228 ：デフォルトの名無しさん：2007/11/29(木) 21:29:00

28歳はおっさんですかそうですよね。

229 ：デフォルトの名無しさん：2007/11/29(木) 22:02:33

外見によっては22でもおっさん。

230 ：デフォルトの名無しさん：2007/11/29(木) 22:22:00

プログラマーは25才が卒業式です

231 ：226：2007/11/30(金) 00:24:07

>>227
失礼な。せめておばさんと呼べ。

232 ：デフォルトの名無しさん：2007/11/30(金) 07:21:18

時代背景を知らないと

テキストVRAMって文字サイズとか位置とか固定になっちゃうじゃんｗｗｗ
超バカスｗｗｗ
なんでグラフィックVRAMに全部書かないのｗｗｗ

とか言い出す奴がいそうだな。
8ビットマシンはグラフィックVRAMに漢字表示できるものもあったわけだが

233 ：デフォルトの名無しさん：2007/11/30(金) 08:53:49

武勇伝はチラシの裏でどうぞ
219はどうなった？

234 ：デフォルトの名無しさん：2007/11/30(金) 19:30:45

単にバイト列としてコンパイルしたいだけなら
#pragma setlocale("C") を入れときゃいいだけでは？

235 ：デフォルトの名無しさん：2007/12/01(土) 09:01:43

POSITION 160,100:PATTERN -16,KANJI$(4746)

236 ：デフォルトの名無しさん：2007/12/01(土) 16:08:27

KANJI$テラナツカシス

237 ：デフォルトの名無しさん：2007/12/02(日) 07:14:19

Unicodeはもうだめだな
サロゲートペア，異体字，半角カナ．．．問題ありすぎ
世界中の文字使えるったってほとんど意味無いしょ
第３水準で変な記号いっぱい追加されたけどそれも要らん
JISが大手PC・携帯メーカーに呼びかけて
MS，アップル，ドコモ，au，ソフトバンク，NEC，富士通，IBM
2バイト文字の最終統一規格を作るしかないんじゃないの？
8080H～FFFFHの16384字あれば十分

238 ：デフォルトの名無しさん：2007/12/02(日) 10:41:18

＞JISが大手PC・携帯メーカーに呼びかけて
逆だ。JISは大手に踊らされている御用団体だからね。
つーか、それができるのならJIS83辺りで統一できているはず。
# 実態は……言うまでもないよな。

＞8080H～FFFFHの16384字あれば十分
計算できる?

239 ：デフォルトの名無しさん：2007/12/02(日) 11:18:03

CJK互換漢字に4字追加されるみたい。

240 ：デフォルトの名無しさん：2007/12/02(日) 11:25:30

>>237
もうおなかいっぱい。
これ以上文字コードを増やさないでくれ。

241 ：デフォルトの名無しさん：2007/12/02(日) 11:45:05

しかも>>237のレベルでは…

242 ：デフォルトの名無しさん：2007/12/02(日) 18:39:01

UTF-8で統一されるのが楽かなあ
>>237
2バイト固定長はもう無理でしょう。というか固定長は結合文字の
存在もあるしコーディング上のメリットがないんだよなあ。
結合文字を考慮した文字検索アルゴリズムとかもうどうしていいんだか・・

243 ：デフォルトの名無しさん：2007/12/02(日) 19:06:21

TronコードでOK

244 ：デフォルトの名無しさん：2007/12/02(日) 20:31:22

>>243
TRONコードは、単に、すでにある文字集合をぶち込む枠組であって、
文字集合の整備は漢字の収集とかやったけど、処理の上位層について
TRON方面は概念を発表しただけで具体的なものは何も出てきて
いないし、現在の問題を何ら解決できるものではない。現状から見て、
たいした期待はできない。

245 ：デフォルトの名無しさん：2007/12/03(月) 01:24:14

グリフ単位での文字検索は諦めて、コードポイント単位で
やるしかないんじゃないの。当面は。

246 ：デフォルトの名無しさん：2007/12/03(月) 22:10:17

結合文字はそのコードポイントが別だから検索がめんどいんじゃないのか・・

247 ：デフォルトの名無しさん：2007/12/03(月) 22:22:07

このへんを実装すれば多分おｋ
http://www.unicode.org/reports/tr10/
http://www.unicode.org/reports/tr15/

248 ：デフォルトの名無しさん：2007/12/03(月) 23:03:38

UTF-8な文字「X」が文字コード AB CD EF で定義されているとして、
別の文字「Y」がこれらをシャッフルした文字コード（ AB EF CD など）で
定義されている、という組み合わせを探しています。
効率的な調べ方とかあるかしら？

249 ：デフォルトの名無しさん：2007/12/03(月) 23:14:28

たかだかx6だからベタでいいだろ。

250 ：デフォルトの名無しさん：2007/12/04(火) 01:18:41

>>249
char a[] = { 0xE3, 0x82, 0xA2, 0x00 };
char b[] = { 0xE3, 0xA2, 0x82, 0x00 };
ってしたときに、aは「ア」だけどbに割り当てられた文字はないでしょう？
そういうのをプログラム的に省きたかったんだ。無理っぽいなあ

251 ：デフォルトの名無しさん：2007/12/04(火) 01:25:35

>>250
んなこと悩んでいる間にベタで書けば5分掛からないだろ。わけわからん。
それともなんかのプログラムの動作中ってこと？

252 ：デフォルトの名無しさん：2007/12/04(火) 07:34:33

これって割り当てられてるってこと？

ttp://www.google.co.jp/search?hl=ja&q=%E3%82%A2
アの検索結果約 73,600,000 件中 1 - 10 件目 (0.05 秒)

ttp://www.google.co.jp/search?hl=ja&q=%E3%A2%82
㢂の検索結果約 2,740 件中 1 - 10 件目 (0.24 秒)

253 ：デフォルトの名無しさん：2007/12/04(火) 09:56:17

日本語の文字には無いけど、中国の文字にあるだろ

254 ：デフォルトの名無しさん：2007/12/04(火) 09:56:49

0xE3, 0xA2, 0x82 だから、文字コード 3882 だよ。

255 ：デフォルトの名無しさん：2007/12/04(火) 10:56:35

U+3882 はちゃんと ExtA に割りあてられてるな。
Windows なら Vista にするか対応フォントを入れれば見えるはず。

256 ：デフォルトの名無しさん：2007/12/04(火) 11:36:45

関数的に書くなら、
端から生成して、端からx6の組み合わせで生成して、
端からUTF-8になってないバイト列を落とすフィルタを通す、
という感じで書くかな。

257 ：デフォルトの名無しさん：2007/12/04(火) 12:05:37

>>251
AB CD EF は16進数の10～15ではなくて、6種類の変数A～Fという意味。

文字列処理関数のテストケースを書いてて、248 みたいな組み合わせが数通り欲しかったのさ。
文字コード一覧表を目視して解決しますた。あんがと。

>>255
ExtAってなんかの制御コード？

>>256
日本語フォントが用意されているかを調べる、というコードが書けない俺orz

258 ：デフォルトの名無しさん：2007/12/04(火) 12:28:23

「日本語フォント」なんて関係ないだろ。
「文字集合」で考えろ。

259 ：デフォルトの名無しさん：2007/12/04(火) 12:48:05

「UTF-8的にあり得る(3バイトの)バイト列」じゃなくて、
「UnicodeからJIS X 0208(あるいはCP932)にマップ可能なコードポイント」を抽出したいのか？
それはテーブル引くしかないような気がする。

260 ：デフォルトの名無しさん：2007/12/04(火) 12:53:57

ExtA = CJK Ideograph Extension A
U+3400～U+4DB5(Unicode3,4), U+4DBF(Unicode5)
いわゆる「機種依存文字」な漢字でUnicode2に入ってなかった奴が入った所と思った。確か

261 ：デフォルトの名無しさん：2007/12/04(火) 13:03:01

JIS X 0208あるいは指定した文字集合だけ考えればいいなら、

JIS X 0208の全ての区点コードをリストアップ ('あ'を例に)
↓
UTF-8の16進数表現に変換 (0xE3 0x81 0x82)
↓
バイト列をソートしたのものを一桁目に(CSV) (0x81 0x82 0xE3, 0xe3 0x81 0x82)
↓
一桁目でjoin (0x81 0x82 0xE3でjoin)
↓
join後、複数項目のあるものをリストアップ。

262 ：デフォルトの名無しさん：2007/12/04(火) 17:55:57

文字集合と符号化方式の概念が理解できてなかった。まさに>>259だ。

>>258、>>260-261
もthx!

263 ：デフォルトの名無しさん：2007/12/04(火) 23:52:17

>>233
ｽﾏﾝ、結局Linuxどうしてんのかレスなかったから見てなかった・・
Stringを自前で作って、各文字コード処理できるようにする方向でやってる

264 ：デフォルトの名無しさん：2007/12/06(木) 01:28:41

std::stringは結局役に立たんからね

265 ：デフォルトの名無しさん：2007/12/06(木) 19:00:37

EUC-JPって第2面をA121～FE7Eに配置できないのかな
第1バイトがA0～FFなら2バイト文字だと認識するようにすれば
いいと思うんだけど

266 ：デフォルトの名無しさん：2007/12/06(木) 20:32:41

>>260
U+4DBFに文字なんか割り当てられてたか?
ブロックの範囲と文字が収録されている範囲をごっちゃにしてる
通信用語の基礎知識あたりの鵜呑みじゃあるまいな

267 ：デフォルトの名無しさん：2007/12/06(木) 20:33:43

>>265
円記号問題どころの騒ぎじゃなくなります
メインフレーム各社の独自コードにはそういう変態割り当てをしたものが
けっこうあるけど

268 ：デフォルトの名無しさん：2007/12/06(木) 20:52:49

>>266
スマン
あたり
orz

3.0 と現行のを調べた。
レンジは 3.0 だと U+4DFF まで、5.0 だと U+4DBF まで、
中身が入ってるのは U+4DB5 まで、で合ってます？

間に入ったのは Yijing Hexagram Symbols って八卦かよw

269 ：デフォルトの名無しさん：2007/12/06(木) 22:09:16

>>268
うむ
ちなみにU+9FA5の後ろには本当に文字が断続的に追加されてるな

270 ：デフォルトの名無しさん：2007/12/06(木) 22:25:43

http://examples.oreilly.de/english_examples/nutshell/cjkv/adobe/
aj16.tar.Zが更新されてる
pri108に対応していくつかのCIDにUnicodeが追加された模様

271 ：デフォルトの名無しさん：2007/12/07(金) 08:24:11

第１～第４＋非漢字で11233字
補助漢字で6067字
補助漢字と第３，第４でかぶるのが約2900字
11233＋6067－2900＝14400字
8080H～FFFFH＝16384字

272 ：デフォルトの名無しさん：2007/12/07(金) 08:42:20

>>267
それはSHift-JIS固有の問題。

273 ：デフォルトの名無しさん：2007/12/07(金) 09:30:20

何そのとんちんかんなレスはw

274 ：272：2007/12/07(金) 09:42:22

あ、ダメかｗ
言いたいのは1～2バイトに収まるようにシンプルにしてほしいってこった

275 ：デフォルトの名無しさん：2007/12/07(金) 10:57:54

UCS-2の過ちを繰り返すのかよw

276 ：デフォルトの名無しさん：2007/12/07(金) 12:51:45

繁体字とか簡体字とかハングルとか要らんだろｗ

277 ：デフォルトの名無しさん：2007/12/07(金) 13:41:14

ハングルという偉大な文字は必要ニダ！

278 ：デフォルトの名無しさん：2007/12/07(金) 13:47:08

自分に必要なありとあらゆるソフトウェアを、その独自規格に準拠したもの
のみでまかなえるなら好きにすればー?

# 文字コードが、文字集合を情報「交換」のために符号化したものである
# ということを理解してないやつがこんなにも多いのは何故だ?

279 ：デフォルトの名無しさん：2007/12/07(金) 13:48:26

漢字なんかいらんだろ（米国人(32)）

280 ：デフォルトの名無しさん：2007/12/07(金) 13:59:54

その昔、Win3.1の時代に漢字対応の必要をアメリカ人に説明しようとしたら、
通訳が「Chinese Characters」って訳しやがって説明に苦労したもんだぜ。

281 ：デフォルトの名無しさん：2007/12/07(金) 15:02:01

もうUTF-8で全部解決だろ

282 ：デフォルトの名無しさん：2007/12/07(金) 16:58:25

Unicode の符号化という点ならそうだけど
Unicode に入れられそうもない変体仮名とかを
符号化する場合を考えると Unicode だけに
頼れないし

283 ：デフォルトの名無しさん：2007/12/07(金) 18:32:19

plain textは諦めてくださいと遠くからUnicode神の声が聴えてきました。

ところで変体仮名のみの文字集合は既に定義されているのですか?
あるとすれば、どういう包接基準を採用しているのですか?

284 ：デフォルトの名無しさん：2007/12/07(金) 20:36:47

るりーる

285 ：デフォルトの名無しさん：2007/12/07(金) 21:04:53

>>272
>>265みたいなことをしたらShift_JISと同じ(もっと悪い)問題が起きるって
言ってるんだが。
>>282
入らないのは日本が入れろと言わないから。
異体字だって結局米国企業のAdobeが登録するまで日本は
なーーーんにもしなかった。

286 ：デフォルトの名無しさん：2007/12/07(金) 21:05:18

>>283
とりあえずTRONにはあるようだ
http://ja.wikipedia.org/wiki/%E4%BD%8F%E6%B0%91%E5%9F%BA%E6%9C%AC%E5%8F%B0%E5%B8%B3%E5%8F%8E%E9%8C%B2%E5%A4%89%E4%BD%93%E4%BB%AE%E5%90%8D

287 ：デフォルトの名無しさん：2007/12/07(金) 21:06:31

>>283
TRONコードに住民基本台帳収録変体仮名とその他の変体仮名が入ってる。
ということは住基統一コードにも変体仮名が入ってるのか

288 ：デフォルトの名無しさん：2007/12/07(金) 21:12:47

こういう文字をUnicodeに入れてくれって言う場合の
日本側の窓口はどこなんだろ。経産省？

密室でやらずに一回ぐらいパブリックコメントの募集してくれよ。

289 ：デフォルトの名無しさん：2007/12/07(金) 21:14:56

こんだけオープンにやってて密室もへったくれもあるか
http://std.dkuug.dk/jtc1/sc2/wg2/
IVDの前回の公開レビューだって
http://www.unicode.org/ivd/pri/pri98/index.html
終了一週間くらい前になって気づいた俺が触れて回るまで
日本で取り上げているサイトが一切なかったという関心のなさっぷり
それで密室とかなんとかいっても説得力のかけらもない

290 ：デフォルトの名無しさん：2007/12/07(金) 21:37:49

そこへ持ってゆく文字の選定をしている日本側の窓口の話をしてるんだが。

291 ：デフォルトの名無しさん：2007/12/07(金) 22:11:20

とりあえず、英語が読めない人は、翻訳者を雇わないと、
投稿手順すら分からないのではないかと。

292 ：デフォルトの名無しさん：2007/12/07(金) 22:17:00

>>287
wikipediaにあるわw
http://ja.wikipedia.org/wiki/%E4%BD%8F%E6%B0%91%E5%9F%BA%E6%9C%AC%E5%8F%B0%E5%B8%B3%E5%8F%8E%E9%8C%B2%E5%A4%89%E4%BD%93%E4%BB%AE%E5%90%8D

http://www.chokanji.com/features/ckv4.html
TRONは何でもぶちこみ方式だろうから、
まだ異体字の包接基準はないのかな。
かなり知識がないと無理だね。

293 ：デフォルトの名無しさん：2007/12/09(日) 10:03:04

TRONはコード表はフリーなんだけど
その運用に事実上必要な異体字のデータベースで金稼いでるんだよね
超漢字検索で変体仮名を検索すると関連字として対応する漢字やひらがなが
出てくるし漢字から変体仮名を検索することもできる

294 ：デフォルトの名無しさん：2007/12/09(日) 12:07:54

いっそ日本代表は無視してUTCのfull memberになったほうが話が早いかもしれない
英語力と金が必要だけど

295 ：デフォルトの名無しさん：2008/01/02(水) 16:32:43

あけましておめでとうございます
結局JIS X 0221の改訂版は2007年中に出ませんでした。
JIS X 0213:2004で2004となるべきところが2003となるような誤植が
今回も発生するのでしょうか。

296 ：デフォルトの名無しさん：2008/01/05(土) 01:13:42

>>295

えっまぢ！？
そういや、12月20日前後の官報がデッドラインだと聞いてたんだけど、
チェックするの忘れてたよ。。。

あーあ、また関係者は地獄を見ることになるのかな・・・

297 ：デフォルトの名無しさん：2008/01/05(土) 01:33:09

そうこうしている間にもamendmentは増えてゆく～

298 ：デフォルトの名無しさん：2008/01/05(土) 01:43:49

>>296
ietf-charsetsで外人が「Hey, 内容変更が何もないのにどうして-2003が-2004
になったんだい? (大意)」みたいなことを安岡センセイに聞いてたのを思い出した。
そりゃ知らないやつは不思議に思うよなあ

299 ：デフォルトの名無しさん：2008/01/05(土) 06:06:50

ちゃんと出てるじゃん
制定年月日2007/12/20になってるから本当にギリギリだったみたいね

300 ：デフォルトの名無しさん：2008/01/05(土) 07:17:14

JISCで閲覧できる規格票が
CJKU_SR.txtをわざわざ50MBのPDFにしてたりしてワロタ

301 ：デフォルトの名無しさん：2008/01/12(土) 07:17:23

>>300
中の人が内規かなにかに従った結果なんだろうね

302 ：デフォルトの名無しさん：2008/01/12(土) 12:12:01

見た目までコントロールしたいからでしょ。
フォント環境の違いで誤解が生じないように。

303 ：デフォルトの名無しさん：2008/01/12(土) 12:27:42

仮にそうだとしてもフォントを埋め込めば済む話ではないの？

304 ：デフォルトの名無しさん：2008/01/12(土) 12:28:15

ただ数字が並んでるだけなのにどう誤解するというのだ
そもそも正文がテキストファイルなんだが

305 ：デフォルトの名無しさん：2008/01/16(水) 19:29:38

質問です
ttp://www.ac.cyberhome.ne.jp/~mattn/cgi-bin/blosxom.cgi/etc/20071221111511.htm
> 1文字毎をメモリに持つのではなく全てバイト列で処理すると言った方法の為、
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが

普通のi18n対応アプリケーションは文字ごとに(codepointごとに?)
メモリに確保して、文字配列として処理されることが多い、けれども
バイト列で処理する…バイト列を喰わせても大丈夫な関数を用意して文字を操作する

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20071130/288467/

*Javaとかのアプローチはcodepointごとに文字を操作。(分解合成がめんどい)
*Vimのアプローチはバイト列を独自関数で文字として操作。(patch workの集大成)

oniguruma とか sakura editor とか emcode.pm とか身近にあるのは
みんなpatch workの集大成なのですか？

306 ：デフォルトの名無しさん：2008/01/16(水) 19:40:01

> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが

ん、じぶんの理解だとここの部分の意図が汲めなくなるか…

内部で Unicode の codepoint に従って処理しているソフトは
あまりないけど…内部でなんらかのエンコードに変換して保持
してるソフトは多くて…でもVimはバイナリのまま保持するですよ…?

というような意味とか? ああなんかよくわからなくなってきた…orz

307 ：デフォルトの名無しさん：2008/01/16(水) 21:53:51

マルチバイト or ワイド文字と分解合成とは直交する問題だろ。
何が言いたいのだろう。

308 ：デフォルトの名無しさん：2008/01/17(木) 13:22:34

まともなi18nの仕事で「patch workの集大成」でないものなんてないぞ。
全ての文字、言語に通じている人間なんていないのだから。

309 ：デフォルトの名無しさん：2008/01/17(木) 14:09:39

仕様が実際patch workだからな
というか言語というものがそもそも...

310 ：デフォルトの名無しさん：2008/01/18(金) 14:46:18

>>307
http://anond.hatelabo.jp/20070902073806
>喫煙と、麻薬や飲酒は直交する問題だと思いますが…
直行する = 相関性のみられない事象のこと = 分けて論じるべき議題

うむ。まずじぶんは小学生あたりからやり直すべきか。
てか日本語って難しいな orz

>>308-309
㌧くす。言語は日々の積み重ね。ちぃおぼえた

311 ：デフォルトの名無しさん：2008/01/18(金) 15:00:13

http://homepage.mac.com/icbp90pink1/iblog2/B1108781646/C1540234484/E20061210205530/index.html
>「おそらく漢字ほど難しくないからそれほどでもないと思うけど、例えば
>"than" を "then" と書く若者が増えてるよ。」っと言っていました。

>「それって全く意味が違うじゃん。」っと言ったら、「orthogonalだね。」と
>言われました。「orthogonalって何？」と聞いたら、90℃（直角）との事。

>「何で180℃じゃないの？」っと聞いたら、「反対の意味って訳じゃないけど
>（左右みたいな）、ぜんぜん違う意味だから、orthogonalって言うんだよ。」
>っと教えてくれました。面白い表現ですね！

『欧米かっ！』と言わざるを得ない…。
グラフをイメージして相関性云々とか考え出すと,
なんで90度でねじれの関係になるんだ, とかわけかわからんかった orz

312 ：デフォルトの名無しさん：2008/01/18(金) 15:52:55

>>310
> >>307
> http://anond.hatelabo.jp/20070902073806
> >喫煙と、麻薬や飲酒は直交する問題だと思いますが…
> 直行する = 相関性のみられない事象のこと = 分けて論じるべき議題

誤変換かもしれないが、直交と直行を混同するようでは先がおもいやられる...

313 ：デフォルトの名無しさん：2008/01/18(金) 16:25:40

本来の意味で使ってる可能性も・・・

314 ：デフォルトの名無しさん：2008/01/18(金) 17:07:36

>>310
文脈から汲めば、分けられないってことだろ
とはいえ>>312みたいな態度が一番気に食わん

315 ：デフォルトの名無しさん：2008/01/18(金) 17:59:53

直交ずる～というと2つのベクトルの内積(2直線の射影でもいいや)を考えるでしょ常考。
高校数学程度の概念は常識として知っておいてくださいな。

316 ：デフォルトの名無しさん：2008/01/19(土) 03:20:48

この文脈でそんな本来の意味の用語を使うわけないでしょ。
それくらい想像力働かせてくださいな。

317 ：デフォルトの名無しさん：2008/01/19(土) 07:02:46

直交⇔互いに独立
∴2つのベクトルの内積(2直線の射影でもいいや)=0

318 ：デフォルトの名無しさん：2008/01/19(土) 07:08:44

「2つのベクトルの内積(2直線の射影でもいいや)」が0以外の値を持つとき
それらは直交しない

つまり「直交」については最初から一貫して「本来の意味」で使われているw

馬鹿は >>315

319 ：デフォルトの名無しさん：2008/01/19(土) 12:20:41

数学総合スレはここですか?

320 ：デフォルトの名無しさん：2008/01/19(土) 14:12:35

>>319
直帰を許可します

321 ：デフォルトの名無しさん：2008/01/21(月) 00:06:37

ん？この流れム板のどこかのスレで見た気が。デジャヴ？

322 ：デフォルトの名無しさん：2008/01/30(水) 01:45:55

SJIS2004とかJISX213系の文字コード表って無いですかね

どうも変換がうまくできない・・・

323 ：デフォルトの名無しさん：2008/01/30(水) 07:47:52

JISCにあるじゃん

324 ：デフォルトの名無しさん：2008/01/30(水) 23:27:43

JISCのPDFから手で書き取れと申すか
※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
とりあえず機械可読な奴がほしかったらここでも見れ
http://x0213.org/codetable/

325 ：デフォルトの名無しさん：2008/01/30(水) 23:32:34

＞※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
ごめんJISCを甘く見てた……

326 ：デフォルトの名無しさん：2008/01/30(水) 23:40:52

JISC・・・ひでえな。

327 ：デフォルトの名無しさん：2008/02/01(金) 21:15:44

www.unicode.org落ちてる?

328 ：デフォルトの名無しさん：2008/02/05(火) 21:26:41

Joel Spolsky氏のブログ翻訳「ソフトウェ開発者なら絶対に最低限知っていなければならないユニコードと文字セットについて」

Servlet Garden ≫ Unicode and Character Sets (Translation)
http://www.t3.rim.or.jp/~yoko-k-h/java/servlet/2008/01/31/unicode-and-character-sets-translation.html

329 ：デフォルトの名無しさん：2008/02/05(火) 23:42:35

Unicode Transformation Format 8 と UCS Transformation Format 8 で混乱するのだけど
それぞれをどう解釈したらいいんだろう？

330 ：デフォルトの名無しさん：2008/02/05(火) 23:56:23

略せばどっちもUTF-8。はい、同じ。

331 ：デフォルトの名無しさん：2008/02/06(水) 00:00:19

Unicode.orgがつけた名前
ISO/IECがつけた名前
中身おんなじ

332 ：デフォルトの名無しさん：2008/02/06(水) 00:11:42

互換性あるのはわかったけど、Unicodeのが4バイト、
UCSのが6バイトみたいなこと書かれてたんで5バイト目以降は違うってことかな？

333 ：デフォルトの名無しさん：2008/02/06(水) 00:32:16

ISO/IEC 10646はAmd2:2006で、0群17面以降には永久に文字を追加しないことにしたから
UTF-8にしたときには5オクテット以上にはならない。

Uniocde.org的には、単に追加予定なしなだけなので、UTF-8は理屈上最長の
6オクテットまで使っていいけど、でも文字入ってないよ？状態。

だから、結局中身おんなじ

334 ：デフォルトの名無しさん：2008/02/06(水) 01:09:46

もともとUnicode的にUTF-16の絡みで10FFFFまでになって、
おれにAmd2:2006で追従したんじゃないっけ。
どちらにしろ、今はどちらも4byteまで。
http://www.rfc-editor.org/rfc/rfc3629.txt 参考までにRFC

335 ：デフォルトの名無しさん：2008/02/06(水) 02:42:04

なるほど。納得できたありがとう。

336 ：デフォルトの名無しさん：2008/02/06(水) 18:15:44

いつの間にかIVS(漢字のVS)正式に決定してた。
http://www.unicode.org/ivd/index.html

337 ：333：2008/02/07(木) 08:54:13

>>334
そうみたいね
俺古いRFC見てたわ

338 ：デフォルトの名無しさん：2008/02/19(火) 23:13:06

U+FDD0～U+FDEFが使用禁止になったのって何でだろう?

339 ：デフォルトの名無しさん：2008/02/22(金) 20:04:35

JIS X 0221:2007規格票の8. 注記3によると
「符号化文字でないことが保証された数値を必要とする内部処理」に使用するためだそうだ。
例として「表を終了させる、テキストの終わりを通知するなど」が挙げられてる

340 ：デフォルトの名無しさん：2008/02/23(土) 03:05:40

文字コードふぜいが表の終了とか意識するな。

341 ：デフォルトの名無しさん：2008/02/23(土) 08:30:49

文字集合はともかく、
符合化方式がその辺りを考慮するのは当然。

342 ：デフォルトの名無しさん：2008/02/23(土) 09:17:36

あとU+FFFFはBMPの最後のコードだから番兵に使うことを特に意識している
U+FFFEは言うまでもなくBOM判別用

343 ：デフォルトの名無しさん：2008/02/23(土) 13:25:24

ASCII にだってコントロールコードの領域があるしね

344 ：デフォルトの名無しさん：2008/03/12(水) 02:47:39

文字コードとやらに興味を抱き、とりあえずユニコードが標準と知り、
番号からUTF-16を使っていたのですが、
このスレの人は何を主に使っているのですか？
検索をしていると16よりも8の話題のほうが見つかるので、
実は8のほうがいいのかなと悩んだりしています。

345 ：デフォルトの名無しさん：2008/03/12(水) 03:08:25

つか、今、同じテキストファイルを変換してみたのですけれども、
よくよく考えたらUTF-8は可変で日本語の文章に関しては、
全てを2バイトで扱うUTF-16に比べて、
日本語部分を3バイトで扱うUTF-8は情報量が多いほど、
容量が無駄に大きくなってしまいませんか?
1.5倍ですよね。それを補うほどの使い勝手の良さがあるのでしょうか。

346 ：デフォルトの名無しさん：2008/03/12(水) 03:14:34

南北アメリカや西ヨーロッパの多く言語は平均すると一文字当たり2オクテット未満であらわせる。

347 ：デフォルトの名無しさん：2008/03/12(水) 03:27:30

後は１要素が1byteに収まるから扱いが楽、とか

まぁ日本語を基準に考えてる時点でUnicodeの思想から外れてる気はする

348 ：デフォルトの名無しさん：2008/03/12(水) 09:29:53

>>344
1.5倍程度でけちけちするな、多言語化ってのはそういうもんだ。
マジレスするとUTF-8側にメリットがあるというよりも、
UTF-16側がサロゲートペアやバイトオーダー、ASCII非互換、guessしずらいなど、
いろいろと面倒なのでUTF-8の方がよい。

349 ：デフォルトの名無しさん：2008/03/12(水) 10:57:52

WindowsがUTF-16なんで、自分のプログラムもUTF-16です。

350 ：デフォルトの名無しさん：2008/03/12(水) 23:33:43

ケチ臭いことを言うんだったら、ASCIIの制御文字の部分の方が勿体無いと思うけどね。
ホントにASCIIてクソだなあ。

351 ：デフォルトの名無しさん：2008/03/13(木) 02:21:38

ASCIIが7bitで治まってくれていて良かった。
ISO 8859-1みたいなんじゃなくて、ASCIIが8bit、
×も≠も欲しいなんて言い出さなくて本当に良かった。
奴等が重ね打ち馬鹿で本当に良かった。

352 ：デフォルトの名無しさん：2008/03/13(木) 19:16:38

すみません、
EUC-JP 系のエンコーディング（含 eucJP-ms, CP5132）においてどういう文字が
割り当てられているかを知りたいのですが、いいウェブページはないでしょうか。

353 ：デフォルトの名無しさん：2008/03/13(木) 20:07:35

>>2

354 ：デフォルトの名無しさん：2008/03/13(木) 20:25:25

そーいや、opengroup の eucjp-ms とユニコードの変換表のページはもう見れないのかな？

355 ：デフォルトの名無しさん：2008/03/13(木) 21:04:03

utf8がascii互換でソースに書いたり、ファイルに書き出すには一番使い勝手はいいと思う。
WinならAPIとの互換性のために、メモリ上はutf16が良い。Shift_JISに変更する気はあんまり起きない。
パーサーなどで、コードポイントを等間隔で扱いたいときにはutf32にしてる。

356 ：デフォルトの名無しさん：2008/03/13(木) 21:27:56

>>353
やはりそこら辺ぐらいですか?

まずは1バイト部分が気になっていたのですが、

>また、16進数で「21」～「7E」の文字にASCIIとJIS X 0201ローマ文字のいずれを使うかは、
>歴史的にはASCIIの方が正しいのですが、実際には使う人の自由にまかされます。

ということは例えば0x5cはreverse solidusでもyen signでも好きな方使え、ということ
なのかな? とほほー。

357 ：デフォルトの名無しさん：2008/03/13(木) 21:41:13

すみません、機種依存文字は、どうして、存在しますか、？
ローマ数字とか、文字化ける、現象の、ことです

358 ：デフォルトの名無しさん：2008/03/13(木) 22:03:50

各ベンダが似て非なる文字コードを使い続けたから。

359 ：デフォルトの名無しさん：2008/03/13(木) 22:22:37

似て非なる文字コードが多くて、判定をミスるからでそ。

360 ：デフォルトの名無しさん：2008/03/13(木) 22:28:35

>>354
numa氏が転載してくれてる
http://blog.livedoor.jp/numa2666/archives/50980727.html

361 ：デフォルトの名無しさん：2008/03/13(木) 22:40:03

>>359
表示できない文字のことを言っている。>>357

362 ：デフォルトの名無しさん：2008/03/13(木) 22:41:16

>>357
お国はどちらで？

363 ：デフォルトの名無しさん：2008/03/13(木) 23:17:28

西村京太郎が書き込んだんだよ。

364 ：デフォルトの名無しさん：2008/03/14(金) 09:14:19

>>352
http://legacy-encoding.sourceforge.jp/wiki/
多分こっちの方がいい。
なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
eucJP-0201 が JIS X 0201 Roman。

365 ：352：2008/03/14(金) 09:55:43

>>364
ありがとうございます。

>なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
>eucJP-0201 が JIS X 0201 Roman。

なるほど。JIS X 0201 Roman はマイナーですね。
なお、今ググったら ICU のサイトもヒットしたので、そっちも参照してみます。
iconv や Perl-Encode なんかはこの辺どうなってるのかな。
しかし EUC-JP 系ってナニゲにタチが悪いですね。下手すると SJIS 系より悪いのではw

366 ：デフォルトの名無しさん：2008/03/14(金) 11:08:59

IANA charset repositoryのは、きっちり決まっているから何も問題ないぞ?

独自改変があるのは、どのコードでも同じだし。
その辺まで全部気にしたいのなら、Windows上でベンダー共同の文字拡張、
firefoxのEUC拡張とか、いろいろありすぎてやってられないと思う。

367 ：デフォルトの名無しさん：2008/03/14(金) 11:59:42

>>365
iconv は glibc iconv と libiconv と森山さんのパッチ済み libiconv と Citrus iconv でも違って、
「EUC-JP」での \x00-\x7F までは ASCII と考えていい、これは IANA で定義されてるから。
ただ、それより多バイトは実装による。

Perl/Encode は Shift_JIS も EUC-JP も \x00-\x7F は ASCII だね。

なお、Shift_JIS は IANA 定義では \x00-\x7F が JISX 0201Roman なことに注意。
これにしたがっている実装はあまりないが、たまにあるので地雷。
ていうか、Shift_JIS でなく Windows-31J/CP932 を使えばトラブルは少ないのでこちらの方が回避は楽。

368 ：352：2008/03/14(金) 13:43:47

>>366 >>367
どうも有益な情報をありがとうございます。

文字コード処理にどのぐらい挙動の幅を持たせるかとかを悩んでいます。
>>365さんも書かれてますが、例えばHTMLでcharset=Shift_JIS or EUC-JPとなっている
が、拡張漢字のコードが入ってた場合（これは結構ある）にどうするかとか。
あと、差のある部分（全角記号等）をどっちだと思って処理するかとか。

369 ：デフォルトの名無しさん：2008/03/14(金) 14:01:57

サーバ側で、かつ、どのクライアントに対してもきっちりやりたいなら、
User-Agent: をみて、独自の拡張、改変にちゃんと対応するしかない。

firefoxのケースはググれば出てくる。
CP51932関連も読んでおいた方がいい。

370 ：デフォルトの名無しさん：2008/03/15(土) 06:16:20

>>365
Shift_JISだって、CP932、Shift_JISX0213、Shift_JIS-2004などの変種がある。
むかし補助漢字を無理やり埋め込む変種もあった。

> Windows上でベンダー共同の文字拡張、

eucJP-ms?

371 ：デフォルトの名無しさん：2008/03/15(土) 09:41:00

> 補助漢字を無理やり埋め込む変種もあった。
kwsk
そういう噂は聞いたことあるけど実際にどんな仕様だったのか調べてもわからない

372 ：デフォルトの名無しさん：2008/03/15(土) 10:19:31

>>370
> Shift_JISX0213、Shift_JIS-2004などの変種がある。
これって名前以外に違いあるんだっけ？

373 ：デフォルトの名無しさん：2008/03/15(土) 10:41:07

Shift_JISX0213は、JIS X 0212:2000に、
Shift_JIS-2004は、JIS X 0212:2004に基づいている。
UCS互換文字が10文字追加されている。

追加だから、表示などの用途に限れば、
Shift_JIS-2004だけで十分だが、
文字集合チェックしたければ区別する必要がある。
(>>352はそういうことをEUC-JPについて知りたいようだったので書いた)

374 ：デフォルトの名無しさん：2008/03/15(土) 10:54:07

そもそもサポートする必要ないよ、とか言ってみる。
増やせば増やすほど混乱の種が増す。
とくに「レガシー」エンコーディングプロジェクトのくせに新しいことをやりたがる奴らは
まとめて氏ね

375 ：デフォルトの名無しさん：2008/03/15(土) 10:58:43

BMP氏ね

376 ：デフォルトの名無しさん：2008/03/15(土) 11:00:35

時代はPNGです(そっちか)

377 ：デフォルトの名無しさん：2008/03/15(土) 11:26:08

>>373
thx

378 ：デフォルトの名無しさん：2008/03/15(土) 13:22:46

>>372
当時のfj.kanjiにいくつかの提案をまとめた記事があったはず。

379 ：デフォルトの名無しさん：2008/03/15(土) 14:11:30

うーんGoogle Groupsには残ってないようだ
当時ニュースグループには参加してなかったからログを探すのが困難だ

380 ：デフォルトの名無しさん：2008/03/15(土) 16:42:56

>>374
>そもそもサポートする必要ないよ、とか言ってみる。

世界中のソフトが足並みを揃えられればいいんだけどね。
現実的にはより「好意的に」データを処理してくれるアプリの方が
ユーザーのウケが良くて、困ったものだ。

それに「レガシー」とはいうものの、メールでもウェブページでもまだバリバリに
使われてるわけだし。

381 ：デフォルトの名無しさん：2008/03/15(土) 16:54:50

なにせここも Shift-JIS だしな

382 ：デフォルトの名無しさん：2008/03/15(土) 18:46:28

>>380
さすがにShift_JIS-2004をサポートした方がユーザーの受けがいいってことはないだろ
むしろ円記号や名簿の高橋さんが文字化けする! とか苦情が増えそうな気がする

383 ：デフォルトの名無しさん：2008/03/15(土) 18:47:21

> 世界中のソフトが
日本中のソフトだけだろ。
最近のソフトやプロトコルは日本人が口出ししない限りUTF-8のみなんて珍しくもないぞ

384 ：デフォルトの名無しさん：2008/03/15(土) 18:53:04

> それに「レガシー」とはいうものの、メールでもウェブページでもまだバリバリに
> 使われてるわけだし。
まだ使われているものをサポートすることは別に反対してない。
現在誰も使ってないどころかかつて使われたことすらないものを
「よかれと思って」付け足そうとする奴は氏ねと言ってる。
ISO-2022-JP-MSとか(頓挫したけど)
NEC選定IBM拡張漢字とIBM拡張漢字にVS付けて区別するとか
正気とは思えない

385 ：デフォルトの名無しさん：2008/03/15(土) 18:53:56

JIS X 0213のせいで日本の悲惨さ倍増w

386 ：352：2008/03/17(月) 04:46:50

皆さんどうも。
Win上だと例えばcharset=EUC-JPだけど実はCP51932なHTMLとかは
あんまり問題にならないのかもしれませんが、非Winだとそうでもなくて、
ちょっと情報を必要としていました。

ウェブブラウザとかメールソフトとかデータベースとか、日本人が開発の
中心にいないものも少なくないんじゃないですかね。そうすると日本語の
エンコーディングに関するバグの説明とか、面倒ですね。

387 ：デフォルトの名無しさん：2008/03/17(月) 05:01:27

糞会社が勝手に文字集合を独自拡張するのがまずいのであって、
受け手が四苦八苦しているのが悪いわけではない。

388 ：デフォルトの名無しさん：2008/03/17(月) 08:01:19

どうでもいいけどWin3より前の時代にアメリカの技術者と話をするときに、
通訳が「漢字」を"chinese characters"と訳すのには閉口させられたなぁ。
現物見せてやっと話が噛み合ったよ。

389 ：デフォルトの名無しさん：2008/03/17(月) 12:18:12

ややこしいが漢字を Chinese characters としている和英辞書があるんだよな。
大昔、千年以上前の日本人にとっては、漢字≒中国語文字かもしれないが
現代の日本人が漢字といえば国字 Japanese characters で漢字体のものを
指すのが普通だな。

通訳は空気を読むべきだと思うが、通訳が頼りない場合は
漢字だと誤訳・誤解されるおそれがあるので日本文字 Japanese characters と
言ったほうがいいかも。

390 ：デフォルトの名無しさん：2008/03/17(月) 12:31:27

普通「漢字」は「ひらがな」「カタカナ」を含まないけど、
文字コードの世界では、含めて「漢字」ということがあるからややこしい。

本来の狭い意味での「漢字」なら、
Japanese Charactersの中のChinese Charactersってことで問題ないはずだけど。

391 ：デフォルトの名無しさん：2008/03/17(月) 12:37:28

最近はKanjiで通じるようになってきたから嬉しい。

392 ：デフォルトの名無しさん：2008/03/17(月) 12:38:11

もうKanjiでおｋ

393 ：デフォルトの名無しさん：2008/03/17(月) 12:44:23

CJK Unified Ideographs のことだろ、Kanji って
ってな、合ってるんだけど間違ってる理解が今後増えそうで嫌だ

394 ：デフォルトの名無しさん：2008/03/17(月) 12:48:45

>>391 >>392
それってひらがな、かたかなは含む?

395 ：388：2008/03/17(月) 12:55:49

あー、そんときは通訳が(理由は忘れたが)席を外したんで、
隙を狙って"Kanji is Japanese special character, not only Chinese."みたいなことを言った希ガス。
当然向こうは"???"となったから、「現物を見せましょう」という流れに持ってった。
# んで、「Windowsじゃそんな文字出せない」みたいなこと言われたんだよなw

396 ：デフォルトの名無しさん：2008/03/17(月) 13:15:36

>>394
391でも392でも無いけど、俺の知っている範囲では「含まない」。

たとえば、日本語学習者とか、日本の漫画やアニメのファンが
"HiraganaやKatakanaは何とかなるけど、Kanjiはホントに難しいyo"
とか、そういう風に口にする。

397 ：デフォルトの名無しさん：2008/03/17(月) 13:52:28

>>394
文字コードのことをちゃんと勉強してる技術者には、
KanjiっていえばHan charactersのうち日本語で使われてる文字だって伝わる。

Unicode万歳って感じだわ。

398 ：デフォルトの名無しさん：2008/03/17(月) 15:17:07

JISの「漢字集合」にはひらがなカタカナも含んだな

399 ：デフォルトの名無しさん：2008/03/17(月) 19:06:02

JIS X 0208の「漢字集合」だとラテン文字やキリル文字まで含むけど、
「漢字」だと漢字だけだよな。

400 ：デフォルトの名無しさん：2008/03/17(月) 23:49:15

JIS X 0208の「非漢字」のうち1文字はUnicodeでは漢字扱いだったな
Unicode 1.0では非漢字領域にもあったけどUnicode 1.1でunifyされたらしい
と安岡センセイか誰かの日記で読んだ

401 ：デフォルトの名無しさん：2008/03/18(火) 00:22:44

更級日記？

402 ：デフォルトの名無しさん：2008/03/18(火) 07:53:24

"仝" だっけ。一部の人にはハートマーク差し替え記号として知られるw
"〆" は文字だっけ？　JIS では記号だけど。

403 ：デフォルトの名無しさん：2008/03/18(火) 08:03:36

>>402
〆は0208由来の非漢字と補助漢字由来の漢字が両方入ってる
EUC-JPとラウンドトリップコンバージョンを確保する必要があるから

404 ：デフォルトの名無しさん：2008/03/18(火) 12:50:52

unicodeで
アファベットかどうかやひらがなかどうかやカタカナかどうかとか
文字種別みたいなものをロジック的に判別する方法ありますか？
それともSJISとかみたいに力任せですか？
あと濁点の「が」と「かﾞ」みたいなのを正規化する方法って決まってませんか？

405 ：デフォルトの名無しさん：2008/03/18(火) 13:11:04

>>404

>文字種
そういうAPIがあるプログラム言語とかライブラリ使え
どれがどの文字種かは >>unicode.org

>正規化
決まってる >>uniocde.org

406 ：デフォルトの名無しさん：2008/03/18(火) 15:00:42

>>405
>正規化
結合文字の正規化目的でNFCを使うとCJK互換漢字でハマるから注意

407 ：デフォルトの名無しさん：2008/03/18(火) 20:19:07

「神」が化けるとかだっけ

408 ：デフォルトの名無しさん：2008/03/18(火) 22:28:39

http://internet.watch.impress.co.jp/www/column/ogata/sp25.htm

409 ：デフォルトの名無しさん：2008/03/19(水) 00:28:49

Unicodeの正規化といえば、MediaWikiが外部から入力された文字列を全部正規化しやがって、
互換漢字を入力できずに困ったことがあったわ。

410 ：デフォルトの名無しさん：2008/03/19(水) 07:34:46

>>407
ファイル名が Unicode ベースなファイルシステムだと何らかの正規化がなされていると
思うけど、同じ場所に「神」という名前のファイルと「神」とのいう名前のファイルを作ろうと
したら、どうなるべきなのかな?

411 ：デフォルトの名無しさん：2008/03/19(水) 07:43:42

>>410
手元のWindowsXP/NTFSだと U+00C4 と A+U0308 を別々に作れた、なので正規化はしてないっぽい。
MacOSXだと作れないだろうね。

412 ：デフォルトの名無しさん：2008/03/19(水) 10:01:39

>>410
> > 何らかの正規化がなされていると思うけど

Mac OS Xくらいしか知らないよ。
Windows, UNIX系ではないんじゃない？

413 ：デフォルトの名無しさん：2008/03/19(水) 10:08:51

>>411
MacOSXでも作れる。
OSXのVFSはNFDに準じたファイル名の正規化を行うが、互換漢字は対象外

414 ：デフォルトの名無しさん：2008/03/19(水) 14:30:19

>>413
VFSじゃないだろ?
CarbonとHFS+でやってんじゃない?

すくなくとも10.3の調査ではそうだった。
だからターミナルからUFSやNFS上にファイルを作成すれば、
ファイル名はNFDされてなかった。

415 ：デフォルトの名無しさん：2008/03/19(水) 17:17:53

>>412
ほんとに? 正規化されてないUnicodeでファイル名を扱うっていうのは
混乱を招くような気がするのだが...

416 ：デフォルトの名無しさん：2008/03/19(水) 18:49:29

データそのものを正規化してしまうような仕組みは嬉しくないなあ。
正規化はソートや検索の時に動的にしてくれたほうが嬉しい。

417 ：デフォルトの名無しさん：2008/03/19(水) 19:02:26

>>416
ヘテロな環境で正規化の方法が違った場合、
USBサムドライブで困るよね。

418 ：デフォルトの名無しさん：2008/03/19(水) 20:53:24

>>414
Technical Q&A QA1173
Text Encoding in VFS
http://developer.apple.com/jp/qa/qa2001/qa1173.html
http://developer.apple.com/qa/qa2001/qa1173.html

419 ：デフォルトの名無しさん：2008/03/19(水) 21:16:22

>>418
この文章だと10.2の頃からそうなっているみたいだけどそれは嘘。
Darwinのソースコード＆テストで調べた。

420 ：デフォルトの名無しさん：2008/03/19(水) 23:00:27

>>415
むしろ下手な正規化(大文字と小文字の同一視とか)をされるより
個々のアプリでの扱いに任せてもらった方が混乱は少ないよ

421 ：デフォルトの名無しさん：2008/03/19(水) 23:19:28

小文字と大文字の同一視は、
Mac, Winでそうだから避けられないのかねえ。
カタカナとひらがなはどうなんだとかきりがないねえ。

422 ：デフォルトの名無しさん：2008/03/20(木) 00:29:04

>>420
そうじゃなくて、NFCとかNFDとか、上に出てたでしょ。

423 ：デフォルトの名無しさん：2008/03/20(木) 00:54:10

>>419
まあ「VFS API」というのが実際に何を意味するかですかね。もしかして UNIX の
ファイルアクセス用の API （システムコール）程度の意味なのかも。
かつ HFS+ のことだけを念頭においているのかも。NFS とかは「例外」扱いだし。

実際 UFS や NFS は正規化はしないですね > Mac OS X

424 ：デフォルトの名無しさん：2008/03/20(木) 01:41:14

>>409
MediaWikiでは正規化されたくない文字は文字参照にするしかないね
それでも項目名には使えない

425 ：デフォルトの名無しさん：2008/03/20(木) 01:43:01

>>421
つ[Collation]
ただし事前処理として正規化が前提になってるのでもし互換漢字のソート順を
統合漢字と変えたかったりしたら使えない

426 ：デフォルトの名無しさん：2008/03/20(木) 07:50:55

>>423
HFS+オンリーで「VFSが」というもの…w

427 ：デフォルトの名無しさん：2008/03/20(木) 23:07:19

OS：WindowsXPproSP2
アプリ：DreamWeaverMX

DreamWeaverMXでhtmlファイルを新規作成したとき、<META>タグは以下の記述でした。
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">

ここではcharsetで文字コードShift_JISを指定していますが、ページをIE6.0以降で見られることを想定した場合に
文字化けをできるだけ減らすためには、charsetの値はどのようにすればいいのでしょうか？

428 ：デフォルトの名無しさん：2008/03/20(木) 23:26:38

そのままでいいよ

429 ：デフォルトの名無しさん：2008/03/20(木) 23:50:02

板違いだからweb制作でも行け

430 ：デフォルトの名無しさん：2008/03/21(金) 12:26:11

>>428-429
了解。ありがとう

431 ：デフォルトの名無しさん：2008/03/23(日) 16:34:58

EUC-JP と宣言しながら CP51932 なウェブページがかなりあるのに
CP51932 相当の IANA 名を定義するような動きはなかったんですかね。
Shift_JIS と Windows-31J の区別はあるんだし。

432 ：デフォルトの名無しさん：2008/03/24(月) 00:50:39

CP51932だってどうしてわかるの

433 ：デフォルトの名無しさん：2008/03/24(月) 08:29:22

>>431
どれぐらい多いの？
日本語で書かれているウェブページのうち、何%がEUC-JPと宣言されてい
て、そのうち何%が実際はCP51932なの？

434 ：デフォルトの名無しさん：2008/03/24(月) 09:39:56

windows-31jって、今からでもwindows-932にならんかね。aliasでもいいんだけど。
他のwindows-コードページの番号ってなってるコードページと一貫性がない。

435 ：デフォルトの名無しさん：2008/03/24(月) 11:06:44

0x81～0x9Fの文字がある=Shift-JIS
0xFD～0xEFの文字がある=EUC
って解釈でいい？

436 ：デフォルトの名無しさん：2008/03/24(月) 14:55:39

まさか

437 ：デフォルトの名無しさん：2008/03/24(月) 19:59:20

そんな楽で良いなら

438 ：デフォルトの名無しさん：2008/03/24(月) 20:04:29

世の中に一体いくつの文字コードがあることか

439 ：デフォルトの名無しさん：2008/03/24(月) 20:06:57

UNICODEの存在意義がなくなる

440 ：デフォルトの名無しさん：2008/03/25(火) 00:08:24

>>434
Microsoftがietf-charsetsに提案してたようだが例によって途中からｇｄｇｄ
http://mail.apps.ietf.org/ietf/charsets/msg01618.html
こんなだからみんな面倒な登録手続きなんか無視して
好き勝手にcharset使い出してカオスになるんだろうな。

そういやISO-2022-JP-2004の登録手続きはどうなりましたか安岡センセイ
http://www.jstage.jst.go.jp/article/johokanri/50/2/67/_pdf/-char/ja/
こんなもの書いてる暇があったらShift_JIS-2004登録してください
規格通りに使いたくても使えないじゃないですか

441 ：デフォルトの名無しさん：2008/03/25(火) 00:09:56

もう全部x-つけといたらいいよ。

442 ：デフォルトの名無しさん：2008/03/25(火) 00:16:39

つーかさー
http://mail.apps.ietf.org/ietf/charsets/msg01783.html
なんでMartin Duerstセンセイともあろうお方が今さらこんなこと言ってるの?
RFC 1192ご覧になったことあります? つーか
> We also wish to thank the following people who contributed in many
> ways towards this document.
> Zhang Zhoucai Martin J. Duerst
見てないはずがないんだけど。

何でcharset-extensionとcharset-editionはみんなに無視されたのに
今度はうまくいくとか無邪気に思い込めるわけ?

443 ：デフォルトの名無しさん：2008/03/25(火) 00:17:15

RFC 1922の間違いorz

444 ：デフォルトの名無しさん：2008/03/25(火) 00:23:06

>>440
いやそのドキュメントは有意義だと思うよ。
ちゃんとまとめて、読めるようにしとかないと、
独自コード乱発は加速するばかりだから。

445 ：デフォルトの名無しさん：2008/03/25(火) 01:19:23

>>431
CP51932 相当の IANA 名をWindows-31Jって言うんじゃね？
テキストエンコーディングが何だろうと、文字集合は同じでしょ。

446 ：デフォルトの名無しさん：2008/03/25(火) 11:35:01

>>445
IANA charsetの「charset」は文字集合+符号化方式のセット

447 ：デフォルトの名無しさん：2008/03/25(火) 11:38:59

>>440
Martinセンセイにドキュメントがないだとか色々突っ込まれて力尽きてたはず。
使いたいなら後をついで進めるといいのかもしれないけど、
必要なドキュメントをJISが握ってる以上難しい気もしないでもない。

448 ：デフォルトの名無しさん：2008/03/25(火) 11:56:26

流れぶった切ってすまん。
日立のEBCDIKコード表探してるんだけど、
http://www.wdic.org/w/WDIC/EBCDIK とか
http://www.pleasuresky.co.jp/ebcdic.php3 とかじゃなくて
日立が提示してるオリジナルがいいんだけど、どっかにないですかね？

449 ：デフォルトの名無しさん：2008/03/25(火) 12:01:21

http://www.pleasuresky.co.jp/images/ebcdic.gif

450 ：デフォルトの名無しさん：2008/03/25(火) 12:04:00

>>449
なにこの汚いコードは

451 ：デフォルトの名無しさん：2008/03/25(火) 12:13:23

文字コードの判別、変換に挫折した…
情けねぇ…

452 ：デフォルトの名無しさん：2008/03/25(火) 18:13:48

EBCDIC くらいは知っとこうぜ

453 ：デフォルトの名無しさん：2008/03/25(火) 21:14:53

>>444
ドキュメントの有意義さは否定しないけど
実際にWebページやメールでそのドキュメントの通りに使えというなら
使えるようにしてくれなきゃ話が始まらない
>>447
俺はUnicodeでいいと思ってるからなー
使いたい人ががんばってくださいとしか
がんばらないで勝手に使うという最悪の選択だけはくれぐれもやめてほしい

454 ：デフォルトの名無しさん：2008/03/25(火) 21:21:11

UpperCharで
小文字 0xED40 纊
が
大文字 0xFA5C 纊
に変換されるのですが、この辺わかりやすく説明しているサイトないでしょうか～

455 ：デフォルトの名無しさん：2008/03/25(火) 21:35:00

>>454
http://support.microsoft.com/kb/170559/ja

456 ：デフォルトの名無しさん：2008/03/25(火) 21:41:47

>>455
非常に勉強になったよ。
ありがとう！

457 ：デフォルトの名無しさん：2008/03/26(水) 02:30:15

>>453
> 実際にWebページやメールでそのドキュメントの通りに使えというなら

言ってないw

458 ：デフォルトの名無しさん：2008/03/26(水) 02:37:51

なるほど
> ケータイの絵文字や、CP932のIBM拡張文字など
はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
直接書いてはいない。でもそれなら何で今インターネットで使えるJIS X 0208:1997
ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
Shift_JIS-2004の絵文字のうち
> 「♪」以外は収録されていなかった
そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?

459 ：デフォルトの名無しさん：2008/03/26(水) 08:47:40

結局世の中の流れとしてはこんな感じ?

1. いわゆるレガシーエンコーディングの、ベンダー毎の拡張みたいのは今後積極的
にはサポートされない。
　-> 新たに IANA に登録されてたりすることはない?
　-> charset にない文字を使っているようなのは化けてもしょうがないって感じ?

2. IBM拡張漢字、絵文字等をどうしても使いたい場合は Unicode で。
　-> Windows-31J は IANA に登録されてるからアリ?

460 ：デフォルトの名無しさん：2008/03/26(水) 09:54:22

Windowsで扱える文字一覧みたいなものはどこかにないでしょうか？

461 ：デフォルトの名無しさん：2008/03/26(水) 12:14:50

コードページ毎で良ければここはどう。
http://www.microsoft.com/globaldev/reference/cphome.mspx

462 ：デフォルトの名無しさん：2008/03/26(水) 13:04:19

>>460
U+0000からU+10FFFFまで扱えるよ

463 ：デフォルトの名無しさん：2008/03/26(水) 13:10:39

>>461
ちゃんと資料があったんですね。ありがとうございます。

464 ：デフォルトの名無しさん：2008/03/26(水) 13:12:18

>>462
すいません、ちゃんとフォントがあって表示できる
またはIMEから入力できるものという意味でした。

465 ：デフォルトの名無しさん：2008/03/26(水) 13:20:32

>>458
>> ケータイの絵文字や、CP932のIBM拡張文字など
>はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
>直接書いてはいない。
IANA charset登録済みのもの。

>でもそれなら何で今インターネットで使えるJIS X 0208:1997
>ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
なんでだろうねぇ。
Windows-31Jとして登録済みの「CP932」の方がマシだと思うんだけど。

>> 「♪」以外は収録されていなかった
>そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?
使っていい、Unicodeに登録されているんで、UTF-8を指定すればよい。
もちろん、JIS X 0213系のエンコーディングはダメ。

466 ：デフォルトの名無しさん：2008/03/27(木) 18:55:27

> Windows-31Jとして登録済みの「CP932」の方がマシだと思うんだけど。
他にも>>440の資料は突っ込みどころ大杉。
> JISにもUnicodeにも違反しており
未使用領域を使用禁止にしているJIS X 0208/0213と違ってUnicodeでPUAを
使うこと自体は何も規格に違反してない。いわば文字化けするのはUnicodeの仕様。
> Windows Vistaの方が、ある意味、正しい動作だと言える。
どっちかが正しい動作だと言うこと自体ミスリーディング。
規格を守っていても「字体化け」するのがJISやUnicodeの「仕様」。

もちろん安岡センセイがそんな初歩的なこと知らないはずがないので
確信犯なんだろうけど(とくに後者)。

467 ：デフォルトの名無しさん：2008/03/27(木) 20:05:38

しかし、文字コード関連は政治的な位置からものを書く人間が多すぎるな

468 ：デフォルトの名無しさん：2008/03/27(木) 20:16:54

文字コードはもともと政治の道具です

469 ：デフォルトの名無しさん：2008/03/27(木) 20:22:49

オタク好きするんだよ。政治というか、勢力争いの話はね。
そういうのが存在する分野の話になると、そこにばっかフォーカスすることになる。

それだけを固めた例としては、ゲーハー板。

470 ：デフォルトの名無しさん：2008/03/28(金) 00:04:05

>467
だったらネタ振ってくれ。例えばNew ASCII配列とか。

471 ：デフォルトの名無しさん：2008/03/28(金) 05:47:01

例まで絞るくらいなら、その話題を自分が振ればいいのに。

472 ：デフォルトの名無しさん：2008/03/29(土) 13:19:21

EBCDICとEBCDIKの違いがあるのも政治的な理由からですか？

473 ：デフォルトの名無しさん：2008/03/29(土) 15:58:10

メリケン野郎にはカナなんかいらんからだろ。

474 ：デフォルトの名無しさん：2008/03/30(日) 02:19:37

ICU のこのページ→ http://demo.icu-project.org/icu-bin/convexp なんだけど、
Aliasってことは「等価な」エンコーディングって扱いなのかな?
もしそうだとすると日本語のエンコーディングに関しては鬱なような...

475 ：デフォルトの名無しさん：2008/03/30(日) 04:31:26

ちょっと横レスですが。

>>472-473
EBCDIKってのは日立方言だよ。
ネットではEBCDIC(カタカナ版)のことだと説明してることが多いけど、
誰かがそう書いたのをよく調べもせずに孫引きで書いている奴が多いだけ。

476 ：デフォルトの名無しさん：2008/03/30(日) 11:19:36

>474
「Converters with conflicting aliases」とか。
ibm-942-P12A-1999とibm-943-p15A-2003が
両方ともaliasにcp932を持ってる事の説明が付かないけど？

477 ：デフォルトの名無しさん：2008/04/04(金) 11:08:02

さて
Unicode 5.1のリリース予定日がやってまいりました

478 ：デフォルトの名無しさん：2008/04/05(土) 21:55:19

無事リリースされますた。
StandardizedVariants.htmlにIVDに関する言及が追加されますた

479 ：デフォルトの名無しさん：2008/04/06(日) 02:55:20

また新しい文字コードが一つ増えただけになるのか、それとも統合されるべく方向に行っているのか。
まったくこのスレのネタすら分からないけど、基本的にutf-8かutf-32?使っておけばよい?
16はなんか面倒とか聞いた覚えがあるが今はそこまで調べる気力なし…。

480 ：デフォルトの名無しさん：2008/04/06(日) 10:49:53

>>479
基本的に UTF-8 使っておけばよし

UTF-32、というか32ビットでの処理はアプリが内部で使う場合の話で
文字コードとして意識する必要はないよ

481 ：デフォルトの名無しさん：2008/04/06(日) 10:58:00

内部処理も行処理程度だとUTF-8のままってのが多いしね。

482 ：デフォルトの名無しさん：2008/04/06(日) 12:53:51

ユニコードで唯一の功績は UTF-8 を発明したこと。
提案したのは部外者だけど。

483 ：デフォルトの名無しさん：2008/04/06(日) 20:02:59

功績か?
utf-8って好き嫌いがはっきりしている気がする。

484 ：デフォルトの名無しさん：2008/04/06(日) 20:07:05

日本語が３～４バイトになるからなあ。
まあ仕方が無いのは分かるが。

485 ：デフォルトの名無しさん：2008/04/06(日) 21:08:59

>>482
Unicodeのエンコード方式の一つとしてはそうなのかもしれんが…
一長一短な気もするけど、今後Unicode対応アプリを作る上ではUTF-8はchar*で扱える
面だけ取れば悪くはないのかも
XMLとかもさ
だけど、結局ファイルやストリームから読み取る分にはUTF-8でいいけど、1～4バイトの
可変長ってのがね
処理内部はUTF-16として扱うのが一番楽だね１文字２バイトと単純計算できるし、
今はサロゲートペアのことを意識する必要が無いから

文字列はそもそもリソース定義すべきだから、ソース中に文字列で埋め込まないんであれば
エンコード方式さえはっきりしてればどうでもいいや
それより、SJISでコメント書いたソースをWindowsエミュレータやリビジョン管理(ClearCaseやCVS、SVN)
で使って、実機やテスト機(Linux)ではEUCだとコンパイル時にコメントが改行されてたりするんだよねｗ
うちんとこでは、Lunuxビルドはmakefileの中でnkfで文字コード変換されてるが…

486 ：デフォルトの名無しさん：2008/04/06(日) 21:19:34

> 今はサロゲートペアのことを意識する必要が無いから
いつかサロゲートペア対応に改良する暇はあるの？
初めからUTF-32にすればいいだろ。

487 ：デフォルトの名無しさん：2008/04/06(日) 21:26:20

ユニコードはエンコード方式がわかっても日本語とは限らないんだな。
CJKでしかないから。

488 ：485：2008/04/06(日) 21:33:50

>>486
Unicode 4.0を見てみたｗ
どう見ても、当面サロゲートペアを使う必要はなさそうだなあｗ
UTF-32でもいいんだけどさ、やっぱ１文字で４バイトってやだなー
特に理由ないんだけどさ
U+10000～を使うことが明らかなら別だけど、使わないしさ

>>487
CJKというか、CJKVのようだけどね
Unicodeは言語を識別するためのものじゃないし、それは別途ISO 639なり使って
管理するとかじゃないの？

489 ：デフォルトの名無しさん：2008/04/06(日) 21:37:48

今の仕様書を1990年に持っていけたらもっとマシなコード体系が出来上がるんだろうなあ…

490 ：485：2008/04/06(日) 21:43:44

>>489
時はバブル、んな将来的なことどうでもいいとか思われそうだがｗ
Y2Kなんて、もっと早急に対応してればあんなに世間が騒ぐこともなかったんだし
結局何も起きなかったけどさｗ

491 ：デフォルトの名無しさん：2008/04/06(日) 21:58:14

世の中の悪い事態の多くは、そうなることが予測不能だったからではなく、
そうなるとわかっているけど対処しなかったから起こったんだ、
とつい最近どっかで読んだけど、まったくだｗ

492 ：デフォルトの名無しさん：2008/04/06(日) 22:12:38

その意味では正に、
「過去に戻れても、やはり同じようになるよ」だな。

493 ：デフォルトの名無しさん：2008/04/06(日) 23:09:49

>>485
>今はサロゲートペアのことを意識する必要が無いから
さすがにもう時間の問題でしょ。
そろそろ JIS X 0213 が要求に入り始めるだろうし。

494 ：デフォルトの名無しさん：2008/04/07(月) 01:51:07

UTF-8は大好きですよ

495 ：485：2008/04/07(月) 08:49:15

>>493
JIS X0213はさすがに困ったちゃんな規格を作ってくれたもんだなぁと思いつつも、いわゆる第三～第四水準に
ようやく人名漢字として略されてたものとかが扱えるとかどうとかで恩恵を受ける人もいるんだろうか？
サロゲートペアを扱うとなると、１文字=2バイトの原則が壊れるんだよなぁ

そういや、2000年だかから中国のGB2312の拡張規格GB18030は、中国大陸における文字表示可能な機器の
全てが対応する必要があるとか訊いて社内で騒ぎになって、Windows2000ではGB18030フォンとパックやら
変なAPIで4バイト文字対応してたとおもうんだけど、こいつはUnicodeとどう親和性を取るつもりなのかな？
規格上はGB18030はISO/IEC 10646を丸ごと飲み込んじゃう規格なんだけど…

496 ：デフォルトの名無しさん：2008/04/07(月) 13:42:22

>>485
>今はサロゲートペアのことを意識する必要が無いから

サロゲートペア以外にも合成文字とかあるんですけど。

497 ：デフォルトの名無しさん：2008/04/07(月) 19:05:39

>>496
MacOS-Xの「ヒ+゜」とかね。
いつ「普通の」データとして飛び込んでくるか分かったもんじゃない。

498 ：デフォルトの名無しさん：2008/04/07(月) 19:12:03

何しろあれが正規形の一つだからな。

499 ：485：2008/04/07(月) 19:41:16

>>496
確かに…
合成文字はヤだなぁ
あと、くっつき方がキモいデーヴァナーガリー文字とかその類も…

500 ：デフォルトの名無しさん：2008/04/07(月) 20:01:44

>>497
Mac持ってないけど「ピ」は合成されてるの？
JISX0213の「か゜」とかじゃなくて？

501 ：デフォルトの名無しさん：2008/04/07(月) 20:26:25

>>500
>>413のNFD

502 ：デフォルトの名無しさん：2008/04/07(月) 20:46:58

>>485
もう現実を見るんだ。
固定バイトの文字コードなんて所詮夢だったんだよ。

503 ：デフォルトの名無しさん：2008/04/07(月) 21:20:35

それでも32bitあればなんとか…

504 ：デフォルトの名無しさん：2008/04/07(月) 21:25:05

HYPHEN-MINUSって文字が誕生した時からこの世はカオスさ

505 ：デフォルトの名無しさん：2008/04/07(月) 22:26:30

UTF-8は0x10入らないようにして欲しいなぁ。

506 ：485：2008/04/08(火) 09:22:27

>>502
そうか、やはりそうなのか…
固定バイトはもはや夢物語なんだなorz
合成文字といえば、ヨーロッパのラテン文字事情なんとかならんのでしょうか？？？
ローカライズにあたって、文字列検索の曖昧検索を行うわけなのだが、Aとキーされようと、
アクセントが付いてようとウムラウトだろうと引っかからないといけないのはまぁいいとして…
A+アクセントとかはやめて欲しいのだがｗ
いったい、ヨーロッパは何言語あるんだYO!

507 ：デフォルトの名無しさん：2008/04/08(火) 09:43:20

L10nされたあいまい検索は、各言語のネイティブの専門家によるアドバイスが
ないとムリポ。
（「エ」と「ヱ」を同一視するかどうかなんて日本人でも判断に困るだろ？）

508 ：485：2008/04/08(火) 11:31:51

>>507
だよねー
今月号の「NEWTON」を読んだら、ラテン語のアルファベットは当初英語で使われるものとほぼ
同じだったとか？
その後に、フランス語やらでアクセント記号が付けられたとかどうとか…
てっきり、逆だと思ってたんだが、Unicode 1.0策定時にCJKの統合に当たってルーツの異なる文字で
似ている物を同一視しようとした件、ラテン語圏でもやはりアクセント記号はそれくらい意味のある文化
の一つなんだろうか…

幸い、自分は合成文字には今のところ携わることはなさそうだが…
中国国家標準のGB 18030をどうにかしてもらいたい…
GB 2312、ASCII、ISO/IEC 10646をうまいこと包含しているという点ではうまいこと考えたなと関心
出来るんだけど、結局は1～4バイトのマルチバイト文字ってワケで、ISO/IEC 10646を包含したとしても
変なジレンマ作ってるだけだし…
そもそも、CJKのグリフが U+3400～U+4DFE、U+4E00～U+9FFEまでしか割り振られてないじゃんか！
BMP面で足りるじゃんかー！

509 ：デフォルトの名無しさん：2008/04/08(火) 13:30:47

>>507
ラテン語ネイティブも、油断してると、
JIS X 0208のFULLWIDTH LATIN (CAPTAL) LETTER *ってのがあるしね。
自前で実装しようとするとHALFWIDTHへの正規化を忘れちゃう。

>>508
表音音文字元祖のフェニキア文字の子孫の
ギリシャ文字でさえ発音記号はないからね。

アクセント記号はcollationの時にも、
取り払ってソートするか付いたままソートするか、
国によって標準的な取り扱いが違って難しい。

510 ：デフォルトの名無しさん：2008/04/08(火) 20:21:30

そのへんはそのうちCollationライブラリが何とかしてくれるから問題ない。

>>GB18030
Unicodeに変換して処理するだけなんだから別に関係ないでしょ

511 ：デフォルトの名無しさん：2008/04/08(火) 20:49:23

他国の心配する前に日本語の処理くらいまともにやってくれ

512 ：485：2008/04/08(火) 21:02:50

>>510
いやいや、GB 18030は現状はUnicodeでグリフのある領域はカバーしてるけど、Unicodeに無い
民族文字やらをどんどん増やす思惑があるらしい…
だったらその思惑をUnicodeコンソーシアムで提起して貰いたいものなんだが…

>>511
俺の文章？orz
どうせローカライズ以前に、各国の文言を用意するのは翻訳チームのすることで、俺は関わってないし

513 ：デフォルトの名無しさん：2008/04/08(火) 21:05:12

自国で独自路線に突っ走りまくってる日本じゃないんだからお前ごときが
他国の心配しなくてもちゃんと国際提案してくるからむしろ日本NBの怠慢ぶりを
何とかしてくれってば

514 ：デフォルトの名無しさん：2008/04/08(火) 21:21:00

そこでJIS第五水準ですよ

515 ：485：2008/04/08(火) 21:46:47

>>513
これは>>513の現場もそうだろうと思うのだが、日本人のSEに限らずPMに至るまで、
日本における標準化についてまともに考えている奴っている？
C++を理解するのにISO/IEC 14882を読んだり、仕様書を書くときに主語をちゃんと
付けることを意識するとかさ？
今俺が書いてる文章なんかは支離滅裂だけどorz

>>514
JIS X0213の二の舞はやめようよｗ

516 ：デフォルトの名無しさん：2008/04/08(火) 22:14:13

＞仕様書を書くときに主語をちゃんと付けることを意識するとかさ？
書かないまでも、意識していないと所謂「とんでも」文書ができあがるわけだが。
# 「マウスボタンが押すとウインドウが表示します」とか。

517 ：デフォルトの名無しさん：2008/04/08(火) 22:40:59

＞５１２
UNICODE的に、新規コードポイントの追加は、
まずは国内規格、次にUNICODEって順番じゃなかったっけ？

518 ：デフォルトの名無しさん：2008/04/08(火) 23:31:00

だから、ウニコードやまりゃいいじゃん

519 ：デフォルトの名無しさん：2008/04/09(水) 00:23:03

はやくExt-C出せー

520 ：デフォルトの名無しさん：2008/04/09(水) 02:59:07

>>515
なんで俺の職場の話がいきなり出てくるのか意味不明だが
日本における標準化の試みは
学者が机上の空論をあーでもないこーでもないと小田原評定のごとくこねくり回した
挙げ句黒船に全部持って行かれるのが通例。
http://www.itscj.ipsj.or.jp/domestic/mojicode/index.html
の異体字アーキテクチャの検討なんて絵に描いたようだ

521 ：デフォルトの名無しさん：2008/04/09(水) 08:47:51

んー、
動画フォーマットとかはそうでもない気がするけど？

522 ：デフォルトの名無しさん：2008/04/09(水) 09:00:50

mbcs/wcs
ISLISP
IPv6, Mobile IP

この辺は日本の団体が組織的に関わってるよ。

523 ：デフォルトの名無しさん：2008/04/09(水) 09:29:05

個人名で論文や案を提出してレビューする形にしないと、
>>520が多い状況はなかなか改善できないと思う。
本来、案もレビューも書かない奴の意見なんて聞く必要ないんだ。

524 ：デフォルトの名無しさん：2008/04/09(水) 13:14:54

意味のあることを何も言えない奴って、無視されると
意味のあることを言った奴より怒るんだよね。

525 ：デフォルトの名無しさん：2008/04/09(水) 23:39:09

>>523-524
* Ideographic Variation Databaseという対案が明確に示されてる
* 日本は>>520を国際提案していない
話にもならんね

526 ：デフォルトの名無しさん：2008/04/11(金) 14:34:46

>>501
Mac OS XのHFS+は、
さらにアルファベットの大文字小文字の同一視もやってるよな。

ファイル名としては大文字小文字が保存されているけど、
比較ではcase ignoreだからFooがあればfooでopenする。
FULLWIDTHなアルファベットも同じ。

ただしFULLWIDTHとHALFWIDTHな文字は同一視しない。
WIDTH範疇が同じ場合に限り大文字小文字を区別。

527 ：デフォルトの名無しさん：2008/04/11(金) 15:11:34

＞WIDTH範疇が同じ場合に限り大文字小文字を区別。
×区別
○同一視

こうですか?

528 ：デフォルトの名無しさん：2008/04/11(金) 18:52:47

>>510
>そのへんはそのうちCollationライブラリが何とかしてくれるから問題ない。

そういえば Unicode で日本語の文字列をソートした場合、普通はどんな並び順に
なるんでしょうか/なるべきなんでしょうか。Collation のライブラリ毎に違うんでしょうか。
unicode.org の TR10 とか見てみましたがよくわかりませんでした。

529 ：デフォルトの名無しさん：2008/04/11(金) 20:02:25

>>526
Case SensitiveなHFS+もあるよ。
同一視する文字や使えない文字はファイルシステム毎に異なるから
あるファイル名が使えるかは単純には判断出来ない。

530 ：デフォルトの名無しさん：2008/04/12(土) 03:00:11

>>529
既にインストーラでは選べないんじゃない?
昔使ってたが、馬鹿アプリで問題発生したので使わなくなった。
アプリ内のファイルがCapitalizedなのに、
アプリが全部大文字でアクセスしてたw

531 ：デフォルトの名無しさん：2008/04/17(木) 22:38:32

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3425.pdf
トンパ文字の提案キター

532 ：デフォルトの名無しさん：2008/04/18(金) 06:22:15

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3409.pdf
ARIB互換漢字についてアメリカとイギリスからIVSを使えよボケと突っ込まれてるｗ

533 ：デフォルトの名無しさん：2008/04/18(金) 21:35:34

これからIVSを積極的に導入してくなら、現在異体字なのに別のコードポイントを
与えられている文字はIVSに吸収してくるとスッキリするんだけど。
今までのしがらみで無理かな。

534 ：デフォルトの名無しさん：2008/04/18(金) 21:48:21

標準に入らなくても、基準とデータは有意義に使われると思うよ。

535 ：デフォルトの名無しさん：2008/04/18(金) 22:25:21

原規格分離規則があるから、全部統一は無理

536 ：デフォルトの名無しさん：2008/04/19(土) 00:09:08

原規格分離規則ってCJK Unified Ideographs領域のみ適用で、
それ以降に定義された領域では使わないっていうアレか。

537 ：デフォルトの名無しさん：2008/04/19(土) 03:41:26

>>533
既存の互換漢字を削除はあり得ないけど、これから追加しようとしたら突っ込まれて当然だろう

538 ：デフォルトの名無しさん：2008/04/20(日) 11:42:06

Uniocde 5.1の文字一覧マダー(aary
ttp://www.unicode.org/Public/5.1.0/charts/
予告期限は過ぎてるんだけど

あともう5.2.0のディレクトリあって吹いたｗ

539 ：デフォルトの名無しさん：2008/04/26(土) 22:57:20

TIP http://www.unicode.org/roadmaps/tip/ 甲骨文字

540 ：デフォルトの名無しさん：2008/04/26(土) 23:04:50

文字コードとグリフを同じに扱おうとしたつけだ
いいじゃねぇの？

541 ：デフォルトの名無しさん：2008/04/27(日) 11:10:56

>>538
来てる

542 ：デフォルトの名無しさん：2008/04/27(日) 20:49:59

ところでT書体はまだですか

543 ：デフォルトの名無しさん：2008/04/28(月) 03:56:41

>>542
http://www.sakamura-lab.org/FONT/
4月中の公開は無理そう
つーか以前は「2006年春」って言っててそれもブッチしてなかったっけ

544 ：デフォルトの名無しさん：2008/04/28(月) 13:30:01

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3475.pdf
結局ARIB互換漢字の追加は受理されたようだ

545 ：デフォルトの名無しさん：2008/04/28(月) 14:19:01

ARIBの仕様書が公開されてた
http://www.arib.or.jp/english/html/overview/doc/2-STD-B24v5_1-1p3.pdf
JIS X 0213の指示には私用終端バイトを使って
JIS X 0208の独自拡張をESC 2/4 4/2で指示するという変態仕様
逆だろ…

546 ：デフォルトの名無しさん：2008/04/29(火) 08:16:41

まったくの初心者です。
↓のコードは何でしょうか？
17163542

何て書いてあるのか、教えてください
よろしく

547 ：デフォルトの名無しさん：2008/04/29(火) 08:20:26

板違い。こちらへどうぞ
http://love6.2ch.net/mystery/

548 ：デフォルトの名無しさん：2008/04/29(火) 08:23:07

>>547
すみません。
文字コードじゃないんですか？

549 ：デフォルトの名無しさん：2008/04/29(火) 09:10:30

こちらへどうぞ。
ttp://google.com/

550 ：デフォルトの名無しさん：2008/05/01(木) 06:43:38

>>543
やっぱり無理ですた

551 ：デフォルトの名無しさん：2008/05/17(土) 07:02:50

とあるアプリの文字エンコーディングの挙動が変だなと思ったので
問い合わせたら、「Win上のIEの挙動と同じにしている」とのこと。

具体的にはEUC-JPで0x5cが円記号で表示されるのですが。
これってreverse solidusが正解じゃなかったでしたっけ?
確かWinだとここら辺、フォントレベルでおかしなことをしてるんでしたっけ?

しかし正直なところもはやWinやIEの挙動を無視することもできず... トホホ。

552 ：デフォルトの名無しさん：2008/05/17(土) 08:02:14

>>551
「円記号で表示される」だけだと、
エンコーディングレベルで何かやってるのか、
単にフォントがU+005Cを円記号で表示してるだけなのかわからんな。

後者ならフォント変えれば REVERSE SOLIDUS に見えるでしょ。

553 ：デフォルトの名無しさん：2008/05/17(土) 08:23:48

IEと同じというなら後者だな。
Tahomaとかの欧文フォントならバックスラッシュ、
フォントリンクでかな漢字も表示出来ていい感じ。

554 ：デフォルトの名無しさん：2008/05/17(土) 09:44:03

501ですが、
アプリはMac OS Xのエディタです。なんでWin上での技術的背景ではなく
ユーザーエクスペリエンスを問題にしている、とでもいいますか。
IEを「普通に」使ってる分にはEUC-JPの0x5cは円に見える訳ですよね。
あえて欧文フォントを割り当ててバックスラッシュを表示できてもそれはある意味
「化けている」のではないでしょうか。
あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。

でもIE、確かASCIIやUTF-8だとデフォで0x5cはバックスラッシュ... ややこしいなあ。

555 ：デフォルトの名無しさん：2008/05/17(土) 11:48:24

なんでエディタの名前を書かないんだろう
人の話を聞く気がないならチラシの裏にでも書き捨てろ

556 ：デフォルトの名無しさん：2008/05/17(土) 12:15:02

>>554
実際にIE使ってみればわかるだろクズ

557 ：デフォルトの名無しさん：2008/05/17(土) 12:24:31

>>554
文字コードと文字フォントは別物だよ。
だから、
> あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
> どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。
でOK。EUC-JPに限らずな。

558 ：デフォルトの名無しさん：2008/05/17(土) 15:10:46

>>551
0x5cというかU+005Cは、ASCIIやJIS X 0213だとUniccode基準で「REVERSE SOLIDUS」でなければおかしいけど、
一般的な日本語エンコードだとJIS X 0201基準だから「YEN SIGN」が正しい。

WindowsのOS標準和文フォントだと、0x5cというかU+005Cは「YEN SIGN」で実装。
Mac OS XのOS標準和文フォントだと、0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。

Windows版のSafariでも、Shift_JIS/EUC-JP/ISO-2022-JPといった日本語エンコードなHTMLでは
和文フォントでも欧文フォントでも0x5cというかU+005CがU+00A5実装Glyph(YEN SIGN)でエイリアス表示され、
それ以外(UTF-8とか)だとフォントのU+005C実装Glyphでダイレクトに表示される。

Mozilla系ブラウザソフトでも「about:config」で、
“layout.enable_japanese_specific_transform　　default　　boolean　　false”を
“layout.enable_japanese_specific_transform　　user set　　boolean　　true”と設定変更すると、Safariと同じ挙動になる。

559 ：558：2008/05/17(土) 15:18:28

>>554
Mac OS Xのエディタでも、設定で0x5cというかU+005CをフォントのU+005Cでダイレクトに表示するか
U+00A5実装Glyph(YEN SIGN)でエイリアス表示かで選択できるものがある。
ttp://pc.watch.impress.co.jp/docs/2006/0907/macos03.htm
ttp://pc.watch.impress.co.jp/docs/2006/0907/macos03_03.jpg

Windowsの方が日本のローカル規格的には親和な設計ではあるけど国際基準的にはいろいろ問題がある。
Mac OS Xだと国際基準的には親和な設計ではあるけど日本のローカル規格的にはいろいろ問題がある。
だから、Mac OS XやマルチプラットフォームなアプリだとOSやアプリレベルでWindowsとは違う日本ローカル規格対処策をしているものがある。

560 ：デフォルトの名無しさん：2008/05/18(日) 15:24:37

>>558
> Mac OS XのOS標準和文フォントだと、
> 0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。

Mac OS Xだと、
内部SJISアプリの0x5CはYEN SIGN（CMapは83pvまたは90pv）、
内部UnicodeアプリのU+005Cは（標準では）REVERSE SOLIDUS（CMapはUniJIS）。

561 ：デフォルトの名無しさん：2008/05/18(日) 22:56:43

>>559
親和うんぬんの段落はちょっと短絡だろ。

もともとREVERSE SOLIDUSが要求されるところで、(例えば\n)
YEN SIGNを使ったり、YEN SIGNを表示に使ったりしていた過去があるんだから、
そんな単純に割り切れないよ。

562 ：デフォルトの名無しさん：2008/05/18(日) 23:23:33

ESC(BとESC(Jですら同じ扱いだからねぇ。UTF-8はそれこそ・・・

563 ：デフォルトの名無しさん：2008/05/19(月) 20:40:22

Vistaで実装されたとかいうJISX213で使われてるSJIS2004、Unicode3.2、EUC2004ってどうなってんのわかりません

Unicodeで実装されてる第三、第四水準漢字ってSJISにちゃんとマッピングされてんですかね。
なんか規則性なく適当に散りばめてるだけな気がするんで
一文字一文字マッピングされてる場所指定する等で対応しないと対応出来ないのかな？

JISX213レベルでのUnicode-SJIS-EUC全部の対応表があれば嬉しいんですが、そんなのって無いですかね

564 ：デフォルトの名無しさん：2008/05/19(月) 20:48:10

VistaのはJIS X 0213にある文字がUnicodeベースで使えるというだけで、
JIS2004自体に対応しているわけじゃなかったような。

565 ：デフォルトの名無しさん：2008/05/19(月) 21:39:56

>>563-564
Vistaの公式ページで資料もフォントも配布されているというのに、
「されたとかいう」
「どうなってんのわかりません」
「そんなのって無いですかね」
「じゃなかったような」
とかいうヤツってナンなの？ゆとり？
ttp://www.microsoft.com/japan/windows/products/windowsvista/jp_font/
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=f7d758d2-46ff-4c55-92f2-69ae834ac928&DisplayLang=ja

566 ：デフォルトの名無しさん：2008/05/19(月) 21:50:06

エンコーディングの話してるのに、フォントの資料を持ってきて
何いってんだか

567 ：デフォルトの名無しさん：2008/05/19(月) 22:04:09

>>566
これだからゆとりは困る。
これがエンコーディングの資料ではないとでも？

・Windows Vista ならびに Windows Server 2008 における JIS2004 対応に関する詳細資料
ホワイトペーパー「Microsoft Windows Vista および Windows Server 2008 における JIS X 0213:2004 (JIS2004) 対応について」(Version 1.2) は、こちら(XPS 形式、PDF 形式) をご参照ください。

・JIS X 0213:2004 / Unicode 実装ガイド
この実装ガイドでは、JIS 文字コードが Unicode 対応の JIS X 0213:2004 へ変更されたことに伴いアプリケーションへ与える影響および対応策などについて説明します。(XPS 形式 1.88 MB、PDF 形式 1.34 MB)

568 ：デフォルトの名無しさん：2008/05/19(月) 22:08:01

ゆとりゆとり言う奴に限って自分では質問に答えられない。

569 ：デフォルトの名無しさん：2008/05/19(月) 22:59:39

>>563
Vistaの実装ではShift_JIS-2004やEUC-JIS-2004には対応していません。
JIS X 0213はUnicodeのレパートリとして実装されています。
必要なら自分で変換してください。

570 ：デフォルトの名無しさん：2008/05/20(火) 21:20:03

>>569
オレオレ変換はやめてくれ
Shift_JISにはマッピングされていないから無理だと思っていただいた方が将来の人が助かる

571 ：デフォルトの名無しさん：2008/05/20(火) 21:43:15

自ら学び自ら考える力を身に付けるための教育(笑)

572 ：デフォルトの名無しさん：2008/05/20(火) 22:52:15

CP932なんて使ってないしShift_JIS-2004のためにも消えてくれ。

573 ：デフォルトの名無しさん：2008/05/20(火) 22:58:09

>>572
お前が使っていなくても、世間が使っている。
ほんと、DOS/Windowsの呪縛の1つだな。

574 ：デフォルトの名無しさん：2008/05/20(火) 23:15:09

2chはCP932だとおもっていたが如何

575 ：デフォルトの名無しさん：2008/05/20(火) 23:15:15

>>572
青空ｳﾝｺ工作員乙

576 ：デフォルトの名無しさん：2008/05/25(日) 00:59:45

http://www.unicode.org/roadmaps/tip/
いつの間にかUnicodeの3面をTertiary Ideographic Plane(第三漢字面)とすることが決まってた。
現時点では1字も定義されてないが古代漢字や甲骨文字を収録するみたいだ。

577 ：デフォルトの名無しさん：2008/05/25(日) 01:08:50

>>576
これは便利だ

578 ：デフォルトの名無しさん：2008/05/25(日) 16:02:10

>>539で既出

579 ：デフォルトの名無しさん：2008/05/30(金) 01:20:21

Unicodeって、色々バージョンがあるみたいだが。
非Unicodeな文字コードとのマッピングが変わることってある？
基本的には予約領域に新しい文字が追加されていくj形という認識で合ってるのかな？

580 ：デフォルトの名無しさん：2008/05/30(金) 06:35:56

各ベンダーのマッピングは文字が追加されなくてもそれぞれ違う。
そもそも一対一対応ですらない。
例えば、http://support.microsoft.com/kb/170559

581 ：デフォルトの名無しさん：2008/05/30(金) 20:36:13

IRGの追っかけやってれば知ってるだろうけどCNS11643とのマッピングはしょっちゅう変わってる

582 ：デフォルトの名無しさん：2008/05/31(土) 12:20:35

資金があればいい加減に文字コードを統一したいよな。
文字コード多すぎるだろう。
10年前のシステムならばしかたがないにしても、
現代のハードウェアやソフトウェアの質を考えたら、
行動を起こしてもいいと思うんだがなあ。
ビルちゃん、気まぐれで動かないかなあ。

583 ：デフォルトの名無しさん：2008/05/31(土) 13:16:57

資金とかの問題じゃないような。

584 ：デフォルトの名無しさん：2008/05/31(土) 13:36:15

現在の世の中に存在するコンピュータでも全てがMBやGB単位のメモリを積んでる訳じゃないんだ。

585 ：デフォルトの名無しさん：2008/05/31(土) 14:17:36

すみません、質問させてください。
ワードで文書を作成する際に文字コードを指定されました（JIS-X0208-1982）.
しかしこの意味が全くわかりません。

普通にワードの画面を開いて文書作成しただけではこのコードにならないということでしょうか？
ググってみると、記号について何年かごとに改正されてきたコードらしいのですが
１９８３はあっても１９８２がみつかりません。また、これをワードでの文書作成時に
どう使うのかが理解できません。

ワードでの文書作成時に「挿入」から記号を挿入する際に何か特殊なことをする必要が
あるのでしょうか？その場合、どうすればいいのでしょうか？
画面下にドロップダウンがあってunicode とかJISとか選べるみたいだったのでやったのですが、
この０２０８というが見つからないし、途方にくれています。
ズブの素人なので、わかりやすく説明していただけると助かります。おねがいします。

586 ：デフォルトの名無しさん：2008/05/31(土) 15:58:22

> ビルちゃん、気まぐれで動かないかなあ。

ビルちゃんはちゃんと動いているだろ。

気まぐれなのは相変わらずだが。(w

587 ：デフォルトの名無しさん：2008/05/31(土) 16:02:21

そのビルちゃんって、いま何兆円ぐらい持ってるの？
7ぐらい？

588 ：デフォルトの名無しさん：2008/05/31(土) 17:53:33

文字コードじゃなくて、文字集合を指定されただけじゃねーの。

589 ：デフォルトの名無しさん：2008/05/31(土) 22:17:23

>>582
> ビルちゃん、気まぐれで動かないかなあ。

一番動かないで欲しい人ですが？

590 ：デフォルトの名無しさん：2008/06/01(日) 00:32:59

>>585
超初心者向け質問スレがちゃんとあるというのに、こんな超廃人スレに来てるＫＹなヤツってナンなの？ゆとり？

【ﾏｼﾞﾚｽ】超初心者の質問に答えるスレ93【ｴｽﾊﾟｰ】
ttp://pc11.2ch.net/test/read.cgi/win/1212070324/

591 ：デフォルトの名無しさん：2008/06/01(日) 00:49:35

プログラム技術＠2ch掲示板
ttp://pc11.2ch.net/tech/

この板はプログラムを作る人のための板です。

プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。

592 ：デフォルトの名無しさん：2008/06/01(日) 02:36:02

JIS-X0208-1982はJIS X 0208:1983の間違いだろう。
いわゆる機種依存文字だけ気にしていればいいんじゃね？

>588さん
俺の予想では、文字集合を指定されたんじゃなくて、
WordがシフトJISで保存すると勘違いした奴が、1978から1983改訂の際の
文字の入れ替えについて改訂後のことだと言いたかったに一票。

593 ：デフォルトの名無しさん：2008/06/01(日) 03:13:41

>>592
ありがとうございます！
私もこんなこと言われたの初めてで、びっくりした上、１９８２なんか
ないのに驚いたんですが、１９８３のことですかとは聞けなくて・・・。
本当にありがとうございました。

594 ：デフォルトの名無しさん：2008/06/01(日) 03:30:43

>>593
「聞けなくて」じゃなくて聞けよ。プログラマーだろ？
想像でなく正確な仕様と要件にもとづいて仕事してくれ。

たとえば
http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+0208%3A1997&dantaiCd=JIS&status=1&pageNo=0
ではX 0208の履歴に1983はありませんが、って言えばいい。

595 ：デフォルトの名無しさん：2008/06/01(日) 03:34:42

間違えた。
誤：　1983はありませんが
正：　1982はありませんが

つーか寝ようよ。そーゆートコだけプログラマーなのな。

596 ：デフォルトの名無しさん：2008/06/01(日) 11:34:51

>>594
すいません、私、プログラマーとかじゃないんですよ^^;
パソコンについては、平均的な知識しかない書類作成係でして・・・・
この指示も書類作成にあたって渡されたんです。

１９８３の件を聞けないのは、この指示を出した技術者が、なんというか、
瞬間湯沸かし器なので、彼のプライドを傷つけるようなことをいったら（
１９８３のことですか？といっただけでも）、大変なことになるので・・・

597 ：デフォルトの名無しさん：2008/06/01(日) 11:42:56

>>596
>>591をもう一度読んで

598 ：デフォルトの名無しさん：2008/06/01(日) 12:22:46

あ、ごめんね、ここの人達は専門の人達だろうから
初心者板にいる人達よりもレベルが高いと思ってきたんだ。
初心者板は起動に関してのトラブルとかばっかりだったし・・

でも、回答くれた方、ありがとう。本当に助かりました。

599 ：デフォルトの名無しさん：2008/06/01(日) 12:30:00

ところで、システム開発の際に>>585みたいに1983版を指定された場合、
どこで規格を入手すればいいんですかね。教えてエロい人

600 ：デフォルトの名無しさん：2008/06/01(日) 13:06:40

ところで、システム開発の際にVisualStudio2008を指定された場合、
どこでそれを入手すればいいんですかね。

601 ：デフォルトの名無しさん：2008/06/01(日) 13:41:51

ところで、システム開発の際にwin98を指定された場合、
どこでそれを入手すればいいんですかね。

602 ：デフォルトの名無しさん：2008/06/01(日) 15:15:12

JISも売り物なんだから買え

603 ：デフォルトの名無しさん：2008/06/01(日) 15:56:38

まぁ、JIS2004の文字を使うなって意味だったんだろうな

604 ：デフォルトの名無しさん：2008/06/01(日) 17:16:39

こっちでいくら専門家いても指示した当人と話す以上にわかるわけないだろうに。
それでもし間違ってたらどうすんだ。

605 ：デフォルトの名無しさん：2008/06/01(日) 22:00:59

>>594
プログラマとしてのプライドを持った奴なら、自分で「ズブの素人」なんて言うわけわけねーだろ、常識で考えて。
しかも全角数字使ってる時点で585を超初心者だと見抜けない594ってってナンなの？ゆとり？

>>598
「あ、ごめんね」じゃねーだろ。
２ちゃんねるのルールが守れないなら、２ちゃんねるに来るな。

>>600-601
それは文字コードの話じゃねーだろ。

606 ：デフォルトの名無しさん：2008/06/01(日) 23:04:25

何このスレ

607 ：デフォルトの名無しさん：2008/06/01(日) 23:05:07

サザエさんの家ににしこりが入るところに見えませんか?

608 ：デフォルトの名無しさん：2008/06/02(月) 03:32:03

>>602
過去の版の入手方法がわかんないってことでしょ。
http://www.jisc.go.jp/jis-act/reading.html
ぱっと見たけど見つからなかった。電話番号書いてあるから訊くのが早そうだな。

>>605
>>594だが何でそこまで言われにゃならんかね。
多くのプログラマーが全角英数字を毛嫌いするのは知ってるが、個人的にはありだと思うが。
少なくとも官庁相手に出す文書は全角にしてる。「Ｊａｖａ」とか「議事録４月１０日」とか。
上のリンク先でも「ＪＩＳ　Ｘ　０２０１」とか「７ビット及び８ビットの２バイト情報」
って書いてるだろ。

ついでにプログラ「マー」って書いたら俺も超初心者扱いか。

609 ：デフォルトの名無しさん：2008/06/02(月) 04:45:04

ならJISの規格票でいわゆる全角英数がどういう扱い受けてるのかくらい知ってるだろ

610 ：デフォルトの名無しさん：2008/06/02(月) 04:49:40

半角だとFAXのとき潰れてしまうます

611 ：デフォルトの名無しさん：2008/06/02(月) 06:07:08

608は「全角数字使用の585を超初心者だと見抜けないためにゆとりといわれた」ことに不満を主張しているようだが、それとJISでの全角数字のあつかいとは関係なくね?
これだけ使われてるんだし。でも585が（・∀・）ｶｴﾚ!なのは同意

612 ：デフォルトの名無しさん：2008/06/02(月) 09:35:02

このスレに居てmohtaを知らんとは言わせん

613 ：デフォルトの名無しさん：2008/06/02(月) 15:47:06

誰だっけ？昔うさげにいた人？

614 ：デフォルトの名無しさん：2008/06/02(月) 18:35:11

「うさげ」も何年かぶりに聞いた単語だな

615 ：デフォルトの名無しさん：2008/06/02(月) 18:49:35

ということにしたいのですね。

616 ：デフォルトの名無しさん：2008/06/03(火) 00:02:01

>>608
ならUnicode StandardでいわゆるEAST ASIAN WIDTHがどういう扱いを受けてるのかくらい知ってるだろ？
それなのにこの場に及んでNORMALIZATIONされていない文字をまだ「ありだと思う」と言い張るその姿勢は実に見苦しい。

>>610
半角は潰れるが全角なら潰れないだと？
そんな文字サイズなら漢字は潰れまくりじゃねーか。

>>611
全角数字の扱いだけではない。
厚顔無恥で教えて君オーラ全開な文章から585の人間性を推し量れない608の稚拙さに問題がある。

>>612
知らん。
ゆとりの俺にも教えてくれ。

617 ：デフォルトの名無しさん：2008/06/03(火) 00:12:58

>>616
今はアラビア数字の世の中なので。

618 ：デフォルトの名無しさん：2008/06/03(火) 00:24:02

EAST ASIAN WIDTHやNORMALIZATIONが何なのか理解できない617ってナンなの？ゆとり？
ttp://www.unicode.org/reports/tr11/
ttp://www.unicode.org/reports/tr15/

619 ：デフォルトの名無しさん：2008/06/03(火) 00:37:45

ＪＩＳ　Ｘ　２０８：１９８３の話にＵＮＩＣＯＤＥもちだしてくんなよ。

620 ：デフォルトの名無しさん：2008/06/03(火) 00:47:49

>>619
今はユニコードの世の中なので。

621 ：デフォルトの名無しさん：2008/06/03(火) 01:38:20

ナンなの？ゆとり？

622 ：デフォルトの名無しさん：2008/06/03(火) 02:32:46

カレーはライスに限る

623 ：デフォルトの名無しさん：2008/06/03(火) 02:52:09

こないだのザ！鉄腕！DASH！！で新しいDASH村住人のバングラディッシュ人がカレー作ってたんだよ。
ナンみたいなヤツも作ってたんだけど確か違う名前だったような？あれってナンな（ｒｙ
ttp://www.ntv.co.jp/dash/village/05_ryou/2008/05/

624 ：デフォルトの名無しさん：2008/06/03(火) 02:59:42

全角英数字がJIS X 0208では「原則として使用しない」で、Unicode規格でも
Restrictなのはわかるが、JISとUnicode規格読んでないとゆとりなんて、
このスレ、ハードル高すぎだっての。

とりあえず次スレは
【ナンなの？】文字コード総合スレｐａｒｔ４【←ゆとり？】
でおねがいします。

625 ：デフォルトの名無しさん：2008/06/03(火) 03:09:12

>>622
カレーと云えばナン。カレーにライスは邪道。
ttp://food8.2ch.net/test/read.cgi/curry/1103503719/

>>624
空気嫁

626 ：デフォルトの名無しさん：2008/06/03(火) 10:48:10

> >>612
> 知らん。
> ゆとりの俺にも教えてくれ。

ttp://www.imasy.or.jp/~yotti/rfc1554jp.txt
これを書いた人

627 ：デフォルトの名無しさん：2008/06/03(火) 10:55:11

>>626
JP-2って名前は良くなかったな。

628 ：デフォルトの名無しさん：2008/06/03(火) 21:53:57

>>626
「mohta うさげ」でググってみたんだが、ゆとりの俺に状況が理解できん。

その昔、うさげというコミュニティが存在していて、そこにはmohtaと呼ばれる伝説の荒らしが常駐してた。
その荒らしがISO-2022-JP-2の規格の根本をまとめ上げたものの、荒らしが作った規格には反発が強く世間には定着しなかった・・・、ってことでおｋ？

それより何でこの話がㇳ突然出てきたんだ？
ISO-2022-JP-2と全角英数字と何の関係あるんだよ？
全然わかんね。

てか、ググったら木村浩一さんのサイトにこのスレがコピペされてるのを発見ｗ
ttp://www.kt.rim.or.jp/%7ekbk/zakkicho/08/zakkicho0806a.html#D20080602

629 ：デフォルトの名無しさん：2008/06/03(火) 22:51:53

>>625
カレーと云えば飲み物。噛んで食べるヤツは邪道｡･ﾟ･(ﾉД`)･ﾟ･｡ｳｴｴｪｪﾝ
ttp://news24.2ch.net/test/read.cgi/mnewsplus/1212452680/

630 ：デフォルトの名無しさん：2008/06/03(火) 23:03:40

ああ、あれね、函数の引数をひとつにするやつ。

631 ：デフォルトの名無しさん：2008/06/03(火) 23:13:51

世界で最も完成されたカレー、それは・・・
ttp://wiredvision.jp/news/200805/2008050121.html

>>629
これだな
ttp://mamono.2ch.net/test/read.cgi/newsplus/1212380001/

632 ：デフォルトの名無しさん：2008/06/04(水) 10:14:43

カレー食いたくなった

633 ：デフォルトの名無しさん：2008/06/04(水) 10:34:23

>>628
voidとか、lalaとか、現代版はotsuneとか、ちょっと前に言われた「モヒカン」タイプの
元祖のような奴がmohta。暴れるという形容は適用されるけど、荒らしとは違う。
mohtaの特異な点として、JIS X 0208に統一して文章を書くという性質が挙げられる。
（>>626のRFC翻訳でもそれをやっている）
Unicode化の流れに対抗したけど、というあたりは多勢に無勢というか。

634 ：デフォルトの名無しさん：2008/06/04(水) 10:36:12

ひとつ書き忘れた
うさげ == fj.net.usage

635 ：デフォルトの名無しさん：2008/06/04(水) 10:38:43

野暮な奴だなお前

636 ：デフォルトの名無しさん：2008/06/04(水) 13:56:27

>>635
fj の「3馬鹿」も mohta、 lala は聞かなくなったな…
void は所を mixi に移してあいかわあらず暴れてるらしいが…

637 ：デフォルトの名無しさん：2008/06/04(水) 16:47:29

> mohtaの特異な点として、JIS X 0208に統一して文章を書く
ホントだワロタ
原文: http://www.ietf.org/rfc/rfc1554.txt
mhota訳: http://www.imasy.or.jp/~yotti/rfc1554jp.txt

一部メールアドレスまで全角だw

638 ：デフォルトの名無しさん：2008/06/04(水) 19:30:43

ゆとり一歩手前の俺ですがvoidだけは見たことがある。他はｼﾗﾈ

639 ：デフォルトの名無しさん：2008/06/05(木) 00:10:29

>>633-634
ありがとう。
なんとなくわかったかも知れん。
「Unicode化の流れに対抗したけど、というあたりは多勢に無勢」とかは、青空文庫工作員と同じ構図なんだな。
つまり、全角英数字を使うヤツは「超初心者」か「極右(笑)」ってことか。

> ちょっと前に言われた「モヒカン」タイプ
知らん。
ゆとりの俺にも教えてく（ｒｙ

バブル世代にとっての「ちょっと前」は、ゆとり世代にとっては「大昔」なんだが・・・。

>>638
ゆとりの俺ですがvoidという名前だけは噂に聞いたことがあるｗ

640 ：デフォルトの名無しさん：2008/06/05(木) 00:32:52

そんなこと知っても何のプラスにもならないから
もう深追いしないほうがいいよ。

641 ：デフォルトの名無しさん：2008/06/05(木) 00:34:51

ここが「“２”ちゃんねる」なのは、このスレ的にどうなの？
「?」もこのスレでは全角の方が多いようだけど

642 ：デフォルトの名無しさん：2008/06/05(木) 01:16:29

管理人が「２ちゃんねる」と全角数字で表記しているんだから、それをわざわざ半角にするのはおかしくね？
疑問符とか感嘆符の類はどっちでも良くね

643 ：デフォルトの名無しさん：2008/06/05(木) 01:44:44

小腹が減ったとき食べるカレーヌードルの旨さは異常
ttp://food8.2ch.net/test/read.cgi/curry/1071495811/

644 ：641：2008/06/05(木) 01:51:37

えーと補足すると、全角／半角というのは単に表示側の表示の問題であって
概念的には同じ文字なので半角にNORMALIZEされた形にすべき、
ってのが昔のvoidの主張だった気がする。JIS X 0208もUnicodeも規格はそういう
考えだったと思う。それがこのスレ的にどうなのかなと。
たとえばUnicodeテキストでWinの「～(U+2015)」とMacの「～(U+2014)」が混ざってたら俺としては
2015に正規化したくなる。でも全角半角は事実上すべての環境で表示される字の大きさが
異なるので同じ文字としては扱いたくないなーと。

645 ：デフォルトの名無しさん：2008/06/05(木) 02:02:01

カレーパンのうた、すげぇｗ
ttp://www.geocities.jp/jugongordie/old/curryfla/curryfla.html

>>644
まぁ細かいこと気にするな
( ﾟДﾟ)⊃ ○ < ｶﾚｰﾊﾟﾝ食え
ttp://food8.2ch.net/test/read.cgi/bread/1092166761/

646 ：644：2008/06/05(木) 02:56:34

間違えた。カレーパン喰ってくる。
(誤)　Winの「～(U+2015)」とMacの「～(U+2014)」
(正)　Winの「∥(U+2225)」とMacの「∥(U+2016)」

ん？　いつから双柱って傾いて表示されるようになった？ Vistaから？

647 ：デフォルトの名無しさん：2008/06/06(金) 00:53:19

‖

648 ：デフォルトの名無しさん：2008/06/06(金) 06:36:11

http://itpro.nikkeibp.co.jp/article/COLUMN/20061221/257533/
の図１２

649 ：デフォルトの名無しさん：2008/06/08(日) 00:31:44

IVS対応ATOKマダー(AAry
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-demo-irg30.pdf
>>646
メイリオだともっと露骨に斜め45度の線2本で表示される。
まあちゃんと研究してるんだろう。角度とか

650 ：デフォルトの名無しさん：2008/06/13(金) 07:22:05

Last Resort Font
http://www.unicode.org/policies/lastresortfont_eula.html
てっきりエイプリルフールネタだと思ってたのに本気でグリフをUnicodeに収録するつもり
なんだろうか

651 ：デフォルトの名無しさん：2008/06/13(金) 18:24:17

>>650
グリフをUnicodeに収録?

まともかく、文字が表示されないときにそれが単にグリフがないせいなのか
Unicodeの範囲に入っていないせいなのかわかるとうれしいけどね。
で前者の場合にはだいたいどこら辺の文字かもわかると。
フォントの自動置換が働く場合には特に。

652 ：デフォルトの名無しさん：2008/06/13(金) 22:20:54

http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1470KXRemainder.pdf
ようやく見出し文字を全部符号化したUnicode康煕字典が作れるようになるのか。
韓国なんかUNC(緊急に必要な文字)を1万字くらい収録しる! とか無理難題言ってるのに
日本の謙虚さは異常。大漢和の未収録文字くらい提案したって罰は当たらないと
思うんだが

653 ：デフォルトの名無しさん：2008/06/13(金) 23:34:12

日本語みたいにひらがなで書けばいいみたいなのができないから
しゃーないのかなと思う所はある。

654 ：デフォルトの名無しさん：2008/06/13(金) 23:41:09

韓国はハングル専用で日本より脱漢字は進んでいるはずなんだけどな

655 ：デフォルトの名無しさん：2008/06/13(金) 23:41:53

そのハングルが合成文字で凄まじい組み合わせ数あるから・・・

656 ：デフォルトの名無しさん：2008/06/13(金) 23:43:09

今回提案されてるのは全部漢字な件

657 ：デフォルトの名無しさん：2008/06/13(金) 23:44:50

そうだったのか・・・

658 ：デフォルトの名無しさん：2008/06/13(金) 23:53:23

Ideographicなんとかグループだから表音文字は対象外だろｊｋ

659 ：デフォルトの名無しさん：2008/06/14(土) 00:20:59

表音文字の癖にコード空間を浪費するハングルは、ほんと迷惑文字。

660 ：デフォルトの名無しさん：2008/06/14(土) 12:48:40

インド人の爪の垢を煎じて飲ませたいな
(インド系文字もハングル式に実装すると数千字分くらいのコードポイントは平気で使う)

661 ：デフォルトの名無しさん：2008/06/15(日) 02:14:47

俺、ハングルのことは全くと言っていいほど知らないんだが、
それ実際にやったら描画・文字幅計算とかアラビア文字みたいにややこしいことにならない？

662 ：デフォルトの名無しさん：2008/06/15(日) 02:30:44

いちおうOpenTypeのグリフ置換の機能を使った組合型の実装例はある
(Hangeul Jamoブロックを使った奴ね)
Mac OS Xは(互換漢字と一部の記号を除いて)NFDだからHFS Plusのボリューム上では
ハングルはバラバラになって記録されてる

663 ：デフォルトの名無しさん：2008/06/15(日) 02:47:33

小学生の頃はどんな漢字も部首の組み合わせで表現できると信じていたのを思い出す。

664 ：デフォルトの名無しさん：2008/06/15(日) 03:32:42

日本政府はわざわざ常用漢字と表外字で字体の違いを発生させて
部首の組み合わせによる表現をやりにくくしてるし

665 ：デフォルトの名無しさん：2008/06/17(火) 12:24:24

ハングルは大移動なんかしないで従来のコードで表せない字母の組み合わせは
U+1100～のHangeul Jamoブロックの組み合わせで表すことにすればよかったのに。
それかどうしても全ての組み合わせのコードが必要なら追加分はBMP外にするべきだったと思う。

666 ：デフォルトの名無しさん：2008/06/17(火) 12:54:01

BMPを占有しすぎだな。
ttp://www.unicode.org/roadmaps/bmp/

667 ：デフォルトの名無しさん：2008/06/17(火) 20:06:18

>>665
> 従来のコードで表せない字母の組み合わせは
> U+1100～のHangeul Jamoブロックの組み合わせで表す
Unicode 1.1までははそうするつもりだったのに全部収録させるためだけに
Hangul and ComputerがUnicode Consortiumのフルメンバーになったりしてだな
http://www.unicode.org/history/contributors.html

668 ：デフォルトの名無しさん：2008/06/19(木) 10:54:24

JIS以降、日本の文字コードで試行錯誤したのをそのままトレースしてるようだなｗ

669 ：デフォルトの名無しさん：2008/06/19(木) 22:29:01

日本がやったのは試行錯誤じゃなくて一学者によるゲリラ活動。

670 ：デフォルトの名無しさん：2008/06/19(木) 23:14:36

今も続く混乱を考えると一学者だけじゃないな

671 ：デフォルトの名無しさん：2008/07/02(水) 23:02:20

次世代文字コードに望む要望
･各国のコード体系をきちんと分けて管理（アジアごっちゃ煮鍋はやめてくれ）
･固定長フォントにおける表示文字幅（半角、全角）を明確に判別し
文字幅長のカウントが可能
（サロゲートペアみたいのはもうこりごり）
･既存の文字コード（機種依存文字含む）からの完全な変換が可能。

672 ：デフォルトの名無しさん：2008/07/02(水) 23:28:35

一から美しい設計でやり直したいというのは技術者の気持ちとしてはわからなくもないけど
たいてい失敗します。IPv6とかIA-64とかOS/2とか。

673 ：デフォルトの名無しさん：2008/07/02(水) 23:33:59

なんだと？Vistaが失敗だと言うのか！

674 ：デフォルトの名無しさん：2008/07/02(水) 23:37:39

XHTMLの悪口、STOP!

675 ：デフォルトの名無しさん：2008/07/03(木) 10:34:45

>>672 がNAT厨かもしれないことはわかった

676 ：デフォルトの名無しさん：2008/07/04(金) 01:29:59

なんで? むしろ互換性を無視してるから現状ちょっと手の込んだNATに甘んじてるんじゃん
NATみたいなことしなくてもIPv4と直接接続できればよかったのに

677 ：デフォルトの名無しさん：2008/07/04(金) 13:15:18

そこまでバカさらす必要はない。

678 ：デフォルトの名無しさん：2008/07/05(土) 12:29:32

djbにケンカを売るか
http://www.unixuser.org/~euske/doc/ipv6ex/index.html

679 ：デフォルトの名無しさん：2008/07/05(土) 12:46:04

djbはIPv4に互換な他の選択肢を提案してないじゃん。
IPv6にはこんな技術的問題点があると主張しているだけ。
彼独自の言い回しで改善を要求しているようには読めないけど、
まあそれは彼の芸風だから、誤解する奴が馬鹿なだけ。

> NATみたいなことしなくてもIPv4と直接接続できればよかったのに

こんなトンデモとは全く違うよ、djbは。
(もちろん彼の芸風はちょっと狂ってる)

680 ：デフォルトの名無しさん：2008/07/06(日) 10:21:20

はいはいスレ違い。
つ http://pc11.2ch.net/test/read.cgi/network/1214112105/

681 ：デフォルトの名無しさん：2008/07/06(日) 10:33:43

こんな連載始まっていたんですね。

“情報化時代”に追いつけるか？　
審議が進む「新常用漢字表（仮）」
http://internet.watch.impress.co.jp/cda/jouyou/2008/06/19/19998.html

682 ：デフォルトの名無しさん：2008/07/06(日) 12:04:03

このスレの住人なら id:ogwata の日記はチェックするものだろ

683 ：デフォルトの名無しさん：2008/07/06(日) 13:32:22

そっちからも見られてる予感

684 ：デフォルトの名無しさん：2008/07/15(火) 18:08:31

外人の友達が携帯用のサイトを作ってるんですが、ドコモだけ文字が化けたり表示されなかったりすると。
数値文字参照が全く使えないと言ってるんですが、他のサイトはどうやって対応しているとかどなたか教えてくれませんか？
ぐぐってここにたどり着いたしろーとで申し訳ないんですけど、よろしくお願いします。

685 ：デフォルトの名無しさん：2008/07/15(火) 18:17:39

SJISで出力してる？

686 ：デフォルトの名無しさん：2008/07/15(火) 18:18:46

unicodeです

687 ：デフォルトの名無しさん：2008/07/15(火) 18:22:45

じゃなくて、UTF-8です、失礼しました

688 ：デフォルトの名無しさん：2008/07/15(火) 21:48:34

>>684
docomoの公式ページで携帯コンテンツ制作者向け情報が公開されているというのに、「どなたか教えてくれませんか？」とか言ってるヤツってナンなの？ゆとり？
ttp://www.nttdocomo.co.jp/service/imode/make/
ttp://www.nttdocomo.co.jp/english/service/imode/make/

・iモード対応HTML ～3.x
文字コード : Shift_JIS
10進数値文字参照(Shift-JIS準拠数値) : &#*****;

・iモード対応HTML 4.0～ (MOVA504i～およびFOMA)
文字コード : Shift_JIS
10進数値文字参照(Shift-JIS準拠数値) : &#*****;
16進数値文字参照(Unicode準拠数値) : &#x\\\\;

・iモード対応XHTML (FOMA)
文字コード : Shift-JISおよびUTF-8
10進数値文字参照(Shift-JIS準拠数値) : &#*****;
16進数値文字参照(Unicode準拠数値) : &#x\\\\;

てか、「友達が」というヤツに限って本当は本人が当事者なんだよなｗ
auとSoftBankの携帯コンテンツ制作者向け情報もきちんと読めよｗ
ttp://www.au.kddi.com/ezfactory/
ttp://creation.mb.softbank.jp/

689 ：デフォルトの名無しさん：2008/07/15(火) 22:15:48

うざいな、知ってるなら最初から出してくれてもいいじゃないですか？
出し惜しみとか最低ですね

690 ：デフォルトの名無しさん：2008/07/15(火) 22:31:46

なんだこりゃ

691 ：デフォルトの名無しさん：2008/07/15(火) 22:34:41

しっかし、文字参照がShift_JISのコードポイントって、ほんとにドコモ
の人は頭わるかったんだねえ。

692 ：デフォルトの名無しさん：2008/07/15(火) 22:37:30

10進と16進で異なるEncodingとは、なんて邪悪。

693 ：デフォルトの名無しさん：2008/07/15(火) 22:49:42

694 ：デフォルトの名無しさん：2008/07/15(火) 23:17:30

>>689
685と688は別人だということを推し量れないヤツってナンなの？ゆとり？

>>691
Internet Explorer 3やNetscape Navigator 3では文字参照がShift_JISのコードポイントってことを知らないヤツってナンなの？ゆとり？

695 ：デフォルトの名無しさん：2008/07/16(水) 01:26:09

1999年2月開始のサービスなのにInternet Explorer 3やNetscape Navigator 3の仕様に
配慮されてもなー

696 ：デフォルトの名無しさん：2008/07/16(水) 02:25:47

HTMLファイルにShift_JISを使っているくらいだから、
文字参照も同じShift_JISにするというのはあまり変だと思わないな。
1999年ならそれに加えてUnicodeに対応させるのは厳しかったのだろうし。
問題はなんでそれを今でも引きずらならなきゃならないのかということだ。

697 ：デフォルトの名無しさん：2008/07/16(水) 07:11:13

まあ(iモードの世界での)互換性というものがあるし。
でもIE4/NN4/HTML4でもうとっくに文字参照はUnicodeが標準になってましたよ
確かにドコモのページには「iモード対応HTML4.0対応機種以降」とか書いてるから
最初はHTML4(の文字参照)に対応してなかったようだけど。
16進文字参照が導入されたのもHTML4だから、16進で書かれたらHTML4とみなす
というのもどうにか互換性を保ちつつ拡張しようとした結果だと思われ

698 ：デフォルトの名無しさん：2008/07/16(水) 09:15:45

ていうか、それがDoCoMoクオリティ、でFA

699 ：デフォルトの名無しさん：2008/07/16(水) 09:51:42

当初はこれやってるのドコモだけだったから、自分たちが決めたこと＝携帯の標準だったからな
メールの文字コードとかもそうだし、mldファイルのMIME-TYPEがtext/plainとかむちゃくちゃやっとったｗ

700 ：デフォルトの名無しさん：2008/07/16(水) 10:17:25

あそこはごく一部以外技術者のレベルが低いから。

701 ：デフォルトの名無しさん：2008/07/16(水) 11:31:45

みなさんありがとうございました。
公式も見たんですが分からなかったんで、グーグルで同じような人いないかなーって調べてたらここに来れたので、普通に聞いちゃいました。
原因も分からないし、友達外人だからいちいち説明もしてらんなかったので、手っ取り早い解決方法を模索しちゃいました。
とりあえずデータベースからの見直しをお願いしようかと思っています。

正直素人なのにあんま貶されなくて、ほっとしましたｗ
ありがとうございましたー

702 ：デフォルトの名無しさん：2008/08/06(水) 19:57:26

いつの間にかAmd.4が正式リリースされてた
http://standards.iso.org/ittf/PubliclyAvailableStandards/c046311_ISO_IEC_10646_2003_Amd_4_2008(E).zip
今回最大の変更点は、実装水準1と2が廃止されたこと。
適合を主張するすべての実装は、合成をサポートしなければならなくなりました。

703 ：デフォルトの名無しさん：2008/08/06(水) 22:34:33

うはー
実装水準3に適合すんの無理くさいのに

704 ：デフォルトの名無しさん：2008/08/08(金) 00:40:01

合成なんてネタだと思ってたよ

705 ：デフォルトの名無しさん：2008/08/08(金) 02:36:23

コンゴトモヨロシク

706 ：デフォルトの名無しさん：2008/08/08(金) 20:56:57

まだ(JIS X 0213対応ですの代わりに)
「JAPANESE NON IDEOGRAPHICS EXTENTION対応です」で逃げられる

707 ：デフォルトの名無しさん：2008/08/08(金) 21:18:29

もっともらしい理由がほしかったら
「ほとんど使われていないJIS X 0213の国際基準版・漢字用8ビット符号や参考に
過ぎない附属書の符号化表現は今後もサポートする予定がないので、国際規格
によるレパートリの記述方法で適合性を表現することにしました」とでも言っておけ
ばよろし。

新常用漢字やら新々人名用漢字やらで、もしIVS対応が必要になったら
もう逃げられないけどね。
# 他にどんなデメリットがあろうと2オクテットで表せるなら互換漢字のほうがマシだ
# って人は多いんだろうなあ…

708 ：デフォルトの名無しさん：2008/08/10(日) 23:06:48

常用漢字の追加候補に「叱」があるけどもしこれが正字で追加されることにでもなったら
サロゲート対応は必須になるな。

709 ：デフォルトの名無しさん：2008/08/10(日) 23:26:49

そういやそうだ。正字で追加しろって意見が多いみたいなんだが
JIS X 0208で(それどころかUnicode BMPですら)表せない文字が追加されることの
インパクトをどれくらい真剣に考えてるんだろうね

710 ：デフォルトの名無しさん：2008/08/11(月) 19:11:53

二面の「拡張漢字」のおかげで、「互換」漢字の位置づけは意味不明に
なってしまっている。初期の博物学のような眩暈のする状況。

711 ：デフォルトの名無しさん：2008/08/11(月) 21:20:25

なぁ、おまえらに聞きたいんだが

Unicode ないほうが楽って思ってるのは俺一人か？

712 ：デフォルトの名無しさん：2008/08/11(月) 21:26:18

真面目に対応しない分には楽だよ

713 ：デフォルトの名無しさん：2008/08/11(月) 22:10:12

「叱」は2004年の人名用漢字追加の時にも正字(U+20B9F)で候補に入ってたな。
結局「糞」や「屍」同様に名付けに相応しくない字とされ追加されなかったが。

714 ：デフォルトの名無しさん：2008/08/11(月) 23:21:44

常用漢字だとその逃げ道は使えんな

715 ：デフォルトの名無しさん：2008/08/11(月) 23:23:19

>>711
お前は今までに実装したISO-IRの符号化文字集合の数を覚えているのか?

716 ：デフォルトの名無しさん：2008/08/11(月) 23:50:26

>>711
Unicodeなしで、例えばIBM ICUくらいのレベルに仕上がった
文字を扱うライブラリってあるんですか？
扱う文字数も含めて。

正直、Unicodeのもたらした困難さは、
文字符合化の困難さのごく一部に過ぎません。
全世界共通の土壌を提供したメリットに比べたら無視できます。

717 ：デフォルトの名無しさん：2008/08/12(火) 10:43:14

>>711
いいも悪いも

　提唱したxeroxと共に死ねよ、規格グチャグチャにしやがって

という思いのみ

718 ：デフォルトの名無しさん：2008/08/12(火) 11:27:15

DIS 10646 1.0(笑)

719 ：デフォルトの名無しさん：2008/08/12(火) 20:21:13

簡単にいうと

以前よりはマシになった程度

720 ：デフォルトの名無しさん：2008/08/12(火) 20:33:00

いろいろとあったが、
とりあえず、Unicodeに入ってしまえば、
ISO 8859だった奴等もそれに従う必要があるというのは大きいし、
世界を視野に入れたソフトウェア産業の思惑とも合致する。
Unicode化しておけば、L10Nの手間がかなり減る。

721 ：デフォルトの名無しさん：2008/08/12(火) 22:29:18

Unicodeは符号化方式が……
UTF-8に統一してくれればいくらか楽だけど、冗長性問題あるしなぁ。

722 ：デフォルトの名無しさん：2008/08/12(火) 23:08:04

>>720
最近では非関税障壁を消してしまうとインド人や中国人の雇用が増えるばかりで
自分たちの仕事が無くなるのを恐れてるんじゃないかと思えてくるようになった

723 ：デフォルトの名無しさん：2008/08/12(火) 23:17:06

そういえばちょっと話は変わるけど、リトルエンディアンを考えたのって誰？
あんな中途半端なことしないで、完全にひっくり返しちゃった方がややこしくない気がするけど。
まあ、UTF-8でエンディアン問題が出てくるからそれはそれで面倒か。

724 ：デフォルトの名無しさん：2008/08/12(火) 23:33:47

は？エンディアンの意味がわからないって事？

725 ：デフォルトの名無しさん：2008/08/13(水) 00:09:35

リトルエンディアンはTRONにすらあったな。準TADとかいう名前で

726 ：デフォルトの名無しさん：2008/08/13(水) 00:27:12

>723
ビッグエンディアンでabcdefghijklmnopABCDEFGHIJKLMNOPというビット列は
リトルエンディアンだとABCDEFGHIJKLMNOPabcdefghijklmnopになると思うけど、
そうじゃなくてPONMLKJIHGFEDCBAponmlkjihgfedcbaまでひっくり返してしまうつうこと。
小さい桁から遡っていく感じですな。

こうすると冗長なゼロが頭に来なくなるから、それなりに便利な気もするけどね。

727 ：デフォルトの名無しさん：2008/08/13(水) 00:36:01

なりません。

728 ：デフォルトの名無しさん：2008/08/13(水) 00:39:42

ワードアクセスのCPUの都合であるエンディアン
だけど、文字の世界でまであわせる必要は無いかと思うがね

729 ：デフォルトの名無しさん：2008/08/13(水) 00:55:42

文字と言ってもその実体は数値な訳で。
UTF-16だとワード幅の数値だからね。

730 ：デフォルトの名無しさん：2008/08/13(水) 03:31:53

>>723=>>726 はネタ確定。

731 ：デフォルトの名無しさん：2008/08/13(水) 04:00:40

>>721
符合化方式が複数ある程度のことが苦になる人は、
文字符合化のことなんて考えないほうがいいですよ。
ライブラリに任せなさい。

732 ：デフォルトの名無しさん：2008/08/13(水) 20:10:50

ライブラリのある無しの問題じゃないだろ・・

733 ：デフォルトの名無しさん：2008/08/13(水) 21:01:08

>>728
ワードアクセスが関係するのはビッグエンディアンだけだろ。
リトルエンディアンの考え自体はワードアクセスの制限を受けない。

>>728
バイト単位でデータ交換する世の中でそれはできねーだろ。
Encoding formのUTF-16だけじゃなくてEncoding shemeのUTF-16がどうしても要る。

>>730
ネタじゃなくて真性だろ。きっと。
俺としてはビッグエンディアンみたいな統一性の無い仕様こそ嫌だね。
つーかUTF-8のエンディアン問題ってナンなの？

734 ：デフォルトの名無しさん：2008/08/13(水) 21:13:26

>>733
>つーかUTF-8のエンディアン問題ってナンなの？

エンディアンというかBOM
UTF-8は本来そんなもんいらないはずなのに
http://www.unfindable.net/~yabuki/blog/2006/08/notepad_171819.html

735 ：デフォルトの名無しさん：2008/08/13(水) 22:29:30

何かと思えばBOM問題かよ。
文字コードに関する情報が無いままテキストファイルが散乱する方が恐ろしいじゃねーか。
必要とか必要じゃないとかじゃなくて、あっても受け入れるのが仕様。
互換性のためなら設計ミスも押し通す。それがJavaがクオリティ。

736 ：デフォルトの名無しさん：2008/08/14(木) 09:35:57

>>723が何を言ってるのかわからなかったが、
もしかしてビット列表記のLSB、MSBも逆に書けと言ってるのか？

737 ：デフォルトの名無しさん：2008/08/14(木) 20:56:49

>>736
違う。書くんじゃなくて、>>723が自分のバイナリエディタで見た16進数を2進数に
書き取った時にビットが逆に並ぶようなアーキテクチャにしてくれ、と言っている。
つまり32ビット値12345678hは、
ビッグエンディアン
　12 34 56 78 (0001-0010 0011-0100 0101-0110 0111-1000)
に対し、>>726式リトルエンディアンでは
　1E 6A 2C 48 (0001-1110 0110-1010 0010-1100 0100-1000)
となる。
俺はノーサンキューだね。
BE/LEどちらも、ビットの順なんて定義していないことを理解して欲しい。

738 ：デフォルトの名無しさん：2008/08/14(木) 21:58:30

BEでは、MSBからBit0になるんじゃなかったっけ？
そういう意味では、たとえばBE32bit数値は、Bit0～Bit31まで
素直に連続してるといえるけど。

739 ：デフォルトの名無しさん：2008/08/14(木) 22:59:51

> BEでは、MSBからBit0になるんじゃなかったっけ？
ならないよ。バイト内のビット順序なんて規定してない。

そもそもの間違いは、日本人が数値を書く時は繰り上がりが発生すると左に桁を
増やして書く(=桁の上位が左側)のに、16進でバイト列書く時は左から右(上位
アドレスが右側)に書くこと。
ワード内の並びなんて文字を右から左に書くか左から右に書くかで何とでも言える。

いいか？　ビッグエンディアンは多バイト整数(ここではUTF-16文字とする)を
複数書くときにワード境界で不連続になるんだ。

740 ：デフォルトの名無しさん：2008/08/14(木) 23:08:30

で？

741 ：デフォルトの名無しさん：2008/08/14(木) 23:44:03

別に日本人関係ねえし

742 ：デフォルトの名無しさん：2008/08/15(金) 05:53:47

もうアホかと。

743 ：デフォルトの名無しさん：2008/08/15(金) 07:27:35

＞> BEでは、MSBからBit0になるんじゃなかったっけ？
＞ならないよ。バイト内のビット順序なんて規定してない。
へー。

http://www.nk.rim.or.jp/~jun/ppcasm/ppcasm02.html
＞(PowerPCは)bit0が最上位になります。ローテイト命令などでビット位置を
＞指定する場合に注意が必要です。上位16ビットは0：15、
＞下位16ビットは、16:31となることに注意してください。

744 ：デフォルトの名無しさん：2008/08/15(金) 08:09:11

>>743
IBM と、今は亡き DGくらいなんだが、 MSB=bit0
MIPS とか SUN とかは LSB=bit0

745 ：デフォルトの名無しさん：2008/08/15(金) 13:30:40

最上位ビットをbit0と呼ぶことと、最下位ビットを右に書くことと何の関係があるんだ?

746 ：デフォルトの名無しさん：2008/08/19(火) 09:04:27

>>743
ﾜﾛﾀ
Unicodeはバイト(=8bit)の内部には関与しません。

747 ：デフォルトの名無しさん：2008/08/19(火) 22:35:39

あらら、まだ続いていたんかいな。

>746
いや、UTF-8の冗長性チェックは内部ビットを意識しないとできないんじゃない？
下位桁が先頭に来るようにすれば、位取り0の挿入による冗長表現の判別が簡単になるから
UTF-8で行う必要のある正当性チェックが簡単になる、ぐらいの話だよ。

>743
PowerPCは最下位桁が先頭なのか……知らんかった。
素人丸出しですな。

748 ：デフォルトの名無しさん：2008/08/19(火) 23:48:33

>>747
だから、バイト内のビットに先頭も末尾もないってば。
だからどっちをビット0と呼ぼうと関係ないんだって。

749 ：デフォルトの名無しさん：2008/08/20(水) 04:11:02

流れをぶった切って済まないが、知恵をお貸ししてもらえないだろうか。
文字コードの変換元が判らなくて、すこし困っているのだが、
だれかこの文字コードが何だか認識できる人はいますかな？
"e2 5a fc 5b e2 eb fc 5b f2 d7".
これ、”セーラー服”ってなるのだが
UTF8 = "e382 bbe3 83bc e383 a9e3 83bc e69c 8d"
EUC-JP = "a5bb a1bc a5e9 a1bc c9fe"
shift-jis = "835a 815b 8389 815b 959e"
あきらかに違うんだよ。自動変換ミス？”ー”（UTF-8: 0xE3 0x82 0xBB）
が　”fc 5b”　になる文字コードってなんかあるのかな？

偉い人、助けてください。

750 ：デフォルトの名無しさん：2008/08/20(水) 08:15:17

それ、cp932を難読化しているんじゃないかな。
0x80未満のコードはそのままで、0x80以上は簡単に暗号化している感じ。
尤も、0x83は0xe2になるのに0x81が0xfcなので単純なxorなんかじゃなさそうだけど。
一対一対応はできていそうだから、サンプルがもう少しあれば解析できそうだ。
今は出勤前だから、取り敢えず電車の中で考えてみるか。

751 ：デフォルトの名無しさん：2008/08/20(水) 14:05:55

すまん、おそらくここでは外出なんだろうが、CJK混在の漢字環境って
どうやって、切り分ければいいの？

752 ：751：2008/08/20(水) 14:14:11

すまん、たぶん言葉が足りていない

この <昔の中国語(漢字はおそらくGBの範囲内)> 単語は、古来日本では
<昔の日本語(漢字はJISの範囲内じゃないかも知れない)> に相当...

の、ような文章が続く場合、<>で挟まれた間の言語の仮定方法がない
と思われるんだが…

つか、言語分からないと、辞書が引けない

753 ：デフォルトの名無しさん：2008/08/20(水) 14:25:32

無理だから、例えばHTMLやXMLのlang属性みたいに上の層でどうにかしろってことじゃね？

754 ：デフォルトの名無しさん：2008/08/20(水) 14:31:55

>>751
サロゲートペアでググれ
>>753
無理じゃねーよ。
もちろんlang属性でも可能。

どちらもまともな対応ブラウザは少ない。

755 ：デフォルトの名無しさん：2008/08/20(水) 22:20:51

よくわからんな。
>>751　その『切り分け』って何だ？
>>752　Unicode系なら、人間が前後の文脈で判断するしかない。
　　　　もしISO-2022で書いてあるなら言語情報はあるので詳しい人に訊け
>>753　辞書引くって言ってるから既に文書があることが前提でしょ。
　　　ISO-2022かlang属性ついてるかでなければ諦めろとしか言いようがない
>>754　何でここでサロゲートペアが出てくるのか理解できん

756 ：デフォルトの名無しさん：2008/08/20(水) 22:34:31

>>752
紙に書いた時と同じだろ。文章で説明しろよ。
lang属性とか言っている奴は馬鹿か？

757 ：デフォルトの名無しさん：2008/08/20(水) 22:34:41

>>749
一般的な文字コードでは無いね。シフトJISが文字化けしてるか独自コード(難読含む)のどちらか。
独自コードのリバースエンジニアリングはこのスレの話じゃなくなる。

758 ：479：2008/08/21(木) 02:27:43

眠い...とりあえず状況報告
>>750 ありがとう、cp932であたりをつけたら、問題発見した。
原因：winzipの規格ではコードページ指定もしくは記録情報が存在しない。
（zipのソース読まなくちゃ判んないとは...規格に書いておいてくれよ...）
勝手にプログラムの方で無理矢理コード変換してるので、でたらめっぽい文字列が出てくる。
解決策：取り合えず、MSWin+JPではShift-jisでファイル自体には保存されている。
MACOSX=Unicode,Unix=UTF/EUC/S-JISどれでもありえる。文字に関係なくLocalLangで
再変換しているので、それをしなければよい。
実験用に、bash+coreutil+iconvでうごく、代用品をでっちあげてみたので、
よかったらどうぞ。
ttp://aikofan.dee.cc/aikoup1/src/f1012.xxx (txt/bash-script)

759 ：749=758：2008/08/21(木) 02:31:13

>>749 == >>758
悪い、素で間違えた。タイプミスを許してくれ。

760 ：デフォルトの名無しさん：2008/08/21(木) 02:31:55

zipの規格でファイルの中身の文字コードを持てというのは無理難題だろ。
勝手にやって失敗しているwinzipが悪いに決まってる。

761 ：デフォルトの名無しさん：2008/08/21(木) 05:09:22

たしか zip には多目的フラグの中に UTF-8 指定するフラグがあったような。
まったく普及してないけど。

762 ：デフォルトの名無しさん：2008/08/21(木) 14:17:12

1bitかよ！

763 ：デフォルトの名無しさん：2008/08/21(木) 15:25:29

pkzip出たの1989年か。DOS時代に広まった後に、
拡張されたフラグなのだからGDGDになってるのもしょうがないな。

764 ：デフォルトの名無しさん：2008/08/22(金) 08:28:52

もしご存知でしたら教えてください。
WindowsOSの環境で、フォルダに格納されているテキスト群の
それぞれに指定されている文字コードを一覧で表示してくれる
ツールをご存じないでしょうか？
精度はそれほど必要は無く、S-JIS/EUCを判別できる程度でも
良いのです。
googleで調べてみたのですが、なかなか見つからなくて・・・。

765 ：デフォルトの名無しさん：2008/08/22(金) 09:07:49

つ[file]

766 ：デフォルトの名無しさん：2008/08/22(金) 10:17:02

nkfのguess

767 ：デフォルトの名無しさん：2008/08/23(土) 00:26:38

俺もnkfだな。あとぱっと思い付くのは秀丸のopenとマクロを使用した方法だが。
ぶっちゃけ、完全なeuc/s-jis/jis判定はできないから。ソフト側で無理矢理
推測するので、間違いもあるけど。

うちでは追加でまず地域指定、あと、含まれるであろうキーワードのリストと
ファイルmimeで多少精度を上げるときもあるけど、処理の割には判定が甘い。
此ばっかりはどうにもならないな。

”勘ピューター”プログラミング、他にはどんな判定方法あったっけ？

768 ：デフォルトの名無しさん：2008/08/23(土) 00:46:34

>>767
日本語文字の出現頻度スコアを持ってるバベルならほぼ完璧に判定できるよ。
ただ、コマンドとしては用意されてないけど。

769 ：デフォルトの名無しさん：2008/08/23(土) 01:16:04

>>出現頻度スコアうちも似たような事して判定してたけど、文書が短いとき、
あと、学術論文とかで数か国語混じってると、誤判定おこすんだよなあ。
やり方としては間違っちゃいないんだろうが。

あれは、文法の前後の単語の頻度スコアはやってないから、中国文っぽいとき
（ただ単に日本語の漢字のみで文書が書かれていた場合）とか、判定ミスる。
轍書き＋前後頻度辞書での組合せでやってるのは今んトコ俺は見たことないが。
（世の中にはあるかもしれない）。FirefoxもUTFで中国文っぽい日本語では、
判定では日本語でも、フォント関係なく部分的に中国文字になるし...はあ。愚痴スマソ。

770 ：デフォルトの名無しさん：2008/08/23(土) 02:02:17

>>769
>文書が短いとき
短いだけなら出現頻度スコアだけで十分な判定精度が得られると思うけど。

>数か国語混じってると
これは下手に対応しようとすると逆に一般的な判定精度が劣化しそうだし、
真面目にやるにはサンプリングデータの収集も面倒だし、判定用に使用する
スコアデータも膨大になってかなり大事になりそうですね。

>中国文っぽいとき
これは厳密にはどういう意味？
例えばSJISで使える文字だけつかって中文を記述したとかそんな感じ？

771 ：デフォルトの名無しさん：2008/08/23(土) 08:49:42

>>765-770
ありがとうございます。皆さん親切に・・・。
いろいろと教えてもらったキーワードから、自分にあったのもを
探してみます。たった一日でこんなにアドバイスもらえるなんて・・・。

772 ：デフォルトの名無しさん：2008/08/23(土) 14:06:17

770>> おお、大変さをわかってくれる人が居るとは...
>中国文っぽいときいや、単に日本語だけでも、プログラムの上では
部分的に中国語判定なるものがある。悪い例（超弩級大型対空支援砲撃用戦艦）（文書に得に意味はなし
でも括弧の間だけ中文判定されたりする（中文じゃないのに）。例としてfirefoxで使用しているフォントレンダリングの
コードは、かなり手抜きで、むしろひらがな、片仮名が無ければ中文判定してんじゃないの、って言われてもしかたない
ような実装に見えてしまう...（別にそう云う訳では無いのだが）。実際、日本的な丸文字フォントがちゃんとあるのに、
その部分だけハネの強い中文体になってたりして、サロゲート、なにそれ？な状態で読んでるとかなり萎える...

つうーか、個人的には、日本でutfの空スベースを少し買収して、そこに一から日本文字のコードセットを
築いてほしい...いや、まじめにね、ラテンでДϦСDЄFԍҺIЈКМИOρ٩ᴦSϮUѴШχyZ使え、って言ったら、ブチ切れるのに、
ハネがすこし違い、少し角張っている・丸い、で一緒くたにされた、glyphおんなじって言われた方は、溜ったもんじゃないんだよ。

いや、疲れてるね、おれ。

773 ：デフォルトの名無しさん：2008/08/23(土) 14:09:04

>>770
漢文とかじゃね？

774 ：デフォルトの名無しさん：2008/08/23(土) 16:44:20

まぁ、できるものなら10年前に戻って（20年前？）和田先生とかmohta氏と一緒に
反対運動をするところだけど、今更どうにもなんないしなぁ

775 ：デフォルトの名無しさん：2008/08/23(土) 17:01:49

>>772
>部分的に中国語判定なるものがある。

lang 指定とかの手掛かりも無しにそれを自動でやるのは無謀以外のなにものでもないだろｗ
それって端的に言うと

『日本語のフォントだと「骨」はこうなるけど、中文のフォントだと「骨」はこうなる。』

みたいな文章の「骨」の部分のフォントを自動判別で切り分けろって話だろ？
このクラスの自動判別を行うには文章の内容をほぼ完全に解析するような
かなり高度なAIが必須なわけで現状では無理。

776 ：デフォルトの名無しさん：2008/08/23(土) 17:05:05

>>772
そういうヒューリスティックが必要な処理はできるだけ避ける方向で行くしか
ないのでは。htmlならlangとcharsetがあるわけだし。

そうそう、グリフに関してはデザインレベルの問題があるよね。
あう意味異体字タグが扱う話よりさらに細かいレベルの問題というか。

777 ：デフォルトの名無しさん：2008/08/23(土) 18:41:18

読者のことを考えると、文章だけで理解、判別できなくてはならない。
langやcharsetは>>752の目的には不適だと思う。

778 ：デフォルトの名無しさん：2008/08/23(土) 19:16:34

人工知能つくってんじゃないんだから

779 ：デフォルトの名無しさん：2008/08/23(土) 21:27:11

>>777
> 読者のことを考えると、文章だけで理解、判別できなくてはならない。

原理的に無理なものはどうしようもない。
あとは運用で何とかしてくれ。

780 ：デフォルトの名無しさん：2008/08/23(土) 22:11:06

完璧な文字コードの自動検出みたいな

781 ：デフォルトの名無しさん：2008/08/24(日) 01:11:53

テキストファイルもバイナリだし究極的には
開いたときに人間が判断できた形式が正解っていう

782 ：デフォルトの名無しさん：2008/08/24(日) 01:57:38

そうしてまた「キャッチ２２」状態のままUTFに移行した訳だが...
>自動でやるのは無謀以外のなにものでもない
>自動判別で切り分けろって話だろ？
そう、その通り。無理だ。それを判らず、文書のコード移行しているから
確実に後で（２０年ぐらい？）検索/UCSで問題が出てくる。
俺にどないせぇーちゅうねん...（泣き

783 ：デフォルトの名無しさん：2008/08/24(日) 06:30:43

そういう分野で仕事して無くて心底良かったと思うわｗ

784 ：デフォルトの名無しさん：2008/08/24(日) 09:37:30

結局、Unicodeと言っても、多言語の混在は現実には出来ないってことなのね。

785 ：デフォルトの名無しさん：2008/08/24(日) 09:43:43

Unicodeは言語情報を直接扱わない。
表現に言語情報が利用されていることがあるだけ。

多言語の混在表現は別のレイヤーで行うべき事。
文字そのもので言語を表現するのは難しいから。

最低でも文字の連である必要がある。
理想は構造化テキスト。

786 ：デフォルトの名無しさん：2008/08/24(日) 09:52:56

なるほど、じゃあそもそもUnicodeである必要も無いってことか。

787 ：デフォルトの名無しさん：2008/08/24(日) 11:36:23

>>782
20年後ぐらいなら特定の分野に特化したものなら
実用的なAIも十分実現可能な範囲だと思うぞ。

788 ：デフォルトの名無しさん：2008/08/24(日) 12:22:36

>>787 ２０年後じゃなくて、今、必要なんだ...
>混在表現は別のレイヤーで行うべき
これを理解できる人は少なく、又はそれを処理できるプログラムでまともなのを見たことが（ry
ユーザから見れば、（IME Shift+Space等で）入力方式選択の時点で既に言語選択の仕事は終わっていると思われていることがある。
入力装置→InputMethod→文字コード　で、IMEngineが中文、日本語と違うのに、結果行き着く文字コードが同じってことは
情報が取りこぼれしてるから、後から別レイヤにしたくてもできなくなる。(いっそJIS2022JPの方が判定し易いという皮肉つきだ)
コードポイントを別にしてくれたのなら、検索の時でも言語別に対応できるのだが(ry

愚痴をきいてくれて、あり(ry

789 ：デフォルトの名無しさん：2008/08/24(日) 12:57:03

>>788
とりあえずお前さんがいま扱ってる真の問題領域は文字コードなんかじゃない。
形態素解析とか人工知能なんかのスレへ逝け。

790 ：デフォルトの名無しさん：2008/08/24(日) 13:16:10

>>788
>入力装置→InputMethod→文字コード　で、IMEngineが中文、日本語と違うのに、結果行き着く文字コードが同じってことは
>情報が取りこぼれしてるから、

普通は、行き先に言語設定だとかフォント設定だとかがあるんじゃないの?
ワープロだとか、検索エンジンだとか。
ウェブ検索で英語を入力しても日本語のサイトだけひっかかって欲しいときとかもあるし。

まどのみち、これ以上は国際化のスレとかかな?

791 ：デフォルトの名無しさん：2008/08/24(日) 13:27:32

>>785
> 表現に言語情報が利用されていることがあるだけ。

多くは国情報だね。
言語情報もあるけどね。

792 ：デフォルトの名無しさん：2008/08/24(日) 23:57:28

Unicodeは多言語混在でなく、英語＋その他1言語の混在しか考えてないと
思うのだが。
「その他1言語」の変更の際にプログラムの改修が少なくなっただけ。

793 ：デフォルトの名無しさん：2008/08/25(月) 00:05:25

混在できるのは文字であって言語ではないのではなかろうか。

794 ：デフォルトの名無しさん：2008/08/25(月) 01:30:23

DIS 10646 1.0(ISO 10646の最終草案) には文字コードに言語情報が含まれる。
これが否決されずにISO規格になっていればよかったのになぁ」って事でしょ。

名前だけで中身がほぼ空のUCS-32を使って、もいちど言語情報を含んだ規格を
策定しよう、なんて話は出ないんかね。

795 ：794：2008/08/25(月) 01:33:08

× UCS-32
○ UCS-4

#UCS-4 は 31ビットだし

796 ：デフォルトの名無しさん：2008/08/25(月) 02:26:12

Unicodeに言語タグってあったよね？
あれじゃダメなの？
使われている場面を知らないけど。

797 ：デフォルトの名無しさん：2008/08/25(月) 09:41:55

言語タグってISO2022のESCシーケンスとどう違うの？

798 ：デフォルトの名無しさん：2008/08/25(月) 09:55:28

ISO 2022は「文字集合」指定。
言語指定でも国指定でもない。
JIS X 0208にはギリシャ文字もロシア文字も含まれてる。

799 ：デフォルトの名無しさん：2008/08/25(月) 12:34:13

バリアントタグじゃなくて言語タグ？

800 ：デフォルトの名無しさん：2008/08/25(月) 22:40:48

>>799
http://www.unicode.org/versions/Unicode5.0.0/ch16.pdf
の16.9 Tag Charactersですな。

> The characters in this block provide a mechanism for language tagging in Unicode plain
> text. The use of these characters is strongly discouraged.

とあり、また、Unicode 5.1.0のSummaryにはTag CharactersはDeprecatedだと書かれている。

Variant tagは標準になるけど、Language tagはやはりUnicode標準とすることは望ましくない
（Unicodeの役目を超えている）という結論になったのではないかと思う。

詳しい人突っ込みよろ。

801 ：デフォルトの名無しさん：2008/08/25(月) 23:24:08

>>797
あれはISO 2022とラウンドトリップコンバージョンをするためだけに入れられたようなもの

802 ：デフォルトの名無しさん：2008/08/26(火) 17:51:33

言語タグを使ってもISO 2022とのラウンドドリップなんて無理だけどな。

803 ：デフォルトの名無しさん：2008/08/26(火) 17:59:37

文字コードから言語を求めるなんて土台無理な話だよな
どうしても言語情報が必要ならHTMLでも使えばって話になる

804 ：デフォルトの名無しさん：2008/08/26(火) 18:12:58

「中国の○って漢字は、簡略化された●です。
あまりに簡略化されているので、
簡体字の○から●を想像することはできません。
また○には、●とは違う意味も付与されていて、
『～□△▲○■◎～』という風に使います。」

『～□△▲○■◎～』の中は中国語として、
中国語の言語タグ付けるのはこの部分だけ?
○には全部付ける?

805 ：デフォルトの名無しさん：2008/08/26(火) 18:20:56

>>804
全部つけるべきだと思うけど、逆にそう思わない根拠はなに？

806 ：デフォルトの名無しさん：2008/08/27(水) 00:25:36

○と言う部分が中国語か否かって事でしょ

まぁ、ここまで来ると完全にスレ違いじゃね
フォント割り当てと言語の問題で文字コードには関係なさげ

807 ：デフォルトの名無しさん：2008/08/27(水) 00:31:49

そうやって逃げまくった結果がこれだよ！

808 ：デフォルトの名無しさん：2008/08/27(水) 02:37:54

だから言語情報とか言い出すなら構造化文書使えよｗ
使用文字と使用言語に因果関係が無いんだから、平文じゃどうしようもないだろ
英語として使われてるアルファベットとローマ字として使われてるアルファベットは確実に区別が出来るべきだとか考えてるの？

809 ：デフォルトの名無しさん：2008/08/30(土) 11:10:07

サロゲートペアとかアホじゃね？
苦し紛れにしても、固定長の最大の利点潰すとかあり得ない

合成文字とか基地外じゃね？
もはやuniじゃないじゃん

810 ：デフォルトの名無しさん：2008/08/30(土) 19:09:08

65535文字で世界中の文字が表せるわけないじゃん？

811 ：デフォルトの名無しさん：2008/08/30(土) 19:35:09

合成文字とかUnicode 1.0からあったわけで今さらそんなこと言ってるほうがおかしい
当初16ｂbit固定長とかさんざん嘘吐いて宣伝してたのは事実だけどね

812 ：デフォルトの名無しさん：2008/08/30(土) 20:37:01

俺たちはまだ諦めちゃいねぇぜ、Unicode hater スレ、ってどっかにないの？

813 ：デフォルトの名無しさん：2008/08/30(土) 21:57:00

合成文字をありがたがる奴なんて、今の世に一人でもいるの？
正規化が必要になってまで得られる利点って何？

814 ：デフォルトの名無しさん：2008/08/30(土) 22:02:39

「国際化対応しました」という大義名分が立ちます

815 ：デフォルトの名無しさん：2008/08/30(土) 22:04:03

>>813
Complex Scriptの文字表現はどうするの？
可能な組合せ全てにprecomposed formのcode point割当てたら
かなり愉快なことになるよ。

816 ：デフォルトの名無しさん：2008/08/30(土) 22:39:27

正規化で結局自動でコードポイント割り振ってるだけじゃん
何もかわらんだろ

817 ：デフォルトの名無しさん：2008/08/31(日) 00:05:31

Unicodeには例の法則が発動したのだよ
ひとに迷惑をかけるなという教育を全くうけていないのだと

818 ：デフォルトの名無しさん：2008/08/31(日) 00:50:28

>>811
今更そんな事言ってるのがおかしいのか
未だにそんな糞仕様が残ってるのがおかしいのか

819 ：デフォルトの名無しさん：2008/08/31(日) 12:12:43

Unicode文字列リストを各国言語を考慮してソートしたいんですが、
どういう方法を使えばいいんでしょうか？
出来ればWindowsAPI辺りで有ればいいんですが。C/C++のコードでもいいです。

820 ：デフォルトの名無しさん：2008/08/31(日) 19:08:07

たとえば、U+5CとU+A5は隣に並べたい？

821 ：デフォルトの名無しさん：2008/08/31(日) 19:25:57

>>818
固定長でなんでも片付くと思ってそれ以外のものを糞仕様とか言い出す頭がおかしい

822 ：デフォルトの名無しさん：2008/08/31(日) 19:35:30

64bit固定長なら解決

823 ：デフォルトの名無しさん：2008/08/31(日) 20:09:23

>>819
CompareStringが使えると思う。LCIDで好きに指定できるはず。
標準C/C++だとstrcollとかuse_faset<collate<wchar_t> >してcompareとかなんだろうけど、
使ったことないからよくわからん。

824 ：デフォルトの名無しさん：2008/08/31(日) 23:28:49

>>821
固定長と可変長の混在ついて糞と言ってるんだが

825 ：819：2008/09/01(月) 01:07:36

>>820
並べるべきだとは思いますが。
逆に、Unicodeにスタンダードな並べ方があれば、それに従うのがいいかなと思うのですが。

>>823
ありがとうございます。
ちなみに、文字列リストに色々な国の言語が混在している場合に、
どの国の人から見てもおかしくないように並べるってのは、
やっぱり無理ですよね？

826 ：デフォルトの名無しさん：2008/09/01(月) 03:00:02

並べる
ナルシスト
並列

はどう並べたいんだ?

827 ：デフォルトの名無しさん：2008/09/01(月) 03:37:46

>>825
無理です。例えばラテンアルファベットの中には
言語によって順番が変わるものもあるので。

きっちりやりたいならここが参考になるかも。
ttp://unicode.org/reports/tr10/

828 ：819：2008/09/02(火) 01:22:12

ですよね。CJKなんて考えたらどうやったって共存は無理だし。
>>827
まだあまり読めてないですが、なんか参考になりそうな感じなので検討してみます。
ありがとうございました。

829 ：デフォルトの名無しさん：2008/09/02(火) 07:58:21

共存しなければいい

830 ：819：2008/09/02(火) 08:30:57

まあ、CJKについてはまだ対応しなくていいんだけど、
とりあえず、欧州系は共存必須なんですよね。頭痛い。

831 ：デフォルトの名無しさん：2008/09/02(火) 10:34:36

ICU4Cとかは使えないの?

832 ：デフォルトの名無しさん：2008/09/02(火) 20:01:14

日本語UNICODEソート順、みたいな話になってるのは、
たしかSQL Serverだっけか？

833 ：デフォルトの名無しさん：2008/09/03(水) 07:32:04

>>830
　　　　*　　　　　　*
　　＊　　ムリです　　＋
　　　 n ∧＿∧　n
　＋　(ﾖ（* ´∀｀）E)
　　　 Y 　　　 Y　　　　＊

って言っちゃいなYO!

834 ：デフォルトの名無しさん：2008/09/03(水) 21:37:59

>>830
死ぬお、、

835 ：819：2008/09/04(木) 01:40:40

どーーー考えても、完全な共存は無理ですよね。

システムに言語モードでも設けて、ユーザが選んだ言語のロケールで
並べるっていう方法で誤魔化せるかな？

836 ：デフォルトの名無しさん：2008/09/04(木) 06:43:38

http://technet.microsoft.com/ja-jp/library/ms143508.aspx

837 ：デフォルトの名無しさん：2008/09/04(木) 08:17:57

>>835
ごまかすって言うか、それが普通じゃない

838 ：デフォルトの名無しさん：2008/09/04(木) 21:07:55

文字コードについて勉強したいのですが、おすすめの本などありませんか？

すれ違いだったらすみません

839 ：デフォルトの名無しさん：2008/09/05(金) 00:19:46

>>838

ちょっと古いし高いけどオライリーのハリセンボンが表紙のやつとか。

ttp://www.oreilly.co.jp/books/4873111080/

あとはこれとか
『文字符号の歴史－欧米と日本編－』
ttp://www.kyoritsu-pub.co.jp/shinkan/shin0602_02.html
文字符号の歴史－アジア編－
ttp://www.cbook24.com/shop/productdetail.aspx?sku=432012040X

840 ：デフォルトの名無しさん：2008/09/05(金) 08:34:38

>>839

おお～ありがとうございます！
ハリセンボンのやつかなりいいお値段ですね・・・
そんだけ中身がいいのかなー

検討してみます。ありがとうございました。

841 ：デフォルトの名無しさん：2008/09/05(金) 09:22:17

ハリセンボンはやめたほうが良いよ。

ここに常駐している連中は皆持っているだろうし、内容は良いと思うが、
残念ながら出版年が古い。
もし著者に聞いても同じことを言うだろう。

今年中に改訂版が出るから、買うならそちら。

842 ：デフォルトの名無しさん：2008/09/05(金) 10:01:18

また「日本語版マダー」の日々が来るのか...

843 ：デフォルトの名無しさん：2008/09/05(金) 12:31:48

>>841

改訂の予定があるとは知らなかった
情報をありがとう。

更に厚くなるのかな(笑)
分冊か

844 ：デフォルトの名無しさん：2008/09/05(金) 21:50:22

ラトルズの本：文字コード「超」研究
ttp://www.rutles.net/books/051.html

845 ：デフォルトの名無しさん：2008/09/05(金) 23:41:47

>>844
持ってるし、かなり参考になったが、これだけは言っておく。

誤植多すぎ。正誤表に載ってないのもまだあるぞ。

846 ：デフォルトの名無しさん：2008/09/06(土) 00:03:07

ワシの誤植は百八まであるぞ

847 ：839：2008/09/06(土) 00:33:12

で、>>838は何を読めばいいんだい?
満点は無理としても相対的に一番ましなのは何?

848 ：デフォルトの名無しさん：2008/09/06(土) 01:55:43

あんたの挙げた残りの本でも何でも良いじゃないか。

>>838のような質問をする人間が、1万5000円も出した本に
「第三第四水準」のお話がどこにも書いてないことがわかったら
騙されたとしか思えんだろうよ。

849 ：デフォルトの名無しさん：2008/09/06(土) 03:22:39

便乗して聞きたいんだけど、本じゃなくてサイトはありますか？
できれば最新情報をキャッチアップしてるやつ

850 ：デフォルトの名無しさん：2008/09/06(土) 17:59:51

788で人工無能スレへ逝ってきたとしあきだが、別に蒸し返すつもりはないのだが、
こんな物を上げてみる→正規化した後のレンダリングの悪い例。
http://aikofan.dee.cc/aikoup1/src/f1060.png
（原因はわかりきっているが、対処不能だ）
話に乗って聞いてみるが（別に意味はない）、
誰か、文字集合と言語指定の一対一の対応ができるモンは見たことないよな？
>>819　タイ語＋英語の高速文字ソートだけで論文が出せるぐらいだ、あきらめるか
ソート部を外部プラグインにでもして、後で必要に応じて対応しろ。

851 ：デフォルトの名無しさん：2008/09/10(水) 19:42:33

>>850は人工無能が組み上げた文章なの？

852 ：デフォルトの名無しさん：2008/09/11(木) 09:51:31

「警官の髭は半分建設中」を思い出した。

853 ：デフォルトの名無しさん：2008/09/18(木) 08:52:39

MAPPING表で、ISO-8859-?からUnicodeに1対1変換したものは、可逆的に1対1で元のコードに戻るとして。
最初から、欧州系パソコンで入力されたテキストって、MAPPING表でISO-8859-?系に
1対1で変換出来るものなのかな？たぶん入力に使ったソフトに拠るような気がするけど。

どういうことかと言うと、結合文字とか、正規分解？というのが有るみたいなんだけど、
UnicodeテキストをISO-8859-?に変換するにはどうすればいいのかな、ということなんだが。
ライブラリを使うのも手なんだが、簡単に変換出来るなら自力で実装したいんで。

854 ：デフォルトの名無しさん：2008/09/18(木) 22:43:01

>>853
>ライブラリを使う

855 ：デフォルトの名無しさん：2008/09/18(木) 23:39:56

ウンコードは互換性なんて全く考えてないから、素直にライブラリ使えばいいよ

856 ：853：2008/09/19(金) 01:22:01

やっぱり、そうなんだ。
分かった、ありがとう。

857 ：デフォルトの名無しさん：2008/09/20(土) 02:14:25

正規合成の結果って、ロケールによって変わったりする？

858 ：デフォルトの名無しさん：2008/09/20(土) 08:37:12

しない

859 ：デフォルトの名無しさん：2008/10/02(木) 16:00:18

皆さんはどのように文字エンデコードを学ばれたのでしょうか？

860 ：デフォルトの名無しさん：2008/10/02(木) 21:03:44

お母さんに教わりましたけど

861 ：デフォルトの名無しさん：2008/10/02(木) 23:39:53

去年亡くなったばーちゃんの遺言書に書いてあった。

862 ：デフォルトの名無しさん：2008/10/03(金) 00:37:22

首を吊りながら槍に刺されて九日九夜経った時ひらめきますた。

863 ：youto：2008/10/03(金) 01:08:19

a......+...n=1n+a...............................sigma.........................
.................../雲の流れる様子のソフト/
................#.............#............dotdotdotdotdot
begin
clear
end#ecs#...ENTERzonedclick,UNIBAC####OS2......dotdotdot
begin
..............dotdotdot
...............#dotdotdotdot

/modeprienfathis:mode2BASICyoutoSyntacsErrmode2clear
/Sysntacs all clear/

864 ：デフォルトの名無しさん：2008/10/03(金) 23:10:11

>>862
オーディンだと思い出すのに数十秒かかった

865 ：デフォルトの名無しさん：2008/10/09(木) 03:24:57

いつの間にかUnicode Consortiumのメンバ一覧から
JustSystemが消えて、日本の企業0になってる。

866 ：デフォルトの名無しさん：2008/10/16(木) 22:26:47

http://www.unicode.org/reports/tr37/tr37-4.html
まあ現状追認のためにはそうするしかないだろうけど
http://d.hatena.ne.jp/NAOI/20080718
あとこの20字をIVSにねじ込んで独立した符号位置の追加提案なしで済ませたいんだろうけど
ますますカオスに…

867 ：デフォルトの名無しさん：2008/10/17(金) 20:09:56

http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499Cover.doc
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P01-20.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P21-40.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P41-60.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P61-66.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499Mapping.txt
互換漢字2,621字の追加提案
日本NBはIVSと全面戦争する気満々ですねｗ

868 ：デフォルトの名無しさん：2008/10/17(金) 21:47:50

平仮名のヤ行のえ(HIRAGANA LETTER YE)と片仮名の元々のア行のエ(KATAKANA LETTER ORIGINAL E)のUnicodeへの追加が提案されてた。

869 ：デフォルトの名無しさん：2008/10/18(土) 13:23:43

それよりも　変体仮名のし「志」こ・「古」、いくつかの合字（「こと」など）を追加して欲しい

870 ：デフォルトの名無しさん：2008/10/18(土) 21:58:43

また変な文字が追加されてサニタイズが面倒になるのか

871 ：デフォルトの名無しさん：2008/10/19(日) 00:03:23

昔はア行のエとヤ行のエは区別されてて
ア行のエは平仮名は現在の「え」と同じ、片仮名は「ラ」の横棒を丶に変えたような字
ヤ行のエは片仮名は現在の「エ」と同じ、平仮名は「に」を続けて書いたような字だったらしい。
これらはゐゑヰヱよりも遥か前に廃れてしまったんだってさ。

872 ：デフォルトの名無しさん：2008/10/19(日) 02:02:02

じゅうきかなw

873 ：デフォルトの名無しさん：2008/10/19(日) 06:25:41

住基仮名って検索してもwikipediaの孫引きみたいな記事ばっかりなんだよな。
しかもそのwikipediaには出典書いてないし。

874 ：デフォルトの名無しさん：2008/10/21(火) 00:18:54

http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3529.doc
やっとかよ。
拡張組も一緒に提案してくれ。
CONTEMPORARY LITHUANIAN LETTERSはUSIと一緒に提案されてたんだから。

875 ：デフォルトの名無しさん：2008/10/21(火) 01:07:46

>>867
なんだこりゃ。
なぜIVSに統合せずにcompatibility ideographs?

876 ：デフォルトの名無しさん：2008/10/21(火) 06:28:09

>>875
http://slashdot.jp/~yasuoka/journal/451203
こういうことらしい。個人名は出てないけど安岡センセイが関わってることは確実だろうし。
率直に言って安岡センセイが何言ってるのかわけわかりませんが、つーか言いがかり
としか思えないが。
一番恐れているのは

互換漢字を提案 ← 今ここ
↓
当然ながら却下される
↓
安岡センセイがへそを曲げて、提出そのものを取り下げる(もちろんIVSに再提出などしない)
日記でくだを巻く

というパターン。そうなったらAdobeがこれらをAdobe Japan1-7に収録でもしてくれないと
絶望的。

877 ：デフォルトの名無しさん：2008/10/21(火) 07:02:49

>>869
「こと」の合字ってU+30FFじゃなくて?
「住基で必要」という理由で互換漢字の追加提案するなら同様の理由で変体仮名が来ても
おかしくはないな

878 ：デフォルトの名無しさん：2008/10/21(火) 07:34:49

>>876
お前がやれ > 再提出

879 ：869：2008/10/21(火) 10:44:46

>>877
> >>869
> 「こと」の合字ってU+30FFじゃなくて?
それとは別にひらがな版がある。

880 ：デフォルトの名無しさん：2008/10/22(水) 00:18:00

　､_
　と

みたいな

881 ：デフォルトの名無しさん：2008/10/22(水) 10:42:49

住基仮名はTRONに入っている
ttp://www2.tron.org/set10.html
なぜか ttp://www2.tron.org/repertoire.html には無いが（さぼってんのか？）
つつけば連中が何を典拠にしたか出てくるんじゃね？

882 ：デフォルトの名無しさん：2008/10/24(金) 18:33:53

SJISとUNICODEの判別はどのようにすればいいですか？

883 ：デフォルトの名無しさん：2008/10/24(金) 20:39:20

BOM。
無ければ、統計判断。

884 ：デフォルトの名無しさん：2008/10/24(金) 20:43:41

utf-8だけなのか、utf-16も含むかでずいぶん違う。

885 ：デフォルトの名無しさん：2008/10/24(金) 21:34:38

http://tricklib.com/cxx/ex/babel/babel.cpp の analyze_base_encoding() って関数で
文字コードの判別やってるからよかったら参考にしてくれ。

やってることは >>883 に上がってるように BOM や統計判断、それから 0x00 の
出現の有無およびその位置なんかを手掛かりに判断してます。
あと、どうしてもわからない場合は、奥の手で渡されたテキストが HTML か
なにかであると仮定し、どこかに文字エンコードの指定がずばり記述されてないか
探したりといったインチキなことまでやってます。

886 ：デフォルトの名無しさん：2008/10/25(土) 21:54:10

日本語テキストであれば糸偏の漢字の出現率で意外と判断できそうな気がした

887 ：デフォルトの名無しさん：2008/10/27(月) 02:47:21

>>881
什器台帳のかなはひでーな。
あれはもはや文字ですらないよ。
なんであんなもんに貴重な番号を振ってるんだか・・・

888 ：デフォルトの名無しさん：2008/10/27(月) 03:05:47

>>867
漢字にも方言がいっぱいあるんですねえ・・・
方言に独自の番号を振ると日本語は崩壊します。

889 ：デフォルトの名無しさん：2008/10/27(月) 03:12:11

中国なんて毎日新しい漢字が生まれているのに

890 ：デフォルトの名無しさん：2008/11/02(日) 04:18:44

こうなったら漢字は全部組み立て文字にするしか…

891 ：デフォルトの名無しさん：2008/11/02(日) 08:32:58

このプログラムをコンパイルすると、

#include<stdio.h>
#include<stdlib.h>
#include<locale.h>
int main() {
　　char ch[] = "Kitty on your lap";
　　wchar_t wch[] = L"Kitty on your lap";
　　setlocale(LC_ALL, "");

　　printf("char 型文字列 = %d¥n%s¥n" , sizeof ch,ch);
　　printf("wchar_t 型文字列 = %d¥n%s¥n" , sizeof wch,wch);
　　return 0;
}

char 型文字列 = 18
Kitty on your lap
wchar_t 型文字列 = 72

という実行結果が得られるんですが、
うまくwchar_t型のKitty on your lapを出力するには
どうすれば良いのでしょうか?

892 ：デフォルトの名無しさん：2008/11/02(日) 09:37:45

>891
ます環境を書いて質問する。

893 ：デフォルトの名無しさん：2008/11/02(日) 09:59:55

うお、すいません。
なんか試行錯誤しているうちに、いろいろまざってしまいました。
私はC言語の本を一冊読み終えた程度の初心者で、
初めて日本語を扱うプログラムを書いてみようと思いトライしている最中です。
環境はhp-uxです。
ロカールはLANG=ja_JP.utf8です。
gccは
Using built-in specs.
Target: hppa2.0w-hp-hpux11.11
gcc バージョン 4.2.3
です。
まず最初に、サンプルコードの通り、
#include <stdio.h>
#include <stddef.h>
#include <locale.h>
#include <wchar.h>
int main()
{
wchar_t *nihon = L"あいう";
setlocale(LC_ALL,"");
wprintf(L"%s\n", nihon);
return 0;
}
とやりましたが、コンパイルに成功しても、表示されませんでした。
そこで、いろいろ調べていると、
wprintf(L"%ls\n", nihon);や
printf("%ls\n", nihon);
とやると成功することがわかりました。
わからないところは、なぜ、本に書いて有るとおりに
プログラムを書いても表示されなくて、
フォーマットに%lsを指定すると成功したのでしょうか?ということです。

894 ：デフォルトの名無しさん：2008/11/02(日) 10:01:37

>>891
%ls

895 ：デフォルトの名無しさん：2008/11/02(日) 10:37:48

>>893
その本が間違っているからでは？

896 ：デフォルトの名無しさん：2008/11/02(日) 12:09:07

間違いが存在してるとは思えませんね。

897 ：デフォルトの名無しさん：2008/11/02(日) 12:20:32

>>893
規格すら読まずに書かれている糞本の名前を晒せ。

http://docs.hp.com/ja/B2355-60128/index.html
すら読まんお前もどうかと思うが。

898 ：デフォルトの名無しさん：2008/11/02(日) 12:43:17

明らかにスレ違いだろうが。
スレッドの趣旨もわからないような池沼ならどんなばかげたことをやっていても不思議はない。

899 ：デフォルトの名無しさん：2008/11/02(日) 21:12:19

>>876
＞当然ながら却下される

却下されなかった(JTC1/SC2/WG2/N3554R)
N3530はN3525と抱き合わせで議論されることが決まった
つまり互換漢字でありながら同時にIVSも振られる

900 ：デフォルトの名無しさん：2008/11/02(日) 22:48:07

かどうかはまだ分からない。
現時点ではIRGと全NBと全liaisonに意見を求めただけ。

901 ：デフォルトの名無しさん：2008/11/03(月) 08:42:25

とりあえずIVSでいいから統一しろと。

902 ：デフォルトの名無しさん：2008/11/06(木) 00:41:38

Windows 7 Build 6801では日本語フォントにIVSは含まれてないし
UniscribeもIVSに対応してなかった(´・ω・`)
まあVistaのときも最初のベータではメイリオがJIS2004字形じゃなかったりしたから
今後に期待か。
# IVS対応はDirectWriteのみとかだったらやだな

903 ：デフォルトの名無しさん：2008/11/06(木) 00:49:53

却下というと門前払いみたいに読めるのがまずかったか。
議論の末採用は見送られるだろJKと思ってるわけだが

904 ：デフォルトの名無しさん：2008/11/06(木) 01:28:59

>>902
というか、IVS対応など、特に日本語環境での希望事項は、今のうちに
DirectWriteやWindows 7のチームにWish出しまくったほうがいい。

905 ：デフォルトの名無しさん：2008/11/06(木) 12:32:57

wchar_t型でUTF-16を保持しているとして、これをSJISに変換した場合保持するバッファの型はchar型でよいのでしょうか？

906 ：デフォルトの名無しさん：2008/11/06(木) 12:47:07

mbs=multi byte stringって奴だね。

←→wcs=wide character string

907 ：デフォルトの名無しさん：2008/11/06(木) 12:50:34

>>905 いい

908 ：デフォルトの名無しさん：2008/11/06(木) 13:36:51

>>907
文字列の特定の部分のみ変換する場合はどうすればよいでしょうか？

909 ：デフォルトの名無しさん：2008/11/06(木) 14:25:14

何使うの?
iconv(3)なら変換するサイズ指定できるが。

910 ：デフォルトの名無しさん：2008/11/06(木) 16:43:02

>>903
一般的に「却下」は門前払い、審理を行なった上で退けるのは「棄却」やね。

911 ：デフォルトの名無しさん：2008/11/06(木) 18:22:53

それ裁判用語なだけやろ

912 ：デフォルトの名無しさん：2008/11/06(木) 22:04:14

>>911
広辞苑
明鏡

913 ：デフォルトの名無しさん：2008/11/07(金) 20:53:43

ISO-2022-JPの文字コード判定でJIS X 0208 1990のESC & @ ESC $ Bは何を表しているのですか？

914 ：デフォルトの名無しさん：2008/11/07(金) 23:02:11

&はIRRです。
直後に支持する文字集合の改訂番号指定です。

915 ：デフォルトの名無しさん：2008/11/08(土) 00:17:10

>>914
ようやくわかりました。ありがとうございます。

916 ：デフォルトの名無しさん：2008/11/08(土) 08:15:40

RFC 1468 に ESC & @ ってシーケンスあったっけ？

917 ：デフォルトの名無しさん：2008/11/08(土) 08:40:31

ないです。
ただFormal Syntaxで定義されてないのにも関わらず、

The JIS X 0208 standard was revised in 1990, to add two characters at
the end of the table. Although ISO 2022 specifies special additional
escape sequences to indicate the use of revised character sets, it is
suggested here not to make use of this special escape sequence in
ISO-2022-JP text, even if the two characters added to JIS X 0208 in
1990 are used.

とBackground Informationでは「ここでは推奨しない」と微妙な表現w
「使えないことにした」と書けば良かったのに。

918 ：デフォルトの名無しさん：2008/11/08(土) 12:39:52

WIndows XP　C++
上の環境でSJIS、JIS、EUC、UNICODE(UTF-16)、UTF-7、UTF-8など
文字コードを判別する方法を教えてくだしあ

919 ：デフォルトの名無しさん：2008/11/08(土) 12:47:03

文章の先頭から並列的に（マルチスレッド化するわけではない）
それらの文字コードとして成り立っているかどうかをチェックし、
最後まで残ったものが候補。
候補が複数残った場合は判別失敗。
候補が残らなかった場合はその他の文字コード、もしくはバイナリ。
候補が１つ残った場合はその文字コードかバイナリ。
バイナリかどうかチェックするため、候補が１つに絞られても
一定バイト数チェックはした方がいい。

920 ：デフォルトの名無しさん：2008/11/08(土) 13:48:41

要するに地味にやれって事です

921 ：デフォルトの名無しさん：2008/11/08(土) 14:16:47

>>918
>>885

922 ：デフォルトの名無しさん：2008/11/16(日) 02:06:02

1. なんかのライブラリを使う。
2. 公開されているソースコードを流用する。

923 ：デフォルトの名無しさん：2008/11/16(日) 04:31:26

>>922
>>918は
1. どのライブラリを使えばいいか。
2. どこに流用できるソースコードが公開されてるか。
を聞いてるんだろ
そんな無意味なレスして、馬鹿なの？

924 ：デフォルトの名無しさん：2008/11/16(日) 09:38:34

1. mlang, iconv, ICU
mlang http://msdn.microsoft.com/ja-jp/library/aa767865(en-us).aspx
iconv http://www.gnu.org/software/libiconv/
ICU http://www.icu-project.org/

2. iconv, ICU のソース
文字コード判別が出来てオープンソースのテキストエディタを探す
　 >>885

925 ：デフォルトの名無しさん：2008/11/16(日) 16:56:52

>>923
お前こそちゃんと文章を読め。
1,2って番号ついてるだろ。自分で判別処理書くより、なるべく
ライブラリを使った方が早いってこと。

だいたいそう思うだったら、お前が紹介すればいいじゃんか。
どうせ文句ばっかつけて何も知らないんだろ。

馬鹿はお前だ。

926 ：デフォルトの名無しさん：2008/11/16(日) 17:24:41

>>925
だからどんだけ馬鹿なの？
>>918の書き方を見て、>>918が自分で判別コード書きたいって言ってるようにしか見えないんだ？
何でそんな馬鹿に育っちゃったの？ねぇ、なんで？

927 ：デフォルトの名無しさん：2008/11/16(日) 18:21:57

>>926

>>918が自分で判別コード書きたいと言っているように見えたとは
言ってないだろ。
>>918の質問に対して自分で判別コード書く場合のレスが続いたから
それよりもライブラリを使った方が早いって言ったんじゃんか。

928 ：デフォルトの名無しさん：2008/11/16(日) 18:42:05

>>927
だーかーらーライブラリ使ったほうが早いなんて常識だろ
自明だっつってんの

929 ：デフォルトの名無しさん：2008/11/16(日) 19:49:52

>>928
だから、
それなのに自分で判別コード書くレスしかないんで、
ライブラリの方に話をもってこようとして書いたんだよ。

でも、お前と違って、ちゃんと回答している人に対して
あんまり否定的な言い方したら、失礼かなって思って、
わざと分からないように書いたの。
お前にむかついて、書いちゃったんで、もう意味ないけど。

930 ：デフォルトの名無しさん：2008/11/16(日) 21:02:08

ちゃんと解答してる921は無視か
失礼な奴だな

931 ：デフォルトの名無しさん：2008/11/16(日) 21:54:44

921もbabelのソースコードを参考にするって話で、
ライブラリは使ってないだろ。

932 ：デフォルトの名無しさん：2008/11/17(月) 13:58:54

babelとICUどっちがいいの？

933 ：デフォルトの名無しさん：2008/11/18(火) 02:56:15

babelは使ったことないのでわかんないけど、
ICUは文字コード変換というより、国際化全般向けのライブラリ。
日本語対応の正規表現とか使えるようになるのが利点じゃないか
と思う。
ただ、文字コード変換とかだけに使うなら、ちょっと大物すぎる
かな。

934 ：デフォルトの名無しさん：2008/11/18(火) 11:17:02

文字にまつわる処理を概観するのにはいいよ。
ICUのAPIを調べるのは。
真面目にやり出すときりがないって事が分かる。

935 ：デフォルトの名無しさん：2008/11/18(火) 11:49:14

結局10日もかけて実用レベルの答えが出てない

936 ：デフォルトの名無しさん：2008/11/18(火) 11:51:12

みんな普通にできることを>>918がわからないのがおかしいだろ
バカにいちいち付き合ってられん

937 ：デフォルトの名無しさん：2008/11/18(火) 11:56:27

顔真っ赤な即レスわろた

938 ：デフォルトの名無しさん：2008/11/18(火) 12:22:33

顔真っ赤とか妄想してる即レスに爆笑

939 ：デフォルトの名無しさん：2008/11/18(火) 12:59:03

ガキの喧嘩か

940 ：デフォルトの名無しさん：2008/11/19(水) 14:25:08

>>876
安岡センセイ、JTC1/SC2/WG2/N3530に御不満らしい
http://slashdot.jp/~yasuoka/journal/458659

941 ：デフォルトの名無しさん：2008/11/19(水) 14:50:09

unicodeで統一しろ

942 ：デフォルトの名無しさん：2008/11/19(水) 15:58:59

HTMLからタイトルを抜き出してそのタイトル名でファルダを作りたいけど
: (コロン)とかはフォルダ名につかえないけど
どうやって代用しようか？

D:\tool\53: ■ ＨＵＮＴＥＲｘＨＵＮＴ
D:\tool\゜・:,。*:テニスの王子様..。o○
とか

943 ：941：2008/11/19(水) 16:00:29

OSはWindowsXPです

944 ：デフォルトの名無しさん：2008/11/19(水) 16:25:11

>>942
つ URLエンコードに準ずる

945 ：デフォルトの名無しさん：2008/11/19(水) 20:10:34

>>944
どゆこと？

946 ：デフォルトの名無しさん：2008/11/19(水) 20:18:16

文字→整数列と見なす→それぞれ文字列表現
じゃないかね。
@なら%40とか。

まぁbase64とかpunycodeとか他にもやり方あるし、好きなの使えば？
…てかそもそもエスケープ出来ないんだっけ？

947 ：デフォルトの名無しさん：2008/11/19(水) 21:00:38

エスケープすると今度はファイル長制限にひっかかるかも。
(エスケープしなくてもそうなる可能性はあるが)

948 ：デフォルトの名無しさん：2008/11/19(水) 23:11:37

可逆である必要性が無いんなら、可読性も落ちないし全角文字に変換しとけ。

949 ：デフォルトの名無しさん：2008/11/19(水) 23:22:02

そこでファイル名重複ですよ。

950 ：デフォルトの名無しさん：2008/11/20(木) 05:45:54

sha1のハッシュを付けてそれをキーにして本当の名前を検索できるdbを作る

951 ：デフォルトの名無しさん：2008/11/20(木) 05:54:49

ここ質問スレじゃない、と言われるかもしれないけど。

うちの会社の連中、ファイル名とかフォルダ名に⑲とか⑳とか、算用数字を
丸で囲んだ文字をけっこう使ってる人が多いのね。19年度とか、20年度とかを
表すために。例えば　⑲東京支店決算詳細.xlsとか。
で、21とか、22とかの算用数字を丸で囲んだ文字は、用意されていない、と。

たいていの人は、文字変換しようとして、字が用意されていないことに
気づいて、（いったんは憤る人もいるかもしれないけど）諦めると思う。
(21)東京支店決算詳細.xlsとか、いくらでも表現のしようはあるから。

ただ、誰かが外字エディタでも使って、フォントを作って、ShiftJIS
（別な文字コードでもいいけど）のどこかの空いているコードにマッピングして…
しまいにはそれをファイル名やフォルダ名に使い出したときの影響、って

そういう字をインストールしていないWindowsパソコンから見たときに
・東京支店決算詳細.xlsのように、文字化けする、ってだけなのかしら。
そういう創作された字を含んだファイルとか扱ってるうちに、
Windowsエクスプローラとか、壊れたりしないのかしら。

952 ：デフォルトの名無しさん：2008/11/20(木) 07:01:39

さようなら

953 ：デフォルトの名無しさん：2008/11/20(木) 07:12:09

エクスプローラは壊れないが、>>951が壊れかけてる。

954 ：デフォルトの名無しさん：2008/11/20(木) 07:14:13

>>951
Unicodeには丸50まであるし、CIDフォントには丸100までのグリフが入ってる。

955 ：デフォルトの名無しさん：2008/11/20(木) 07:15:36

>>951
全てを忘れてとりあえず寝ろ
話はそれからだ

956 ：デフォルトの名無しさん：2008/11/20(木) 07:30:11

>>954
元はJIS X 0213な。
CIDはAdobe-Japan1-4のやつな。

957 ：デフォルトの名無しさん：2008/11/20(木) 07:35:03

俺様愛用のぱうフォントにも入ってるかな？

958 ：デフォルトの名無しさん：2008/11/27(木) 20:17:28

携帯絵文字をユニコードに入れるんだって
http://sites.google.com/site/unicodesymbols/Home/emoji-symbols

959 ：デフォルトの名無しさん：2008/11/27(木) 23:29:49

BA-90とBA-88を先に入れてくれ！
いやまじで。

960 ：デフォルトの名無しさん：2008/11/27(木) 23:35:50

毎日のごとく仕様がでてくるけど
実際組み込まれるのはいつの話だよってことだ

961 ：デフォルトの名無しさん：2008/11/28(金) 00:12:08

携帯絵文字Unicodeに追加するならBMP外かな。
U+2600～U+27FFあたりに似たようなものがある絵文字はそれと統合するべきだな。
あと確か俺の使ってるソフトバンクの携帯には色の違うハートマークがあったな。
これらは色が違うだけだがそういうのはどうするんだ?Unicodeでは色の指定は無いはずだが。

962 ：デフォルトの名無しさん：2008/11/28(金) 10:26:43

先に使っちゃって他の国の文字はどうするんだろうねぇ
まぁ、縁がないからどうでもいいですけど

963 ：デフォルトの名無しさん：2008/11/28(金) 12:47:50

ところでケータイのUnicode対応度って実際どうよ？
エンコーディングがUTF-8で文字集合が0208のウェブページなら
見られなくもないとかそういうレベルだよな。iモードとかは。

964 ：デフォルトの名無しさん：2008/11/28(金) 17:36:56

ウンコマークもUnicodeに追加されるんだな。

965 ：デフォルトの名無しさん：2008/11/28(金) 18:57:10

WindowsXP でフォルダに使用できないフォルダ名は
どうやって判定するのでしょうか？

966 ：デフォルトの名無しさん：2008/11/29(土) 03:42:18

>>965
ちょっとアホな方法だけど、%TEMP% フォルダの下で実際に作ってみて、
本当に作成できるかどうかで判断するのが一番確実。

967 ：デフォルトの名無しさん：2008/11/29(土) 04:55:27

>>966
いやいや、それが一番賢い方法だよ、残念な事に
アクセス権でファイルが実際に作れるかとか、名前制限とかは実際作るのが一番手っ取り早く確実
それ以外の手段は、100倍のコストをかけても結局不確かな物でしかないからな

968 ：デフォルトの名無しさん：2008/11/29(土) 07:19:55

ドキュメント読めよ、うんこども

969 ：デフォルトの名無しさん：2008/11/29(土) 07:37:39

話題を知っているだけで
具体的な話になるとな～んにも答えられないんですね

970 ：デフォルトの名無しさん：2008/11/29(土) 07:38:42

>>968
どこのドキュメントか示されないと読みようがない

971 ：デフォルトの名無しさん：2008/11/29(土) 09:11:46

>>968
というか、お前こそドキュメント読んでないだろ。

そのへんはドライブのフォーマットなんかにも依存する話だから、
厳密には個々の環境に依存する話になっちゃうから
アンドキュメントな領域なんだよ。

972 ：デフォルトの名無しさん：2008/11/29(土) 09:18:00

Driveオブジェクトにファイルシステム種別が書いてあるんじゃね？
その辺は%TEMP%じゃしょうがねえしな。
http://www.ipa.go.jp/security/awareness/vendor/programming/b08_01_main.html
あたりもイヤらしいが、そもそも板違いだろ。> Windows

973 ：デフォルトの名無しさん：2008/11/29(土) 10:37:21

文字コード関係なさそうだしな。

974 ：デフォルトの名無しさん：2008/11/29(土) 13:24:39

自治房乙

975 ：デフォルトの名無しさん：2008/11/29(土) 19:59:23

ドキュメント読んだ事があるから実際作るなりして試すのがベストプラクティスだって判るんだろうが
あれらのドキュメント読んで全うに実装はじめようと考えたなら、今すぐ他業種に行け公害野郎

976 ：デフォルトの名無しさん：2008/11/29(土) 20:24:25

有効なパスの判定なんて正規表現で判定出来ると考えてた時期が
私にもありました

977 ：デフォルトの名無しさん：2008/11/29(土) 21:37:57

ファイルからテキストを読み込み文字コード変換する場合は、
変換元バッファと変換先バッファのサイズをどのくらいにして変換すべきですか？

978 ：デフォルトの名無しさん：2008/11/29(土) 21:39:37

512byte