5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

文字コード総合スレ part5

1 :デフォルトの名無しさん:2009/03/09(月) 01:26:03
プログラマーなら一度は煩わされたことのある文字コードについてのスレです。
ShiftJIS、JIS、EUC、Uincode、 UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/

2 :デフォルトの名無しさん:2009/03/09(月) 01:27:06
■参考サイト
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
IANA: Character Sets
http://www.iana.org/assignments/character-sets
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
CP50220
森山さんの説明
http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-March/000002.html
JISX4061
日本語文字列照合順番
http://www.jisc.go.jp/

3 :デフォルトの名無しさん:2009/03/09(月) 01:28:20
漢字袋
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/
池田証寿
http://homepage3.nifty.com/shikeda/zatsubun.htm
SJIS2004とかJISX213系の文字コード表
http://x0213.org/codetable/
※JISCの奴は無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
Windowsで扱える文字一覧(コードページ毎で良ければ)
http://www.microsoft.com/globaldev/reference/cphome.mspx
docomoの携帯コンテンツ制作者向け文字コード情報
http://www.nttdocomo.co.jp/service/imode/make/
auの携帯コンテンツ制作者向け文字コード情報
http://www.au.kddi.com/ezfactory/
SoftBank携帯コンテンツ制作者向け文字コード情報
http://creation.mb.softbank.jp/
漢字データベース
http://kanji-database.sourceforge.net/index.html


4 :デフォルトの名無しさん:2009/03/09(月) 01:29:08
■これまでに行われた議論
・WinでCP50220 は Unicode からマルチバイト文字への変換でいわゆる半角カタカナを全角カタカナに置き換え
 内部的には Unicode -> CP932 -> CP5022x って変換な気もする
・人名をソートかけたらバストサイズ順の並びになる?
・Shift JIS や EUC-JP や Big5 や GB なんかをUnicode に変換してしまうと、ラウンドトリップは保証されるか
・単一情報をソースの文字コード(or 言語)情報なしに元に戻したい (統計的に文字の出現確率なんかを調べる)
・PC-98x1シリーズのMS-DOSはShift_JISだが漢字ROMはJIS、変換は何処で行っていた?
・0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、逆変換時に結果が変わるの問題
・丸付き数字は機種依存文字か?。MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
 Macではフォントによっては表示されないし、フォントによっては表示される
・Shift_JISと名乗っているCP932やISO-2022-JPと名乗っているCP50220を表示(Unicodeに変換)する際に
 機種依存文字はサポートされるか?
・Safari文字コード変換のバグは
・Microsoft文字コード変換のバグは
・U+31F0..U+31FF(アイヌ語表記用小書きカタカナ)が入ってない件
・なぜ携帯業界はunicode化しないのか?
・このスレへの書き込みはブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換しているのか
・文字化けに強いishフォーマットでエロ画像を交換する場合、ssより、s7のほうが化けにくい

5 :デフォルトの名無しさん:2009/03/09(月) 01:30:45
・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(U+6076)」に統一。口偏+恶(U+6076)は普通に使われているがUnicodeにはない
・日本人のニーズが満たせないのも確かなので原規格分離(中国では「曾→曽」は簡体字と繁体字の違いとはみなされていないとか)
・UNICODEを扱うプログラムはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろって→YES
・UnicodeとUTF-8の違いは?
・日本のCJK Ext.D Submissionに{魚針}が含まれてる件
 U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
 ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。
 中国ではってレベルじゃねーぞ。
・Windows Vista での「IME パッド - 文字一覧」の「JIS X 0213 (1面)」のバグ
 UTF-16: 0x304B 0x309A → Unicode: U+FD61809A (間違い) (ISO/IEC10646はU+10FFFFまで)
 サロゲートペアからコードポイントを引き出す計算を無理やり適用(間違い)
 ((0x304B - 0xD800) << 10) + (0x309A - 0xDC00) + 0x10000が 0xFD61809A になる。
・文字コードではインドカレーは飲み物か否か。カレーパンうまうま。
・CJK混在の漢字環境ってどうやって、切り分ければいいの? → ムリです。
・Winzipで保存されるファイル名が文字化け→zipではコードページ情報が無い。直接zipファイルから切り出せ
・Unicodeは言語情報を直接扱わない。 多言語の混在表現は(unicodeでは)できないか
・Unicode文字列リストを各国言語を考慮してソートしたいんですが → ムリです。
・Unicodeサニタイズが面倒になるのか
・SJISとUNICODEの判別はどのようにすればいいですか?BOM。無ければ、統計判断。 ライブラリを使うが吉
・ところでケータイのUnicode対応度って実際どうよ? → ウンコマークもUnicodeに追加されるんだな。
・WindowsXP で フォルダに使用できないフォルダ名はどうやって判定
  → ちょっとアホな方法だけど、%TEMP% フォルダの下で実際に作ってみて。本当に作成できるかどうかで判断。

6 :デフォルトの名無しさん:2009/03/09(月) 01:31:39
■ライブラリ
IBM Globalization - ICU
http://www-306.ibm.com/software/globalization/icu/
NKF32.DLL
http://www.vector.co.jp/soft/win95/util/se020949.html
http://www1.ttcn.ne.jp/~kaneto/dll/nkf32dll.html
バベル
http://tricklib.com/cxx/ex/babel/
バベルの文字コード判定で使ってる日本語文書内での各文字の出現頻度データです。
http://tricklib.com/cxx/ex/babel/scoremap.csv
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/


7 :デフォルトの名無しさん:2009/03/09(月) 11:23:37
RedHatで狽ェ文字化けする。

・(総和の)狽ノついて
cp932でRedHatに持ち込んで、iconvでutf-8に変換できるが表示が化ける。
iconvでeuc-jpには変換できない。
win端末上でeuc-jpとして保存した場合、cygwinのiconvで他のコードに変換できない。
→euc-jpとしては存在しない文字扱い?

・(ギリシャ文字の)Σについて
コード変換は問題ないが、viで開くと1カラム幅の文字と認識するようだ。

8 :デフォルトの名無しさん:2009/03/09(月) 11:45:17
1乙。ようやく立ったか。
しかし>>4-7みたいなのは、Wiki立てて
そこでまとめたほうがいいような気がするな。

9 :7:2009/03/09(月) 12:08:01
あーいや、>7は纏めじゃなくてちょっと気になったから書いたのだけど。
で、今確認したら(当たり前だけど)Σ以外のギリシャ文字も1カラム幅と認識している模様。
実際に使われているフォントは2カラム幅なのに……

10 :デフォルトの名無しさん:2009/03/09(月) 12:35:33
>>7
> →euc-jpとしては存在しない文字扱い?

JISにない。
JIS X 0208にGREEK CAPITAL LETTER SIGMAがあるから、
必要ないと判断された。

GREEK CAPITAL LETTER SIGMAはISO-8859-7にもある。
ただASCIIと違って、JIS X 0208と一緒に使う習慣はなかったから、
FULLWIDTH GREEK CAPITAL LETTER SIGMAというのはない。
LATIN LETTERSとちがって。

11 :7:2009/03/09(月) 12:44:22
>>10
なるほど、半ば呆れつつ納得。THX!

12 :デフォルトの名無しさん:2009/03/09(月) 16:46:00
>人名をソートかけたらバストサイズ順の並びになる?
よくこんなの引っ張り出してきたな

13 :1:2009/03/09(月) 20:15:43
( >>1->>6 の続き)
■単語一覧
・UTF-16は16ビット単位にエンコードするけど、サロゲートペアがある
 表現できる文字空間はUTF-8と同じく20ビットとちょっと
・丸付き数字は機種依存文字か?MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
 MacJapaneseではフォントによっては表示されないし、フォントによっては表示される。
今のMac(内部Unicodeアプリ)は、フォント依存ではなくアプリ依存。
似非ISO-2022-JPや似非Shift_JISのドキュメント中の丸付き数字は、
素直にAppleのAPIを使ってるアプリならゲタ(U+FFFD)になる。
・Mail.appではISO-2022-JPに収まらずCP932に収まるメールは、含まれる字種によって
 charset=CP932で送信される場合とISO-2022-JP(もどき)で送信される場合がある
・MSでのウニコードとSJIS変換のバグ。
 U+007E TILDE <-> Shift_JIS 0x7E OVERLINE
 U+301C WAVE DASH -> Shift_JIS NA 【MSの問題】
 U+FF5E FULLWIDTH TILDE <-> Shift_JIS 0x8160 WAVE DASH 【MSの問題】
・SafariでのウニコードとSJIS変換のバグ。
 U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
 U+301C WAVE DASH <-> Shift_JIS 0x8160 WAVE DASH
 U+FF5E FULLWIDTH TILDE <-> Shift_JIS NA
・winzipの規格ではファイル名のコードページ指定もしくは記録情報が存在しない。
 解決策:取り合えず、MSWin+JPではShift-jisでファイル自体には保存されている。
 MACOSX=Unicode,Unix=UTF/EUC/S-JISどれでもありえる。文字に関係なくLocalLangで
 再変換しているので、それをしなければよい。

14 :1:2009/03/09(月) 20:17:32
とりあえず纏めてみた。それでは、マッタリ行ってみよう。

15 :デフォルトの名無しさん:2009/03/09(月) 20:38:52
これ加えとくわ。
Google Standard Unicode Emoji Mapping
http://unicode.org/~mdavis/08080r-emoji-proposal/
Proposal for Encoding Emoji Symbols/N3582
http://unicode.org/~scherer/emoji4unicode/snapshot/emoji.pdf
Emoji Symbols: Background Data
http://unicode.org/~scherer/emoji4unicode/snapshot/full.html

16 :デフォルトの名無しさん:2009/03/10(火) 00:58:55
> References
> *http://en.wikipedia.org/wiki/Japanese_mobile_phone_culture
おいおい
まあファイストスの円盤文字もウィキペディア参照してたけど

つーかもうJTC1/SC2/WG2のサイトにも上がってるみたいなのに
WG2のページトップが更新されてねえ
なので直リンク
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3582.pdf
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3583.pdf

17 :デフォルトの名無しさん:2009/03/10(火) 01:10:32
絵文字とかHistoric Kana(今はKATAKANA LETTER ORIGINAL Eのみ)を含んだ
Amd.7のドラフト
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3580.pdf

18 :デフォルトの名無しさん:2009/03/10(火) 20:44:25
Last Resort Pictures (N3412) が含まれてないけど
あれはやっぱりエイプリルフールのジョークだったってことでいいのかな

19 :デフォルトの名無しさん:2009/03/11(水) 00:35:59
立ってたのか、>>1

20 :デフォルトの名無しさん:2009/03/11(水) 14:27:07
こんなFirefox拡張あるんだな。
Emacsのdescribe-charみたいなやつ。

Character Identifier
https://addons.mozilla.org/ja/firefox/addon/3929

21 :デフォルトの名無しさん:2009/03/11(水) 20:46:58
Ext.Dに「トキ」「トモ」の合字が提案されてるんだが、
Historic Kanaブロックができた以上そっちのほうに入れるべきじゃね?

ってコメントしたいんだけどどうすれば届くのかさっぱりわからん

22 :デフォルトの名無しさん:2009/03/11(水) 20:56:35
>>1
これはポニテでうんぬん

23 :デフォルトの名無しさん:2009/03/12(木) 06:15:19
国旗周りでUnicode listが爆裂してたせいか
国旗もEMOJI COMPATIBILITY CHARACTERみたいな謎の記号に置き換えられてるな

24 :デフォルトの名無しさん:2009/03/12(木) 07:05:23
つーかまたUnicode listが燃え上がってるな

25 :デフォルトの名無しさん:2009/03/13(金) 11:16:41
自分でフォント作って組み込めば無問題。
こわいものなし。

26 :デフォルトの名無しさん:2009/03/13(金) 20:04:47
Unicode-C初期UTF-8エンコードの規格覚えている奴まだ居るか判らないけど、
やはりあの時、言語学者の言うこと等聞かずに、国別にセクション割り当てて、VLEで通すべきだったな。
glyphが多ければ無制限に拡張できる規格。
殆どの言語が一文字3バイトに収まって、ソート問題もなし、政治的配慮もありだったのに。
しくじった。


27 :デフォルトの名無しさん:2009/03/13(金) 20:17:09
collectionや制限部分集合の要素としてglyphic subsetも指定できるように
拡張してくれないかなあ。
要素はあくまでglyphic subsetなので、実装は必ずしもIVSをサポートする必要はない
(してもいいけど)。デフォルトの字形がglyphic subsetの範囲内に収まっていれば、
適合性を主張できることにする。
こうすれば、「新常用漢字の字形を実装したフォント」とか「JIS2004の字形を実装した
フォント」を、規格上曖昧さのない方法で表現できる。規格の行間とかJIS委員が
blogのコメントで吐き捨ててる愚痴まで読まないとまともに実装できないなんて
規格としては不健全きわまりない。
互換漢字大好きの日本代表には少しも期待してないのでUTCがんばれ

28 :デフォルトの名無しさん:2009/03/15(日) 08:29:09
>>26
日本のためだけにそんなオーバースペック提案しても通らない。というか通らなかった
わけで。
iconvだって文字列1つしかオプションに取れないのはほとんど欠陥といってもいいが、
ありとあらゆる柔軟な変換を可能にするためのオプション類の追加なんてできないので、
エンコーディング名に何でもかんでも詰め込む羽目に陥ってる(UTF-8-MACとか)。

29 :デフォルトの名無しさん:2009/03/15(日) 09:39:30
オーバースペックどころか、意図から外れてる。


30 :デフォルトの名無しさん:2009/03/19(木) 00:18:33
日本代表と全面戦争ktkr
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3590.pdf

31 :デフォルトの名無しさん:2009/03/19(木) 19:20:06
ちょっとアホな質問かもしれんが、つまり、U+624D の AJ1E0100 と N3530E0103は同じと考えておk?
いいのか?


32 :デフォルトの名無しさん:2009/03/19(木) 22:22:25
USは同じでいいんじゃね? と主張しているだけで、最終的に判断して再提出するのは
(あるいはあくまで互換漢字を入れろと突っ張るのは)日本。

33 :デフォルトの名無しさん:2009/03/23(月) 18:46:12
ARIBといいケータイ絵文字といい昔の仮名といい
最近日本の文字のUnicodeへの提案多いね。
いい事だ。

34 :デフォルトの名無しさん:2009/03/23(月) 18:53:27
ぜひ写研時代の記号文字も提案を…

35 :デフォルトの名無しさん:2009/03/23(月) 19:23:39
変体仮名は住基仮名だけでも追加したほうがいいと思う。
戦前生まれの人の名前で戸籍上で使われてる事があってこだわる人がいるだろうから。
ところで名前に変体仮名を持つ人ってどれくらいいるのかな?
あまり見ないからごく小数なんだろうけど、実際に使われてても平仮名、片仮名あるいは元になったとされる漢字に置き換えたもので通してることが多いのかな?


36 :デフォルトの名無しさん:2009/03/29(日) 16:06:45
携帯絵文字の大半はBMP外になるみたいだね。
まあ仕方ないか。あれだけ数あるから。
U+2600〜U+26FFはARIBとサッカーボールで全部埋まってしまうみたいだし。
U+2700〜U+27FFには所々に隙間があって少しここに入れるものがあるみたいだがこの領域全部埋めようとはしないのかな?

37 :デフォルトの名無しさん:2009/03/29(日) 16:07:56
BMPに入るわけないだろw

38 :デフォルトの名無しさん:2009/03/29(日) 18:31:19
つーかそろそろBMPは終了のお知らせが近づいてる。
JIS X 0213:2000がかつて勝手に使ってたカッコ付きUCSの位置にもついに
割り当てが入るみたいだし。
IPv4アドレスとどっちが先に枯渇するかってくらいの勢いだ

39 :デフォルトの名無しさん:2009/03/30(月) 17:21:40
絵文字のどこらへんがBなんだ。

40 :デフォルトの名無しさん:2009/03/30(月) 22:01:21
Basicじゃなさそうな文字とか記号とかBMPにてんこもりなので
その批判はあんまり意味無いかも

41 :デフォルトの名無しさん:2009/03/31(火) 23:46:06
もうBMPは止めてCMP( Compatible Multilingual Plane )にでも
改名したほうがいいんじゃないかw

42 :デフォルトの名無しさん:2009/04/01(水) 20:09:14
http://smallbear.sakura.ne.jp/tron/btm20093.html#20090331
おいおい、そのレベルの違いを「おかしな字形」と定義するんだったら
TRONコードだって「おかしな字形」の塊なんだが。
ジャストシステムに言いがかり付けてる暇があったらTRONコードの字形
をどうにかしてくれ。ていうか超漢字Vのマイナーバージョンアップと
Tフォントマダー? (AAry
http://pc12.2ch.net/test/read.cgi/tech/1093251312/160
の件といい、どうしてこうも天に唾するようなことばかり書くのかね。
http://smallbear.sakura.ne.jp/tron/btm20093.html#20090326
> 結局の所、誰もマトモに「常用漢字表」を読んでいないということがあ
> りありと分かるだけ何じゃないかと。
常用漢字表の「明朝体活字のデザインについて」を無視してる奴が
どの口でほざくか。

43 :デフォルトの名無しさん:2009/04/04(土) 23:36:49
http://www.microsoft.com/typography/otspec/cmap.htm
Format 13: Last Resort Font
が追加された。ということはLast Resort Picturesはやっぱり
文字として符号化はしないんだな

44 :デフォルトの名無しさん:2009/04/10(金) 22:44:33
汗マークや怒りマークがようやくUnicodeで使えるようになるな。

45 :デフォルトの名無しさん:2009/04/11(土) 10:59:05
コードはあってもフォントとフォントへのマッピングが普及しているとは限らない罠
もういい加減、基本のフォントはタダで配れよ…

46 :デフォルトの名無しさん:2009/04/11(土) 18:55:01
これはGoogleが検索エンジンのデータベースへ蓄積するために提案したんだから
表示は最初から考慮の対象外
さんざん言われてるけどドコモ以外を正確に再現するには多色カラーや
アニメーションが欠かせないし

47 :デフォルトの名無しさん:2009/04/17(金) 13:17:46
>>35
官報にはたまに出てくるよ>変体仮名

話は全然違うけど、CJKV改訂版の内容レビューだれかやってくれないかな。
本家に行っても、章立てすら見あたらない。

48 :デフォルトの名無しさん:2009/04/18(土) 17:39:45
もうすぐ中旬終わるけど新ライセンスのIPAフォントマダー?
文字鏡16万字版の通常版マダー?
まったくどいつもこいつも出す出す詐欺ばかりだ。

49 :デフォルトの名無しさん:2009/04/19(日) 05:47:42
>>48
おい、乞食のくせに口を慎めよ。

50 :デフォルトの名無しさん:2009/04/19(日) 20:29:36
女真文字
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3618.pdf
なんか漢字が混じってるような

51 :デフォルトの名無しさん:2009/04/19(日) 20:30:10
>>49
文字鏡16万字版はタダじゃねーぞ

52 :デフォルトの名無しさん:2009/04/20(月) 00:27:07
>>50
漢字と同じ字形の文字が少なからずあるからねぇ>女真文字

しかし何だ、こういう一覧表見るとwktkが止まらんな

53 :デフォルトの名無しさん:2009/04/23(木) 23:50:59
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3607.pdf
U+E0200..U+E0545はUnicodeだとdefault ignorableだし
UCSでも(代替)書式文字のために予約されてる範囲なんだが
本当にそこでいいのか?

54 :デフォルトの名無しさん:2009/04/29(水) 11:13:09
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3636.pdf
N3583でもともと提案されてたEMOJI COMPATIBILITY SYMBOLと国旗の収録は
とりあえず断念したらしい。
その代わり/^o^\フッジサーンと東京タワーと自由の女神と日本地図とモヤイ像の
名前がEMOJI COMPATIBILITY SYMBOL-nに変わるようだが。

55 :デフォルトの名無しさん:2009/04/29(水) 12:19:38
>>54
なんでその中にモヤイ像が入ってんだ?w

56 :デフォルトの名無しさん:2009/04/29(水) 16:42:22
アメリカかなり妥協したなあ。
よっぽどAmd.8に入れたかったんだな。

57 :デフォルトの名無しさん:2009/04/29(水) 17:00:34
モヤイ像といえば渋谷名物だからなw

58 :デフォルトの名無しさん:2009/04/29(水) 17:27:35
109涙目w

59 :デフォルトの名無しさん:2009/04/30(木) 22:16:09
米がN3607に歩み寄ったってことは、もしかするとトランプも入ったのか

60 :デフォルトの名無しさん:2009/05/04(月) 17:43:21
トランプは全て入ったけど
i-mode隠し文字(EMOJI COMPATIBILITY SYMBOL)は誰が考えたってダメだろ

61 :デフォルトの名無しさん:2009/05/04(月) 19:02:28
TRONコードですらi-mode隠し文字の位置は空欄になってるぞ。
最初空欄を空けるのを忘れてて後から訂正が入ったりしたのはご愛敬
http://www2.tron.org/set08.html

62 :デフォルトの名無しさん:2009/05/04(月) 23:53:57
麻雀ドミノに続いてトランプか。
これなら花札も行けるかもな。

63 :デフォルトの名無しさん:2009/05/05(火) 05:31:05
トランプのところにはタロットの小アルカナも包摂するみたいなことが書いてあるから
そのうち大アルカナも提案されるのかね
いい加減節操がない気もするが

64 :デフォルトの名無しさん:2009/05/05(火) 12:33:16
ショウギーはまだぁ?

65 :デフォルトの名無しさん:2009/05/05(火) 12:52:43
ショウギーの駒は先手と後手の両方が必要だ

66 :デフォルトの名無しさん:2009/05/05(火) 22:15:29
WHITE SHOGI PIECEは上下逆さにしたものを包摂してるらしい

67 :デフォルトの名無しさん:2009/05/05(火) 23:15:26
MacOSでのShift_JISとUnicodeとのマッピング
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
見てたんだけど、
Unicodeの私用領域にマッピングしてる文字や、
2文字以上にマッピングされる文字が約60文字もあるのね…。

Shift_JIS Unicode
0x8645  0xFF4D+0xF87F # square m
0x8791  0x5927+0x20DD # ideograph big + COMBINING ENCLOSING CIRCLE

みたいなの。
Webアプリ作ってるんだが、胃が痛い…。

68 :デフォルトの名無しさん:2009/05/05(火) 23:19:09
>>64
碁も必要ではないだろうか。

69 :デフォルトの名無しさん:2009/05/05(火) 23:34:26
碁は符号化するとしたらどんな感じになるんだろ。
○●の背後に┼があれば良いのかな。

70 :デフォルトの名無しさん:2009/05/05(火) 23:54:23
白丸の中に数字、と、黒丸の中に白抜き数字、で、十分な数
(とりあえず999まででおk?)が必要じゃないかな。

あと、デザインを合わせて丸の内側に三角とか四角とかも。

そもそも、碁の棋譜を文字で表現すべきものなのか、激しく疑問だが。

71 :デフォルトの名無しさん:2009/05/06(水) 01:53:51
楽譜や数式と同様にIgo Markup Languageと組み合わせて使うこと前提で登録なら
ありうるかも

72 :デフォルトの名無しさん:2009/05/06(水) 10:42:43
雀牌もやるきかw

73 :デフォルトの名無しさん:2009/05/06(水) 14:13:59
麻雀牌は収録済み

74 :デフォルトの名無しさん:2009/05/06(水) 14:55:24
あとはシャンチーとか?
シャンチーって↓これね
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%A3%E3%83%B3%E3%83%81%E3%83%BC

75 :デフォルトの名無しさん:2009/05/06(水) 16:28:16
モンゴル将棋も忘れずに!
ttp://history.chess.free.fr/hiashatar.htm


76 :デフォルトの名無しさん:2009/05/06(水) 17:29:20
チェスと将棋に包摂されたりして
麻雀牌も中国麻将を区別してないみたいだし

77 :デフォルトの名無しさん:2009/05/07(木) 20:50:11
>>67
何を作っているかしらんけど、もしcharset=Shift_JISならそもそもそういう
文字は使うべきではないのでは。

ってゆうかそもそもそれをShift_JISと呼んでいる時点でアレだが。

78 :デフォルトの名無しさん:2009/05/08(金) 01:28:09
MacEncodingをInternetで使っちゃダメだよ
Mozillaが対応してるのもほとんど事故のようなものだし

79 :デフォルトの名無しさん:2009/05/08(金) 01:48:50
これってUTF-8のときも、MacOSでこの文字入力したら
私用領域の文字送ってくるってことでしょ。
対応しないならしないで、もしユーザーが使ったら
エラーメッセージ出さないと…。

80 :デフォルトの名無しさん:2009/05/08(金) 02:41:55
対応も何もOSに依らず私用領域の文字を使うか否かはユーザの責任でしょ。
私用領域の文字でなくてもNSString/CFString (UTF-16)からShift_JISにする段階で変換できない文字は存在しうるし。

自分のソフトウェアでShift_JISな文字列からNSStringを作る場合は
[NSString stringWithCString: string encoding: NSShiftJISStringEncoding]
の代わりに、
(NSString *)CFStringCreateWithCString(NULL, string, kCFStringEncodingDOSJapanese)
とか、kCFStringEncodingShiftJIS_X0213を使うという手もあるよ。

81 :デフォルトの名無しさん:2009/05/08(金) 13:20:15
ユーザーが私用領域とか知った上で入力するとは思えないなぁ…。
あなたのソフトウェアのユーザーと、私が対象としてるユーザーは
違うようなのでもう消えます。さよなら。

82 :デフォルトの名無しさん:2009/05/08(金) 13:47:11
>>81
Webアプリ作っているお前の責任なんだが?
お前がUnicodeフレームワークの「利用者」

83 :デフォルトの名無しさん:2009/05/08(金) 14:03:41
>>82がよくわからない。

>>81は、「Webアプリ作っているオマエの責任」として私用領域ははじこうとしている。
>>82の言っているそのままなんだが…。

84 :デフォルトの名無しさん:2009/05/08(金) 14:06:13
>>81は、「対応する」=「そのままうけつける」、「対応しない」=「エラーとしてはじく」としているが、
>>82はどちらも「対応には変わりない」と言ってるんだろ。

85 :デフォルトの名無しさん:2009/05/08(金) 14:31:49
麻雀って赤牌は別コードになるのか?

86 :デフォルトの名無しさん:2009/05/08(金) 20:50:47
将棋の駒の上下逆さにしたの追加されるみたい。(ARIBにあるから)
ということは>>66で包摂しているって書いてあるが、これからは分離されるってことかな。

87 :デフォルトの名無しさん:2009/05/08(金) 23:37:10
CJK統合漢字拡張Dは数がかなり少なくなるみたい。(200字強)
でそれより後に拡張Eが追加されるみたい。これも少量になって残りは拡張F、G、…になるかも。
やっぱり拡張Bのときいっぱい追加して重複とかあったから、
反省してこれからは慎重に少しずつ追加していくことにしたのかな?


88 :デフォルトの名無しさん:2009/05/09(土) 01:27:23
漢字といえばN3530はどうなったんだろ
Resolutionsには言及されていないからMinutes待ちか

89 :デフォルトの名無しさん:2009/05/09(土) 12:30:36
>>85
Unicodeは色を符号化しません。
cf. 絵文字

90 :デフォルトの名無しさん:2009/05/09(土) 13:07:22
で、「じゃあフランス国旗とイタリア国旗はどうなんだよ」と突っ込まれたのが
国旗収録断念の理由の一つ

91 :デフォルトの名無しさん:2009/05/10(日) 12:53:41
>>90
包摂しちゃえばいいのに

92 :デフォルトの名無しさん:2009/05/10(日) 13:01:02
>>91
それじゃラウンドトリップコンバージョンが崩れるからダメなんだと
理由は他にもあるし

93 :デフォルトの名無しさん:2009/05/10(日) 22:45:12
ハートマークの色違いとかHEART-1、HEART-2、…とか名称は-数字を付けるらしいな。
以前の案では縞模様とか網掛けに置き換えるとかしてたみたい。

94 :デフォルトの名無しさん:2009/05/10(日) 23:26:56
なんかUnicode追加文字の符号位置だいぶ変更するみたいだね。ヤ行のえと□デはSMPの方に変更するらしい。
ヤ行のえは現代の仮名と古代の仮名は一緒にしない方がいい、
□デについてはU+32FFは○ンかもっと重要な文字が必要になったときのためにとっておいた方がよいということなどの理由らしい。
U+26xxに追加が提案されてたARIBの記号の一部はU+27xxやU+2Bxxに変更するみたい。
U+26xxのブロックはまだ埋まらないことになる。で携帯絵文字の内、蛇遣い座の記号はBMP内のU+26CEに提案されてた。
今後も変更があるかも知れない。最終的な決定はもう少し先になりそうだ。
個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。

95 :デフォルトの名無しさん:2009/05/10(日) 23:57:06
ARIB関連はもう動かせないよ。Amd6はFDAMに移行するから。
残りは明日からのUTCの会議次第でまだ紆余曲折あるかも。

96 :デフォルトの名無しさん:2009/05/11(月) 03:39:36
結合文字はIME文字一覧からでしか入力出来ませんか?

97 :デフォルトの名無しさん:2009/05/11(月) 11:53:28
> 個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。

一昔前によく使われた、写研の記号BA-90はどうすんだ、とか
収拾がつかなくなる気がする。じだいとともにうつりかわってるし。

98 :デフォルトの名無しさん:2009/05/11(月) 15:08:10
少なくともBA-90やBA-88はかつて漫画を中心に大量に使われたので
どこか提案して収録はして欲しいがSMPで良い。

99 :デフォルトの名無しさん:2009/05/11(月) 17:39:41
絵文字のとこに入ってる顔のついた月が
それっていう解釈でもいいかもね


100 :デフォルトの名無しさん:2009/05/11(月) 20:29:22
イワタアンチック体が収録しているんだが、これは外字だな
http://www.iwatafont.co.jp/MO_FONTS/set_image_pdf/antique/anti_b.pdf

このあたりの写植時代の記号類、Unicodeに入れてほしいね

101 :デフォルトの名無しさん:2009/05/12(火) 00:45:27
BA-88はFIRST QUARTER MOON WITH FACE、BA-90はFULL MOON WITH FACEと包摂か。
ところでBA-90って満月なの?

102 :デフォルトの名無しさん:2009/05/12(火) 04:50:52
BA-86からBA-89まで月が続いてるからBA-90は満月だと思い込んでたが、
そういわれりゃ太陽って可能性もあるわけか。

103 :デフォルトの名無しさん:2009/05/12(火) 11:13:50
ぽげむたマークか、懐かしいな(ひげ無いけど)

104 :デフォルトの名無しさん:2009/05/13(水) 23:20:09
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3553.pdf#page=15
> Some X0213 characters are mapped to
> compatibility ideographs. The problem stated in the paper is not reported in Japan
> ? my personal experience is that the problem stated in the paper has not occurred.
おいおいこんなのが日本代表やってんのかよ。小形の連載とか直井さんのblogあたり
を10646回読み直せ。それでもまだこんな寝言ほざくつもりならとっとと帰国して二度と
米国代表の邪魔をするな。

105 :デフォルトの名無しさん:2009/05/13(水) 23:49:14
wg2のminutesは面白いよな
utcのminutesも各自の発言まで載ってるといいのに

106 :デフォルトの名無しさん:2009/05/14(木) 08:08:09
> not reported
で、そのreportとやらはどこに送ればいいの?
太玄経記号の名前の天地人がおかしいとか、JIS X 0213用のNamed Sequencesが
足りねーよとかも、どこに言ったらいいかさっぱりわからないから2chとかで騒いでるん
だけど。
Unicodeは窓口を明確にしてるし、どっかの国のガス抜きのためだけにある
パブリックコメントと違ってちゃんと反映もしてくれるし必要ならWG2への提案まで
してくれるのに。日本人が日本代表動かすより米国代表やUTC動かすほうが
簡単ってどうなの?

107 :デフォルトの名無しさん:2009/05/15(金) 11:37:21
http://www.itscj.ipsj.or.jp/sc2/open/02n4015.pdf
とかに彼のものっぽいメールアドレスがあるから、
直接報告してあげればいいんじゃないの。

108 :デフォルトの名無しさん:2009/05/16(土) 03:33:02
>106
ロクな下調べもしないで騒ぐのならば、2chで始めた方が相手にも迷惑かからないかもね。
太玄経記号の天地人とかは amd 2 で直されて、annex p に注記が
入っている。0213のUSIとかもamd.7に入ってるけど、それでも足りないのがある?

109 :デフォルトの名無しさん:2009/05/17(日) 21:14:41
>>104
Suignardの言ってることも変。
IVSもnormalizationかけたら、現状じゃ落ちちゃうだろ。
将来は大丈夫って、そんなのウソ。

110 :デフォルトの名無しさん:2009/05/18(月) 02:05:03
>>109
IVSはnormalizationかけても落ちないよ。
ただ、SPP(14面)の文字は、文字列の等価性の比較のときは無視するべき。
照合アルゴリズムで、それをちゃんとやってるソフトも規定も現状では
整備されてないから、絵にかいた餅だってこと。

111 :デフォルトの名無しさん:2009/05/18(月) 02:07:48
SPP -> SSP

112 :デフォルトの名無しさん:2009/05/21(木) 23:34:35
PDAM8はsymbolばっかりだなあ、
と思ったら名前からしてAdditional symbolsが先頭に来ているのか。

113 :デフォルトの名無しさん:2009/05/30(土) 15:29:44
10646の新版もようやくCDですか

114 :デフォルトの名無しさん:2009/05/31(日) 03:48:29
ExtBマルチカラム化実現したのか

115 :デフォルトの名無しさん:2009/06/01(月) 03:39:53
ちゃっかりAmd.8まで入れてあるような。

116 :デフォルトの名無しさん:2009/06/06(土) 23:00:50
小形さんうまいこと引っ張るなぁ。

117 :デフォルトの名無しさん:2009/06/06(土) 23:24:51
北朝鮮(KP)のフォントが用意できてないみたいだけど、
規格票用のフォントを作る余裕なんてあの国にあるんだろうか。
なんかこっちが心配してしまうw

118 :デフォルトの名無しさん:2009/06/07(日) 12:27:50
北朝鮮にはウンチの絵文字をあげるよ

119 :デフォルトの名無しさん:2009/06/10(水) 09:07:45
絵文字ad hocは決定事項の報告が主だから、あれを元に
Peterが中立だったというには無理があるんじゃないかなあ。

Oさんが独自のソース持っているのなら話は別だけど。

120 :デフォルトの名無しさん:2009/06/28(日) 01:18:10
いつの間にか「祷」(第3水準の正字でなく第1水準の略字の方)と「穹」が人名用漢字に追加されてた。

121 :デフォルトの名無しさん:2009/06/28(日) 03:56:38
蒼穹のうんたら

122 :デフォルトの名無しさん:2009/07/02(木) 21:15:54
ここら辺の記号類もunicodeに入れてほしいなぁ。
手話シンボル http://www001.upp.so-net.ne.jp/wakan/Others/HandSignFont.html
ケアーマーク/リサイクルマーク http://gaiji.info/pictgram/6-pictogramfontdownload/11-caremarkfont.html
地図記号 http://gaiji.info/pictgram/6-pictogramfontdownload/13-2008-11-25-06-10-47.html
一般案内用図記号 http://gaiji.info/pictgram/6-pictogramfontdownload/12-2008-11-25-06-03-04.html
校正記号 http://www.erc-books.com/ERC/How/H2-List.html
交通標識 http://www.menkyo.ne.jp/menu/kiso/hyoshiki.html
電気記号 http://www.ne.jp/asahi/ja/asd/gijutu/zukigou/zukigou.htm

123 :デフォルトの名無しさん:2009/07/02(木) 21:43:02
あと難しいかもしれないけどWebdings、Apple Symbolsあたりをunicodeに入れてほしいなぁ。

124 :デフォルトの名無しさん:2009/07/02(木) 21:49:08
うるせえだまれ

125 :デフォルトの名無しさん:2009/07/02(木) 21:54:19
すんません

126 :デフォルトの名無しさん:2009/07/02(木) 23:24:51
>>123
Apple Symbolsって殆どUnicodeでそれ以外はAppleの私的な記号やん

127 :デフォルトの名無しさん:2009/07/02(木) 23:31:29
標識類や回路図用の記号なんかは難しいらしい。

ttp://std.dkuug.dk/JTC1/SC2/WG2/docs/principles.html
の34ページ目以降に解説があるから興味があったらどぞ。

128 :デフォルトの名無しさん:2009/07/03(金) 10:21:49
改正されたJISマークはどうなるんだろう。
というか、旧JISマーク(〄)は何をソースに入ったんだ?

129 :デフォルトの名無しさん:2009/07/03(金) 13:38:16
まさかデザイン変更するとは予想してなかったんじゃね? それよりも、かつてのJIS X 0213のドラフト案には

ベンゼン環

があったんだよ。そんなもの一体何に使うんだっていうの。

130 :デフォルトの名無しさん:2009/07/03(金) 13:45:13
よくわからんが、化学式に使うんじゃねーの

131 :デフォルトの名無しさん:2009/07/03(金) 14:52:12
有機化学系の書籍では普通に本文中に埋め込まれてる。


132 :デフォルトの名無しさん:2009/07/03(金) 15:12:23
ベンゼン環はUnicodeには入ってるな。

133 :デフォルトの名無しさん:2009/07/04(土) 02:50:17
ベンゼン環だけあったって何の役にも立たんのにといつも思う。

134 :デフォルトの名無しさん:2009/07/05(日) 21:13:11
>>128
Adobe-Japan1-1じゃね?
新JISマーク取り込んだAdobe-Japan1-7まだー?

135 :ぎじつしゃ1:2009/07/05(日) 21:37:27
中途半端なぎじつしゃです。

各種プログラミング言語には文字列の判定処理でcharlenというものが用意されていますが
同じプログラミング言語でもHP-UXなどのUNIXとWindowsなどプラットフォームにより
返り値が違う文字コードがあるとききました。
具体的には 0x8240〜0x824e などの機種依存エリアの判定です。

HP-UXでは 返り値=1  WIndowsでは 2 となるようです。

どこか技術文書などがあれば紹介いただきたいのですが・・

136 :デフォルトの名無しさん:2009/07/05(日) 23:54:56
>>134
AJ1-7 は Unicode 5.2 の制定後になるのかな?
新JISマークが入るかどうかは知らんが

137 :デフォルトの名無しさん:2009/07/06(月) 01:15:45
Unicodeとは連動していない気がする。1-6が出てからもう5年近く経つし。
どういうタイミングで更新しているんだろな。

138 :デフォルトの名無しさん:2009/07/06(月) 09:43:01
>>135 マニュアル嫁

139 :デフォルトの名無しさん:2009/07/11(土) 23:38:41
Adobe-Japan1の非漢字にはUnicodeに入ってないのいっぱいあるよな。
JASマークとか一部の組文字とか。
これらはUnicodeに入れないのかな?
漢字は大半がIVSで表せるし表せないもの(撥の拡張新字体など)は拡張CやDで追加されるみたいだけど。




140 :デフォルトの名無しさん:2009/07/12(日) 01:16:00
JASマークは別に文章中で文字として使わないしなぁ・・・
まあそんなこと言い始めたらキリがないけど
というか、既に収録されているカタカナの組文字ってどういう基準で採用したんだろう?
http://www.unicode.org/charts/PDF/U3300.pdf

141 :デフォルトの名無しさん:2009/07/20(月) 06:49:29
そういえば、BETA Unicode 5.2.0でてるね、みんな読んだ?
http://www.unicode.org/versions/beta.html

142 :デフォルトの名無しさん:2009/07/21(火) 18:16:11
別スレにも書き込んでここで3度目なので、しつこいようですがよろしくお願いします


文の格納に必要なバイト数をJISコードの場合とシフトJISコードの場合のそれぞれで計算する問題なのですが、これはどうやって考えれば良いのですか?

漢字、カタカナ、英数字(半角)、記号で構成されている文です

曖昧な質問で申し訳ないのですが、ここでは課題の文を晒せないので、よろしくお願いします><

143 :デフォルトの名無しさん:2009/07/21(火) 18:27:53
>>142
あんた馬鹿?

144 :デフォルトの名無しさん:2009/07/21(火) 18:58:45
ttp://charset.7jp.net/jis.html
ttp://charset.7jp.net/sjis.html

145 :デフォルトの名無しさん:2009/07/21(火) 21:00:52
いまどき「JISコード」と教えてるとは感心できない学校もあるもんだ

146 :デフォルトの名無しさん:2009/07/21(火) 22:32:47
問題のための問題だろう。
おそらくJISの決まり事とか問題文と一緒に書かれている。
スレ違いだな。

147 :デフォルトの名無しさん:2009/07/22(水) 00:47:27
みんな冷たいな。

>>142
文の格納に必要なバイト数をJISコードの場合とシフトJISコードの場合のそれぞれで計算すればいいと思うよ。

148 :デフォルトの名無しさん:2009/07/22(水) 02:52:14
>>147
ご親切にありがとうございます

計算とは、実際どのようにすれば良いのですか?
例文を挙げて説明して頂けると有難いです


こんなこと聞いてホントに申し訳ないです;;
実は大学の選択科目の課題なのですが、基礎知識ゼロで飛び込んでしまったので、問題文の意味すら分からず困り果てている状態です><

149 :デフォルトの名無しさん:2009/07/22(水) 05:34:37
><

150 :デフォルトの名無しさん:2009/07/22(水) 05:39:31
今回の皆既/金環日食はトカラ列島中心だけど
2012年5月にはほぼ日本全国で金環日食が見られるんです

151 :デフォルトの名無しさん:2009/07/22(水) 08:30:50
>>148
友達を作るチャンスだろ
こんなとこ書き込んでないで周りと話せ

152 :デフォルトの名無しさん:2009/07/22(水) 17:28:05
「JISコードの場合」ってのがわからん。
ISO-2022-JPのこと?

153 :デフォルトの名無しさん:2009/07/22(水) 18:10:25
違うんじゃないかな

154 :デフォルトの名無しさん:2009/07/22(水) 18:12:46
>>148
足し算だけでいけると思うよ
文を作って左から数えるだけ

155 :デフォルトの名無しさん:2009/07/22(水) 20:20:57
You! ダブっちゃいなよ!

156 :デフォルトの名無しさん:2009/07/25(土) 04:30:38
>>141

どうやらようやくヒエログリフが(><)ノ

これでやっと画像ファイルなくせる

157 :デフォルトの名無しさん:2009/07/26(日) 01:51:16
Amd.5と6の分か。
日本関連だと拡張漢字CとARIBかな。

158 :デフォルトの名無しさん:2009/07/26(日) 04:36:39
>>157
Amd.6も収録されるのか。
win7のTVゴシックはPUAにARIB外字が入ってるけど、どうなるんだろ。
AJ1-7あたりにも入るんかな>ARIB

159 :デフォルトの名無しさん:2009/07/26(日) 14:54:23
最終的にはAmd.6で決まった符号位置に移動させるんだろうけど、
Unicode5.2とWin7のリリースがほぼ同時期なだけに、
タイミングが難しそう。

160 :デフォルトの名無しさん:2009/07/27(月) 10:24:39
凄い初歩的な質問です。文字コードというよりエンディアンの質問になってしまいますが・・・
UNICODEのLEは
例えば、
23 43 23 12 34 35
と文字列が並んでいて、これをBEに変換するには
35 34 12 23 43 23となるのでしょうか?
それとも、それぞれ2バイトで文字列が切れるとして
34 35 23 12 23 43
ということなのでしょうか?
前者だとすると、最後までデータを読まないと、頭の文字がわからないという事ですよね?
でも、そういうわけでもなさそうですし。
後者だと、自分が学生の頃学んだ記憶によれば、LEとは言わずに、ミドルエンディアンと習った覚えがあります。
どちらなのでしょうか?

161 :デフォルトの名無しさん:2009/07/27(月) 11:03:07
UNICODE って何?
UTF-16 とか、きちんと用語が使えるようになってからまた質問してね。

162 :デフォルトの名無しさん:2009/07/27(月) 13:37:19
文字列はビッグエンディアン

163 :デフォルトの名無しさん:2009/07/27(月) 13:39:57
ビッグトンチンカン

164 :デフォルトの名無しさん:2009/07/27(月) 13:47:44
>>160
文字をBEで表現するかLEで表現するかの違いこそあれ、
文字が逆順に表現されるようなエンコーディングは存在しない。

165 :デフォルトの名無しさん:2009/08/04(火) 21:24:11
>>148
質問の意図が分からないので、推測するけど、 JIS == JIS X 0208でよいのかな?
マジスレすると、一言に漢字と言っても、JIS X 0208では6,355文字しか定義されていないので、
格納する文字列の中の漢字で、JISX0208に含まれない漢字(例:JISX0212等)
がある場合は切り替え命令が必要なので、その分必要なバイト数は増える。
半角カナ使用の場合も同様に切り替え命令の分必要なバイト数が増える。
例)"あ" == "<1b 24 42> 24 22 <1b 28 42>"
例)”aあああa”="61 <1b 24 42> 24 22 24 22 24 22 <1b 28 42> 61 0a"
例)"aあaあa"="61 <1b 24 42> 24 22 <1b 28 42> 61 <1b 24 42> 24 22 <1b 28 42> 61"
英数と言うのは、ASCIIと仮定して、記号もASCII規格のやつと仮定して、
基本的に英数と半角カナは1バイト、ひらがな、漢字は2バイト、その他は3バイトで計算(かなり大雑把だけど)
違う文字集合ごとに切り替える必要があり、その度に三バイト必要になる。
ただ、例外的に格納する文字列の始めがASCIIの場合、<1b 28 42>は必要なく、
新たに[現在の文字集合とは]別の文字集合にぶつかる度に三バイト必要になる。
また、文字列の最後の文字が属する文字集合がASCII以外である場合、<1b 28 42>を追加して
きちんと基本のASCII文字集合に切り替えて末端処理を行わないといけない。
当然、二つの文字列をつなぎ合わせる場合は、もし末端処理が不要(一つ目の文字列の最後の文字と、
2つ目の文字列の最初の文字が同じ文字集合に属し、かつASCII文字集合では無い)な場合、
末端処理として入れられた一つ目の文字列の最後の<1b 28 42>と二つ目の文字列の
最初の切り替え命令3バイトを取り除く必要がある。

粗悪なプログラムの場合、この辺の末端処理とか使われていないとか、切り替え命令の除去がされていないので、
注意する必要がある。
厳密には「文字集合」の意味は違うけど、多分質問者の教材ではそこまで深く掘り下げないと思うので


166 :デフォルトの名無しさん:2009/08/04(火) 21:25:41
あと、追加(文字数大杉)。
各国(192ぐらい?)毎の使用符号化方式と言語一覧表探してるんだけどだれか持ってない?
とりあえず地味に20ヶ国ぐらいググってるんだが、マイナーな国の情報とか乗ってない…orz
例) 日本=日本語、euc-jp,shift-jis,iso-2022-jp;みたいに。
アフガニスタンとか、Extended Arabic Lettersの前に元々使っていたコードページとか
ある筈なんだけど、だれかエロい人おしえて?


167 :デフォルトの名無しさん:2009/08/05(水) 01:00:06
ここからたどれない?

ttp://www-01.ibm.com/software/globalization/expertise/index.jsp

168 :デフォルトの名無しさん:2009/08/08(土) 06:54:27
MicrosoftだとCode Page Identifiersとか。
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
ただ、実際にそこの国の人々がもっぱらどんな体系を使っているかは、
こういうのだとわかんないんだよね。
台湾のUAOとか最近まで知らなかったよ。

169 :デフォルトの名無しさん:2009/08/08(土) 17:07:22
Historic Kanaって名称は邦訳が難しそう
Kana Supplementの方が汎用性もあるし好都合なんじゃないか

170 :デフォルトの名無しさん:2009/08/09(日) 00:04:05
ほんとだよな。
それだったら「イ」と「エ」が合体したものや小書き「ヰ」「ヱ」「ヲ」や琉球語表記用の「て」と「ぃ」が合体したものなどの拡張仮名も入れることができるのに。


171 :最近までShift_JISとMS932を混同してた:2009/08/12(水) 11:42:19
>>169
> Historic Kanaって名称は邦訳が難しそう
ん?「旧かな字」とかでいいんじゃない?とか素朴に思ってしまったんだけど……


あ、パンドラの続編が来たね。最終回は次回、らしい。
「絵文字が開いてしまった「パンドラの箱」第5回--絵文字と日本マンガの親密な関係」
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174,00.htm

172 :デフォルトの名無しさん:2009/08/13(木) 21:29:19
今回は今ひとつだったなあ。
あんまりダブリン会議のこと引っ張ってると情勢変わるかもよ。
2〜4月と8〜10月は一番動きがある時期なんだから。

173 :デフォルトの名無しさん:2009/08/14(金) 04:13:09
絵文字なんてエスケープシーケンスとかmixiみたく特定の文字列で対応すればいいだろうが。
こんなの認め始めたらキリがないって。

174 :デフォルトの名無しさん:2009/08/14(金) 05:46:47
遅かれ早かれWEBにもあふれ出してきて、豆腐だらけになるんだろうな。

175 :デフォルトの名無しさん:2009/08/14(金) 15:25:35
iPhoneでSMSを使ったときのセキュリティー問題で話題になった豆腐も、きっとなにかの絵文字だったんだろうな。

176 :デフォルトの名無しさん:2009/08/15(土) 17:36:39
>>173
エンコーディングとキャラクタセットを混同している。

177 :173:2009/08/15(土) 20:28:41
>>176
俺は絵文字をキャラクタセットに組み込んで欲しくないから、そうしろと言ってるんだけど。

画像を別に準備(gifでもjpgでも何でもいい)しておいて、表示時に画像を埋め込むようにすれば十分。

178 :デフォルトの名無しさん:2009/08/15(土) 20:55:50
> 俺は絵文字をキャラクタセットに組み込んで欲しくないから


179 :デフォルトの名無しさん:2009/08/15(土) 20:58:41
ごめん途中で送信しちゃった

> 俺は絵文字をキャラクタセットに組み込んで欲しくないから
その前提を最初に主張しないと後ろの意見だけ言っても伝わらないって。

180 :デフォルトの名無しさん:2009/08/17(月) 10:05:42
笑える
http://japan.cnet.com/image/l/story_media/20398174/fig_5-8.jpg

181 :デフォルトの名無しさん:2009/08/17(月) 10:55:52
アイルランド・ドイツ提案のやつ見てたらアイマスフォントを思い出した

182 :デフォルトの名無しさん:2009/08/17(月) 11:08:03
>>180
これ直接行けないんだな。
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174-4,00.htm
の図8。

183 :デフォルトの名無しさん:2009/08/17(月) 11:09:46
え?
直接行けたけどな。専ブラだから?

184 :デフォルトの名無しさん:2009/08/17(月) 11:10:15
・アニメ風牛の顔
・牛の影絵
が包摂されるわけですね。

僕の書いたべか子ちゃんの顔アイコンも包摂されてしまうとしたら哀しいです


185 :デフォルトの名無しさん:2009/08/17(月) 22:15:23
クジラの影絵を見てクジラって言い当てられたらすごい

186 :デフォルトの名無しさん:2009/08/17(月) 23:10:35
動物の顔のマークを動物の全体像で置き換えちゃ
記号の意味が変わるというつっこみを受けて
結局分離することになりました…ってあたりを次にやって連載完結かな。

187 :デフォルトの名無しさん:2009/08/19(水) 00:31:09
Old Hungarianはpunctuationすら一本化できないのか
本当もめるなあ

188 :名無しさん@そうだ選挙に行こう:2009/08/30(日) 04:17:00
WG2 Meeting 55 って東京開催だけど、あれって一般人でも傍聴可?

189 :デフォルトの名無しさん:2009/09/12(土) 01:45:38
JIPSEとJIPSJの違いを知りたい。

190 :デフォルトの名無しさん:2009/09/12(土) 02:00:46
NECって昔から糞な会社の代表で、ここのせいで日本のITが立ち遅れたのは間違いない。
JALとともに、さっさとつぶれてほしい筆頭の会社だがね。


191 :デフォルトの名無しさん:2009/09/12(土) 12:55:17
なんだおめーEかHかFかSの回しもんか

192 :デフォルトの名無しさん:2009/09/12(土) 15:03:51
NECのお陰で日本のHentai文化が育った。
PC88のおかげで日本は世界一のFM音源大国になった。
PC98のおかげで日本のFDDの出荷率は2倍になった。

193 :デフォルトの名無しさん:2009/09/12(土) 16:25:10
NECのおかげでJIS78がえんえん生き残った、ぐらいだよなぁ。
このスレの話題的に恨まれることと言えば。
それも、変えたほうが悪い、と言われるような規格だし。

FM音源の普及にはセガのおかげも大きいし、FDDについては単に98が
最大のシェアを持ってたからってだけで、特筆するようなものでもないと思う。

194 :デフォルトの名無しさん:2009/09/12(土) 16:47:55
いや、PC98のFDDの出荷率2倍は皮肉でしょw
当時のPC98はメモリが少なく、HDDも一般的で無かった事から
何をするにも、FDDが2つ搭載されてないと困った。
なので2台搭載されてるのがデフォだったんだよ。


高性能なIBM PCやX68kを見て
「FDD1つしか搭載されてないじゃんw」ってPC98ユーザーが馬鹿にするジョークがあった。
これは、2つ搭載しないと性能的に駄目なPCって意味なんだけどね。

195 :デフォルトの名無しさん:2009/09/12(土) 17:22:10
>194
> 高性能なIBM PCやX68kを見て
ここ笑うところですか?

196 :デフォルトの名無しさん:2009/09/12(土) 19:13:04
Cドライブから始まるのは正直ダサいw

197 :デフォルトの名無しさん:2009/09/12(土) 19:21:53
仮想FDドライブ懐かしい

198 :デフォルトの名無しさん:2009/09/12(土) 19:28:10
X68kはFDD二台あったよ

199 :デフォルトの名無しさん:2009/09/12(土) 19:29:27
当時の5インチFDの中身が読みたいんだが
USBのFDDとかで5インチって無いのか?

200 :デフォルトの名無しさん:2009/09/12(土) 19:29:54
日本が海外の進行を食い止めたのは
漢字ROMをはじめとするハードウェアの日本語化の障壁があったからだと思う。
メモリが贅沢に積まれはじめて、ソフトウェアで実現出来るようになっても、
漢字Talkや超漢字みたいに、漢字対応を全面に出したOSが出るくらいだから、
やっぱり海外は日本語のフォント作りに苦心したんだろう。

なので、日本のITが遅れた主な元凶は、日本語にあると思う。
これが英語圏だったらそんな事はなかった。

逆に、漢字文化を持ってるからこそ、勝たなければ行けなかった分野で最近負けてるのが気がかり。
検索エンジンなんて、絶対に日本が勝たなければいけなかった分野なのに・・・。
はじめから分かち書きされてる英語圏に、先に様々な問題意識を持たれ、字句解析の技術も先行され・・・
本当に馬鹿な事をしてると思うよ。まぁ、日本は人工知能に偏った思い入れがあるから、いつまでたっても認知科学の分野から頭が離れなかったのも主原因にあると思う。
何十年焼き回し研究をやってるんだと言いたい。

201 :デフォルトの名無しさん:2009/09/12(土) 20:16:23
研究費で食ってる香具師らにろくなのはおらんよ
理研ですら利権まみれだったからな

202 :デフォルトの名無しさん:2009/09/13(日) 00:32:27
IBM 5550 には FDD 3台ついてたよ。


203 :デフォルトの名無しさん:2009/09/13(日) 04:00:16
>>200
「日本語情報処理」を外人が書いちゃうような、そんな後進国だもの<日本

204 :デフォルトの名無しさん:2009/09/13(日) 04:45:50
NEC内部コードEとNEC内部コードJとかいう変態のコードとUTFの変換テーブルはどこかにありませんか?

205 :204:2009/09/13(日) 04:50:01
質問が間違えた。
NEC漢字コード体系という変態から逃れたいんですがどうしたら良いでしょうか。
ヘンテコ汎用機で困るんです。


206 :デフォルトの名無しさん:2009/09/13(日) 05:33:57
     固定機能を排除するにしても、固定機能の代替となるようもう一段ミドルウェアをかまさないとつらいからな

207 :デフォルトの名無しさん:2009/09/13(日) 08:46:51
>>203
電子情報通信学会編「日本語情報処理」ってのもあるんだけどな。
日本人のやることは、日本人ってバカにするのが好きだからさw

208 :デフォルトの名無しさん:2009/09/13(日) 11:04:31
>>207
それ内容はどうなの?入手方法は?

209 :デフォルトの名無しさん:2009/09/13(日) 14:03:49
自然言語処理が日本で人気が出始めたのも、Googleが成功してからだもんな・・・。
NAISTの茶筅やMeCabやNamazuの開発者たちは、とっくにGoogleに持ってかれてるし。
気づくのおせえよ。

210 :デフォルトの名無しさん:2009/09/13(日) 16:42:16
>>185
一瞬、秋刀魚かとおもたw


211 :204:2009/09/15(火) 00:45:06
日本ってコンピュータ言語とか互換性を重視しているわりに、
携帯絵文字コードにみられる非互換で競争してしまう行動はどこからきてるんだろうか。
単に差別化するのが簡単とかそういう理由なんだろうか。

212 :デフォルトの名無しさん:2009/09/15(火) 08:55:19
ポケベルの頃に絵文字がたくさん使える機種が売れたんです。
ドコモの若手チームの功績とする読み物がウェブにもありますよ。

213 :デフォルトの名無しさん:2009/09/15(火) 09:28:20
プログラミング言語でも、いざ実装となると規格の踏み外しが多かったりとか、
日本企業製のプロダクトはそういう妙な非互換性をかかえてることが多い。

なにかをはじめるときに、既存のものをとりいれることをよしとしない変な
空気があるのか、なんなのか。
一旦非互換なものを作ると、顧客ロックインのためにしがみつく傾向もある。

世界的にも、コード共通化について意識したのは早かったのに、企業からの
参加者から縛られたくないだのなんだのの意見が多かった、と、コード会コードの
話にはあるよね。

214 :デフォルトの名無しさん:2009/09/15(火) 09:51:33
>>211
日本人お得意の、改良をしたがるんだよ。

後は囲いこみ。

215 :デフォルトの名無しさん:2009/09/15(火) 10:55:29
>日本ってコンピュータ言語とか互換性を重視しているわりに、

そもそもここがまちがい


216 :デフォルトの名無しさん:2009/09/15(火) 20:30:45
確かに。どっちかというと自分の理解できないものを無視してあたかもなかったことにすることのほうが
多いような。

217 :デフォルトの名無しさん:2009/09/16(水) 00:22:54
非互換で囲い込みってアフォだよな。
物理的に良いもので囲い込みとかのほうがよっぽどマシな結果になりそうだが、
それだけ競争が激しいということなんだろうか。

218 :デフォルトの名無しさん:2009/09/16(水) 01:06:35
DoCoMoとか自民党とかのことを思えば。

219 :デフォルトの名無しさん:2009/09/16(水) 04:31:09
競争が激しいのは客があほだから

220 :デフォルトの名無しさん:2009/09/18(金) 04:21:05
非互換に関してひとつには世に出る迄に時間がかかりすぎるから。
そして世に出てしまうとしゃにむにそれにすがってしまうから。

つまり最初に決めて行けば良いのだが,「社内」=「世の中」の人が
先に作り込みすぎてしまって方向転換が後ではできないから。

で、先に決めて行こうとすると「我れ先に足の引っ張り合い」をするので,うまくいかないと。

221 :デフォルトの名無しさん:2009/09/18(金) 07:59:27
>>220
> 非互換に関して
< 標準化しないのは

だろ。言いたいのは。
それに先にきちんと標準化しても、非互換の派生は出るぞ。

222 :デフォルトの名無しさん:2009/09/18(金) 08:09:02
売る側からすれば、ユーザ囲い込み機能を標準化してどうするんだよ・・・って感じだろ。
まあ、日本は欧米と違い、標準化の意識が薄いってのもあるけど。


223 :デフォルトの名無しさん:2009/09/18(金) 12:41:24
ようするに日本って標準化するという作業工程が下手なんだよな。
競争が激しくて足の引っ張り合いが多いんだろうけど。

最終的にユーザ側の不利益になってしまうなら、
非競争分野は標準化してそれを厳守、それ以外の要素で競争するのが望ましいと思うが、

なし崩し的に物事を進めていく傾向が強いのか、
まぁビジネスだから儲けてナンボではあるんだよね。

224 :デフォルトの名無しさん:2009/09/18(金) 23:16:20
俗流文化論的に分析してみる。

アメリカでは末端の能力が低いから、標準化をしなければやっていけない。
また、末端を束ねる立場にたつ人の能力には高いものが求められる。

日本では末端の能力が高いから、標準化なしでもなんとか出来てしまう。
また、能力の低いものが束ねる立場に立っても何とかなってしまうことが多い。

225 :デフォルトの名無しさん:2009/09/20(日) 20:30:16
日本の消費者はメーカー/プロバイダ乗り換えを考えない、自分の選択肢を狭めることに何も躊躇が無い人が多いんだと思うよ。
だから囲い込みが成功しやすいのだと思う。
これは日本のメーカー/プロバイダの品質の高さから来たものだが、消費者が信者化し貶しあう文化が生まれ、標準化の圧力が生まれてないのだと思う。

226 :デフォルトの名無しさん:2009/09/21(月) 02:34:37
日本人は単一民族だからな
みんなで力を合わせるのが苦手な人種
共通化の欲求よりも
足の引っ張り愛の
我田引水の圧力が勝ってしまう

227 :デフォルトの名無しさん:2009/09/21(月) 12:06:46
>>171
遅レスだがアイルランド・ドイツ提案に交通標識と地図用記号ってw
>>122とか将棋の全コマとか花札全種とかパソコンで使われる汎用アイコン一式とか企業のロゴとか各名詞や各動詞に対する絵文字とか追加していったらキリが無くね?

228 :デフォルトの名無しさん:2009/09/21(月) 13:56:41
杭全

229 :デフォルトの名無しさん:2009/09/21(月) 19:37:40
携帯絵文字は日本文化が色濃く出ててるから、
どの辺まですくい取るかが問題なんだろうけど。

日本の消費者は、あの顔文字じゃぁ気に入らないだろうなw
携帯電話は、従来通りキャリアごとに異なる形状でOKなんだろうか。

230 :デフォルトの名無しさん:2009/09/21(月) 20:02:30
UNICODEをシンプルに全部32bit文字としていれば、
絵文字ぐらい余った空間に簡単に置けれたのに。

一応65万文字分のコードポイントがあまっているとはいえ、
絵文字なんか入れたら足りなくなるかもな。

231 :デフォルトの名無しさん:2009/09/21(月) 20:38:12
そーいう問題じゃないだろ。

232 :デフォルトの名無しさん:2009/09/21(月) 23:28:37
世界標準は大事だと思うけど、
実際の形状を該当国・地域に強制するのは本当は良くないことなのではないか。
例えば顔文字で「スマイル」を意味するものがあったとして、
あくまでも受け手の問題なので、該当の国・地域で良い絵柄が選ばれるのが望ま
しいと思う。

実際に日本とその他の国または地域では表現上の好みの違いがあるわけで、
英語文化圏標準はこれ、日本文化圏標準はこれ、日本の九州地方はこれですと、
多段的なものであってもいいんでないの?

どの辺のドメインを区切るかというのはあるけど、わりに自由度があってしかる
べきものなのかもしれない。

世界標準なったら面白味の欠けるものになりそうなんだよな。


233 :デフォルトの名無しさん:2009/09/22(火) 23:13:23
今議論している絵文字は、あくまで既存の製品に実装されているものだけだから。
新しい絵文字を作ろうって話じゃないから。
つーか複数言語混在できないようなシステムはダメだろう

234 :デフォルトの名無しさん:2009/09/23(水) 11:45:36
>>233
アイルランド・ドイツ提案100回読み直せ

235 :デフォルトの名無しさん:2009/09/23(水) 14:45:26
絵文字といえばPDAM8の投票が終わった頃だな。
さて米・愛蘭独あたりはどんなコメントを寄せたか…

236 :デフォルトの名無しさん:2009/09/23(水) 18:45:38
文字として認識出るもの以外入れないで欲しいと常々思う。
外字って言うアイデアはシンプルで良かった。

237 :デフォルトの名無しさん:2009/09/25(金) 00:51:53
ユニコードにも外字エリアあるよね。
昔ほど必要性がなくなったかも

238 :デフォルトの名無しさん:2009/09/25(金) 10:22:55
いきなりで申し訳ないんだけど、ここの住人ならわかるかな?

AutoCADのデータを渡されたんだけど、そこに書いてある文字が

#F#R!%#6#6!!#S#E#C!% ←こんなの

この変な文字化けみたいな物をなんとかしろ!って言われたんだけど、
得たいの知らない記号みたいな物渡されても何がなんだか・・・

これが何なのか、また、どうやったら日本語として読めるのか、知恵を貸してほしいorz

239 :デフォルトの名無しさん:2009/09/25(金) 11:24:55
JISコード (ISO-2022-JP) のシフトIN/シフトOUT (エスケープシーケンス) が抜けたやつじゃないか
バイナリエディタかなんかで前後にシフトIN/シフトOUTを付加してJISコード対応のエディタかWebブラウザで開いてみ

240 :デフォルトの名無しさん:2009/09/25(金) 11:33:00
シフトIN、シフトOUTってなんだよ。
このスレの住人らしからぬ...

IN/OUTじゃなくてGOTOだ、ってその昔の和田先生のテキストにもあるだろうに。

0x1b(ESC) '$' 'B' という3バイトのシーケンスを先頭に。
0x1b(ESC) '(' 'B' という3バイトのシーケンスを末尾に。

その例だと "FR.66 SEC." だね。

241 :238:2009/09/25(金) 13:25:50
>>240
例を見てから、自分がわからないと言ってた文字を見てみると
「#」抜かせば、ある程度わかるじゃん!って事に気づいた。

JISコードって言うのかな?なんだか複雑そうで、正しい対処法はできないかもしれない。
内容量は多くないから、例を参考に睨めっこでもしながら修正していこうと思います。

「ド」がつく素人な者で、アドバイスを生かしきれなくて申し訳ないのですが、
どうもありがとうございます!

242 :デフォルトの名無しさん:2009/09/26(土) 01:22:38
>>241
こんなページを見つけたよ。
http://masaka.dw.land.to/mr/jmr.php

ここで、解読できるみたいだよ。

243 :デフォルトの名無しさん:2009/09/26(土) 14:58:37
絵文字提案に関係のある国は全部PDAM8に反対ですかそうですか。
N3681は前とどこが変わったのか分からんなあ。Oさんあたりが連載で書いてくれるかな。

244 :デフォルトの名無しさん:2009/09/29(火) 16:48:55
絵文字に便乗して、各国記号類の追加提案をしまくってるな…

245 :デフォルトの名無しさん:2009/09/29(火) 17:08:45
もうUNICODEに、国コード+その国用文字 というコードポイント作れよw
何万文字かを国ごとに割り当て、その国で自由に使い方を決める。


246 :デフォルトの名無しさん:2009/09/29(火) 23:38:23
てらISO 2022w

247 :デフォルトの名無しさん:2009/09/29(火) 23:51:18
絵文字の話が出ていたと思うけど、これは自然に出た発想だと思うよ
英語圏のサイトにあるチャットには大体絵文字がついてたりするし、日本一国の携帯にクローズアップしてるような印象を与えたのはマスコミに責任があるかなあ

248 :デフォルトの名無しさん:2009/09/30(水) 00:02:15
だって実際日本一国の携帯に対応するために提案されたんだし。

249 :デフォルトの名無しさん:2009/09/30(水) 01:02:56
UNICODEって合成文字って概念があるでしょ?
日本語なら、「は」と「゛」で「ば」とか
ウムラウトとかなんとかいうの。

それを拡張して、たとえば、32ドット×32ドットの格子の
升目一個を塗りつぶした形を合成文字にして
合成文字を複数組み合わせて、絵を作るという発想

250 :デフォルトの名無しさん:2009/09/30(水) 01:15:46
デメリットをよりもメリットがあるのか?それ

251 :デフォルトの名無しさん:2009/09/30(水) 01:28:53
犬+首輪=首輪を付けた犬
こんな合成文字でプレインテキスト書きたいです

252 :デフォルトの名無しさん:2009/09/30(水) 02:47:06
犬+首輪+横向き+吠える+擬人化 の絵文字ください。

253 :デフォルトの名無しさん:2009/09/30(水) 09:43:24
 |+-夕胃ノしよ"ぁぃハ合成文字っつーかまmどくせ

254 :デフォルトの名無しさん:2009/09/30(水) 10:28:24
>>252
人狼ですね、判ります。

255 :デフォルトの名無しさん:2009/09/30(水) 11:12:14
狼+林檎+横向き+萌える+擬人化 の絵文字ください。

256 :デフォルトの名無しさん:2009/09/30(水) 20:58:07
ある意味で当事者とも言える、キャリアの人が書いた文書。

世界のケータイ事情「ケータイ絵文字がグローバルに」
http://k-tai.impress.co.jp/docs/column/worldstrend/20090930_318157.html

257 :デフォルトの名無しさん:2009/09/30(水) 21:05:47
鬼と天狗はさすがに日本も「せめて名前にJapaneseをつけろ」とツッコミ入れてたっけ

258 :デフォルトの名無しさん:2009/10/01(木) 13:28:28
絵文字より「.日本」をどうにかしろよと思う
レイヤー違う話だけど

259 :デフォルトの名無しさん:2009/10/01(木) 17:22:35
窓の杜 - 【NEWS】マイクロソフト、Windows 7のMS系フォントをXP互換に戻すパッケージを公開

ttp://www.forest.impress.co.jp/docs/news/20091001_318719.html

ワラタ

260 :デフォルトの名無しさん:2009/10/01(木) 19:13:42
>>259
TrueTypeやOpenTypeって字形やglyphを選ぶ機能持ってるのに、これフォントごと入れ替えてるの?
字形選択機能に対応してるアプリはそのままで良いし、そうでない物はフォントレンダラに対して
デフォールトの字形を設定する手段を提供すれば良いと思うんだけど...

261 :デフォルトの名無しさん:2009/10/01(木) 20:55:28
レンダラで処理されるサイズではなくて内蔵ビットマップを使うサイズのグリフの問題だから、だと思う。

ttp://www.microsoft.com/japan/powerpro/TF/column/ro2_01_3.mspx
<< MS UIゴシック / MS P ゴシックの変更 >>

こんな話も。

262 :デフォルトの名無しさん:2009/10/03(土) 00:21:58
WindowsはIVSに対応しないんだろうか…

263 :デフォルトの名無しさん:2009/10/03(土) 01:03:37
IVSってなんのこと?

264 :デフォルトの名無しさん:2009/10/03(土) 01:06:22
異字体セレクタ

265 :デフォルトの名無しさん:2009/10/03(土) 01:09:35
ふーん。初めて聞いた。

266 :デフォルトの名無しさん:2009/10/03(土) 05:09:39
だっせ

267 :デフォルトの名無しさん:2009/10/03(土) 05:41:51
おっくれてる〜

268 :デフォルトの名無しさん:2009/10/03(土) 18:51:34
>>108
Amd.2で修正される前の話。知る限りこの時点では誰も指摘してなかった。
http://academy6.2ch.net/test/read.cgi/gengo/1040929046/170
USIを最初に指摘したのもやっぱりAmd.7よりはるか大昔(2chじゃないけど)。
> それでも足りないのがある?
USIを含んだJIS X 0213非漢字のExtended Collection

UTS #37の公開レビューだって最初の締め切り直前に某所でコメントするまで
日本じゃ全くといっていいほど話題になってなかった。

269 :デフォルトの名無しさん:2009/10/03(土) 19:17:11
Unicode 5.2.0 リリース
http://www.unicode.org/versions/Unicode5.2.0/
今回もちゃんとレビューコメントは反映されてた。
「個別に返事しない」と言っているにもかかわらず返事くれたし

270 :デフォルトの名無しさん:2009/10/05(月) 23:01:12
age

271 :デフォルトの名無しさん:2009/10/06(火) 00:11:42
>>269
数年チェックしてなかったけど、Ext.C収録されたのね。ずいぶん数減ったなぁ。
昔は面をまるごと使いかねないくらい大量にあった気がする。

272 :デフォルトの名無しさん:2009/10/06(火) 08:54:31
>>269
Windows版はどこでダウンロードするの?

273 :デフォルトの名無しさん:2009/10/06(火) 10:39:11
>>272

274 :デフォルトの名無しさん:2009/10/06(火) 12:06:30
ステレオタイプというか典型的な質問に、全力でワロタw

275 :デフォルトの名無しさん:2009/10/07(水) 22:49:37
http://mainichi.jp/select/today/news/20091008k0000m030036000c.html
文字コードはどうすんだろう。

276 :デフォルトの名無しさん:2009/10/07(水) 23:14:53
そりゃ、名前の正式な表記が今やっと分かったって話で、
新しいハングルや漢字が生まれたわけじゃない。既存のでOK。

277 :デフォルトの名無しさん:2009/10/08(木) 01:27:28
275が言ってるのは、北朝鮮の文字コード規格KPS 9566のことだと思われ。

当然、また新たに3文字が追加されるんだろうw



278 :デフォルトの名無しさん:2009/10/08(木) 03:39:47
>>275 のは U+C6B4 → U+C740 という話。



279 :デフォルトの名無しさん:2009/10/08(木) 05:35:46
北朝鮮でもUNICODE使ってるのか
南朝鮮のと同じじゃだめなん?

280 :デフォルトの名無しさん:2009/10/08(木) 20:54:25
N3684は各国いろんなこと言ってるけど、要求が衝突してるのは
やっぱり例の国旗用互換文字か。
こりゃ東京でもad-hoc、下手すりゃPDAM 8.2コースか。

しかし日本もこの機会に入れたい記号類、何かないのかね。

281 :デフォルトの名無しさん:2009/10/08(木) 23:00:21
ぜんぜん日本語と関係ないけど、電源スイッチの記号は入らないのかねえ
上が切れた○に棒が刺さってるようなやつ

282 :デフォルトの名無しさん:2009/10/09(金) 09:55:21
こんな顔だったかい?
□□□■□□□
□■□■□■□
■□□■□□■
■□□□□□■
■□□□□□■
■□□□□□■
■□□□□□■
□■■■■■□

283 :デフォルトの名無しさん:2009/10/09(金) 11:24:17
メニューキーもきぼん
■■■■■■■■□□□□
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□
■■□□□□■■■■□□
■■■■■■■■■□□□
■□□□□□□■□□■□
■□■■■■□■□□□■
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□

284 :デフォルトの名無しさん:2009/10/10(土) 00:31:01
文字コードのことわかってないおとこ大杉。。。

285 :デフォルトの名無しさん:2009/10/10(土) 01:12:17
良くわからないけど、結局、全世界の文字を集めたら32ビットでたりそうなの?

286 :デフォルトの名無しさん:2009/10/10(土) 01:49:15
最近絵文字が流行り出したから32bit空間は枯渇したらしい

287 :デフォルトの名無しさん:2009/10/10(土) 09:03:20
ここいらで絵文字が絵なのか文字なのかはっきりさせとくべき
ちなみに俺は絵文字は絵であって文字コードに入れるのはナンセンスだと思ってる

288 :デフォルトの名無しさん:2009/10/10(土) 09:23:01
Unicodeの空間は21bitsですよ

289 :デフォルトの名無しさん:2009/10/10(土) 14:17:07
21bitあれば210万近く文字使えるんだから
10万文字ぐらい絵文字にくれてやっても良いじゃないか?

290 :デフォルトの名無しさん:2009/10/10(土) 14:26:45
だがことわる

291 :デフォルトの名無しさん:2009/10/10(土) 15:30:06
21bit全部に文字が割り当てられるわけじゃなくて、実際に定義or予約されているのは110万程度。
10万は面をまたぐことになるのでアレだけど、1面丸ごとpictgramsに割り当てるのはアリかもね。

292 :デフォルトの名無しさん:2009/10/10(土) 16:33:19
何か基準がないとなしくずしに絵文字!絵文字!絵文字!

293 :デフォルトの名無しさん:2009/10/10(土) 23:11:38
今回限りにしてくれるんなら多少こういう妙なものが入ってるのも
おもしろいかなあと思うけど、
このまま今後ずるずるとこういうものが入り始めるのは御免こうむりたい

294 :デフォルトの名無しさん:2009/10/11(日) 03:41:07
絵文字を入れるのは変体仮名と平仮名・片仮名の合字すべてを入れてからにしてくれよ。
そっちの方が先だろうが。

295 :デフォルトの名無しさん:2009/10/11(日) 03:51:39
n3695渋いねえ。簡体字って歴史浅いくせにもう廃止された字があるのか。
しかしよくこんなの見つけてくるわホント。

296 :デフォルトの名無しさん:2009/10/11(日) 07:21:17
ユニコードの体系変わったら
OS側も合わせなきゃ意味ないよね?
フォントとかも

297 :デフォルトの名無しさん:2009/10/11(日) 07:41:08
>>295
1935年の第一批簡体字、シンガポールで使われていた簡体字、それと二簡字か。
二簡字はわりと有名だけど、1935年の第一批簡体字の方は見たことなかった。
ソースのスキャンが欲しいな。

298 :297:2009/10/11(日) 08:05:33
ってPDFの後ろに画像ついてたわ。俺あほす

299 :デフォルトの名無しさん:2009/10/11(日) 13:37:45
将来、漢字みたいに使う絵文字だけの言語もできるかもしれんしな。ないけど

300 :デフォルトの名無しさん:2009/10/11(日) 13:48:04
象形文字とか、古代の文字はそんな感じじゃね?

301 :デフォルトの名無しさん:2009/10/11(日) 13:50:18
文字の退化。

302 :デフォルトの名無しさん:2009/10/11(日) 14:14:41
脳の退化

303 :デフォルトの名無しさん:2009/10/11(日) 22:29:43
中国のナシ族のトンパ(巫師)が使う文字は、
一応現役の象形文字だろうね

304 :デフォルトの名無しさん:2009/10/11(日) 23:02:28
よし、ここで俺が、
数式文字と音符をUnicodeに含めることを提案する!

305 :デフォルトの名無しさん:2009/10/11(日) 23:08:08


306 :デフォルトの名無しさん:2009/10/11(日) 23:13:15
>>305
ちげーよ。

音階ごとだよ。

307 :デフォルトの名無しさん:2009/10/11(日) 23:23:04
じゃあ聞くが、音階ごとだと何個必要なんだ?

308 :デフォルトの名無しさん:2009/10/12(月) 00:11:51
たしか全角で911とかをwindingsで表示すると

309 :デフォルトの名無しさん:2009/10/12(月) 00:38:20
911って緊急通報用電話番号か?

310 :デフォルトの名無しさん:2009/10/12(月) 00:40:35
>>307
しらね。

楽譜で表せる程度なんだから
たいした数じゃないだろ?

311 :デフォルトの名無しさん:2009/10/12(月) 00:45:10
>>310
数えてみろよ
たいした数じゃないんだろ?

312 :デフォルトの名無しさん:2009/10/12(月) 01:16:48
まあまあ、楽譜って世界共通だという印象だけど、
それが入っていないってのはなんか不思議な感じがする。
アナログ的なものだからあんまりコンピュータと同時に利用する場面がないのかしら。

313 :デフォルトの名無しさん:2009/10/12(月) 01:21:34
音符はもうあったはず

314 :デフォルトの名無しさん:2009/10/12(月) 01:22:55
だから具体的に音階ごとだと何種類入れればいいと思ってんだ?
それに、例えば32x32程度のドットで表現できる?64でもいいよ?
ていうか、楽譜みたことあんの?

315 :312:2009/10/12(月) 01:32:21
音階について詳しく知らないのだが、
もしかして低音と高音ともに限界のない表現方法だったりするの?

まぁ普段の生活で必要な程度の記号の範囲で良いとおもうけどね。

316 :デフォルトの名無しさん:2009/10/12(月) 01:37:02
人間の可聴範囲でも20,000Hzなんだから
1Hzに1文字割り当てたとしても、
2万個もいかんだろ?たったこんだけ。

317 :デフォルトの名無しさん:2009/10/12(月) 01:41:07
文字コードはあくまで文字コードであって
グリフは規定されて無いから、32×32ドットといわれても意味が無い。

318 :デフォルトの名無しさん:2009/10/12(月) 01:41:29
使わない文字に2万も浪費するって時点でフォント屋がキレそうだが
楽譜でふつうに使われる和音と長さ、連符休符など組み合わせるとウンザリするな

319 :デフォルトの名無しさん:2009/10/12(月) 01:43:47
>>317
素直に負けをみとめろよw

320 :デフォルトの名無しさん:2009/10/12(月) 02:07:29
楽譜ってそんなに体系化されてないだろ
人によっても色々書き方違うし
だからってITの分野とちがって標準化すればいいってもんでもないしな
普通に記号だけでいいと思うよ

321 :デフォルトの名無しさん:2009/10/12(月) 02:16:16
音階が欲しいって言ってんじゃん。

322 :312:2009/10/12(月) 02:20:51
まぁ、あれだ。
単一の記号で表現できるものと、できないものがあるから、
文字コードとして適正のあるものと無いものがあるというところかな。


323 :デフォルトの名無しさん:2009/10/12(月) 02:24:31
なんだこいつ

324 :デフォルトの名無しさん:2009/10/12(月) 03:25:47
>>323
ふぁびょるなよw
もうちっと楽しませろクズw

325 :デフォルトの名無しさん:2009/10/12(月) 06:54:49
「五線譜とその第一線上の四分音符」なんてのは
音楽系の平文に埋め込まれた利用例あるだろな。

326 :デフォルトの名無しさん:2009/10/12(月) 07:26:45
そういうのはXMLの仕事だったはずでしょ。

327 :デフォルトの名無しさん:2009/10/12(月) 08:25:12
携帯絵文字が入って、化学記号や数式記号が入らない理由が見つからない。

328 :デフォルトの名無しさん:2009/10/12(月) 09:01:59
♪ とか♪とか欲しい
 ̄   ・

329 :デフォルトの名無しさん:2009/10/12(月) 10:37:12
>>328
文字化けしたらスマン
𝅘𝅥𝅮𝅽 U+1D160 + U+1D17D
𝅘𝅥𝅮𝅭 U+1D160 + U+1D16D

330 :デフォルトの名無しさん:2009/10/12(月) 12:41:29
一度でもまともに楽譜を見たことがあるなら、音階ごとに四分音符を並べるだけのものなんて無意味に近いと判りそうなもんだが。
MusixTexのマニュアルとか読んでみろよ。

331 :デフォルトの名無しさん:2009/10/12(月) 18:45:48
コルトレーンとかもうね...
http://www.youtube.com/watch?v=2kotK9FNEYU

332 :デフォルトの名無しさん:2009/10/12(月) 19:30:42
phpからPEARのMail.phpを使用してWeb上から
ソフトバンクのケータイに日本語のメールを送信すると
文字化け?してるのかわかりませんが日本語の部分が表示されません。

ソフトバンクのケータイはutf-8じゃないといけないとどっかのサイトで見つけたので
mb_language("ja");
mb_internal_encoding("UTF-8");
mb_convert_encoding($Message,"UTF-8","auto");
のように変換を行ったのですが、うまく変換されてないのか成功しません。

変換ができてないのか、それとも文字コードの指定事態が間違ってるかすらも検討がつかなくて
どーすればいいかわからない状況です。

333 :デフォルトの名無しさん:2009/10/13(火) 01:02:39
>>321
音階にも種類があるでよ?

334 :デフォルトの名無しさん:2009/10/13(火) 01:16:44
12平均律だけならいいけど、31とか53平均律なんてものも世界には存在してだな

335 :デフォルトの名無しさん:2009/10/13(火) 01:20:14
まだやんの?その話

336 :デフォルトの名無しさん:2009/10/13(火) 01:25:04
>>332
webprog板だかで聞くべし

337 :デフォルトの名無しさん:2009/10/13(火) 11:21:41
絵文字は文字で(絵じゃない)、音符は絵の一種に見える(文字でも記号でもない)俺は異端かなぁ……

338 :デフォルトの名無しさん:2009/10/13(火) 11:31:07
敢えて言おう。音符を入れるくらいなら気象記号を入れてみろ。
どちらも手書きであるが故の美しさがあると言う点で、絵のようなものだ。

339 :デフォルトの名無しさん:2009/10/13(火) 14:46:20
地図記号が絵文字関連で幾つか入るようだから、天気図記号が入っても悪くはないはず。

ただ、こういうのってXMLとかでの実用が前提じゃなかったっけ?知らんけど。

340 :デフォルトの名無しさん:2009/10/13(火) 15:01:12
国ごとに微妙に違うからなあ

341 :デフォルトの名無しさん:2009/10/13(火) 20:26:24
>>338
手書き故の美しさを言い出したら、
文字全部そうじゃね?

342 :デフォルトの名無しさん:2009/10/13(火) 20:28:43
地図記号って、おまんじゅう工場も入るのか?

343 :デフォルトの名無しさん:2009/10/13(火) 20:47:41
おまん工場

344 :デフォルトの名無しさん:2009/10/16(金) 00:37:32
シフトJISの外字領域とMS932の外字領域のコード範囲は同じなのでしょうか?

345 :デフォルトの名無しさん:2009/10/16(金) 11:47:37
JISのシフトJISに外字領域は無い。

346 :デフォルトの名無しさん:2009/10/21(水) 09:33:11
>>47
CJKV Information Processing の2版がgoogleブックに登場してた。
Ebook Release: June 2009
この時期に登場したのか?

ttp://books.google.co.jp/books?id=SA92uQqTB-AC
ttp://oreilly.com/catalog/9780596514471/preview

347 :デフォルトの名無しさん:2009/10/22(木) 18:17:37
最近更新がないと思ったら、小形さんこんなの準備してたんだ。
とうとう単なる傍観者じゃいられなくなりましたか。
しかし来週はこりゃ絵文字の議論だけで終わりそうな勢いだ。

348 :デフォルトの名無しさん:2009/10/22(木) 21:20:19
http://www.otacky.jp/files/oald7/oald7-pkg.el
ここのページにある記号を自作プログラムで扱いたいんですけど、
firefoxでutf-8で記号が読めるので
テキスト文書を(IE8)でutf-8にして文書全部をコピーして
貼り付けて見たところ数割くらいが?マークになってしまいます.
utf-8って複数あるんでしょうか?どうやったら保存できるんでしょうか.
osはvistaです.

349 :デフォルトの名無しさん:2009/10/22(木) 21:23:02
どこに貼り付けたんだ?
貼り付けた先のアプリケーションがUnicodeに対応していないのでは?

350 :デフォルトの名無しさん:2009/10/22(木) 21:29:49
テキスト文書utf8_1.txtというファイルを作って貼り付けたんですけど
クリップボード他入出力がダメなんでしょうか

351 :348:2009/10/22(木) 21:39:53
すいません、
ブラウザからそのファイルへのリンクを右クリックしてとりあえず
情報が失われないように保存は出来たんで、また自分で
色々やってみますお騒がせしました

352 :デフォルトの名無しさん:2009/10/26(月) 06:17:08
あれで参加者の反発を買わないよう配慮したつもりなのか…

353 :デフォルトの名無しさん:2009/10/26(月) 06:24:13
>>347
顔文字ジェネレータ面白いなw
http://fonts.jp/emoji/images/00.02.05.23.26.27.png
http://fonts.jp/emoji/images/00.02.04.25.34.png
無理とは分かっていても合字グリフの方向へ持ってって欲しいなと感じてしまったw

354 :デフォルトの名無しさん:2009/10/26(月) 06:42:20
http://fonts.jp/emoji/images/00.02.16.23.33.png
http://fonts.jp/emoji/images/00.02.05.25.26.32.png
http://fonts.jp/emoji/images/00.02.03.16.32.png
http://fonts.jp/emoji/images/00.02.08.23.34.png
http://fonts.jp/emoji/images/00.02.15.19.33.png

355 :デフォルトの名無しさん:2009/10/26(月) 06:55:44
顔だけじゃなくて胴体も入れようぜ→それなんてサウスパークジェネレーター?

356 :デフォルトの名無しさん:2009/10/27(火) 13:19:23
PSOのシンボルチャットを連想したのは私だけではないはずだ。

357 :デフォルトの名無しさん:2009/10/28(水) 01:00:41
グリフ変更というeditorialな部分は通ったけど
その他のtechnicalな部分は全部預かられてしまったと

んーどうだろ、一応顔は立ててもらえたようだけど

358 :デフォルトの名無しさん:2009/10/29(木) 00:05:59
>>356
確かにPSOのシンボルチャットっぽいw

359 :デフォルトの名無しさん:2009/11/01(日) 18:37:16
EUCもSJISもJISも面倒見てくれるktermが、UTF-8以外は排除するxtermに駆逐されたのは納得いかない

360 :デフォルトの名無しさん:2009/11/03(火) 07:24:03
javaでWindows31-J⇔Unicodeの変換で、外字領域を含めて変換できない文字はあるのでしょうか?


361 :デフォルトの名無しさん:2009/11/03(火) 12:17:25
バージョンによっても違うからここ読め
http://www.ingrid.org/java/i18n/encoding/

362 :デフォルトの名無しさん:2009/11/03(火) 17:00:14
>>361
お答えありがとうございます。
Java5なのですが、のっていなかったです。
Shift-JISでいうところの外字領域は対応しているのは実際に確認しました。
変換に失敗するとまずいので、保障が欲しいのです。
また、変換できない文字があれば事前にチェックをしたいので、変換できない文字を知りたいのです。

363 :デフォルトの名無しさん:2009/11/03(火) 17:07:45
全部変換してみりゃいいだろう

364 :デフォルトの名無しさん:2009/11/03(火) 18:22:33
>>362
想定する文字セットが提示されていれば、
その中で変換できない文字を調べられるけど
漠然と変換できない文字って言われてもな……

365 :デフォルトの名無しさん:2009/11/03(火) 18:27:53
Windows 31Jってデーヴァナーガリー文字とかも含んでるの?


366 :デフォルトの名無しさん:2009/11/03(火) 18:32:31
Windows31JからUnicodeに行って戻ってこれれば十分なのか
⇔記号の見た目通り相互変換を意味しているのか


367 :デフォルトの名無しさん:2009/11/03(火) 23:50:44
Windows3.1Jってまた懐かしいなw


368 :デフォルトの名無しさん:2009/11/04(水) 01:11:03
>>365
ないよ。要はシフトJISだし。

369 :デフォルトの名無しさん:2009/11/04(水) 01:33:56
外字ありだぜ?

370 :デフォルトの名無しさん:2009/11/04(水) 04:24:15
>>367
3.1・・・ってまさか・・・


勘違いしてる気がするw

371 :デフォルトの名無しさん:2009/11/04(水) 18:25:03
OS(XP)の外字エディターで、U+21336の文字(土並)を参照表示させる事は可能?

372 :デフォルトの名無しさん:2009/11/08(日) 21:23:05
外字エディタってそういう風に使うものなの?

373 :デフォルトの名無しさん:2009/11/09(月) 10:59:59
単?

374 :デフォルトの名無しさん:2009/11/09(月) 20:02:26
>>372
Windowsの外字エディタは字形の原形として既存のフォントからグリフを読み込んで
そのビットマップをちょこちょこいじって外字を作ることができるんですよ。読み込み
インタフェースがBMPの符号位置しか選択できないように見えるので、何かSIPの
文字を読む方法ない?っていう相談なんじゃないかな。

>>371
Windows XP SP2しか手元にないけど、SimSun (FounderExtended)から
SIPの漢字を読み取る方法はわかんなかった。MS-IMEの「文字一覧」もそう
だけど、どうもこれの設計はcp932とBMPだけで完結しちゃってる気がする。

この漢字はHKSCSにも入っているようなので、HKSCS対応のフォントだと
強引にBMPのどっかの符号位置にマップしてたりしませんかねえ。。。

375 :デフォルトの名無しさん:2009/11/09(月) 22:38:02
>>374
>既存のフォントからグリフを読み込んで
なるほど、知らなかった。ありがとう。

>>371
374の言う通り、HKSCS対応のフォントでU+EB00に[土並]があった。
フォント名で言えばMingLiU_HKSCSとかDfSongStdとかMing(ISO 10646)とか。

376 :デフォルトの名無しさん:2009/11/10(火) 21:25:30
Oさん意気揚々ですな

377 :371:2009/11/17(火) 00:59:07
>>374>>375
thx
試してみます

378 :デフォルトの名無しさん:2009/11/18(水) 18:21:34
UTF-8をSHIFT-JISに変換するコードどこかないでしょうか?
iconv UNIX,LINUX系統以外


C/C++
Windows VC++ 環境で

379 :デフォルトの名無しさん:2009/11/18(水) 20:24:41
MultiByteToWideChar()
WideCharToMultiByte()

380 :デフォルトの名無しさん:2009/11/19(木) 00:30:54
自分で書けばええやん

381 :デフォルトの名無しさん:2009/11/19(木) 00:57:52
>>378
http://pc12.2ch.net/test/read.cgi/tech/1214657360/715
メモリ解放は自分でやれ

382 :デフォルトの名無しさん:2009/11/29(日) 15:50:10
Win7では異体字セレクタ対応してた。
対応フォントは付いてないけどY.Ozフォント入れてメモ帳とOpenOfficeで出来た。
モンゴル文字や数学記号のBMPの異体字セレクタを使ったものは使えるかどうか知らんが、とりあえずU+E0100〜の漢字用異体字セレクタは使えるみたい。

383 :デフォルトの名無しさん:2009/11/29(日) 19:44:29
fdam8の1F61Dはこういうデザインなのかはたまたゴミが混じっているのか…

384 :デフォルトの名無しさん:2009/11/29(日) 19:46:03
fdam8じゃないやfpdam8だった

385 :デフォルトの名無しさん:2009/11/30(月) 01:52:14
>>383
見てみた。ワラタ

386 :デフォルトの名無しさん:2009/11/30(月) 11:26:47
毛が抜けてショボーンな波平

387 :デフォルトの名無しさん:2009/12/04(金) 08:10:10
unicode対応でWindowsプログラムを作成しているのですが、
英語以外、日本語やアラビア語などすべての文字が使える
フォントを教えてください。


388 :デフォルトの名無しさん:2009/12/04(金) 22:54:15
ない。

389 :デフォルトの名無しさん:2009/12/04(金) 23:02:43
フォント作成の会社に問い合わせればいいんじゃない?

390 :デフォルトの名無しさん:2009/12/05(土) 00:24:02
ttf/otfの仕様上、全部込みのフォントを作ること自体無理。
ただ漢字以外全部なら作れるかもしれない。

391 :デフォルトの名無しさん:2009/12/05(土) 00:57:16
まずはArial Unicode MSから。

392 :デフォルトの名無しさん:2009/12/05(土) 06:10:41
code2000でも使っておけ

393 :デフォルトの名無しさん:2009/12/07(月) 20:30:47
失礼致します。

現在、「Unicode」に収録されていない「GB18030」の文字を調査しております。
調べた結果ではチベット語や康熙字典、少数民族で使われている特殊漢字が
未収録らしいとうことしかわからず、具体的な文字と文字コードを見つる
ことができませんでした。

未収録の具体的な文字とそのGB18030の文字コードを1文字でもいいので知りたいのです。
ご存知の方がおりましたらどうかご教授して頂けないでしょうか。

394 :デフォルトの名無しさん:2009/12/07(月) 21:58:06
中国人にでも聞けば?

395 :デフォルトの名無しさん:2009/12/08(火) 07:29:21
Adobeの中の人あたりとかが知ってそうだな。
小形さんあたりに知ってそうな人紹介してください、って頼めば、教えてもらえるんじゃないか?

396 :デフォルトの名無しさん:2009/12/08(火) 08:04:35
なーんか、ろくすっぽ英語も中国語も読まない上に、
ネットで漁ることだけを「調べる」と言い切ってる某ブログの人みたいだな。。。。

OPACで関連文献がありそうな図書館に足を運んだり、または
赤坂の日本規格協会の海外規格ライブラリとかはちゃんと調べたの?

397 :デフォルトの名無しさん:2009/12/08(火) 20:00:54
>>393
全部入ってるだろ。

398 :デフォルトの名無しさん:2009/12/09(水) 02:44:02
>>393
http://www.google.co.jp/search?hl=ja&lr=&num=50&q=gb18030+%E4%B8%80%E8%A6%A7
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1010865940
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1210910707
よくわかんないけど2番目のマッピングテーブル見て3番目のフォント調べればあるんじゃないの?

399 :デフォルトの名無しさん:2009/12/09(水) 11:41:44
それはテーブルもフォントも2000年版ベースだな。
いずれにせよ全部Unicodeに入ってるだろ。

400 :デフォルトの名無しさん:2009/12/09(水) 17:45:53
>>393
もしかしてGBKの
A98A→到底漢字には見えない点々の集まり
FE5D→常の冠の部分チョンチョンチョンみっつ
とかの文字の事じゃない?
GBKでは未定義だけどGB18030では全ての文字がUnicodeで定義されているよ(A98A→U2FF0のように)

401 :デフォルトの名無しさん:2009/12/09(水) 18:09:01
393です。

皆様方ご教授下さり有難うございます。
396さんの仰るとおりネット上で調べただけであり、文献など
そのようなものがあったことをを全く知らずお恥ずかしい限りです。
GB18030は全ての文字がUnicodeで定義されているのですね。
調べた上で分かったといっていた内容は古い情報だったのでしょうか。

長々と失礼しました。改めまして、皆様方有難うございました。

402 :デフォルトの名無しさん:2009/12/16(水) 15:24:16
シフトJISのGB2312版(シフトGB?)みたいなコードセットってあるの?

403 :デフォルトの名無しさん:2009/12/16(水) 18:41:44
安岡センセのあれはつまりGoogle以外はBMPしか通らないってことなのかな。

404 :デフォルトの名無しさん:2009/12/16(水) 23:34:17
ttp://ja.wikipedia.org/wiki/UTF-8#.E3.82.A8.E3.83.B3.E3.82.B3.E3.83.BC.E3.83.89.E4.BD.93.E7.B3.BB
1B U+0000...U+007F 0xxxxxxx (00-7f) 07bit
2B U+0080...U+07FF 110yyyyx 10xxxxxx (c0-df)(80-bf) 11bit
3B U+0800...U+7FFF 1110yyyy 10yxxxxx 10xxxxxx (e0-ef)(80-bf)(80-bf) 16bit
4B U+10000...U+1FFFFF 11110yyy 10yyxxxx 10xxxxxx 10xxxxxx (f0-f7)(80-bf)(80-bf)(80-bf) 21bit
だと。

405 :デフォルトの名無しさん:2009/12/17(木) 00:22:32
>>402
高電社の日中翻訳ソフトとかは、Windows 98時代までは
GB 2312 をShift_JIS流にして日本語Windowsで無理やり中国語を使ってたね。

406 :デフォルトの名無しさん:2009/12/17(木) 09:25:58
>>405
てことは、中国語版MS-DOSやWindowsでは、GB18030以前ないしUnicode以前は
ふつうはEUC-CN使ってたの?

407 :デフォルトの名無しさん:2009/12/17(木) 10:32:56
なぜ「てことは」になるのかわからん。
Shift_JIS流だとあるのに、なぜEUC-CN?

408 :デフォルトの名無しさん:2009/12/17(木) 22:41:58
>>406
こんな低レベルな質問をする人が402だったなんてショックです。
てかコードページも知らないで>>402の質問をする本意はなんなんだ?

409 :デフォルトの名無しさん:2009/12/17(木) 22:43:05
MS-DOS 5.0〜WindowsXPまでのコードページ
ttp://msdn.microsoft.com/en-us/goglobal/cc563921.aspx
Supported Code Pages (コードページなしは変換)
ttp://msdn.microsoft.com/en-us/library/aa288104(VS.71).aspx
Code Pages Supported by Windows (コード表)
ttp://msdn.microsoft.com/en-us/goglobal/bb964654.aspx

410 :デフォルトの名無しさん:2009/12/17(木) 22:59:59
>>405
Shift_JIS流って、
Shift_JISのJIS X 0201 kanaに相当する部分は何が入っていたの?

411 :デフォルトの名無しさん:2009/12/17(木) 23:01:11
うるさいな

412 :312:2009/12/17(木) 23:07:42
そういえば、常用漢字表が2010年に改訂するって小耳に挟んだんですが、
具体的に困ることってあるんですか?

413 :デフォルトの名無しさん:2009/12/17(木) 23:11:55
http://itpro.nikkeibp.co.jp/article/COLUMN/20091209/341831/

414 :デフォルトの名無しさん:2009/12/17(木) 23:20:00
この記事わかりずらいですね。だれか簡単に翻訳してw


415 :デフォルトの名無しさん:2009/12/17(木) 23:22:37
ならば、君には関係の無い話なんだよ

416 :デフォルトの名無しさん:2009/12/17(木) 23:28:52
要約:「常用漢字にシフトJIS範囲外の文字が入る。困った」

そんな文字使わなきゃいいんだけど、常用漢字に入ると名前に使えるよ
うになるので人名を扱うシステムでは将来困るね。


417 :デフォルトの名無しさん:2009/12/17(木) 23:34:56
無知で申し訳ないけど、
常用漢字という定義は、公共なシステムで例えば住民基本台帳とかそういうので
サポートされるという意味になるの?

418 :デフォルトの名無しさん:2009/12/17(木) 23:36:46
違う
プログラム的にはまったく関係が無い

419 :デフォルトの名無しさん:2009/12/18(金) 04:15:01
>どうしても「??」がサポートできそうにないなら、その旨を文化審議会国語分科会に陳情する、という手も残されている。

何で一OSメーカーの怠慢を文化審議会が肩代わりしないといけないんだよ。

420 :文字化けしちゃったよ:2009/12/18(金) 04:22:04
上の引用文中にある
?? は ��

421 :デフォルトの名無しさん:2009/12/18(金) 05:00:47
「XPのメモ帳はサロゲートペアを2つの文字として扱ってしまう」というのが
何のことかよく分からん。
今XP sp3のメモ帳で試してみたけど、ちゃんと1文字扱いされてる。

422 :デフォルトの名無しさん:2009/12/18(金) 08:04:33
>>419
常用漢字表の標準字体に、
使われてないタイプを採用する文化審議会がおかしい。

423 :デフォルトの名無しさん:2009/12/18(金) 08:51:01
>>421 確かにXPはサロゲートペアにはだいぶ前から対応してた気がするな。

424 :デフォルトの名無しさん:2009/12/18(金) 10:45:17
>>423
確かに気がしますね。

425 :デフォルトの名無しさん:2009/12/18(金) 13:03:30
MSはサロゲート対応早かったよ
XP+Word 2000という組み合わせでもサロゲートペアの文字が使えてた

426 :デフォルトの名無しさん:2009/12/19(土) 00:39:28
Surrogate Support in Microsoft Products
ttp://unicode.org/iuc/iuc18/papers/a8.ppt

ソフトによって、消すとき二回消さないといけないとか、あったかも。

unicodeの表示処理は、uniscribe(usp10.dll)経由だから、
バージョンアップで合字とかも対応できたりする。
ttp://ja.wikipedia.org/wiki/Uniscribe
ttp://charset.info/surrogate.html

関係ないけど、改定常用漢字表の記事その2
ttp://internet.watch.impress.co.jp/docs/column/jouyou/20091217_336436.html


427 :デフォルトの名無しさん:2009/12/19(土) 02:02:32
文章を書く時に、常用漢字表という枠組みを意識している人って
どれぐらいいるんだろうね。

428 :デフォルトの名無しさん:2009/12/19(土) 02:11:21
役人、新聞編集、教科書ライター、学校職員

429 :デフォルトの名無しさん:2009/12/19(土) 04:14:01
Unicodeのメジャーバージョンアップに、10646の改訂に、
Shift_JISでは扱えない字を含む常用漢字表。

来年は色んな点において節目の年になりそうだ。

430 :デフォルトの名無しさん:2009/12/19(土) 04:25:20
大抵のかな漢字変換ソフトには常用漢字や学年別学習漢字での制限があるしな。

431 :デフォルトの名無しさん:2009/12/19(土) 12:31:13
バックエンド(DBなど)は、http://ja.wikipedia.org/wiki/Shift_JIS-2004
みたいな拡張エンコードも採用されてるけど、フロントエンドは互換性の問題でないよな。


叱のロ七ってUnicodeでなんで別コードになったんだっけ?
ttp://homepage.mac.com/ogwata/.Public/0213_2004add.pdf

Unicodeが既存の互換用以外1文字1コードから1字形1コード認める方針変わって
例示の変更後、Unicodeに申請したんだっけ?

432 :デフォルトの名無しさん:2009/12/19(土) 13:41:42
JIS X 0213:2004 のほうが後なの?

433 :デフォルトの名無しさん:2009/12/21(月) 13:15:07
Extension B(Unicode 3.1)は2001年。
20B9Fは康煕字典ソースで53F1とはnon-cognate。

434 :デフォルトの名無しさん:2009/12/21(月) 14:44:53
他人の空似なのか。やっぱり無理筋だ。

435 :デフォルトの名無しさん:2009/12/22(火) 15:58:13
>>426
この記事、パソコンから携帯へはどういう設定で送ったんだろ。
utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
JIS X 0208の範囲に押し込む手もあると思うけど。

436 :デフォルトの名無しさん:2009/12/22(火) 17:59:57
絵文字の場合は送信側のサーバで一括変換してるけど、
Unicode対応は機種によって違うから、サーバで変換しちゃまずいだろ。

437 :デフォルトの名無しさん:2009/12/23(水) 03:03:35
>>435
> utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
> JIS X 0208の範囲に押し込む手もあると思うけど。

似た字に変換しちゃえって事?

438 :デフォルトの名無しさん:2009/12/23(水) 11:06:56
携帯に限って言えば、キャリア側で勝手に包摂しちゃえばいいんじゃないの
わざわざ常用漢字表の側で配慮すべきだとは思わない

439 :デフォルトの名無しさん:2009/12/23(水) 22:06:14
>>438
包摂で済むなら苦労しないし、できるんだったら第2水準を作る時点で新字旧字にそれぞれ別コードを与えない。

「常用漢字表と字体が違うYO!」 と言ってくる人が必ず出てくる。
今後>>438が「常用漢字お客様相談センター」の窓口を一手に引き受けてくれるのであれば別だが。

440 :デフォルトの名無しさん:2009/12/24(木) 20:39:55
「口匕」と「口七」は元来別字だったからややこしい。現代文では両方とも「シカる」の意味で使う。
本当に字形の差の問題だけだったら、Unicodeでは中国の字体と統合されている「将」や「直」の方が問題だろう。

441 :デフォルトの名無しさん:2009/12/25(金) 08:32:30
CJK統合の問題は言っても始まらない、というか終わっちゃう、というかw

442 :デフォルトの名無しさん:2009/12/25(金) 18:00:26
俺は生粋の日本人だけど、日本と朝鮮と越南が中国領になれば解決するアルよ。

443 :デフォルトの名無しさん:2009/12/25(金) 20:21:12
visciiを巻き込まないで

444 :デフォルトの名無しさん:2009/12/26(土) 11:49:18
今回のパブコメは募集要領でわざわざ
>今回は,「「新常用漢字表(仮称)」に関する試案」からの変更点に関連する御意見を中心に
と断っているから、out of scopeではねられるものが大量に出る予感。

445 :デフォルトの名無しさん:2009/12/29(火) 23:49:54
cnetの絵文字の話は越年か…

446 :デフォルトの名無しさん:2010/01/09(土) 23:50:29
文字コードじゃなくてフォントの話なんだけど、
「礫」をMS明朝の16ポイントで表示させると旁の「白」が「自」になるのに気づいた。

これって有名?

447 :デフォルトの名無しさん:2010/01/10(日) 02:17:32
そのくらいの省略(ヒンティングでかもしれんが)はいくらでもあるんじゃないか?


448 :デフォルトの名無しさん:2010/01/10(日) 08:06:54
いや、画数が足りないならともかく、多いんだからバグだろ。

449 :デフォルトの名無しさん:2010/01/10(日) 13:10:55
まったく、フォント作成までもが中国に丸投げかよ

450 :デフォルトの名無しさん:2010/01/10(日) 13:52:36
16以外は大きくても小さくても白だなw

451 :デフォルトの名無しさん:2010/01/10(日) 14:35:57
16ポイント埋め込みビットマップのみの問題か。
こんな名前にもポスターにも使わそうにない漢字良く気づいたな。

452 :デフォルトの名無しさん:2010/01/10(日) 15:56:11
礫は砂礫・礫岩の礫か。
あとは、東京都文京区小石川は礫川とも書く。



453 :446:2010/01/10(日) 20:23:33
みんなレスありがとう
手書き認識で別の字を書いたときに旁の変な「礫」が出てきて、
あれこんな字あったっけ? みたいな。

8ポイントの「預」が「矛頁」になるのは比較的有名だと思うんだけど、
これは最初の発見者になれたかなw

454 :デフォルトの名無しさん:2010/01/14(木) 17:02:05
文字コード界隈もついったーばやりだなぁ。

455 :デフォルトの名無しさん:2010/01/17(日) 01:05:32
Twitterといえば、Webインターフェイスからつぶやくと、
サロゲートペアはキッチリ2文字としてカウントしてくれるせいで140字打てない
Twitpicってutf-8を文字境界ではないところで切っているせいで
よく文字化けをおこしている
まあたとえサロゲートペアを1文字としてカウントしたり、utf-8を文字境界で切ったとしても
結合文字の問題もあるんだけどね。

456 :デフォルトの名無しさん:2010/01/17(日) 03:37:14
結合文字はちゃんとやろうとするとテーブルが要るから
処理を端折りたくなる気持ちは分かるけど、サロゲートはちゃんとやってほしいな。

457 :デフォルトの名無しさん:2010/01/17(日) 12:48:25
16進数で3xが0-9まで数xになる文字コードってなに?

458 :デフォルトの名無しさん:2010/01/17(日) 13:13:41
ASCII

459 :デフォルトの名無しさん:2010/01/17(日) 13:51:05
^^b

460 :デフォルトの名無しさん:2010/01/26(火) 17:07:08
当方はXP SP3でMSのJIS2004フォントを適用した環境です。

ATOK2009の「文字パレット」でフォントに「MS 明朝」を指定して漢字検索する時、
以前は一部のサロゲートペア文字も検索結果で正常表示されていたのに
今回検索したら「・・」表示になってしまってました。(例:>371の「土並」とか)
これは他のフォントに変更しても同じ

またサロゲートペア以外に「・」表示になってしまった文字も多数。(例:U+50F7の「イ葉」とか)
但しコチラは「Tahoma」や「MS Sans Serif」に変更すると表示されました。

JIS2004フォントを削除して再インストールしても直りませんでした。

この現象を解決する方法、何方かご存じでしょうか?

461 :デフォルトの名無しさん:2010/01/26(火) 19:44:57
エディタやブラウザでMS 明朝の該当グリフが表示されるかどうかを試してみて、
ATOKの問題かOSのフォント認識の問題か切り分ける。

462 :460:2010/01/27(水) 09:33:29
>461
エディタやブラウザでも「・」や「・・」で表示されるのでOSのフォント認識の問題と思われます。
念の為、IME2002に切り替えて確認しましたが同じでした。

463 :デフォルトの名無しさん:2010/01/27(水) 15:17:31
文字コードについて誤った情報が掲載されているPDFを探しています。
なかなか見つけられないので協力してください。

464 :デフォルトの名無しさん:2010/01/27(水) 15:25:21
なぜPDF?

465 :デフォルトの名無しさん:2010/01/27(水) 15:35:05
PDFと指定されたからです。
何が誤っているかも分らない分野で、明日までに提出と言われたので困り果てていました。
ここの方なら分るかと思い質問しました。

466 :デフォルトの名無しさん:2010/01/27(水) 15:51:01
>文字コードについて誤った情報が掲載されているPDF

この条件だけでいいんだったら、

1 嘘の記事をメモ帳なりワードなりで自作して
2 Bullzip PDF Printer などでPDF化

で簡単に作れるべ

467 :デフォルトの名無しさん:2010/01/27(水) 15:52:56
http://www.google.co.jp/search?q=文字コード+filetype%3Apdf
こんなかから、うそっぽいのをさがせ。

468 :デフォルトの名無しさん:2010/01/27(水) 15:55:20
あやしいのだらけだが、こいつはそうとうにあやしい。

ネット時代の必修科目、文字コードの謎をひも解く
ファイルタイプ: PDF/Adobe Acrobat
図3 ASCIIは1バイトの半角文字を扱うための文字コード体系。JISとシフトJISは2バイトで日本語を扱うために開発された。EUCは日本語版のほか、 ... 図2 大抵の文字化けは文字コードの設定を切り替えることで対処できる。IE7では「ページ」→「エ ...
pc.nikkeibp.co.jp/pc/npcs/pdf/071022/tokushu1.pdf -

469 :デフォルトの名無しさん:2010/01/27(水) 15:56:13
>466
自分で作るのも考えたんですが、
それらしいものを作る自信がなくて諦めていました。

>467
ちょっと見てきますありがとう。

470 :デフォルトの名無しさん:2010/01/27(水) 15:57:44
>468
これも見てみます。ありがとう。

471 :デフォルトの名無しさん:2010/01/27(水) 16:09:04
「漢字は2バイト」とあり、それがUnicodeの文脈で、
にもかかわらずエンコーディング方法に言及してないとかなー。

半角カナは1バイト、とかも似たような(EUC-JPだと…)


472 :デフォルトの名無しさん:2010/01/27(水) 17:17:46
そりゃnikkeibpだもん
仕方ないよ

473 :デフォルトの名無しさん:2010/01/27(水) 22:55:34
>>470
あんた赤点決定ね。

474 :デフォルトの名無しさん:2010/01/28(木) 01:59:24
>471がよくわかりません。
詳しく教えてください。

475 :デフォルトの名無しさん:2010/01/28(木) 02:10:33
ちょっとは自分で調べましたみたいな姿勢を見せないでただ質問するだけって嫌われるよ。

476 :デフォルトの名無しさん:2010/01/28(木) 03:47:31
数年後日本の開発者は文字コードの乱立を知らない世代ばかりになって
ますますソフト業界は世界から立ち遅れると思われ

477 :デフォルトの名無しさん:2010/01/28(木) 08:37:02
欧米か!

478 :デフォルトの名無しさん:2010/01/28(木) 09:44:48
>>476
オライリーのCJK本の事を思い出してしまった


479 :デフォルトの名無しさん:2010/01/28(木) 10:34:41
>>476
IMEの開発を朝鮮に丸投げしてるからなぁ

480 :デフォルトの名無しさん:2010/01/28(木) 10:40:09
ttp://www.amazon.co.jp/dp/4873111080

481 :デフォルトの名無しさん:2010/01/28(木) 11:07:29
むしろShift_JIS的発想から抜け出せないことの方が、立ち後れの原因になりかねない。
一行あたりの文字数をバイト数から算出しようとするような。

某有名国産テキストエディタが、合成文字をちゃんと表示できるようになるのはいつの事だか…

482 :デフォルトの名無しさん:2010/01/28(木) 18:19:21
固定ピッチフォントでは全角は2倍の幅という慣習も、今後どうなるんだろう?

483 :デフォルトの名無しさん:2010/01/28(木) 19:02:25
そら、「全角」は「半角」の倍の幅に決まってますがな。

484 :デフォルトの名無しさん:2010/01/31(日) 12:09:58
画面上では2倍だが、ドットプリンタの世界では全角は半角の1.5倍だったけどな

485 :デフォルトの名無しさん:2010/02/02(火) 20:53:53
Windows 7だとUnicode 5.2で追加された字のUnicodeのSMP(第1面)の文字が表示出来ず・・になってしまう。
MS-IMEやATOKの文字パレットを見るとUnicode 5.1で未定義だったSMPのコードポイントがそうなってる。
これらだけでなく第15、第16面の私用面も全部・・だった。BMPやSIP(第2面)はそうでなかった。現在文字が全く定義されてない第3〜13面はどうか知らない。
なんでこうなってしまったんだ?Vista以前では表示出来たのだが。
ちなみにUnicode 5.2の文字を含んだフォントは和田研細丸ゴシック2004ARIB(ARIB外字を含んでいる)がある。
他には古代文字などを収録しているフリーフォントがいくつかあって、中にはUnicode未定義の文字のために15面の私用面を使ってるのもあった。
これらが普及する前に早く修正パッチ出てほしいもんだ。

486 :デフォルトの名無しさん:2010/02/05(金) 01:01:27
>>462
コントロールパネル-地域と言語のオプション-[言語]タブで
「複合文字や右から左方向に書く言語 (タイ語を含む) のファイルをインストールする」
にチェック。
レジストリを直接いじる方法もあるようだけどたぶんこれが一番簡単

487 :デフォルトの名無しさん:2010/02/06(土) 00:48:23
いずれ絵文字もAdobeJapanに収録されるのかな。
AJの採集基準ってどうなってんだろ。

488 :デフォルトの名無しさん:2010/02/06(土) 15:38:32
基本的には国家規格の文字を収録してるだけだよ
ただ日本に限ってはそれだけでは使いものにならないというだけ

489 :デフォルトの名無しさん:2010/02/09(火) 23:19:10
結局、絵文字にまつわるUnicode改訂ってどうなったん?

490 :デフォルトの名無しさん:2010/02/09(火) 23:23:05
すぐに巷に流れたらメシの種がなくなるじゃねえか

491 :デフォルトの名無しさん:2010/02/09(火) 23:30:15
そか、じゃあもうちょっと待ってみる

492 :デフォルトの名無しさん:2010/02/10(水) 00:40:51
絵文字を含むAMD8は3回中2回目の投票中。後はこれに各国が意見を言って、
4月の会議で摺り合わせして終わり。
絵文字にかんしては対立点がほぼ解消されたので、もう大波乱はないんじゃないかな。

Oさんもうワントライするようだけど、実際は前回のフィードバックを
どこかの国が投票コメントで拾ってくれるかどうかが鍵だと思う。
会議に出るのはNB本体の意向を代弁する人たちだから。

493 :デフォルトの名無しさん:2010/02/10(水) 00:48:26
携帯キャリアの連中、支持を表明しただけで自分たちじゃ何にもしてないのな。


494 :デフォルトの名無しさん:2010/02/10(水) 01:04:50
ミーティングには日本の代表団もいたはずなのに
なんでこんなに影薄いんだ

495 :デフォルトの名無しさん:2010/02/10(水) 01:14:20
毛が薄いから

496 :デフォルトの名無しさん:2010/02/10(水) 11:38:26
電話屋って、ITU-T以外の規格はなべてバカにしてよい、っていう意識があるからな。

497 :デフォルトの名無しさん:2010/02/10(水) 22:54:19
ISO/IEC JTC1/SC2/WG2/IRG か

498 :デフォルトの名無しさん:2010/02/12(金) 00:04:53
ttp://www.unicode.org/roadmaps/smp/
U+1B000〜U+1B0FFがHistoric Kana(歴史的仮名)からKana Supplement(仮名補助)に変更されてた。
ということは今後このブロックには昔の仮名だけでなくイとエが合体したものや小さいヰヱヲなどの拡張仮名が追加される可能性もあるということかな。

499 :デフォルトの名無しさん:2010/02/12(金) 00:34:20
小さいヰヱは、NDL-70とかいう国会図書館の文字コードにあるらしいので、
典拠としてそのコード表が示せれば比較的すんなり追加されるんじゃないか。

500 :デフォルトの名無しさん:2010/02/12(金) 04:49:55
前のブロック名でぐぐると、変体仮名と結びつけちゃってる人も結構いるなぁ

501 :デフォルトの名無しさん:2010/02/13(土) 00:05:25
変体仮名用のエリアじゃないのか。

502 :デフォルトの名無しさん:2010/02/13(土) 21:53:21
変態かな

503 :デフォルトの名無しさん:2010/02/14(日) 05:06:19
変態だよ

504 :デフォルトの名無しさん:2010/02/14(日) 17:53:24
サプリメントの中にヘンタイがみっしりと

505 :デフォルトの名無しさん:2010/02/14(日) 18:42:23
きそば

506 :デフォルトの名無しさん:2010/02/19(金) 16:33:18
チェックボックスにチェックの入った文字コードってある?

507 :デフォルトの名無しさん:2010/02/19(金) 16:59:04
U+2611 (BALLOT BOX WITH CHECK) って答えでいいの?


508 :デフォルトの名無しさん:2010/02/19(金) 18:39:21
合字で作れないのかな。

509 :デフォルトの名無しさん:2010/02/22(月) 12:26:14
(´・ω・`)やーだお

510 :デフォルトの名無しさん:2010/02/26(金) 19:03:31
グリフウィキって変体仮名にも着手してたのか
一通り完成したらその先の展開も色々ありそうななさそうな

511 :あああ:2010/03/04(木) 19:24:40
バカスギテアタマキチャウネ〜〜〜~~フェフェフェフェエフェフェフェフェフェフェフェ

512 :あああ:2010/03/04(木) 19:25:50
fgthtgヌウウウウウウウウウウウウウウウデエfウウウウウウウウウウウウウウウウウウウrfゲwgrgrギウウウウggggツバカヤロウdソフィエイオペヲエフェr

513 :あああ:2010/03/04(木) 19:29:21
アアアアアアアアアアアアアババババババカkkkッカアアアアアアアア

514 :あああ:2010/03/04(木) 19:30:14
sfヘウfヴィネオツウウウウウエjmgfdsvmcdslc、エコfk派wk度kpwkでミkムyジュyrtytryrytrytryt

515 :デフォルトの名無しさん:2010/03/06(土) 17:22:06
Annexだけ先行してUnicode 6.0のPublic Review始まってるのか。
この間5.2が出たとこだと思ったのに。早いなあ。

516 :デフォルトの名無しさん:2010/03/06(土) 21:36:17
順調に行くと2010年末にはUnicode 6.0になってるのか。
と、思った記事があった気がする。

517 :デフォルトの名無しさん:2010/03/07(日) 01:13:25
javaのjTextAreaで編集したテキストから日本語文字を[ctrl+c]でコピーして
テラパッドなどのテキストエディタに[ctrl+v]でペーストした時に
日本語が文字化けしてしまいます。防ぐ方法はありますか。
【Java】 1.6.0_17-b04 (Sun Microsystems Inc.)
【OS】 Windows XP 5.1 (x86)
Java低速GUI Swing 9スレでこちらを進められてきましたよろしくお願いします。

518 :デフォルトの名無しさん:2010/03/07(日) 03:02:26
Ctrl+cしたときの、クリップボード中に保持してるテキストの文字エンコーディングと、
エディタのクリップボードで想定してるエンコーディングが合わないんだろうけど

GUIしてないので分からない・・

519 :デフォルトの名無しさん:2010/03/07(日) 03:07:53
エディタ側で、開いてるテキストの文字エンコーディングとクリップボードの文字エンコーディングを揃えてるか、
エディタ側で、クリップボードは決め打ちのどっちかなんじゃないか。

ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/45006


520 :デフォルトの名無しさん:2010/03/07(日) 03:23:54
ttp://www.atmarkit.co.jp/fwin2k/win2ktips/103clipbook/103clipbook.html
XPなら、clipbrd.exe で、クリップボードの中がみれる。
日本語Windowsの場合、テキストならcp932(sjis) Unicodeテキストならutf-16le


521 :517:2010/03/08(月) 23:25:35
解決しました、ありがとう

522 :デフォルトの名無しさん:2010/03/09(火) 20:14:04
Rubyになんかキタ。
ttp://github.com/ruby/ruby/commit/62f8df2d3c95816028c006ecbe70bc51704eec4b

523 :デフォルトの名無しさん:2010/03/10(水) 03:59:01
携帯キャリアがこのタイミングでなあ
しかしたとえ名前の上だけだとしても色なんて飲めるのかねえ、WG2的に
FPDAMの段階でこれだけ問題提起されたら、もうぬるぽな悪寒

524 :デフォルトの名無しさん:2010/03/10(水) 04:35:52
ぬるぽにするためにあえてこの段階で言いがかり付けてきたとか。
だって今までもさんざん携帯キャリアには何やってるのか言ってたけど
反応なかったって言ってたにょ

「色」があるからマッピングが不適切だっていうなら麻雀の赤牌もやっぱ符号化が必要かね。
つーかTRON涙目
http://www2.tron.org/set08/imode/imode-set.gif

フリーダイヤルマークはやっぱり商標問題が火を噴いたか。

525 :デフォルトの名無しさん:2010/03/10(水) 04:56:52
前にキャリアから取り付けたコメントがポストされてたもんね。
Google/Appleにしたら、なんであの時言わなかったんだってなるだろうなぁ。

WG2としちゃ文句のついた"Symbols"を棚上げすりゃ済む話だろうけど、
「絵文字対応」が目的のUnicodeとしちゃ、それじゃ駄目だろうし。

526 :デフォルトの名無しさん:2010/03/10(水) 07:29:29
失礼、FPDAM8読み直してみたら、すでに色の名前入りの絵文字あったわ
それほど難題でもないのかな

527 :デフォルトの名無しさん:2010/03/10(水) 21:26:01
>>523 >>524
ガッ! ガッ!

528 :デフォルトの名無しさん:2010/03/13(土) 00:14:02
こういう名前にしてくれ、それが駄目ならうちの絵文字とマッピングしないで
くれってのがいやらしいな。

529 :デフォルトの名無しさん:2010/03/13(土) 10:56:53
国内のメーカーはそういうことを言って標準化の、ひいては利用者の足をひっぱってきた。
コード会コードの昔から。

530 :デフォルトの名無しさん:2010/03/13(土) 13:11:23
>>528
> それが駄目ならうちの絵文字とマッピングしないでくれ

「〜の絵文字インスパイヤード」って位置づけにして、
変換テーブルに突っ込めば問題なし。

531 :デフォルトの名無しさん:2010/03/13(土) 17:26:52
>>532
ガラパゴス

532 :デフォルトの名無しさん:2010/03/13(土) 17:50:27
http://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/787bc8429b2ef1fd247b59b5515e5321_400.jpg

533 :デフォルトの名無しさん:2010/03/19(金) 00:32:32
もうdocomoとKDDIの担当者にもサンノゼ行ってもらうしかなかんべ
ただ合意できてもそのままFDAMに行けるのかって問題は残りそうだけど

534 :デフォルトの名無しさん:2010/03/21(日) 00:07:23
Amd.6フリーになったー
と思ったけどここら辺はすでにUnicodeに入ってるんだっけか。

535 :デフォルトの名無しさん:2010/03/23(火) 08:29:45
>>533
http://slashdot.jp/%7Eyasuoka/journal/
>正直なところ、NTTドコモよりKDDI(au)の方がひどい
KDDIは色がどんどん変わっていってるらしい

536 :デフォルトの名無しさん:2010/03/24(水) 21:54:20
>>524
フリーダイヤルの商標だが、現在はNTT東・西(0036・0039)ではなくて、
NTTコミュニケーションズ(0033)が持っているんだよな。

537 :デフォルトの名無しさん:2010/03/25(木) 03:45:28
フリーダイヤルは削除かなあ。あとはマッピング変えたり新しいの足したりで
対応できなくもなさそうだけど、KDDIのジョーカーが少し厄介だな。
黒だの赤だの区別しない包括的なジョーカーを求めているんだとしたら、
落としどころが難しそう。

538 :539:2010/03/25(木) 13:08:45
test

539 :デフォルトの名無しさん:2010/03/29(月) 22:15:24
1F609と1F60Aは本当にkiddingでいいのかなあ
「失敗しちゃった、テヘ」で舌出してるのならともかく
「あかんべー」で舌出してるのなら「拒絶」だろうし

540 :デフォルトの名無しさん:2010/03/30(火) 21:45:01
FCD(N3739)に見る次期10646のム板的ポイント

・Group-Plane-Row-Cellという概念が消え、代わりに "17planesからなる単体物
 (regarded as a single entity made of 17 planes)" に (p.17)
・UCS-2はdeprecatedと明記 (p.24)
・UCS-4は、UTF-32の単なる別名扱い (p.24)
・Implementation levelsという概念はもうない

Unicode化ここに完了ってとこか。
サロゲートや合成文字も、今後はきっちり対応していかなきゃならんのだろうな。

541 :デフォルトの名無しさん:2010/03/31(水) 00:15:52
> Group-Plane-Row-Cellという概念が消え
マジっすか?

542 :デフォルトの名無しさん:2010/03/31(水) 07:16:58
確かにPlaneくらいしか使わないけど……全体的に思い切ったな

543 :デフォルトの名無しさん:2010/03/31(水) 13:31:17
久しぶりにIVDの登録申請ががが
ttp://www.unicode.org/ivd/pri/pri167/

544 :デフォルトの名無しさん:2010/03/31(水) 23:20:12
>>543
日本が>>30で互換漢字の提出をあきらめてIVDの登録申請に切り替えた奴だな。
ついにキタワァ.*・゜゚・*:.。..。.:*・゜(n‘∀‘)η゚・*:.。. .。.:*・゜゚・*!!!!!☆

545 :デフォルトの名無しさん:2010/04/05(月) 08:00:59
CP51932の登録申請がietf-charsetに来てた。
mohtaも村田真も安岡先生も途中でほっぽりだしたわけだが
今度こそ最後までやってくれるんだろうかねえ。

546 :デフォルトの名無しさん:2010/04/07(水) 18:29:30
西夏文字帰ってきたのか…!

547 :デフォルトの名無しさん:2010/04/11(日) 07:50:28
FPDAM8はあちこち炎上してますな
Agendaも議題の量がエラいことになってるし、現地行く人は大変だ

548 :デフォルトの名無しさん:2010/04/15(木) 00:16:14
汎用電子のプレフィックスはどういう意味なんだろうか
KS=戸籍統一文字番号
らしいというのだけはわかった

549 :デフォルトの名無しさん:2010/04/15(木) 13:41:45
HG=法務省外字とか?
安岡センセに聞けば一発な気もする。

550 :デフォルトの名無しさん:2010/04/15(木) 23:30:09
IPは安岡先生の日記でネタばらしされてた
http://slashdot.jp/~yasuoka/journal/504963
JAPANESE IDEOGRAPHICS SUPPLEMENTの平成明朝体による実装がソースらしい

551 :デフォルトの名無しさん:2010/04/16(金) 20:54:44
欧州各地の空港が麻痺しているらしいけど、欧州組は
週明けのWG2に無事参加できるのかな。

552 :デフォルトの名無しさん:2010/04/18(日) 08:26:02
米vs欧の案件が多いのに片っぽ来られないんじゃまずい罠

553 :デフォルトの名無しさん:2010/04/18(日) 08:27:40
ロシアあたりまで鉄道で抜けてから飛行機で飛ぶしかないのか

554 :デフォルトの名無しさん:2010/04/18(日) 08:28:32
ネット会議でいいじゃない

555 :デフォルトの名無しさん:2010/04/18(日) 09:02:26
ジェットエンジンの欠陥だろ
ヘリコプターなり
ロケットエンジンなりの
航空機なら飛ばせるぜ

556 :デフォルトの名無しさん:2010/04/18(日) 09:14:16
>>555
ヘリコプターもジェットエンジンなんだが?

557 :デフォルトの名無しさん:2010/04/18(日) 09:22:34
ヨーロッパ組のいない間に好きにやって、FDAM8投票が万一コケたら
洒落にならんなあ。係争中の字は全部取り除こうフラグが立ったかこれ。

558 :デフォルトの名無しさん:2010/04/18(日) 09:32:50
投票にならんだろ常考
延期だな

559 :デフォルトの名無しさん:2010/04/18(日) 09:59:36
Eversonだけはネット会議ででも参加すべき

560 :デフォルトの名無しさん:2010/04/19(月) 12:05:19
>>555
ロケットエンジンの航空機で実用的な例があるとでも?
間抜けにも程がある。

>>556
レシプロエンジンのヘリもなくはないがw
そもそもヘリなら低高度を飛べるから問題ないし。

561 :デフォルトの名無しさん:2010/04/20(火) 23:43:08
で、結局ヨーロッパ組はたどり着けたのか?

562 :デフォルトの名無しさん:2010/04/21(水) 05:38:11
http://www.iana.org/assignments/ianacharset-mib
これみると、csCPxxxxって無いし、csIBMxxxx、cswindowsxxxxが多いので、
csCP51932 じゃなくて、cswindows51932 という気がする。
略称 CP51932だけど、

windows code page の 51932 のようだ。
ttp://en.wikipedia.org/wiki/Windows-1258

563 :デフォルトの名無しさん:2010/04/21(水) 19:43:25
構わない
芸能界

2chでは文字化けしないのか。

564 :デフォルトの名無しさん:2010/04/22(木) 00:19:02
code pageという単語含んでるのは、
EDBIC?(IBM)か、DOSかWINDOWSなんでそうなってんのか。
まあ、重なることがなければ特に問題無いんだろ

565 :デフォルトの名無しさん:2010/04/22(木) 23:35:26
もういろんな意味でぬるぽ

566 :デフォルトの名無しさん:2010/04/23(金) 00:40:46
やっぱり
「BLACKとかWHITEは文字通りの色を表してるわけじゃねーよ」
で突っぱねるつもりみたいだな

567 :デフォルトの名無しさん:2010/04/24(土) 00:44:18
ドイツの
「ブロンドと西洋人を結びつけるのはナチズムだ」
ってのもすげーな

568 :デフォルトの名無しさん:2010/04/24(土) 03:37:24
まあナチの優生学的ってことでわからんでもないがな。

569 :デフォルトの名無しさん:2010/04/24(土) 09:40:20
実際ユダヤ人はゴキブリ並み出汁

570 :デフォルトの名無しさん:2010/04/24(土) 13:24:35
テメーゴキさんディスってんのか

571 :デフォルトの名無しさん:2010/04/25(日) 09:25:37
投票制度変更の件は、会議の開催を今後は8ヶ月ごとに
することで解決したのか。

572 :デフォルトの名無しさん:2010/04/27(火) 01:27:52
NEUTRAL FACEがN3769由来で、USも支持してるってこと見落としてるのかなあ

573 :デフォルトの名無しさん:2010/04/28(水) 12:58:10
Nさんも気づいたね。

pipelineにStage 7が出現してますな。最近じゃレアだ。

574 :デフォルトの名無しさん:2010/05/01(土) 17:21:59
せっかく新10646の全容が確定したのにfdisは秋か…
Unicode6の方が先かな

575 :デフォルトの名無しさん:2010/05/05(水) 00:38:31
BabelStoneによると、2nd editionはフォントの問題でExtBだけマルチカラム化見送り。
そのかわりamendmentなしですぐ3rd editionの作成に入ってこれを修正するそうだ。

576 :デフォルトの名無しさん:2010/05/08(土) 02:34:25
矢野啓介『プログラマのための文字コード技術入門』(技術評論社、2010年、本体 ¥2,580 + 税)
http://gihyo.jp/book/2010/978-4-7741-4164-0
http://ja.wikipedia.org/wiki/Special:Booksources/978-4-7741-4164-0

577 :デフォルトの名無しさん:2010/05/08(土) 02:58:29
>>576
宣伝乙
http://gihyo.jp/magazine/wdpress/plus/978-4-7741-4164-0/0002

578 :デフォルトの名無しさん:2010/05/08(土) 03:44:22
このスレ読むような人なら十中八九既知だと思う。


579 :デフォルトの名無しさん:2010/05/08(土) 13:04:09
でももうucs-2ってdeprecatedになるのよね

580 :デフォルトの名無しさん:2010/05/08(土) 17:51:16
わざわざUTF-16ではなくてUCS-2を持ち出すあたりに恣意的なものを感じる
著者の名前を見るとある意味納得なんだが

581 :デフォルトの名無しさん:2010/05/10(月) 15:07:59
ひゅるり

582 :デフォルトの名無しさん:2010/05/10(月) 15:32:09
ひゅるりらら〜

583 :デフォルトの名無しさん:2010/05/11(火) 14:27:32
>>580
恣意的というか思想に偏りがあるから、この本に書いてあることを信じて実装したら死ねると思うなー。

584 :デフォルトの名無しさん:2010/05/11(火) 14:40:25
ここでいいのか分からないけど質問してみる

例えば"東京"でググったら↓のURLになって
http://www.google.co.jp/search?hl=ja&q=%E6%9D%B1%E4%BA%AC&btnG=%E6%A4%9C%E7%B4%A2&aq=f&aqi=&aql=&oq=&gs_rfai=

%E6%9D%B1%E4%BA%AC ←ここの部分が東京を表してるんだと思うんだけど
"東京"から"%E6%9D%B1%E4%BA%AC"への変換は、google独自のもの?一般的な方法がある?


585 :デフォルトの名無しさん:2010/05/11(火) 14:42:00
東京→UTF-8→urlencode

586 :デフォルトの名無しさん:2010/05/11(火) 14:46:29
ageすま

587 :デフォルトの名無しさん:2010/05/11(火) 14:47:31
ありがとうございます
なんかすごい簡単な質問だったようですんません

588 :デフォルトの名無しさん:2010/05/11(火) 14:53:07
マルチ死ね
http://pc12.2ch.net/test/read.cgi/tech/1271996751/

589 :デフォルトの名無しさん:2010/05/11(火) 16:04:54
はふ

590 :デフォルトの名無しさん:2010/05/11(火) 16:15:53
UTF8ってBase64エンコードと紛らわしくて厄介。

591 :デフォルトの名無しさん:2010/05/11(火) 20:33:15
さすがにそれはだいぶ違うと思う

592 :デフォルトの名無しさん:2010/05/16(日) 07:14:45
なかったことにされつつあるUTF-7とごっちゃにしてないか

593 :デフォルトの名無しさん:2010/05/16(日) 08:47:56
「Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディング された文字列の脆弱性」ってやつか・・・

594 :デフォルトの名無しさん:2010/05/19(水) 00:23:19
JISコード群にはJISロゴが入っていないが
UnicodeにはJISロゴが入っているふしぎ

595 :デフォルトの名無しさん:2010/05/19(水) 14:40:26
asciiコードにasciiのロゴが入っていないが如し。

596 :デフォルトの名無しさん:2010/05/19(水) 16:54:17
ロゴを直接Unicodeに入れるのは今もう難しい希ガス

597 :デフォルトの名無しさん:2010/05/19(水) 21:44:36
ああ、こんなことならもっと早くうちの家紋捻じ込んでおけばよかった。

598 :デフォルトの名無しさん:2010/05/19(水) 22:19:47
ワロタ

いやでも、Googleの絵文字の件みたいに、誰かが家紋を入れるとか言い出したら楽しいことになりそうだ。


599 :デフォルトの名無しさん:2010/05/19(水) 22:33:11
Unicodeだもん、家紋も当然包摂なんだろうな。
菊紋だろうが桐紋だろうが葵紋だろうが、細かいデザイン上の違いはばっさり切り捨て。

600 :デフォルトの名無しさん:2010/05/19(水) 23:10:37
丸に違い矢なら、違い矢+丸の合成文字で。

601 :デフォルトの名無しさん:2010/05/19(水) 23:10:57
そこでTronコードの出番だ

602 :デフォルトの名無しさん:2010/05/19(水) 23:18:48
丸囲みの三つ葉葵紋については葉形によって指し示す人物が全然異なるという事実があるから、
すくなくともIVSの適用は期待できると思うぞ。徳川一門全部含めたら足りるかどうかわからんけどな。
ttp://aal.msis-net.com/kamon/tokugawa_1.html

603 :デフォルトの名無しさん:2010/05/19(水) 23:39:43
しかし特定個人と結びつけてしまうと逆にジョンイルメソッドで却下される悪寒

604 :デフォルトの名無しさん:2010/05/20(木) 01:15:29
明治・大正・昭和・平成は入ってるからそこは政治力次第

605 :デフォルトの名無しさん:2010/05/20(木) 01:32:20
確かに。現天皇を元号で呼ぶことこそなくても、在位と元号が一致してるのなら実質個人名相当か。

てか、将来平成の次の元号が出来たときもちゃんと扱いやすいところに確保してもらえるんだろうか

606 :デフォルトの名無しさん:2010/05/20(木) 01:58:38
日本国の書類(市役所とか法律関係とか)は西暦じゃないんだよな
当たり前だけど

607 :デフォルトの名無しさん:2010/05/20(木) 05:36:04
>>605
次の元号がもし入るとして、平成とかのあるCJK Compatibilityは埋まってるから
収まりのよさそうな場所はEnclosed Ideographic Supplementあたりかな、Enclosedじゃないけど

608 :デフォルトの名無しさん:2010/05/20(木) 07:25:36
天皇を元号で呼ぶのは死後だけどな

609 :デフォルトの名無しさん:2010/05/20(木) 08:00:29
諡号だけに

610 :デフォルトの名無しさん:2010/05/20(木) 08:47:03
平成のあと意味ありげな空きがあるのはJIS第三だっけ?

611 :デフォルトの名無しさん:2010/05/20(木) 17:01:19
6.0.0ディレクトリ下が慌ただしくなってきた
>Unicode 6.0.0 (Scheduled September, 2010)
らしいのでそろそろベータレビューかな

612 :デフォルトの名無しさん:2010/05/20(木) 18:17:27
>>607
むしろ元号のほうが、既存の組文字採用すればよくね?iとか、例の㌬とか。
過去にも神護景雲とか、漢字2字じゃない変てこな元号もあるしさ。

613 :デフォルトの名無しさん:2010/05/20(木) 19:40:45
けんさんAJ1-7の話題なんか出すんじゃなかったと
いまごろ後悔してないかな…

614 :デフォルトの名無しさん:2010/05/21(金) 00:48:41
汎用電子(のうちAJ1-6までと重複しないもの)もやっぱりAJ1-7に入るんだろうか

615 :デフォルトの名無しさん:2010/05/21(金) 01:05:42
こういうの追っかけてるともうascii基本だけでいいような気がしてくるぜ

616 :デフォルトの名無しさん:2010/05/22(土) 01:12:02
株の自動売買プログラムを自作中なんですが、証券会社の配布してるツールの中で
株価の情報をソケット通信で要求している部分を調べてみたところ、
文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコードをしているんです。
これって一般的に使われるものなんですか?

617 :デフォルトの名無しさん:2010/05/22(土) 02:17:32
株やってるギャンブラーには教えてやらん

618 :デフォルトの名無しさん:2010/05/22(土) 06:07:41
ヌルターミネートの1バイトすら貴重な時代にはよく見かけたな
SYMDEBのシンボルテーブルとか

619 :デフォルトの名無しさん:2010/05/22(土) 19:31:52
>UTC has decided to revise the procedures related to IVS registration

ほほう。
ttp://blogs.msdn.com/michkap/archive/2010/05/20/10013737.aspx

620 :デフォルトの名無しさん:2010/05/22(土) 20:18:00
>>619
何が起こるの?

IVSの登録方法が変わるの?

621 :デフォルトの名無しさん:2010/05/22(土) 21:17:19
>>620
汎用電子とAJ1の重複問題を何とかしたいということらしい

622 :デフォルトの名無しさん:2010/05/22(土) 21:29:28
もともとアメリカは、AJ1にないグリフだけ登録するか、いっそのことAJ1に
組み込んでしまうことを提案してたからねえ
ここへ来てAJ1-7の話がちらほら出てきたのもこれがらみかなと邪推

623 :デフォルトの名無しさん:2010/05/22(土) 21:46:40
なんかこっちが('A`)な気分になってくるな

624 :デフォルトの名無しさん:2010/05/22(土) 23:14:14
月と肉月の区別みたいな話ならまだ分かるんだが、
何画目が縦だの横だのってレベルになるとついてけんわ

625 :デフォルトの名無しさん:2010/05/23(日) 00:45:43
最初から先見性を持って康煕ベース、その他は出自を問わず全部IVSにしてしまえばすっきりしたのに

626 :デフォルトの名無しさん:2010/05/23(日) 00:57:37
康熙字典は5万字弱あるから、Unicodeの当初設計に収まらないけどね。
当初設計がそもそも悪すぎるわけだけど。


627 :デフォルトの名無しさん:2010/05/23(日) 01:08:36
せめて16じゃなく24ビット固定ならね。

コンソーシアムは今からでも625の方向へ収束させる気ないのかなあ。
正規化とVSを組み合わせれば出来そうな気もしないでもない。

628 :デフォルトの名無しさん:2010/05/23(日) 02:16:31
Extension Bで康熙字典の漢字はすべて突っ込んだことになってるらしいな。
実際には漏れがあるようでちょくちょく追加されてるけど。
その頃はまだUTS #37がなくてVariation Selectors Supplementは
あっても使いようがなかったから仕方ない

629 :デフォルトの名無しさん:2010/05/23(日) 03:17:40
汎用電子の公開レビューが終わるまでには、
新UTS #37候補のレビューも始まるのかな。

630 :デフォルトの名無しさん:2010/05/23(日) 18:38:17
明日はぶっちぎるぜ!

631 :デフォルトの名無しさん:2010/05/23(日) 19:02:56
落ち着け

632 :デフォルトの名無しさん:2010/05/25(火) 10:46:11
WindowsでIBM EBCDIC 930/939をUTF-16に変換するは面倒だ

633 :デフォルトの名無しさん:2010/05/25(火) 17:11:14
Lundeさんのコメント付いてる>>619
UTCでの議論に参加してたかんじだ。

634 :デフォルトの名無しさん:2010/05/25(火) 17:32:16
合意によるsharing authorityか…汎用電子はモノがモノだけに厳しそうだな

635 :デフォルトの名無しさん:2010/05/25(火) 18:48:34
ふとスレタイを眺めて、「あ、ここUnicode専用スレじゃなかったんだ」と気付いた。ほかの話題なんてないものな。

636 :デフォルトの名無しさん:2010/05/25(火) 19:12:00
http://pc12.2ch.net/test/read.cgi/tech/1177930957/

637 :デフォルトの名無しさん:2010/05/26(水) 06:43:21
>>636
今度はスレタイが限定的すぎて微妙

638 :デフォルトの名無しさん:2010/05/26(水) 14:05:32
というか埋まっとる

639 :デフォルトの名無しさん:2010/05/26(水) 14:07:45
うむ。
ファイルの先頭のマークに対して奇数アラインだったらどうすんのとか
アホなこと言ってるやつに一言言いたかったがな

640 :デフォルトの名無しさん:2010/05/29(土) 22:34:10
気を取り直して、と

641 :デフォルトの名無しさん:2010/05/30(日) 06:59:01
amd8が済むと、日本に関係ある提案は当面なくなるのかあ

642 :デフォルトの名無しさん:2010/05/31(月) 22:50:33
うむ,新スレ立ってるな
http://pc12.2ch.net/test/read.cgi/tech/1274937437/

643 :デフォルトの名無しさん:2010/05/31(月) 23:06:04
まあ不毛な争いは隔離されていただいた方がありがたい

644 :デフォルトの名無しさん:2010/05/31(月) 23:17:29
誰がハゲじゃコラ

645 :デフォルトの名無しさん:2010/06/01(火) 07:04:03
すみません頭髪の量をチャレンジされている人に言い直します

646 :デフォルトの名無しさん:2010/06/01(火) 17:26:39
>頭髪の量をチャレンジされている人

ハゲに包摂します。

647 :デフォルトの名無しさん:2010/06/01(火) 22:32:49
Win7って出荷時に未定義だったコードポイントは
フォント入れても豆腐になるんだな
ttp://babelstone.blogspot.com/2010/05/prototyping-tangut-imes-or-why-windows.html

Unicode 6.0までにSP来なかったら絵文字はおろかAMD5以降全滅か…

648 :デフォルトの名無しさん:2010/06/01(火) 22:48:03
リンク先読んでないけどなんでそんなひどい仕様なんだ

649 :デフォルトの名無しさん:2010/06/01(火) 23:10:59
この仕様はMS社内のフォント開発部隊が困るんじゃないか。

650 :デフォルトの名無しさん:2010/06/02(水) 00:15:27
ほんとなんでそんな仕様にしたのか分からん。誰得だよ。
Unicode5.2ってWin7発売直後だったよな。せめて5.2くらいは使えるようにしとけよ。
確かにバンドルされるフォントには無いけど、有志によって作られたフリーフォントには既にUnicode 5.2の文字を含んだのあるんだぞ。
こういうのはUnicode新ヴァージョンリリース直後どころかフライングで作られて公開されることもあるというのに。
ちなみに第15面、第16面の私用面もダメだった。で、何故かBMPと第2面は未定義だったのもOKだった。
一応UniscribeをVista以前のにすればWin7でも表示出来るけど当然Win7で新しく利用可能になったIVS等を犠牲にすることになる。

651 :デフォルトの名無しさん:2010/06/02(水) 00:18:17
その支離滅裂さは仕様じゃなくて不具合の匂いが…


652 :デフォルトの名無しさん:2010/06/02(水) 00:49:41
マジでバグであってほしい
MS様がいいと言うまで新しい文字は使えず、MS様がWin7のサポートを
打ち切った場合も新しい文字はもう使えないなんて嫌すぎる

653 :デフォルトの名無しさん:2010/06/02(水) 01:19:09
てかこれまで誰も気付かなかったのか

654 :デフォルトの名無しさん:2010/06/02(水) 09:42:45
まだUnicode5.2対応フォントが少ないしXP使い続けてる人も多いから仕方ないか。
でも今MSに要望出しておかないとSP1や次期Windowsでも放置される危険性があるな。

655 :デフォルトの名無しさん:2010/06/02(水) 18:39:43
困ったなあ

656 :デフォルトの名無しさん:2010/06/02(水) 23:11:51
なんだ。
会社のPCをまとめてWindows 7への移行を考えて、金も少し使ってたのに振り出しじゃん。
なんて言い訳すんべか。

657 :デフォルトの名無しさん:2010/06/03(木) 06:36:09
DirectWriteへ移行させるための嫌がらせとか。
いやDirectWriteなら豆腐にならないのかどうかは知らないけど

658 :デフォルトの名無しさん:2010/06/03(木) 07:16:08
> applications need to set an undocumented flag in Uniscribe
> [SCRIPT_CONTROL.fMergeNeutralItems = TRUE] for the Format 14 cmap
> substitutions to work
Windows 7のUniscribeをコピーするだけじゃダメなのはそれでか…

659 :デフォルトの名無しさん:2010/06/03(木) 07:38:33
FirefoxだけはなぜかWin7でもUnicode 5.2で追加されたARIB外字を表示できた。
テストに使ったのはこのフォント
http://glyphwiki.org/font/gw442923.ttf
IE8/9, Chrome5/6, Safari4, Opera 10.5を試してみたけど他のブラウザは全滅だった

660 :デフォルトの名無しさん:2010/06/03(木) 08:47:44
Firefoxはフォント周りの処理が独特で、
どうも自前でグリフを抜き出しているみたい。

661 :デフォルトの名無しさん:2010/06/03(木) 09:03:20
そんな中Unicode 6.0.0のBeta Reviewがはじまた

662 :デフォルトの名無しさん:2010/06/05(土) 00:50:31
由仁子!

663 :デフォルトの名無しさん:2010/06/05(土) 01:29:49
who?


664 :デフォルトの名無しさん:2010/06/09(水) 12:31:41
うんこマークも入るようだ。2chのAA等で使われるかも。
でもMS明朝/ゴシックやメイリオに収録されないと普及しないか。
その前に>>647に書いてあるWin7のUniscribeの不具合を直してもらわないかんが。

665 :デフォルトの名無しさん:2010/06/09(水) 16:30:51
うんこマーク入るのかw

逆卍とかと同じく宗教的に嫌う人向けにMSがグリフ削除ツールを出したりするのかな。

666 :デフォルトの名無しさん:2010/06/09(水) 19:28:04
既にBMPに入っているフェイスマークでぐぐっても結果が出ないな。
symbolは弾いているのか。絵文字の人気調査には使えそうにないな。

667 :デフォルトの名無しさん:2010/06/09(水) 21:08:59
所謂「まきぐそ」は日本の漫画内だけで通用する符牒だと読んだことあるけど、
名前(何になったの?)無しだとどれぐらいの外人が意味を認識できるんだろう。

ファストフードのおしながきにソフトクリームサインとして使われたりしたら楽しいな。

668 :デフォルトの名無しさん:2010/06/09(水) 21:41:25
フォント屋が泣くわ

669 :デフォルトの名無しさん:2010/06/09(水) 21:54:27
  入       ∧
  .(_)      (_)
  (___)     (___)
 (___)    (___)

  Serif   Sans-Serif

670 :デフォルトの名無しさん:2010/06/09(水) 22:39:38
2chでウンコマークを大量に書き込む荒らし行為が流行りそうな悪寒

671 :デフォルトの名無しさん:2010/06/09(水) 22:51:44
>>667
まきぐその、ドラフトでの文字名は
PILE OF POO
翻訳すれば、「山盛りのうんち」
要するに、巻いてなくても良いらしい。

>>670
Windowsに、まきぐそのグリフが標準で入る日が来るのだろうか?w


672 :デフォルトの名無しさん:2010/06/09(水) 23:16:40
Unicode6はドラフトとはいえ、もう名前は変えられないので確定ですな

フォント入れればまきまきだし入れなければ豆腐か…

673 :デフォルトの名無しさん:2010/06/09(水) 23:20:19
ユーザーの囲い込み目的で無節操に絵文字を考え出してた連中は
絵文字登録の流れをどんな思いで見ているのだろう。



674 :デフォルトの名無しさん:2010/06/09(水) 23:21:38
今日もまたまきまきうんちのヒンティングする仕事が始まるお…

675 :デフォルトの名無しさん:2010/06/10(木) 01:14:18
考えたことなかったけど、絵文字ってベジエ曲線で作るとなると
結構面倒くさそうだなあ。
ドット絵だと大した手間じゃないんだろうけれど。

676 :デフォルトの名無しさん:2010/06/10(木) 01:20:07
ドット絵なめんな

677 :デフォルトの名無しさん:2010/06/10(木) 03:59:16
>>669はもっと評価されていいと思う

678 :デフォルトの名無しさん:2010/06/10(木) 04:41:22
おいらも好きだよ
崩れかけにしてcursiveってやろうと思ったけどやめた

679 :デフォルトの名無しさん:2010/06/10(木) 08:13:44
崩れかけワラタ

680 :デフォルトの名無しさん:2010/06/10(木) 18:16:38
OSに付いてくれば使う人も少なくないんだろうけど
フォント買ってまで使いたいって人はいるのかなぁ

681 :デフォルトの名無しさん:2010/06/10(木) 20:21:08
そこで色つきの文字やアニメーションまで完全再現できるSVGフォントですよ。
問題は対応ブラウザがひとつもないことだが

682 :デフォルトの名無しさん:2010/06/11(金) 03:14:07
そっか。絵文字の場合、OSにインストールして使うフォントよりも
WebFontsの方が需要あるのかもしれないね。

683 :デフォルトの名無しさん:2010/06/11(金) 08:22:02
>>681
WebKitで使えなかったっけ?

684 :デフォルトの名無しさん:2010/06/11(金) 19:33:44
>>683
現在SVGフォントに対応しているブラウザはすべてAcid3を通すためだけの実装で、
色つきの文字やアニメーションを再現するための仕様に対応していない

685 :デフォルトの名無しさん:2010/06/12(土) 00:05:09
普通に単色でグリフ表示できるだけで立派なもんじゃねえの

686 :デフォルトの名無しさん:2010/06/12(土) 03:30:58
色つき文字のモノクロ化には、hatchingとかいうのが利用されてるらしい。
ttp://en.wikipedia.org/wiki/Hatching_system

687 :デフォルトの名無しさん:2010/06/12(土) 11:30:08
>>685
それだけならTTFやWOFFのWebフォントに対して何もメリットがない
(Acid3で3点ゲットする以外に)

688 :デフォルトの名無しさん:2010/06/12(土) 12:39:09
これはとても重要な確認なんだけど、いま色の話をしてるのはうんこマークからの流れなの?

689 :デフォルトの名無しさん:2010/06/12(土) 13:55:04
せっかく絵文字を実装するんなら色やアニメーションも正確に再現したいじゃん

690 :デフォルトの名無しさん:2010/06/12(土) 14:30:33
そのうち巻き具合の指定にIVSが使えるようになるのだろうか


691 :デフォルトの名無しさん:2010/06/12(土) 15:54:21
"Ideographic" Variation Selectorは使えないだろ。
絵文字は表意文字かもしれないが
この文脈でのIdeographは漢字の婉曲な言い回し

692 :デフォルトの名無しさん:2010/06/12(土) 16:07:46
特定の読みが存在しないんだからむしろ漢字より本来の意味の表意文字に近いな

693 :デフォルトの名無しさん:2010/06/12(土) 16:36:32
実質IVSというかVSだよねあれ

694 :デフォルトの名無しさん:2010/06/12(土) 16:40:28
漢字とモンゴル文字以外はU+FE00〜U+FE0Fを使うことになってるし
UTS#37は漢字(正確にはUnified_Ideographプロパティを持つ文字)にしか適用されない

695 :デフォルトの名無しさん:2010/06/12(土) 16:44:47
>正確にはUnified_Ideographプロパティを持つ文字

はー、そうなのか。

696 :デフォルトの名無しさん:2010/06/14(月) 16:46:01
U+E0100〜U+E01EFは漢字以外には使っちゃいかんのだな。
非漢字で17個目以降のVSが必要になったらU+E01F0〜かどっかにVS-257〜を追加しないといかんのかな。

697 :デフォルトの名無しさん:2010/06/14(月) 17:56:56
それを分けてる意味ってそもそも何なんだろう?

698 :デフォルトの名無しさん:2010/06/14(月) 21:01:15
どちらかと言うと先着16個の漢字のglyphic variantにBMPのVSを使う「特権」を
与えたくなかったんじゃなかろうか。

699 :デフォルトの名無しさん:2010/06/14(月) 22:16:08
何でVSはBMPとSSPに分けたんだろ?どちらか一方に全部の方がよかったんじゃないかな?
そういやVS-2〜16を使うのってまだ1つも無いんだな。パスパ文字以来非漢字のVSの提案全く無いし。

700 :デフォルトの名無しさん:2010/06/14(月) 22:20:03
すでに240個もVS「ごとき」に使わせられる余裕はBMPになかったと思う
JIS X 0213の300個程度の漢字ですら蹴られてたしな

701 :デフォルトの名無しさん:2010/06/15(火) 00:08:42
なんでBMPそんなに余裕がないんだよ…誰だよ最初の見込み立てた奴は…

702 :デフォルトの名無しさん:2010/06/15(火) 00:15:59
Unicodeにはハングル完成形が1万字以上全てBMPにあるけど実際に使われるのは2〜3千字とか。すごい無駄だよな。
統合漢字も拡張AからBMP外にした方が良かったのでは?使用頻度の低い字ばかりだし。

703 :デフォルトの名無しさん:2010/06/15(火) 00:35:20
いつかUCSをデフラグしてほしい。

704 :デフォルトの名無しさん:2010/06/15(火) 00:44:19
     [゚д゚]
     /[_]ヽ          デフラグを使うと
      | |
 ■■□■■□◇_◇□□□

     [゚д゚]
     ■_]ヽ□        ハード ディスクのファイルや未使用領域を再配置し
      | |
 ■■□_■_◇_◇□□□

        □
■⌒      ヾ
   \[゚д゚]ノ          プログラムの実行速度を上げることが
      \\/ 
 ■■□ /■_◇_◇□□□


   □   ( )         出来る・・・かも知れません。
  ■  ヽ[ ̄]ノ
 ■■□[゚д゚]■◇_◇□□□


   □               デフラグを実行しますか?→YES
  ■
 ■■□    ■◇_◇□□□


705 :デフォルトの名無しさん:2010/06/15(火) 00:48:33
使用人口/収録数でいうと多分ハングルがぶっちぎりで悪いよね。一番の優等生は算用数字。

706 :デフォルトの名無しさん:2010/06/15(火) 00:57:39
>>705
生まれが組み合わせ文字なのに無理矢理全部いれやがって
しかも発音のうち自国で使ってない物はいれなかったせいで、ハングルを採用させられた某国では結局PC化でふべんを強いられてるし


707 :デフォルトの名無しさん:2010/06/15(火) 01:25:20
>1万字以上全てBMPにあるけど実際に使われるのは2〜3千字

それは漢字にもほぼあてはまるんだが……


708 :デフォルトの名無しさん:2010/06/15(火) 02:22:27
>>705
いや、優等生はCRだろ。

709 :デフォルトの名無しさん:2010/06/15(火) 02:55:14
日本もBMPがスカスカなうちに変体仮名入れときゃ良かったのに

710 :デフォルトの名無しさん:2010/06/15(火) 04:54:14
丸付き数字があっちこっちに飛び飛びで入れられてるのが地味に気持ち悪い

711 :デフォルトの名無しさん:2010/06/15(火) 05:51:42
>>701
欧米人は「東アジアさえなければ16bitで足りなくなるわけなかっただろJK」
とか思ってるよきっと

712 :デフォルトの名無しさん:2010/06/15(火) 05:53:51
つか最初は「GB2312とKSC5601とJISX0208合わせても余裕じゃん」とか
言ってたらしいからな。さすがに止めたらしいけど(で、漢字統合とか言い出した)

713 :デフォルトの名無しさん:2010/06/15(火) 05:59:06
これだな
ttp://www.unicode.org/history/unicode88.pdf
現代の文字以外はPUAを使わせるつもりだったという

714 :デフォルトの名無しさん:2010/06/15(火) 07:05:46
「16ビットで十分ですか?」「はい」
力強いな
> fixed-length 16-bit character
ときっぱり言い切って可変長にたいする利点を強調しておるな

715 :デフォルトの名無しさん:2010/06/15(火) 08:08:18
容易に想像できる懸念を無視して美しさにこだわったら、
すぐに破綻して一番美しくないgdgd状態になってしまったでござるの巻

716 :デフォルトの名無しさん:2010/06/15(火) 10:53:03
>>713
そこに入ってるWriting System別のGNP表、今集計しなおしたらかなり変わってるんだろうな…

717 :デフォルトの名無しさん:2010/06/15(火) 17:52:11
>>707
しかし漢字は合成済み文字と用途の被る偏旁別の合成用パーツが収録されてるわけではあるまい?

718 :デフォルトの名無しさん:2010/06/15(火) 19:14:29
こういう今となってはちょっとあれな文書も、
堂々と公開しているのはえらい。

719 :デフォルトの名無しさん:2010/06/15(火) 19:48:24
>>717
なんたらradicalsとかIDSとか
正直この件で韓国叩いてもブーメランが返ってくるだけだよ

720 :デフォルトの名無しさん:2010/06/15(火) 20:27:02
いくらか青臭くもあったけど あの頃はみんな若くて輝いていた みたいな青春の証左

721 :デフォルトの名無しさん:2010/06/16(水) 02:04:05
>>711
Unicodeなんてもともと、東アジアへの対応に嫌気がさして作った規格だろ。

722 :デフォルトの名無しさん:2010/06/16(水) 02:12:38
誰がどういう意図でそんな事を言ったんだ?

723 :デフォルトの名無しさん:2010/06/16(水) 04:34:26
未だに欧米のUnicode化してないアプリだとダメ文字問題とかあるでしょ?
(「表」を含んだファイルが開けないとか)
1バイト文字で用が足りる連中にいくら言っても理解すらしてもらえないから
(似非でも)2バイト固定にしたほうが少しはマシになるってこと。

724 :デフォルトの名無しさん:2010/06/16(水) 09:26:32
理解してもらえないから、UTF-8なんかにせず、2バイト固定のほうがよかった、というのか?
よくわかんない。

725 :デフォルトの名無しさん:2010/06/16(水) 19:48:35
アメリカ人はUTF-8のほうが好きだがそれは(連中にとっては事実上)
何も変更しなくてすむから。
プログラマーは基本的にlazyなのです。

726 :デフォルトの名無しさん:2010/06/16(水) 22:25:48
>>724の頭がよくわかんない。

727 :デフォルトの名無しさん:2010/06/16(水) 22:27:06
そのとばっちりで日本語が基本1文字3バイトになるんだから
たまったもんじゃないな

728 :デフォルトの名無しさん:2010/06/17(木) 00:30:44
いや別に。外部表現だし。

729 :デフォルトの名無しさん:2010/06/17(木) 01:42:26
>>727
文字数が多い場合は問題になるが、大抵の場合はそこまで問題にならないと思うぞ。

そして、文字数が多い場合は当然圧縮もかかってると見るべき。そのときどうなるか調べてみた。
青空文庫の「吾輩は猫である」現代仮名遣、テキストのを落としてきた。
ttp://www.aozora.gr.jp/cards/000148/card789.html
元ファイルはsjisなのでiconvでutf-8に変換したものと比較。圧縮形式はgzとbz2

無圧縮でのファイルサイズ
sjis: 748715
utf-8: 1120272
比率: 1.496

gz圧縮
sjis: 344127
utf-8: 390050
比率: 1.133

bz2圧縮
sjis: 251847
utf-8: 265362
比率: 1.054

まとめ
・utf-8の方が常にファイルサイズが大きいことには変わりない
・圧縮するとファイルサイズの比率は少なくなる
・sjisでもutf-8でも情報のエントロピーは同じはず
・なので優れた圧縮形式だと比率は1に近づく
 (が、優れてない圧縮形式でも偶然1に近づいたり1を下回ったりすることもありうる)
・圧縮せずに使いたいサイズの大きいテキストや、非常にサイズが大きくbz2での6%以下のファイルサイズ増加でも
 大きな影響を与える場合は、utf-8は避けた方がいい
・そこまででもない場合は、そこまで気にしなくても良い

730 :デフォルトの名無しさん:2010/06/17(木) 02:13:47
プレーンテキストに日本語の文章を書くような場合は、
utf-8よりutf-16の方がいいだろうね。

ただ(x)htmlの場合は、ファイル中に占めるタグやら何やらの比率が高いから、
sjisとutf-8との差は相対的に小さくなる。

731 :デフォルトの名無しさん:2010/06/17(木) 10:24:07
今時utf-8のサイズがどうこう、sjisの方がうんぬん、なんて時代錯誤がいるとは驚きを禁じ得ない。

どう考えても、既にsjisやらiso-2022-jpやらの時代ではありません。


732 :デフォルトの名無しさん:2010/06/17(木) 11:57:44
対案も出さずに文句だけ言う口か

733 :デフォルトの名無しさん:2010/06/17(木) 11:59:16
世の流れ

734 :デフォルトの名無しさん:2010/06/17(木) 20:09:30
どうみても UTF-8 一択です
ほんとうにありがとうございました

735 :デフォルトの名無しさん:2010/06/17(木) 23:45:52
1995年頃ならまだしも今さら「対案」なんか出されても迷惑なだけだがな。

736 :デフォルトの名無しさん:2010/06/18(金) 00:29:56
合成済み文字は排除する・漢字はIDSで表記する
これなら16bitで行けそうな気がしないでもない。

737 :デフォルトの名無しさん:2010/06/18(金) 01:50:12
>>731
今も昔も、sjisをutf8に変えると約1.5倍になる事実には変わりがない。
ちょっとしたテキストファイルがHDDを圧迫する時代ではなくなったが、莫大な量のテキストを扱う用途もありうる。
それすらも考えられないのは時代云々以前の問題。

ただ、時代的に、サイズを問題にするならギガバイト越えはしてるんだろうな、
DVDに収まらなくなってからでも全然遅くはないぞ、とは思う。

738 :デフォルトの名無しさん:2010/06/18(金) 05:52:05
ストレージの価格や回線の速度やSJISで表せない文字の需要がぜんぜん違うだろ。

739 :デフォルトの名無しさん:2010/06/18(金) 05:53:11
今も昔も円記号問題は変わらんな

740 :デフォルトの名無しさん:2010/06/18(金) 09:04:50
莫大な量のテキストならなんらかの構造を持ったデータにするだろ。
ベタデータで 1.5 TB じゃダメで 1TB なら OK っていう場合なんて、ちょっと想像つかない。

741 :デフォルトの名無しさん:2010/06/18(金) 09:13:44
2GB以下でないと圧縮すると壊れるファイルとかあるからな
そういうのにシビアな環境のひとなんだろう

742 :デフォルトの名無しさん:2010/06/18(金) 09:19:50
通は故・UTF-7

743 :デフォルトの名無しさん:2010/06/18(金) 10:41:39
なんか痛々しくてどうにもならんな。

そんなサイズを云々するような規模の文書なら、プレーンってことはないだろ。
装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。そうなりゃsjisとutf-8のサイズの差なんて誤差だわ。

あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。


744 :デフォルトの名無しさん:2010/06/18(金) 11:43:27
文章を書く側が、自分の書くものがSJISで書けると分かっていて
SJIS使う分には別にどうも思わん。

プログラムを書く側が、SJIS前提のプログラムを書くのはさすがに
今となっては勘弁してほしい。

745 :デフォルトの名無しさん:2010/06/18(金) 12:07:26
とりあえず、難がなくて的確な>>744に同意しておこう

746 :デフォルトの名無しさん:2010/06/18(金) 12:10:07
>>741
pgr

747 :デフォルトの名無しさん:2010/06/18(金) 20:37:38
>>743
一般的な用途にはutf-8でいいというのは認めた上での話なのに、全く的外れ。

> 装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。
そんなことするってどこに書いてある?

> あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。
何を表現できるかじゃなくて何を表現したいかが問題。
漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。

748 :デフォルトの名無しさん:2010/06/18(金) 22:19:37
>漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。

ならば UTF-8 がいいよ

749 :デフォルトの名無しさん:2010/06/18(金) 22:47:24
なんというどっちもどっちだ

750 :デフォルトの名無しさん:2010/06/18(金) 23:51:02
>>748
ひらがな、半角カナならsjisで十分だし、容量も少なくなる。

751 :デフォルトの名無しさん:2010/06/18(金) 23:59:41
いやその前提はおかしい

752 :デフォルトの名無しさん:2010/06/19(土) 00:05:55
UTF-16にしたら

753 :デフォルトの名無しさん:2010/06/19(土) 00:55:02
Unicodeに絵文字収録されても「全部」でない以上何の解決にもならん木がするんだが…

754 :デフォルトの名無しさん:2010/06/19(土) 00:58:10
絵文字
一時しのぎに外字登録みたいなことするとか?

755 :デフォルトの名無しさん:2010/06/19(土) 01:38:09
>>754
機種依存文字の時代に逆戻りなわけですね。

756 :デフォルトの名無しさん:2010/06/19(土) 03:36:51
>>755
mixiみたくエスケープすればいいだけの話。
一般の文字と同様にコード空間に割り当てることだけは断固として反対する。

757 :デフォルトの名無しさん:2010/06/19(土) 04:28:08
>>756
もはや文字コードじゃないね。

758 :デフォルトの名無しさん:2010/06/19(土) 09:13:02
sjis真理教には何を言っても無駄っぽいなw

どうせ何を言っても彼には結論が一つしかないんだし、相手しない方が良さそうだ。

759 :デフォルトの名無しさん:2010/06/19(土) 09:19:11
エスケープっつーとJISみたいな感じか?

760 :デフォルトの名無しさん:2010/06/19(土) 09:28:27
mixiの絵文字の場合は、[m:123] みたいな形式。

絵文字だって文字なんだからコード空間に割り当てられるのは当然の流れだろう。
誰も使ってない象形文字にすら文字コードがある時代なのに。


761 :デフォルトの名無しさん:2010/06/19(土) 09:32:54
図書館の◆とかだろ

762 :デフォルトの名無しさん:2010/06/19(土) 09:44:40
絵文字は文字じゃねーよ
絵だよ

763 :デフォルトの名無しさん:2010/06/19(土) 09:51:57
絵文字は象形文字だよ

764 :デフォルトの名無しさん:2010/06/19(土) 09:53:27
┏━─┓
│    ┃
└┐┌┘
  ┗┛

こいつらに言ってやれよ

765 :デフォルトの名無しさん:2010/06/19(土) 10:20:32
>>758
それはユニコード原理主義者の話だろ。

sjis真理教信者は幸い、ここには来てないよ。
ごく限られた用途によってはsjisの方がいい場合もありうるって話

766 :デフォルトの名無しさん:2010/06/19(土) 10:37:48
携帯とか通信量がシビアな場合はSJISの方がいいように思う

767 :デフォルトの名無しさん:2010/06/19(土) 10:44:32
通信量というか通信料だなw

768 :デフォルトの名無しさん:2010/06/19(土) 10:47:32
まあどっちでも通じるけどw

769 :デフォルトの名無しさん:2010/06/19(土) 10:59:58
最近アナタたち元気ね

770 :デフォルトの名無しさん:2010/06/19(土) 11:01:15
圧縮すれば大差ない

771 :デフォルトの名無しさん:2010/06/19(土) 12:59:59
どう見てもごく限られた用途の話なんかしてなかったけどな

772 :デフォルトの名無しさん:2010/06/19(土) 13:05:09
>>771
だよね。>>737, >>747みたいな使用例って極めて一般的だよね。

773 :デフォルトの名無しさん:2010/06/19(土) 13:21:47
自作自演カコワルイ

774 :デフォルトの名無しさん:2010/06/19(土) 13:25:04
どっちも落ち着けよ

775 :デフォルトの名無しさん:2010/06/19(土) 16:32:47
Shift_JISはテキストデータのサイズが小さくなる!(キリッ


776 :デフォルトの名無しさん:2010/06/19(土) 17:39:27
そういうのはやめれ。どっちもどっちだと思ってたけど
議論でさえない煽りに熱中しだすのはただの迷惑行為だ。

777 :デフォルトの名無しさん:2010/06/19(土) 18:48:42
もうこれでいいんじゃね?

・相当な理由がない限りはutf-8を使え
・相当な理由があるときは、本当にutf-8じゃダメかを再検討せよ
・やっぱりutf-8じゃダメなら、本当に{sjis, euc-jp, ...}が有効な解決方法か検討せよ
・{sjis, euc-jp, ...}が有効な解決方法なんだったら、もう仕方ない

778 :デフォルトの名無しさん:2010/06/19(土) 19:22:42
まあそれでいいんだが、たまにはutf-16のことも…

779 :デフォルトの名無しさん:2010/06/19(土) 19:51:57
utf-16を採用しているのは
JavaとJavaScriptと
WindowsとMacOSXだっけ?
qtもUTF16だっけか。
たくさんあるよな。

780 :デフォルトの名無しさん:2010/06/19(土) 21:19:52
プログラミング言語内では UTF-16、ファイル出力とか外部との通信は UTF-8 ってことで。

781 :デフォルトの名無しさん:2010/06/19(土) 23:55:46
>>779
linuxはディストリによって違うのか?
まあ大体はUnicode化されているよね。

782 :デフォルトの名無しさん:2010/06/20(日) 00:20:10
日本語ならUTF-8よりUTF-16の方が良いもんなあ
サロゲートペアが嫌な感じではあるが

783 :デフォルトの名無しさん:2010/06/20(日) 00:23:20
C言語が癌なんだろうね。
昔から有るC言語のライブラリが
ASCII前提で作られている。

具体的に言うと、文字列の終わりは文字コード0になっていないといけない。
UTF16やUTF32は16bit、もしくは32bitで見れば、文字コード0ではないが、
1バイトずつ見ると、文字コード0が含まれているように見えてしまうことがある。
だから文字列の途中で文字の終わりと認識されてしまう。

784 :デフォルトの名無しさん:2010/06/20(日) 00:27:22
UTF-8はASCII互換が高いからねえ
検索関数とかそのまま使えるし

785 :デフォルトの名無しさん:2010/06/20(日) 00:49:32
>>781
そうなのか?
ロケールの話だと日本ならWindowsはsjisだし内部コードの話だと思うのだが、Linux内部ってそんな複雑な振り分けしてるのか?

786 :デフォルトの名無しさん:2010/06/20(日) 00:54:16
>>783
なんで1byteずつ見るんだ。
wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
0が含まれてなくても、2byteなり4byteなりで考えないと境界が曖昧になる問題は避けられないだろ。

787 :デフォルトの名無しさん:2010/06/20(日) 00:55:29
×ロケールの話だと日本ならWindowsはsjisだし

WindowsはUTF16。ただし9x系は各国ごとに違った文字コードで、
日本語版ならSJISだった。今のWindowsも9x系用のアプリを動かせるように
互換性機能がありUTF16に対応していない古いアプリを、
どの国の文字コードとして扱うかを設定切り替えられる。
もちろん日本語版はデフォルトでSJIS

788 :デフォルトの名無しさん:2010/06/20(日) 00:59:07
Macは基本UTF-8なんじゃないの

789 :デフォルトの名無しさん:2010/06/20(日) 01:01:00
>>786
昔のライブラリは文字列はcharであらわしているから。

> wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
型が変わってる。それじゃ互換性が保たれない。
つまりchar使っているアプリ(ライブラリ)すべて見直しが必要になる。
文字列を使う箇所といえばファイル名。ファイルを使うアプリはすべて見直し。
C言語の関数はcharを使っている。これは決まりだから変える事は出来ない。

C言語で作られているLinuxにとって、それは膨大な修正となる。
だからLinuxはunicode対応といえば、UTF8で、
UTF16やUTF32に対応しているものは無い。

790 :デフォルトの名無しさん:2010/06/20(日) 01:03:17
>>788
ファイルシステムがUTF8なだけで、
OS内部はUTF16

791 :デフォルトの名無しさん:2010/06/20(日) 01:08:24
>>790
複雑な事やってんだな

792 :デフォルトの名無しさん:2010/06/20(日) 01:11:45
WindowsNTやMacOS Xははじめからutf-16だもんな。
後からunicode対応した訳じゃなくて。

793 :デフォルトの名無しさん:2010/06/20(日) 01:15:48
>>791
.NETもそうだけどね。
内部は(Windows前提だから)UTF-16で、入出力はUTF-8が基本。
入出力用のAPIが標準でUTF-8を使うようにしておけば、アプリ側では特に何もしなくていい。

794 :デフォルトの名無しさん:2010/06/20(日) 01:23:45
サロゲートペアというレアケース以外固定長なUTF-16を使った方が
処理が早くなるとかあるんだろうか

795 :デフォルトの名無しさん:2010/06/20(日) 02:21:07
>>794
時代的な問題だよ。

当時は16bitで世界中の文字を
あらわせると思われていた。

wchar_t もそのころの名残だろう。
まさか可変長バイト文字(UTF8およびサロゲートペア)を
使わないとすべての文字が表せない。
wchar_t(16bit)が使い物にならなあい時代になるとはな。

796 :デフォルトの名無しさん:2010/06/20(日) 02:34:39
規格上は wchar_t の表現ビット数の上限 == 16bit というわけじゃないけどね
実際 gcc とか sizeof(wchar_t) == 4 だったりするし
wchar_t 導入時(規格になる前)は
16bit 決め打ちだったのかもしれないけど(当時の事は知らないので何とも言えない)

797 :デフォルトの名無しさん:2010/06/20(日) 02:54:05
>>787
だから、それがロケールに当たるものなんじゃないの?

>>789
実際のところ、utf-16にしないことでどれくらい、修正の手間が減るんだ?
修正が必要かどうかを判断するプロセスも含めて。

バグは見つかってから対応すればいいって考え方だったら結構手間が減りそうだけど、
はじめからある程度バグとったものを、と考えるとどうせ見直す範囲は多くなると思うぞ。

798 :デフォルトの名無しさん:2010/06/20(日) 02:59:37
>>795
1文字、という考え方だとサロゲートペアやらUTF-32ですら微妙。

799 :デフォルトの名無しさん:2010/06/20(日) 03:03:30
>>797
ASCII → UTF-16 文字列を扱う全ての関数に修正が必要。
ASCII → UTF-8 ほとんどの関数は手を加える必要がない。

800 :デフォルトの名無しさん:2010/06/20(日) 07:42:35
>>777
>・相当な理由がない限りはutf-8を使え

お役所様がSJISをお望みの場合が多いです。

801 :デフォルトの名無しさん:2010/06/20(日) 07:46:26
>>797
こういう、問題が起きたら直せばいいじゃん、とか言ってる奴、
いざ自分に問題が降りかかると延々とgdgd言い続けるんだよな。
当然自覚はあるよな?

802 :デフォルトの名無しさん:2010/06/20(日) 12:31:56
>>799
そんなことは分かってる。が、
> 文字列を扱う全ての関数に修正が必要
charをwchar_tに書き換えるだけで修正できるものも多い

> ほとんどの関数は手を加える必要がない。
手を加える必要がないことを見極める必要がある

その上で、具体的にどれくらいutf-8の方が手間が減るのか、というのを聞いてる。

>>801
>>797はそんなこと言ってないよ。ストレス貯まりすぎで文章が歪んで見えたか。かわいそうに。

803 :デフォルトの名無しさん:2010/06/20(日) 12:34:35
ストレス貯まりすぎで自分の文章を客観視できなくなっているらしい。放置推奨。

804 :デフォルトの名無しさん:2010/06/20(日) 13:54:21
>>802
いやね、C言語標準ライブラリだから
変えたらいかんのよ。
これは規格だからね。

printfの第一引数はchar*と決まってるのです。

805 :デフォルトの名無しさん:2010/06/20(日) 13:56:13
fopenの第一引数もchar*なのです。
そう決まっているのです。

806 :デフォルトの名無しさん:2010/06/20(日) 14:09:50
wprintfの第一引数はwchar_t *と決まってるのです。

807 :デフォルトの名無しさん:2010/06/20(日) 14:11:58
そこで最後の結論が出るわけさ。
wprintfなんてのは誰も使っていません。

808 :デフォルトの名無しさん:2010/06/20(日) 14:14:25
ま、printf とかを使ってたら _tprintf に置き換えなきゃいけないから、「charをwchar_tに書き換えるだけ」とは言えないか。
コンパイラで型エラーになるから直しやすくはあるけど。

809 :デフォルトの名無しさん:2010/06/20(日) 14:15:31
使ってないのなら、世の中のすべての
printfをwprintfにすればいいじゃない。
fopenをwfopenにすればいいじゃない。

wfopenという関数が世の中に無いなら
作ればいいじゃない。

互換性なんてすてればいいじゃない!

810 :デフォルトの名無しさん:2010/06/20(日) 14:16:47
>>808
_で始まる関数は、標準じゃないので
使わないでください。

811 :デフォルトの名無しさん:2010/06/20(日) 14:21:18
ここまでいえば理解できただろ?

charに問題なく代入できて、
問題なく処理できるように考えて作られたUTF8と

wchar_tに変えたところで16bitの可能性があるから
UTF16やUTF32を代入できるとは限らない。
じゃあどうしろと?という互換性の差を

812 :デフォルトの名無しさん:2010/06/20(日) 14:31:14
みんなGo言語使おうぜ!

813 :デフォルトの名無しさん:2010/06/20(日) 14:46:43
>>802
タダじゃ修正できませんのよ?
タダじゃテストできませんのよ?
タダじゃ見極められませんのよ?
ANSI Cの制定の時の苦労話とか読んでみ?

814 :デフォルトの名無しさん:2010/06/20(日) 17:29:20
新しい常用漢字表が、採用されて数年経てば、Unicodeで、保存するようになるんじゃね?
役所がSJIS2004を調達基準にすれば、Windowsでも対応するかもしれないけど。

815 :デフォルトの名無しさん:2010/06/20(日) 17:46:44
>>783
リトルエンディアンで半角英数をUNICODE化すると1バイト目が

816 :デフォルトの名無しさん:2010/06/20(日) 18:16:38
圧縮の話なんで、興味ない人は、するーするー

最近実用化されてきてる圧縮DBとかだと、
・LZO系のO(1)?なストリーム向け圧縮アルゴリズム
・インデックスなどで、局所的に取り出せる圧縮アルゴリズム
・圧縮RAMキャッシュ
とかあるから、将来は、普通のFSやDBからはじまって、アプリ向けのAPIやOSの機能として、
一般化するんだろうなとは思う。

http://db2.jugem.cc/?eid=1856
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.6676&rep=rep1&type=pdf
http://oai.cwi.nl/oai/asset/10892/10892D.pdf
http://cloud.watch.impress.co.jp/epw/cda/hardware/2008/07/09/13376.html

だけど、局所的に取り出せる圧縮アルゴリズムで、utf-8とsjisの差が縮まるかはまったく分からん。

Trieとか簡潔(圧縮)データ構造
http://www.kyoritsu-pub.co.jp/series/algo.html#8
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%82%A4%E6%9C%A8
http://gihyo.jp/magazine/wdpress/archive/2008/vol42
http://codezine.jp/article/detail/261
http://hillbig.cocolog-nifty.com/do/files/2005-12-compInd.ppt

817 :デフォルトの名無しさん:2010/06/20(日) 18:40:01
>>802

簡単にcharをwchar_tに書き換えると言うけど、gccなんか未だに
wchar_tに対応できてない部分が多数あるんだぞ。


818 :デフォルトの名無しさん:2010/06/20(日) 18:49:06
>>803
もし>>797>>801のように言ってるなら>>799はなんのために答えたんだー
>>807
誰もってことはないだろーなー
>>811
utf16なら問題ないんだろー
>>813
だからこそ、具体的にどれくらいかを聞いてるのに、何をするとか、誰が使ってるとかの話ばっかりで、
手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー

819 :デフォルトの名無しさん:2010/06/20(日) 21:20:30
sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。


820 :デフォルトの名無しさん:2010/06/20(日) 21:48:01
> 手間を定量化して

ソースコードの中のcharの数を数えたら?


821 :デフォルトの名無しさん:2010/06/20(日) 22:12:04
>>820
それだと、できてない。
charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。
大規模なプログラムでは、機械的な変換でどうにでもなるcharからwchar_tへの書き換えよりも、
真に大変なのは、意味的に正しいかどうか判定しなければならない部分。
(例えば、バイト数を数えているのか文字数を数えているのかでstrlenを使うのが適切か不適切かは変わってくる)

そのへんを加味すると、utf-8とutf-16のコスト差は、圧倒的ではなくなる可能性がある。
utf-8の方が多少はマシだとは思ってるが、圧倒的に楽だとはとても思えない。

822 :デフォルトの名無しさん:2010/06/20(日) 22:19:23
Qt

823 :デフォルトの名無しさん:2010/06/20(日) 22:19:42
>>819
レッテル貼りに走るのは、文字の読めない人のすることだ。

> てか、CなんかよりC++を使え。
なんでそういうバカなこと言っちゃうかなぁ。
万人に取って、すべてのソフトウェアに取って、CよりC++の方が適してるなんて限らないんだから。
無駄に選択肢狭めることを、人に押し付けちゃいかんよ。

824 :デフォルトの名無しさん:2010/06/20(日) 22:23:14
やっぱり単なる馬鹿でした。


825 :デフォルトの名無しさん:2010/06/20(日) 22:40:08
双方が馬鹿馬鹿言ってるから手に負えない

826 :デフォルトの名無しさん:2010/06/20(日) 22:45:26
このスレ、ひとつの方法しか認めたがらない人多いの?

827 :デフォルトの名無しさん:2010/06/20(日) 22:58:13
全部包摂したくなるのさ

828 :デフォルトの名無しさん:2010/06/20(日) 23:26:39
>>821
> charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。

UTF8でもUTF16でもUTF32でも、同じようにかかるコストは比較しても、
”同じ” になるので、ここで取り上げる必要は無いんじゃないですかぁ?

それ以外のコストの話をしましょうよ。ニヤニヤ

829 :デフォルトの名無しさん:2010/06/20(日) 23:28:51
>>821
strlenぐらいなのと、
すべて書き換えないといけないのと
比べるまでも無いだろ。アホw

物事ってのは少しずつ変えていくもんだ。
一気に全部変えたらどうなるか予想ぐらいつくだろ。

830 :デフォルトの名無しさん:2010/06/21(月) 00:44:14
>>818
>手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー

中学生の脳内じゃないんだから、それにだって金も手間もかかるんだよ。

831 :デフォルトの名無しさん:2010/06/21(月) 07:25:53
そもそも utf-8だと日本語文字が1.5倍の容量を食うから
sjis それでなければwcharって主張がこの流れになってるんだろ?

だったら gccでwcharは4バイトって話が出た時点で終了だろ


832 :デフォルトの名無しさん:2010/06/21(月) 08:57:50
sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。


833 :デフォルトの名無しさん:2010/06/21(月) 09:54:10
>>828
なにいってんだ?
utf16で余分にかかるコストの「割合」の話してるんだぞ?

>>829
>>801

>>830
やらないって選択肢もあるけど、やってもいないことを断定するな。

>>831
sjisの話とは別だろ。

834 :デフォルトの名無しさん:2010/06/21(月) 11:55:57

それ以外のコストの話をしましょうよ。ニヤニヤ

835 :デフォルトの名無しさん:2010/06/21(月) 12:04:20
放置推奨。

836 :デフォルトの名無しさん:2010/06/21(月) 12:24:10
>>833
なんでやってないと思うんだろう。
普通やるだろサラリーマンなら。

837 :デフォルトの名無しさん:2010/06/21(月) 12:51:31
おまいらスレ伸ばしすぎ

838 :デフォルトの名無しさん:2010/06/21(月) 13:07:07
本人たちが楽しそうならそれでいいじゃないか。

839 :デフォルトの名無しさん:2010/06/21(月) 16:09:19
よっぽどネタが無いんだな。


840 :デフォルトの名無しさん:2010/06/21(月) 23:58:09
>>836
なのに、実際にやったって話が出てこないんだぜ。

841 :デフォルトの名無しさん:2010/06/22(火) 13:37:07
やった人は反対意見の方にまわるからさ

842 :デフォルトの名無しさん:2010/06/22(火) 19:22:02
>>841
反対意見出す側にも、やったけど全然違った、と言ってる人はいないよ。

843 :デフォルトの名無しさん:2010/06/22(火) 19:26:18
端から見てるともはや何を言い争ってるのか分からんレベル
他所ん家の夫婦喧嘩見てるみたいだ

844 :デフォルトの名無しさん:2010/06/22(火) 19:49:45
それだけ仲がいいってことさ

845 :デフォルトの名無しさん:2010/06/22(火) 19:57:23
>>842
やったけどぜんぜん大変だよ。


というと次はソースを要求するのが中学生。
しかしコストかけたものをただで出すバカはいない。

846 :デフォルトの名無しさん:2010/06/22(火) 22:19:59
>>845
んなもん、仕事で測定したデータを詳細に2chで晒せなんて思っとらんわ。

動作確認コストの大きさが、大分前から理由として挙げられてるのに、
utf8が圧倒的楽って言ってるレスではその大きさについて触れようともしてないよね。
実際にやってみたなら、そのコストが大きいことは容易に分かるはずなのに。

847 :デフォルトの名無しさん:2010/06/22(火) 23:07:12
utf8が圧倒的に楽というのはな、
utf8の文字列を普通のC言語関数に渡したら
普通に処理してくれることで十分理解できるよ。

普通のC言語関数が使えなくなるのと
普通のC言語関数が使えることの差は
改めていうまでのこともない。


848 :デフォルトの名無しさん:2010/06/23(水) 01:46:25
>>847
まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は?
関数が動作することと、そこでその関数を使用することの妥当性の確認は全然違うことも分かってるよね?

その説明は「圧倒的に」楽である説明にはなってない。

849 :__STDC_ISO_10646__:2010/06/23(水) 02:26:47
「wchar_tは俺の嫁。俺の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」

850 :デフォルトの名無しさん:2010/06/23(水) 02:26:54
> まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は?
なんのことを言っているの?

たとえば、printfという関数。
これはよく使われている関数だよね。

これが使えなくなったら、大損害。
これはわかるよね?


851 :デフォルトの名無しさん:2010/06/23(水) 07:39:16
2バイト以上の文字が表示できるとは限らんぞ

852 :デフォルトの名無しさん:2010/06/23(水) 08:35:23
それは関数の問題?
外形から容易に想像できる機能の見積もりなんか楽なもんだ。

853 :デフォルトの名無しさん:2010/06/23(水) 08:54:57
>>850
そんなprintfをwprintfに機械的に置換すりゃ済むことを大損害って言ってたの?

854 :デフォルトの名無しさん:2010/06/23(水) 12:08:23
>>853
釣り?
無条件に置き換えられたら動かなくなるだろ。
ニートと素人は黙っててほしい。

855 :デフォルトの名無しさん:2010/06/23(水) 12:55:58
本当に毎日楽しいスレだな

856 :デフォルトの名無しさん:2010/06/23(水) 18:47:37
まるでSJIS用のprintfをそのままUTF-8でも使えるかのような勢いだな

857 :デフォルトの名無しさん:2010/06/23(水) 20:59:03
sjis用のprintfって何?

printfに渡すのは char *であって、sjisとかutf-8 とか別け隔て
しない良い子だよ


858 :デフォルトの名無しさん:2010/06/23(水) 21:06:27
printf が特別扱いするのは % だけで、 \ はスルーだし。

859 :デフォルトの名無しさん:2010/06/23(水) 22:52:06
>>857
( ゚д゚)ポカーン

860 :デフォルトの名無しさん:2010/06/23(水) 23:01:19
>>857
いいか
UTF-8の大きな特長ってのは
従来の検索関数が「実装を全く変更しなくても」そのまま使えると言う事だ
printfは実装の変更が必要になる例だ

861 :デフォルトの名無しさん:2010/06/23(水) 23:07:08
>>860
どんな変更が必要?

862 :デフォルトの名無しさん:2010/06/23(水) 23:56:26
>>861
まずprintfではUTF-8以外のUNICODEを扱えない。
扱えるようにするためにprintfの内部も修正する必要があるだろうが、
引数もchar*では対応できない。wchar_t*に変更する必要がある。
(なおSJISもEUC-JPもchar*のまま使える)

printfの引数をwchar_tに変更するということはどういうことか、
たとえばLinuxならCライブラリがインストールされているわけだが、
そのライブラリを修正しないといけなくなる。

もちろんライブラリを修正すると、
それを使っているアプリ全部修正しなければいけなくなる。

printfを使っていないアプリはまず無いため、OSもアプリも
ほぼすべてのソースコードに修正が必要になるということを意味する。

Linuxの世界では、アプリの作者はばらばら。その全員に対してwchar_tに変更してください。
と頼むのは現実的ではない。かといってディストリビューターがパッチとして提供するには
量が多すぎる。

863 :デフォルトの名無しさん:2010/06/24(木) 00:00:16
>>862
それはUTF-8以外の場合は、printfの実装に変更が必要ってことだろ?
UTF-8の場合はprintfの実装は変更しなくても動くよ。

864 :862:2010/06/24(木) 00:01:18
>>863
そういう話をしたつもりだけど・・・

865 :デフォルトの名無しさん:2010/06/24(木) 00:01:18
>>862
そんなことは聞いていません。
printf を UTF-8 に対応させるのに必要となる「実装の変更」を聞いています。

866 :デフォルトの名無しさん:2010/06/24(木) 00:02:46
UTF-8はcharでいいだろう常考

867 :デフォルトの名無しさん:2010/06/24(木) 00:03:05
glibcにwprintf()は入っているしprintf()は%lsを受け付けるのだから
ライブラリを修正する必要なんかどこにも無いだろ

868 :デフォルトの名無しさん:2010/06/24(木) 00:04:53
>>865
SJISは2バイト目に\がある場合があるので、
エスケープシーケンスと誤認しないようにチェックが必要
そのチェックが入ったコードはUTF-8では使えない

869 :デフォルトの名無しさん:2010/06/24(木) 00:05:33
printf は \ を特別扱いしないんだってば。

870 :デフォルトの名無しさん:2010/06/24(木) 00:07:03
printfにSJISコード渡してもEUCコード渡しても
正しく動くんだよね。

これはSJISもEUCも(もちろんUTF-8も)ASCII互換だから。
英数文字の部分はASCIIコードと同じでそのほかの文字のコード
ASCIIコードに間違われないような形でうまく配置している。
だからchar*に渡してもちゃんと動く。

でもUTF16やUTF32はASCII互換じゃないんだよね。
ASCIIコードの文字コード自体が8ビットから16ビット、32ビットに
変わってしまっているから、基本的なprintfでさえ
型の変更が必要になってしまっている。

871 :867:2010/06/24(木) 00:07:37
wchar_tを使いたいなら、れっきとした標準であるC95で導入された
wchar_t用の関数を使えばよい、もう15年も前の標準だ

localeに応じてwchar_tへ変換したり、wchar_tでファイルを読み書きするための
関数もC標準には用意されている
UTF-8に変換する関数などというものは標準には無いがな

872 :デフォルトの名無しさん:2010/06/24(木) 00:08:01
>>865 コンパイラ(およびプリプロセッサ)のやることと、ライブラリのやることを混同してるだろ。

873 :デフォルトの名無しさん:2010/06/24(木) 00:09:13
>>871
規格にあるからといってまともな実装があるとは限らないのだがな・・・

874 :デフォルトの名無しさん:2010/06/24(木) 00:09:16
アンカを訂正
>>868 コンパイラ(およびプリプロセッサ)のやることと、ライブラリのやることを混同してるだろ。


875 :デフォルトの名無しさん:2010/06/24(木) 00:10:04
>>869
じゃあどうしてるんだ

876 :デフォルトの名無しさん:2010/06/24(木) 00:11:02
>>868
> SJISは2バイト目に\がある場合があるので、
> エスケープシーケンスと誤認しないようにチェックが必要

UTF16、UTF32は2バイト目、3バイト目、4バイト目に
\0が、よく使われる英数文字に入るので、今のコードは使えない。

もし、printf((char*)"Hello World") (Hello WorldはUTF16)
なんてことをすると、Hしか表示されない(エンディアンによっては何も表示されない)

877 :デフォルトの名無しさん:2010/06/24(木) 00:12:24
>>876
今はUTF-8の話してるんだから邪魔しないでくれ

878 :デフォルトの名無しさん:2010/06/24(木) 00:13:35
>>871
> wchar_t用の関数を使えばよい、もう15年も前の標準だ

そこで俺が止めを刺してやろう。
wchar_tを使うfopenの代わりになる標準関数は無い。

つまりUTF8以外のUNICODEのファイル名は
オープンできませんw

だいたい、wchar_t用の関数を使ってないコードが
たくさんあるから、大問題って話だろうが。
みんなprintf使ってるよ? 知らないの?

879 :デフォルトの名無しさん:2010/06/24(木) 00:14:16
>>875
エスケープシーケンスはコンパイル時に解決されるので
printfは解析しない

880 :デフォルトの名無しさん:2010/06/24(木) 00:15:19
ならprintfに変更すべき点はないのか・・・

881 :デフォルトの名無しさん:2010/06/24(木) 00:16:26
>>878
一体何が「とどめ」なんだ?

Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
char*で扱えばよいだけだ
何でもかんでもwchar_tにしろとは誰も言っていない

もしwchar_tで保持されているテキストをファイル名として扱いたいときは、
wcstombs()などで変換すればよいだけだろ

882 :デフォルトの名無しさん:2010/06/24(木) 00:16:37
本当に毎日楽しいスレだな


883 :デフォルトの名無しさん:2010/06/24(木) 00:16:59
>>875
じゃあどうしてるんだって?
そんなもんコンパイラがSJISで書かれたコードだと判断したら、
SJIS用に2バイト目に\がある場合の処理をちゃんとするだけだろ。

ここまでがコンパイラの仕事。



884 :デフォルトの名無しさん:2010/06/24(木) 00:17:12
printf()には%lsでwchar_t文字列を食わせられるだろうに

885 :デフォルトの名無しさん:2010/06/24(木) 00:18:42
>>881
> Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
> char*で扱えばよいだけだ

ただのバイト列じゃないよ。\0で終わるバイト列。
UTF16やUTF32は文字に\0が含まれるため、
ファイル名が途中で切れることになる。

つまりchar*でUTF16、UTF32はどうやっても扱えない。
UNICODE系はUTF8だけがchar*で扱える。

886 :デフォルトの名無しさん:2010/06/24(木) 00:19:08
wchar_t使ってんのは実質Windowsだけだろ。

887 :デフォルトの名無しさん:2010/06/24(木) 00:20:09
>>885
wcstombs使えばいいで答えが出てる

888 :デフォルトの名無しさん:2010/06/24(木) 00:21:30
>>878
utf-8でエンコードしたファイル名を受け付けるかどうかは処理系依存だがな。

889 :デフォルトの名無しさん:2010/06/24(木) 00:22:28
>>887
じゃあwcstombs使ってファイルオープンするコード書いてみw

890 :デフォルトの名無しさん:2010/06/24(木) 00:23:46
>>885
そういう話か
それはその通りだが、プログラム側としては「ファイル名のエンコーディング」
というものは意識しない/仮定しないのが正しい
あくまで0終端されたバイト列で、それ以上の物ではない

>>886
想像で嘘を言わないように
例えばwcwidth()はワイド文字の幅を取得する関数だが、非常に多くのプログラムで使われている
http://www.google.com/codesearch?q=wcwidth&hl=ja&btnG=%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%A4%9C%E7%B4%A2

891 :デフォルトの名無しさん:2010/06/24(木) 00:25:55
>>888
> utf-8でエンコードしたファイル名を受け付けるかどうかは処理系依存だがな。

それは問題ない。UTF-8はASCIIと互換性がああるため、
コード自体にUTF-8対応の処理は必要ない。
ま、あえて言うのなら1文字を8bitで処理していればいいだけ
(つまり7bitではないということ)

EUC-JP対応なら当然8bitで処理しているので、
何の問題も無く、UTF-8のファイル名をつけつけられる。

だから互換性が高いといわれているんだよ。
そしてそうではないUTF-16、UTF-32がだめだって話の流れ。


892 :デフォルトの名無しさん:2010/06/24(木) 00:28:21
(しばしばゼロ終端された)バイト列を扱うコンテキストにはUTF-16やUTF-32は
向かない
ファイル名や入出力などだ

が、プログラムのメモリ上で扱う内部エンコーディングとしては何の問題もないよ
特にUTF-8と16, 32はただの表現形式の違いに過ぎないのだから
容易にかつ無問題に相互に変換できる

893 :デフォルトの名無しさん:2010/06/24(木) 00:37:34
自分のアプリだけで完結するのなら
文字コードは好きにしろって話だけど、
ま、普通は既存のライブラリを使う。
そして既存のライブラリの多くはchar*が使われている。

これを変更するとなると影響範囲が大きすぎる。
そこで作り出されたのがUTF-8。UTF-8を使っていれば、
外部のライブラリからはまるでASCIIで渡されたような感じで処理できる。
これが互換性。

ファイル名や入出力だけでなく、
外部のライブラリを使う場合もUTF-8が優れている。
もしすべてをUTF16とかに変えようとすると、多大なコストがかかることになる。

894 :デフォルトの名無しさん:2010/06/24(木) 00:54:47
今日になって1時間足らずで30も伸びていてマジ驚愕

895 :デフォルトの名無しさん:2010/06/24(木) 06:13:31
printfスレでやれ

896 :デフォルトの名無しさん:2010/06/24(木) 07:19:02
誰が誰と何を争ってるのか全くわからん。

897 :デフォルトの名無しさん:2010/06/24(木) 07:48:55
>>860

だすらprintfは、sjisだろうがutf-8だろうが関係なくてchar *を
淡々と扱うだけで、sjis用printf だのutf-8用printfなんてのは
ない。 だからsjis用printfって何?って問うたんだよ。

898 :デフォルトの名無しさん:2010/06/24(木) 07:51:52
>>871

そのlocaleとwchar_tに関してgccなどは地雷を抱えてたりするわけだが


899 :デフォルトの名無しさん:2010/06/24(木) 07:53:19
文字コードと直接関係ないんだからC言語のスレでやれよ。

900 :デフォルトの名無しさん:2010/06/24(木) 09:57:57
>>891
つけられたってしょうがないだろ。
無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
今までのソフトウェア資産を捨てるか改造して、全部UTF-8にするってのなら別だけど。

901 :デフォルトの名無しさん:2010/06/24(木) 11:13:45
>>900

それはUTF-16だって同じ事だろ。

ASCII前提の処理系でASCIIで名前を付けたファイル名を扱うプログラムを
そのまんま、UTF-8前提の処理系でUTF-8のファイル名を扱うプログラム
として使用できる(ごくわずかな修正で)って話なんだから。

902 :デフォルトの名無しさん:2010/06/24(木) 13:48:19
晴れてるけど土砂降り

903 :デフォルトの名無しさん:2010/06/24(木) 14:02:40
このスレの情景か

904 :デフォルトの名無しさん:2010/06/24(木) 15:01:51
C++は第一引数にwchar_tを使えるfopenあるよ〜

905 :デフォルトの名無しさん:2010/06/24(木) 20:58:01
>>901
勝手に処理系を仮定されてもなぁ。

906 :デフォルトの名無しさん:2010/06/24(木) 22:01:43
勝手に処理系を仮定って言うけど、
EUCも同じだろ。 あとはEBCDIC とかEBCDIKとかかw


907 :デフォルトの名無しさん:2010/06/24(木) 22:59:08
>>906
別にEUCじゃなくても文字化けするよ。
>>891
>EUC-JP対応なら当然8bitで処理しているので、
>何の問題も無く、UTF-8のファイル名をつけつけられる。
なんて面白いこと書いてたから。

908 :デフォルトの名無しさん:2010/06/24(木) 23:10:22
UTF-8を引き摺りおろそうとする気持ちはわかるが
UTF-16の方がもっとひどいという事実は変わらないよw

909 :デフォルトの名無しさん:2010/06/24(木) 23:17:22
>>900
> 無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
うん。文字化けに見えるよね?
人間としては正しいよそれは。

だけどね、バイナリとしてはどちらも同じなんだ。

文字化けというものは二種類ある。
一つは、化けてしまったら、元に戻せない文字化け。
もう一つは、化けても、元に戻せる文字化け
(ブラウザとか。エンコード切り替えするだけでちゃんと表示できる)

化けても元に戻せる文字化けというのは、処理の段階で文字化けは発生してないんだよ。
単に表示する段階で違う文字で表示されているだけ。データとしては一緒。
ようするにASCIIを扱う関数にUTF-8を渡しても正しく処理してくれる。ま、ごくわずかの例外はあるが。
例外というほど、少ない事例。そしてUTF-16をASCIIを扱う関数に渡したらほぼすべて動作しない。

910 :デフォルトの名無しさん:2010/06/25(金) 10:40:08
>>908
別に誰も引きずり下ろそうとしてないよ。

>>909
fopenにおいては、それじゃダメだろ。そしてremoveもrenameも例外か。
標準ライブラリ関数は例外か例外でないかのリスト用意すれば見分けが着くが、
人が作った関数はリストなんて作ってられないからなぁ。いちいち中身みないと。

そのまま渡したら動作しないことには誰も反論してないのに、なんでそれをまた主張するかなぁ。

911 :デフォルトの名無しさん:2010/06/25(金) 15:20:38
プログラムの側で実行環境のlocaleは仮定しちゃだめだし、仮定できないだろ
localeがUTF-8なら上手く動きますよ、じゃダメ

(大した内容でなくとも)なんらかのテキスト処理をするプログラムは
事実上エンコーディング変換は必須だろ
8bitクリーンにしとけばいいなんてのは、バイト列をそのまま右から左に
流せばすむプログラムだけだ


912 :デフォルトの名無しさん:2010/06/25(金) 22:34:45
>>910
なんか勘違いしてない?

fopenにUTF-8の文字コードのファイル名を渡したら
正常に処理されるよ。

実際にfopen使ってコード書いて、
UTF-8のエンコードに設定してある
Linuxで動かせばわかるじゃん。


913 :デフォルトの名無しさん:2010/06/25(金) 22:52:10
fopenにUTF-16のファイル名を与えたら・・・・
型が違うから与えられないけどなw
UTF16は互換性が無い。

914 :デフォルトの名無しさん:2010/06/25(金) 23:41:37
>>913
お前は前々から誰と戦ってんだ。
UTF-16がマルチバイト系のエンコーディングと互換性がないのを理解していない奴なんて誰一人いないじゃないか。

915 :デフォルトの名無しさん:2010/06/26(土) 00:13:50
> お前は前々から誰と戦ってんだ。
wchar_t野郎w

916 :デフォルトの名無しさん:2010/06/26(土) 00:52:25
文字コード方面は処理系ごとで違いがありすぎるからな。
wchar_tもwindowsではutf-16だかucs-2だか、glibcではutf-32だかucs-4だか、
それ以外じゃ下手すると非透過で>>849みたいな話になるし。
ファイル名とか言い出し始めるとOS/実行環境にも依存するべ。
現実的には標準関数のレベルで汎用的にはしよーとしないのが吉じゃね、本気でやるなら。
使い捨てのコードなら用が足りる程度に動きゃ何でもいい。

917 :デフォルトの名無しさん:2010/06/26(土) 02:26:01
>>912
何も勘違いしてない。君が混乱してるんじゃないのかい?
utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね?

みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
そうじゃないことも分かってるんだよね?

918 :デフォルトの名無しさん:2010/06/26(土) 08:17:32
Subversionスレから導かれて来ました。
git,Mercurialで日本語だとsjis,utf-8混在環境は簡単に出来ちゃうわけで。
日本以外でも、latin-1やロシア東欧のコードとutf-8の混在が問題になっているわけで。
sjis,euc混在という先輩でもある日本としては、パス名として厄介な'/','\'が含まれず、
無効の判断が容易なutf-8が現時点での妥協点では無いでしょうか?
Linuxでは、ロケールutf-8じゃないと動かないアプリが多くなってきましたし。

919 :デフォルトの名無しさん:2010/06/26(土) 09:11:14
誰だ召喚したのは

920 :デフォルトの名無しさん:2010/06/26(土) 11:02:38
>>918
他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」って主張は受け入れる気にはなれないけど。

いきなりなんでそんな話を?

921 :デフォルトの名無しさん:2010/06/26(土) 11:02:53
>>917
> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね?
どうなると思ってるんだ?


922 :デフォルトの名無しさん:2010/06/26(土) 11:05:49
utf8なバイトってのもよくわからんな。

16進数で考えれば、UTF8もそれ以外も
0x00〜0xFFのバイトの並びでしかないだろ。

923 :デフォルトの名無しさん:2010/06/26(土) 11:21:07
>>922
latin1ならその考えでいい。utf8はそれなりに考えられて作られている。

924 :デフォルトの名無しさん:2010/06/26(土) 11:36:57
> utf8はそれなりに考えられて作られている。
その中身を言えって。お前何も言って無いじゃん。

925 :デフォルトの名無しさん:2010/06/26(土) 11:37:04
>>920
> いきなりなんでそんな話を?
・ファイル名がunicodeというのはマルチプラットフォームでないということ
・そういえば、Javaってどうだったけ
・cygwin utf-8という曲者も出てきた

926 :デフォルトの名無しさん:2010/06/26(土) 11:38:27
> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね?
重要なことだからもう一度言います。

どうなると思ってるんだ?(笑)

927 :デフォルトの名無しさん:2010/06/26(土) 11:43:30
>>917
俺は>>912ではないが
lsなどで表示したらそのファイルは文字化けして見えるだろうが、
それでfopen()では何の問題も無く開ける

あくまでそのロケールで「テキストとして解釈できない」だけだ
fopen()のような関数は名前をテキストではなく単にゼロ終端されたバイト列として
扱うので、テキストとして解釈できないことは何も問題ではない



928 :デフォルトの名無しさん:2010/06/26(土) 11:47:48
一方、Javaあたりだと、ファイル名をテキスト(String)として扱うので、
そのファイルを開けないと思う

929 :デフォルトの名無しさん:2010/06/26(土) 12:00:09
それがUTF16やUTF32だと文字の一部にゼロが含まれるので
ゼロ終端されたバイト列として解釈できないんだよね。

だからLinuxはUTF8のロケールには対応しても
UTF16等には対応していない。LinuxはC言語をベースに作られているので
対応しようとなると大幅な変更が必要になる。

930 :デフォルトの名無しさん:2010/06/26(土) 12:02:20
localeをUTF16化しろとは誰も言っていないんじゃないの
UTF16や32は、基本的にプログラムの内部で(ワイド文字で)使うための
エンコーディングでしょ

931 :デフォルトの名無しさん:2010/06/26(土) 12:08:27
そんな話だっけ?
UTF16に簡単に変更できるとか言う話じゃなかったか?

932 :917:2010/06/26(土) 14:26:02
>>927
そのとおり。

そして>>917の後ろにも
> みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> そうじゃないことも分かってるんだよね?

って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
(それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)

933 :デフォルトの名無しさん:2010/06/26(土) 14:26:50
>>931
そんなこと誰が言った?

934 :デフォルトの名無しさん:2010/06/26(土) 14:46:56
一体UTF8の人は誰と戦ってたんだろうって思ってたが、ようやく疑問がとけた。
UTF8の人はUTF8にするのに、本当に何も手間がいらないと思い込んでいる。

そして、それはコンパイル通ってアプリケーションが落ちなければ、文字化けしてもどうなっても構わない、
という観点でいうのなら、正しい。


UTF16持ち出してきた人はUTF8にするにしても、文字化けしないなどの動作としての正しさを検証するためには
どうせソースをひっくり返して読まなければならず、それをする手間はあまりに多いので、
ついでにcharをwchar_tに、printfをwprintfにするくらい大したことじゃないと考えている。
そしてUTF8なら変更不要って、検証コストはどこにいった、それを評価した上で言ってるのか?と言っている。

wchar_tへの変更がついでにできてしまうほどに検証が大変だというのは大げさだろうが、
検証コストの大きさが無視できないのは確かだろう。
実際に、UTF8の人が勿体つけて出してきた「fopenはchar*しかうけつけない」というのも、
そのまんま渡すと文字化けする代物だったし。

935 :デフォルトの名無しさん:2010/06/26(土) 14:52:05
つまり、結局のところ、UTF8 vs UTF16って構造は間違いで、
UTF8だと手間なし派 vs UTF8でも手間はかかる派  なわけだ。にもかかわらず

UTF8でも手間はかかる派: UTF8でかかる手間を指摘
UTF8だと手間なし派: UTF16でかかる手間を指摘
してるから、手間なし派は見えない敵と戦ってるようになってしまってる。

936 :デフォルトの名無しさん:2010/06/26(土) 14:52:06
>>932
> >>927
> そのとおり。
>
> そして>>917の後ろにも
> > みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> > そうじゃないことも分かってるんだよね?
>
> って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
> そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
> (それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)

IMAP UTF-7 ってのがあってだね・・・


937 :デフォルトの名無しさん:2010/06/26(土) 14:54:25
>>935
あー、だからお前はあんなこといってたのねw
今やっとお前がずれていることがわかったわ。

938 :デフォルトの名無しさん:2010/06/26(土) 14:56:47
UTF8が文字化けするというのはあくまで表示の話で、
処理の内容は何も変わっちゃいないというのが
理解できてないんだから笑っちゃう。

fopenが何一つ修正なしに、UTF8の文字のファイル名を
受け取れるということが、理解できないようだね。

939 :デフォルトの名無しさん:2010/06/26(土) 15:25:43
極端な話、fopenの中で動くファイルシステムのコードが正規化を考慮するかって話の時に
知るか馬鹿って側と気になってしょーがねえって側の戦いみたいな。
あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか?

940 :デフォルトの名無しさん:2010/06/26(土) 15:48:17
>>939
不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
Windowsの場合、fopen_s, _wfopen_s という2つの関数がある。

941 :デフォルトの名無しさん:2010/06/26(土) 15:48:30
> あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか?
やっぱり理解してないね。

fopenが期待しているのは、
ゼロ終端されたバイト列。
文字コードは考慮していない。

942 :デフォルトの名無しさん:2010/06/26(土) 16:10:56
>>940
> >>939
> 不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
> Windowsの場合、fopen_s, _wfopen_s という2つの関数がある。
fopen自体はダメ文字は関係ないのか?

943 :デフォルトの名無しさん:2010/06/26(土) 16:13:30
>>937
匿名掲示板でお前って誰だww

944 :デフォルトの名無しさん:2010/06/26(土) 16:16:25
>>938
どのレスがそれ理解できてない人?

>>941
その通りで、君が言っていることは
fopenの第2引数が期待してるのがゼロ終端されたバイト列であって、
別にrとかwとかである必要がない、と言ってるのと同じくらい正しい。

945 :デフォルトの名無しさん:2010/06/26(土) 16:18:12
fopenの第一引数の間違いだろ。アホめ

946 :デフォルトの名無しさん:2010/06/26(土) 16:19:34
泥沼化したこの闘いに終わりはあるのか

947 :デフォルトの名無しさん:2010/06/26(土) 16:19:53
>>941
実装が余計な事しないのを保証する規格にもなってないんじゃね?
正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。

948 :デフォルトの名無しさん:2010/06/26(土) 16:21:32
> 正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。
何の話してるの?

fopenでゲタになんかならないけど。


949 :デフォルトの名無しさん:2010/06/26(土) 16:22:44
そもそも勝手にゲタになってしまったら、
違うファイル名(もとからゲタになっているファイル名)
を開いてしまうことになるぞw

950 :デフォルトの名無しさん:2010/06/26(土) 16:23:41
>>945
そだね。>>941は第一引数に限定してないよね。

951 :デフォルトの名無しさん:2010/06/26(土) 16:24:58
なんか文字の1と、数値の1の違いを
理解していない奴を相手にしているような気がしてきたw

fopenの中の人がsjis期待してるとか
意味不明すぎで、こいつが何を考えているのかわからん。

952 :デフォルトの名無しさん:2010/06/26(土) 16:25:30
いやあ、保証があるかの話で具体例は知らんのだけど。
>>949がありえない話なのだろうか?という疑問

953 :デフォルトの名無しさん:2010/06/26(土) 16:26:01
「ゼロ終端されたバイト列」の説明が必要では?

954 :デフォルトの名無しさん:2010/06/26(土) 16:27:35
>>952
それは、幽霊肯定派が、幽霊は本当にいないのだろうか?って言っているようなもんだな。

幽霊がいるというのなら、幽霊がいるという証拠をもってこい。
ありえないといいたいのなら、ありえない証拠をもってこい。

955 :デフォルトの名無しさん:2010/06/26(土) 16:28:33
>>953
え?説明されんとわからんのか?

だから話が通じないのかw

956 :デフォルトの名無しさん:2010/06/26(土) 16:32:00
>>951
fopenのプロトタイプはsjis期待してないけど、中の実装は期待してる。

Windows環境(パスの区切り文字は0x5c)を仮定するとだな。
ファイル"\x61\x5c\x61"は、ディレクトリ./a上のファイルaと解釈されるが、
ファイル"\x95\x5c\x62"は、ディレクトリ./上のファイル表aと解釈される。

957 :デフォルトの名無しさん:2010/06/26(土) 16:46:31
つまり文字コード厄介だからおまえらナメてかかるんじゃないぞという理解でよろしいか?

958 :デフォルトの名無しさん:2010/06/26(土) 16:49:34
>>957
うん。あるいはutf-8にすれば全てが嘘のようにうまくいく。どっちか信じたい方。

959 :デフォルトの名無しさん:2010/06/26(土) 17:01:09
SJIS, Windowsの話は出てきたけど、UTF-8-MACは?

960 :デフォルトの名無しさん:2010/06/26(土) 17:01:40
MACてなに

961 :デフォルトの名無しさん:2010/06/26(土) 17:05:45
>>956
だがな。UTF8はその0x5Cを
二バイト以降に配置しないようにしているから、
何の問題も無いんだよ。

互換性問題を解決した文字コード。
fopenを何の問題も無く使える。

962 :デフォルトの名無しさん:2010/06/26(土) 17:06:40
全てが嘘のようにうまくいくように
考えて作られたUTF8で
全てが嘘のようにうまくいくのは当たり前。

963 :デフォルトの名無しさん:2010/06/26(土) 17:09:55
LinuxってSJISに対応していないんだな。
ASCII互換ではないかららしい。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=10&topic=17296

逆に言えばASCII互換なら全て問題が解決する。
ということでUTF8が選ばれた。

964 :デフォルトの名無しさん:2010/06/26(土) 17:14:44
Sambaはutf8にしても安全になったの?

965 :デフォルトの名無しさん:2010/06/26(土) 17:15:19
>>956
それは、Windowsが特別にそういう実装になっているだけだな。
SJISはMSが作ったのだから、そういう変則的なことに対応していても不思議は無い。

だが、一般的なfopenではそんな実装をするとは決まってないし、
実際に実装されてない。ASCII互換でないものをもってきても
ASCII互換であるUTF8の例えにはならない。

966 :デフォルトの名無しさん:2010/06/26(土) 17:32:04
というかSJISで開くべきならSJIS使いなさい、
UTF-8で開くべきならUTF-8使いなさい以上の話ではないなという。

967 :デフォルトの名無しさん:2010/06/26(土) 17:45:31
UTF8の互換性の高さの話だろ。
なにも修正しないでも多くの関数でそのまま使える。

968 :デフォルトの名無しさん:2010/06/26(土) 17:56:23
>>961
でも0x95が2バイト目以降に来る場合はあるでしょ?
そしたら、その次の0x5cはバックスラッシュを意図しているはずだけど、そう解釈されない場合が出てくる。

>>965
特殊実装扱いにするにはメジャーすぎるよ。
けどそういうのはどうでもよくて、もともと>>956出したのは、
sjisを要求するfopenが存在しないかのように書いた人がいたからなんだけどね。

そして、sjis程度のascii非互換性でutf8神話は崩壊するって思っていいんだね。

>>966
全くその通り。それが一番正しいし、ほとんどの人にとってそれが当たり前。

969 :デフォルトの名無しさん:2010/06/26(土) 18:06:25
>>968
> でも0x95が2バイト目以降に来る場合はあるでしょ?
ASCII互換のUTF8は無い
そうならないように作られた。

970 :デフォルトの名無しさん:2010/06/26(土) 18:26:52
>>969
ムチャイウナ

971 :デフォルトの名無しさん:2010/06/26(土) 18:30:25
ツッコミどころがおかしいんだよ!
SJIS期待してるとこにUTF-8でしかもASCII外の文字食わして何する気だってとこなんだよ!
だから>>966で解決なんだよ!

972 :デフォルトの名無しさん:2010/06/26(土) 18:40:04
色々な論点がごっちゃになっとるなあ
プログラムの内部エンコーディングと外側でユーザが設定するロケールは
別物だろうし…

UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
ユーザに、UTF-8ロケールにしてファイルも何もかもUTF-8にしなさい
そうでなきゃ僕は知りませんと言いたいのか?

973 :デフォルトの名無しさん:2010/06/26(土) 18:46:20
>>972
Windowsのような特殊環境以外はfopenは文字コード関係なく'\0'で終わったchar*で問題無いって話なんじゃないの?

974 :デフォルトの名無しさん:2010/06/26(土) 19:15:25
>>973
char*でやろうがwchar_tでやろうが別にかまわないが
エンコーディングの問題からは逃げられんだろ
一般に、localeや処理するテキストファイルの中身がUTF-8だとは限らないのだし
UTF-8だとしてもテキスト処理においてはマルチバイト処理を必要とする
Shift-JISよりはずっと性質のいいエンコーディングではあるが

975 :デフォルトの名無しさん:2010/06/26(土) 19:21:02
>>974
fopenの話に収斂していたと思うけど、どこから遡ればいいの?

976 :デフォルトの名無しさん:2010/06/26(土) 19:27:57
fopen()だけ取り出してエンコーディングの問題を論じるのはナンセンスじゃないのか
まあそういう話ならどうでもいいし、特に言うべきことはないが


977 :デフォルトの名無しさん:2010/06/26(土) 20:35:47
>>971
必死だなw

ASCII期待しているLinuxに
UTF8を食わして問題無いんだよ。
互換性だからな。

978 :デフォルトの名無しさん:2010/06/26(土) 20:46:57
>>974
> >>973
> char*でやろうがwchar_tでやろうが別にかまわないが
wchar_tじゃだめでしょって話で、
ここまでやって例が1つもないから作った。

#include <stdio.h>
#include <stdlib.h>

int main(int arvg, char* argc[])
{
wchar_t *w = L"aaa";
FILE *f ;
f = fopen((char *)w,"w");
fclose(f);
return 0;
}


979 :デフォルトの名無しさん:2010/06/26(土) 20:52:14
他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」


980 :デフォルトの名無しさん:2010/06/26(土) 21:05:47
>>978
内部コードをそのままI/Oに使うとは、アホかw
内部のテキストをwchar_tで持っている場合、I/Oでは変換するのが普通だし
Unix系のOSでファイル名をわざわざwchar_tで扱う意味も無い

981 :デフォルトの名無しさん:2010/06/26(土) 21:12:35
その変換が必要ないのがUTF-8なわけだ。
これも互換性の高さゆえだな。

982 :デフォルトの名無しさん:2010/06/26(土) 21:24:09
変換が必要が無いのは、外部エンコーディングがUTF-8である場合だけだろ
Unixではユーザが任意にlocaleを設定できるのだし
テキストには多様なエンコードが使われている(メールは今でもiso-2022-jpだ)

単にそうなればいいね、便利だね、というだけの話?
実はそこで話がずれてんの?


983 :デフォルトの名無しさん:2010/06/26(土) 21:30:28
> Unixではユーザが任意にlocaleを設定できるのだし
だから、Unixで指定できるlocaleは
ASCII互換で無ければならないんだよな。

SJISとかUTF16とかUnixは対応していない。

984 :デフォルトの名無しさん:2010/06/26(土) 21:30:46
>>977
いつからLinux限定の話になったんだ? euc-jpじゃダメなのか?

985 :デフォルトの名無しさん:2010/06/26(土) 21:33:38
euc-jpもASCII互換だからね。
日本語だけしか扱えないけど。

986 :デフォルトの名無しさん:2010/06/26(土) 21:35:03
>>983
だから、EUC-JPとかは普通に使えるし、伝統的に使われてただろ
EUC-JPとUTF-8でテキスト処理を書く場合、同じコードにはならない
EUC-JPではリードバイトと後続バイトの区別がつかないから
文字の区切りが知りたければ先頭から舐めるしかないからだ

それにファイルの中のデータとして使われるエンコーディングならもっと範囲が広い
2chは言うまでも無くShift_JISだ

987 :デフォルトの名無しさん:2010/06/26(土) 21:40:54
>>986
うん、だけど、EUC-JPは2バイト目に0x80以下の文字を含まないから、
たいていの日本語に特に対応していないプログラムでも普通に処理できてしまうわけさ。
これが互換性の高さ。UTF8も同じだよね。

それに引き換えSJISやUTF16は2バイト目に0x80以下の文字を含むから
別途対応が必要。

988 :デフォルトの名無しさん:2010/06/26(土) 21:49:49
おまいら>>1にマッタリって書いてんだろ
一日でどんだけ伸ばしてんだよ
シバくぞ

989 :デフォルトの名無しさん:2010/06/26(土) 21:51:03
> たいていの日本語に特に対応していないプログラムでも普通に処理できてしまう
甘い
EUC-JPもUTF-8もバイト数=文字幅ではないし
半角カナ絡みで問題を起こすプログラムは非常に多かったし
文字を文字として認識しなければ、文字の真ん中で文字列を区切ることも普通に
有り得る

「たいていの」は言い過ぎ
「ほとんどテキスト処理を必要としないプログラム」ぐらいが本当のところだろ

990 :デフォルトの名無しさん:2010/06/26(土) 21:53:11
実は共通認識が多いんだけど、喧嘩する為にお互いあえて無視しているスメル
そろそろ次スレでつね

991 :デフォルトの名無しさん:2010/06/26(土) 22:05:11
うめ

992 :デフォルトの名無しさん:2010/06/26(土) 22:06:18
2chはどうして糞で最悪のSJISを標準エンコードにしたんだろw

993 :デフォルトの名無しさん:2010/06/26(土) 22:07:39
>>989
だが文字がずれる程度でたいていは処理出来てしまう。

994 :デフォルトの名無しさん:2010/06/26(土) 22:08:11
うめ

995 :デフォルトの名無しさん:2010/06/26(土) 22:11:07
>>993
じゃあ、後ろ1文字消す処理はどうするの?

996 :デフォルトの名無しさん:2010/06/26(土) 22:11:41
>993
半角カタカナが含まれてると固まったり落ちたりするメイルクライアントが沢山あったんだよ

997 :デフォルトの名無しさん:2010/06/26(土) 22:15:40
>>951

だなw

相手がsjisを期待していようがutf-8を期待していようが、fopenは
変わらず、相手の期待する文字列をchar *で渡してやればいい。

wchar_tだと、そうはいかないって話なのにね。


998 :デフォルトの名無しさん:2010/06/26(土) 22:19:19
>>995
後ろ1バイトが消えるだけ。

>>996
それは8bitコードに対応していないだけだね。
今は普通8bitに対応しているから問題なく動くという。

999 :デフォルトの名無しさん:2010/06/26(土) 22:19:28
>>972

>UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん

そんな奴いたか? wchar_tにすれば何もかもうまくいくよ派は居たけど。


1000 :デフォルトの名無しさん:2010/06/26(土) 22:20:04
>>997
じゃあ、wchar_tに全部置き換えればいいだけ。
define でcharをwchar_tにすれば
解決する話だ。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

219 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)