トップページ⇒tech
1001コメント293KB

文字コード総合スレ part5

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん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/
0002デフォルトの名無しさん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/
0003デフォルトの名無しさん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
0004デフォルトの名無しさん2009/03/09(月) 01:29:08
■これまでに行われた議論
・WinでCP50220 は Unicode からマルチバイト文字への変換でいわゆる半角カタカナを全角カタカナに置き換え
　内部的には Unicode -> CP932 -> CP5022ｘ って変換な気もする
・人名をソートかけたらバストサイズ順の並びになる？
・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のほうが化けにくい
0005デフォルトの名無しさん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% フォルダの下で実際に作ってみて。本当に作成できるかどうかで判断。
0006デフォルトの名無しさん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/
0007デフォルトの名無しさん2009/03/09(月) 11:23:37
RedHatで狽ｪ文字化けする。

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

・(ギリシャ文字の)Σについて
コード変換は問題ないが、viで開くと1カラム幅の文字と認識するようだ。
0008デフォルトの名無しさん2009/03/09(月) 11:45:17
1乙。ようやく立ったか。
しかし>>4-7みたいなのは、Wiki立てて
そこでまとめたほうがいいような気がするな。
000972009/03/09(月) 12:08:01
あーいや、>7は纏めじゃなくてちょっと気になったから書いたのだけど。
で、今確認したら(当たり前だけど)Σ以外のギリシャ文字も1カラム幅と認識している模様。
実際に使われているフォントは2カラム幅なのに……
0010デフォルトの名無しさん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とちがって。
001172009/03/09(月) 12:44:22
>>10
なるほど、半ば呆れつつ納得。THX!
0012デフォルトの名無しさん2009/03/09(月) 16:46:00
>人名をソートかけたらバストサイズ順の並びになる？
よくこんなの引っ張り出してきたな
001312009/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で
　再変換しているので、それをしなければよい。
001412009/03/09(月) 20:17:32
とりあえず纏めてみた。それでは、マッタリ行ってみよう。
0015デフォルトの名無しさん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
0016デフォルトの名無しさん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
0017デフォルトの名無しさん2009/03/10(火) 01:10:32
絵文字とかHistoric Kana(今はKATAKANA LETTER ORIGINAL Eのみ)を含んだ
Amd.7のドラフト
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3580.pdf
0018デフォルトの名無しさん2009/03/10(火) 20:44:25
Last Resort Pictures (N3412) が含まれてないけど
あれはやっぱりエイプリルフールのジョークだったってことでいいのかな
0019デフォルトの名無しさん2009/03/11(水) 00:35:59
立ってたのか、>>1乙
0020デフォルトの名無しさん2009/03/11(水) 14:27:07
こんなFirefox拡張あるんだな。
Emacsのdescribe-charみたいなやつ。

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

ってコメントしたいんだけどどうすれば届くのかさっぱりわからん
0022デフォルトの名無しさん2009/03/11(水) 20:56:35
>>1乙
これはポニテでうんぬん
0023デフォルトの名無しさん2009/03/12(木) 06:15:19
国旗周りでUnicode listが爆裂してたせいか
国旗もEMOJI COMPATIBILITY CHARACTERみたいな謎の記号に置き換えられてるな
0024デフォルトの名無しさん2009/03/12(木) 07:05:23
つーかまたUnicode listが燃え上がってるな
0025デフォルトの名無しさん2009/03/13(金) 11:16:41
自分でフォント作って組み込めば無問題。
こわいものなし。
0026デフォルトの名無しさん2009/03/13(金) 20:04:47
Unicode-C初期UTF-8エンコードの規格覚えている奴まだ居るか判らないけど、
やはりあの時、言語学者の言うこと等聞かずに、国別にセクション割り当てて、VLEで通すべきだったな。
glyphが多ければ無制限に拡張できる規格。
殆どの言語が一文字3バイトに収まって、ソート問題もなし、政治的配慮もありだったのに。
しくじった。
0027デフォルトの名無しさん2009/03/13(金) 20:17:09
collectionや制限部分集合の要素としてglyphic subsetも指定できるように
拡張してくれないかなあ。
要素はあくまでglyphic subsetなので、実装は必ずしもIVSをサポートする必要はない
(してもいいけど)。デフォルトの字形がglyphic subsetの範囲内に収まっていれば、
適合性を主張できることにする。
こうすれば、「新常用漢字の字形を実装したフォント」とか「JIS2004の字形を実装した
フォント」を、規格上曖昧さのない方法で表現できる。規格の行間とかJIS委員が
blogのコメントで吐き捨ててる愚痴まで読まないとまともに実装できないなんて
規格としては不健全きわまりない。
互換漢字大好きの日本代表には少しも期待してないのでUTCがんばれ
0028デフォルトの名無しさん2009/03/15(日) 08:29:09
>>26
日本のためだけにそんなオーバースペック提案しても通らない。というか通らなかった
わけで。
iconvだって文字列1つしかオプションに取れないのはほとんど欠陥といってもいいが、
ありとあらゆる柔軟な変換を可能にするためのオプション類の追加なんてできないので、
エンコーディング名に何でもかんでも詰め込む羽目に陥ってる(UTF-8-MACとか)。
0029デフォルトの名無しさん2009/03/15(日) 09:39:30
オーバースペックどころか、意図から外れてる。
0030デフォルトの名無しさん2009/03/19(木) 00:18:33
日本代表と全面戦争ktkr
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3590.pdf
0031デフォルトの名無しさん2009/03/19(木) 19:20:06
ちょっとアホな質問かもしれんが、つまり、U+624D　の　AJ1E0100 と　N3530E0103は同じと考えておk？
いいのか？
0032デフォルトの名無しさん2009/03/19(木) 22:22:25
USは同じでいいんじゃね? と主張しているだけで、最終的に判断して再提出するのは
(あるいはあくまで互換漢字を入れろと突っ張るのは)日本。
0033デフォルトの名無しさん2009/03/23(月) 18:46:12
ARIBといいケータイ絵文字といい昔の仮名といい
最近日本の文字のUnicodeへの提案多いね。
いい事だ。
0034デフォルトの名無しさん2009/03/23(月) 18:53:27
ぜひ写研時代の記号文字も提案を…
0035デフォルトの名無しさん2009/03/23(月) 19:23:39
変体仮名は住基仮名だけでも追加したほうがいいと思う。
戦前生まれの人の名前で戸籍上で使われてる事があってこだわる人がいるだろうから。
ところで名前に変体仮名を持つ人ってどれくらいいるのかな?
あまり見ないからごく小数なんだろうけど、実際に使われてても平仮名、片仮名あるいは元になったとされる漢字に置き換えたもので通してることが多いのかな?
0036デフォルトの名無しさん2009/03/29(日) 16:06:45
携帯絵文字の大半はBMP外になるみたいだね。
まあ仕方ないか。あれだけ数あるから。
U+2600～U+26FFはARIBとサッカーボールで全部埋まってしまうみたいだし。
U+2700～U+27FFには所々に隙間があって少しここに入れるものがあるみたいだがこの領域全部埋めようとはしないのかな?
0037デフォルトの名無しさん2009/03/29(日) 16:07:56
BMPに入るわけないだろw
0038デフォルトの名無しさん2009/03/29(日) 18:31:19
つーかそろそろBMPは終了のお知らせが近づいてる。
JIS X 0213:2000がかつて勝手に使ってたカッコ付きUCSの位置にもついに
割り当てが入るみたいだし。
IPv4アドレスとどっちが先に枯渇するかってくらいの勢いだ
0039デフォルトの名無しさん2009/03/30(月) 17:21:40
絵文字のどこらへんがBなんだ。
0040デフォルトの名無しさん2009/03/30(月) 22:01:21
Basicじゃなさそうな文字とか記号とかBMPにてんこもりなので
その批判はあんまり意味無いかも
0041デフォルトの名無しさん2009/03/31(火) 23:46:06
もうBMPは止めてCMP( Compatible Multilingual Plane )にでも
改名したほうがいいんじゃないかｗ
0042デフォルトの名無しさん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
> 結局の所、誰もマトモに「常用漢字表」を読んでいないということがあ
> りありと分かるだけ何じゃないかと。
常用漢字表の「明朝体活字のデザインについて」を無視してる奴が
どの口でほざくか。
0043デフォルトの名無しさん2009/04/04(土) 23:36:49
http://www.microsoft.com/typography/otspec/cmap.htm
Format 13: Last Resort Font
が追加された。ということはLast Resort Picturesはやっぱり
文字として符号化はしないんだな
0044デフォルトの名無しさん2009/04/10(金) 22:44:33
汗マークや怒りマークがようやくUnicodeで使えるようになるな。
0045デフォルトの名無しさん2009/04/11(土) 10:59:05
コードはあってもフォントとフォントへのマッピングが普及しているとは限らない罠
もういい加減、基本のフォントはタダで配れよ…
0046デフォルトの名無しさん2009/04/11(土) 18:55:01
これはGoogleが検索エンジンのデータベースへ蓄積するために提案したんだから
表示は最初から考慮の対象外
さんざん言われてるけどドコモ以外を正確に再現するには多色カラーや
アニメーションが欠かせないし
0047デフォルトの名無しさん2009/04/17(金) 13:17:46
>>35
官報にはたまに出てくるよ＞変体仮名

話は全然違うけど、CJKV改訂版の内容レビューだれかやってくれないかな。
本家に行っても、章立てすら見あたらない。
0048デフォルトの名無しさん2009/04/18(土) 17:39:45
もうすぐ中旬終わるけど新ライセンスのIPAフォントマダー?
文字鏡16万字版の通常版マダー?
まったくどいつもこいつも出す出す詐欺ばかりだ。
0049デフォルトの名無しさん2009/04/19(日) 05:47:42
>>48
おい、乞食のくせに口を慎めよ。
0050デフォルトの名無しさん2009/04/19(日) 20:29:36
女真文字
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3618.pdf
なんか漢字が混じってるような
0051デフォルトの名無しさん2009/04/19(日) 20:30:10
>>49
文字鏡16万字版はタダじゃねーぞ
0052デフォルトの名無しさん2009/04/20(月) 00:27:07
>>50
漢字と同じ字形の文字が少なからずあるからねぇ＞女真文字

しかし何だ、こういう一覧表見るとｗｋｔｋが止まらんな
0053デフォルトの名無しさん2009/04/23(木) 23:50:59
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3607.pdf
U+E0200..U+E0545はUnicodeだとdefault ignorableだし
UCSでも(代替)書式文字のために予約されてる範囲なんだが
本当にそこでいいのか?
0054デフォルトの名無しさん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に変わるようだが。
0055デフォルトの名無しさん2009/04/29(水) 12:19:38
>>54
なんでその中にモヤイ像が入ってんだ？w
0056デフォルトの名無しさん2009/04/29(水) 16:42:22
アメリカかなり妥協したなあ。
よっぽどAmd.8に入れたかったんだな。
0057デフォルトの名無しさん2009/04/29(水) 17:00:34
モヤイ像といえば渋谷名物だからなｗ
0058デフォルトの名無しさん2009/04/29(水) 17:27:35
109涙目w
0059デフォルトの名無しさん2009/04/30(木) 22:16:09
米がN3607に歩み寄ったってことは、もしかするとトランプも入ったのか
0060デフォルトの名無しさん2009/05/04(月) 17:43:21
トランプは全て入ったけど
i-mode隠し文字(EMOJI COMPATIBILITY SYMBOL)は誰が考えたってダメだろ
0061デフォルトの名無しさん2009/05/04(月) 19:02:28
TRONコードですらi-mode隠し文字の位置は空欄になってるぞ。
最初空欄を空けるのを忘れてて後から訂正が入ったりしたのはご愛敬
http://www2.tron.org/set08.html
0062デフォルトの名無しさん2009/05/04(月) 23:53:57
麻雀ドミノに続いてトランプか。
これなら花札も行けるかもな。
0063デフォルトの名無しさん2009/05/05(火) 05:31:05
トランプのところにはタロットの小アルカナも包摂するみたいなことが書いてあるから
そのうち大アルカナも提案されるのかね
いい加減節操がない気もするが
0064デフォルトの名無しさん2009/05/05(火) 12:33:16
ショウギーはまだぁ？
0065デフォルトの名無しさん2009/05/05(火) 12:52:43
ショウギーの駒は先手と後手の両方が必要だ
0066デフォルトの名無しさん2009/05/05(火) 22:15:29
WHITE SHOGI PIECEは上下逆さにしたものを包摂してるらしい
0067デフォルトの名無しさん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アプリ作ってるんだが、胃が痛い…。
0068デフォルトの名無しさん2009/05/05(火) 23:19:09
>>64
碁も必要ではないだろうか。
0069デフォルトの名無しさん2009/05/05(火) 23:34:26
碁は符号化するとしたらどんな感じになるんだろ。
○●の背後に┼があれば良いのかな。
0070デフォルトの名無しさん2009/05/05(火) 23:54:23
白丸の中に数字、と、黒丸の中に白抜き数字、で、十分な数
（とりあえず999まででおk？）が必要じゃないかな。

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

そもそも、碁の棋譜を文字で表現すべきものなのか、激しく疑問だが。
0071デフォルトの名無しさん2009/05/06(水) 01:53:51
楽譜や数式と同様にIgo Markup Languageと組み合わせて使うこと前提で登録なら
ありうるかも
0072デフォルトの名無しさん2009/05/06(水) 10:42:43
雀牌もやるきかｗ
0073デフォルトの名無しさん2009/05/06(水) 14:13:59
麻雀牌は収録済み
0074デフォルトの名無しさん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
0075デフォルトの名無しさん2009/05/06(水) 16:28:16
モンゴル将棋も忘れずに!
ttp://history.chess.free.fr/hiashatar.htm
0076デフォルトの名無しさん2009/05/06(水) 17:29:20
チェスと将棋に包摂されたりして
麻雀牌も中国麻将を区別してないみたいだし
0077デフォルトの名無しさん2009/05/07(木) 20:50:11
>>67
何を作っているかしらんけど、もしcharset=Shift_JISならそもそもそういう
文字は使うべきではないのでは。

ってゆうかそもそもそれをShift_JISと呼んでいる時点でアレだが。
0078デフォルトの名無しさん2009/05/08(金) 01:28:09
MacEncodingをInternetで使っちゃダメだよ
Mozillaが対応してるのもほとんど事故のようなものだし
0079デフォルトの名無しさん2009/05/08(金) 01:48:50
これってUTF-8のときも、MacOSでこの文字入力したら
私用領域の文字送ってくるってことでしょ。
対応しないならしないで、もしユーザーが使ったら
エラーメッセージ出さないと…。
0080デフォルトの名無しさん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を使うという手もあるよ。
0081デフォルトの名無しさん2009/05/08(金) 13:20:15
ユーザーが私用領域とか知った上で入力するとは思えないなぁ…。
あなたのソフトウェアのユーザーと、私が対象としてるユーザーは
違うようなのでもう消えます。さよなら。
0082デフォルトの名無しさん2009/05/08(金) 13:47:11
>>81
Webアプリ作っているお前の責任なんだが？
お前がUnicodeフレームワークの「利用者」
0083デフォルトの名無しさん2009/05/08(金) 14:03:41
>>82がよくわからない。

>>81は、「Webアプリ作っているオマエの責任」として私用領域ははじこうとしている。
>>82の言っているそのままなんだが…。
0084デフォルトの名無しさん2009/05/08(金) 14:06:13
>>81は、「対応する」=「そのままうけつける」、「対応しない」=「エラーとしてはじく」としているが、
>>82はどちらも「対応には変わりない」と言ってるんだろ。
0085デフォルトの名無しさん2009/05/08(金) 14:31:49
麻雀って赤牌は別コードになるのか?
0086デフォルトの名無しさん2009/05/08(金) 20:50:47
将棋の駒の上下逆さにしたの追加されるみたい。(ARIBにあるから)
ということは>>66で包摂しているって書いてあるが、これからは分離されるってことかな。
0087デフォルトの名無しさん2009/05/08(金) 23:37:10
CJK統合漢字拡張Dは数がかなり少なくなるみたい。(200字強)
でそれより後に拡張Eが追加されるみたい。これも少量になって残りは拡張F、G、…になるかも。
やっぱり拡張Bのときいっぱい追加して重複とかあったから、
反省してこれからは慎重に少しずつ追加していくことにしたのかな?
0088デフォルトの名無しさん2009/05/09(土) 01:27:23
漢字といえばN3530はどうなったんだろ
Resolutionsには言及されていないからMinutes待ちか
0089デフォルトの名無しさん2009/05/09(土) 12:30:36
>>85
Unicodeは色を符号化しません。
cf. 絵文字
0090デフォルトの名無しさん2009/05/09(土) 13:07:22
で、「じゃあフランス国旗とイタリア国旗はどうなんだよ」と突っ込まれたのが
国旗収録断念の理由の一つ
0091デフォルトの名無しさん2009/05/10(日) 12:53:41
>>90
包摂しちゃえばいいのに
0092デフォルトの名無しさん2009/05/10(日) 13:01:02
>>91
それじゃラウンドトリップコンバージョンが崩れるからダメなんだと
理由は他にもあるし
0093デフォルトの名無しさん2009/05/10(日) 22:45:12
ハートマークの色違いとかHEART-1、HEART-2、…とか名称は-数字を付けるらしいな。
以前の案では縞模様とか網掛けに置き換えるとかしてたみたい。
0094デフォルトの名無しさん2009/05/10(日) 23:26:56
なんかUnicode追加文字の符号位置だいぶ変更するみたいだね。ヤ行のえと□デはSMPの方に変更するらしい。
ヤ行のえは現代の仮名と古代の仮名は一緒にしない方がいい、
□デについてはU+32FFは○ンかもっと重要な文字が必要になったときのためにとっておいた方がよいということなどの理由らしい。
U+26xxに追加が提案されてたARIBの記号の一部はU+27xxやU+2Bxxに変更するみたい。
U+26xxのブロックはまだ埋まらないことになる。で携帯絵文字の内、蛇遣い座の記号はBMP内のU+26CEに提案されてた。
今後も変更があるかも知れない。最終的な決定はもう少し先になりそうだ。
個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。
0095デフォルトの名無しさん2009/05/10(日) 23:57:06
ARIB関連はもう動かせないよ。Amd6はFDAMに移行するから。
残りは明日からのUTCの会議次第でまだ紆余曲折あるかも。
0096デフォルトの名無しさん2009/05/11(月) 03:39:36
結合文字はIME文字一覧からでしか入力出来ませんか？
0097デフォルトの名無しさん2009/05/11(月) 11:53:28
> 個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。

一昔前によく使われた、写研の記号BA-90はどうすんだ、とか
収拾がつかなくなる気がする。じだいとともにうつりかわってるし。
0098デフォルトの名無しさん2009/05/11(月) 15:08:10
少なくともBA-90やBA-88はかつて漫画を中心に大量に使われたので
どこか提案して収録はして欲しいがSMPで良い。
0099デフォルトの名無しさん2009/05/11(月) 17:39:41
絵文字のとこに入ってる顔のついた月が
それっていう解釈でもいいかもね
0100デフォルトの名無しさん2009/05/11(月) 20:29:22
イワタアンチック体が収録しているんだが、これは外字だな
http://www.iwatafont.co.jp/MO_FONTS/set_image_pdf/antique/anti_b.pdf

このあたりの写植時代の記号類、Unicodeに入れてほしいね
0101デフォルトの名無しさん2009/05/12(火) 00:45:27
BA-88はFIRST QUARTER MOON WITH FACE、BA-90はFULL MOON WITH FACEと包摂か。
ところでBA-90って満月なの?
0102デフォルトの名無しさん2009/05/12(火) 04:50:52
BA-86からBA-89まで月が続いてるからBA-90は満月だと思い込んでたが、
そういわれりゃ太陽って可能性もあるわけか。
0103デフォルトの名無しさん2009/05/12(火) 11:13:50
ぽげむたマークか、懐かしいな（ひげ無いけど）
0104デフォルトの名無しさん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回読み直せ。それでもまだこんな寝言ほざくつもりならとっとと帰国して二度と
米国代表の邪魔をするな。
0105デフォルトの名無しさん2009/05/13(水) 23:49:14
wg2のminutesは面白いよな
utcのminutesも各自の発言まで載ってるといいのに
0106デフォルトの名無しさん2009/05/14(木) 08:08:09
> not reported
で、そのreportとやらはどこに送ればいいの?
太玄経記号の名前の天地人がおかしいとか、JIS X 0213用のNamed Sequencesが
足りねーよとかも、どこに言ったらいいかさっぱりわからないから2chとかで騒いでるん
だけど。
Unicodeは窓口を明確にしてるし、どっかの国のガス抜きのためだけにある
パブリックコメントと違ってちゃんと反映もしてくれるし必要ならWG2への提案まで
してくれるのに。日本人が日本代表動かすより米国代表やUTC動かすほうが
簡単ってどうなの?
0107デフォルトの名無しさん2009/05/15(金) 11:37:21
http://www.itscj.ipsj.or.jp/sc2/open/02n4015.pdf
とかに彼のものっぽいメールアドレスがあるから、
直接報告してあげればいいんじゃないの。
0108デフォルトの名無しさん2009/05/16(土) 03:33:02
>106
ロクな下調べもしないで騒ぐのならば、2chで始めた方が相手にも迷惑かからないかもね。
太玄経記号の天地人とかは amd 2 で直されて、annex p に注記が
入っている。0213のUSIとかもamd.7に入ってるけど、それでも足りないのがある？
0109デフォルトの名無しさん2009/05/17(日) 21:14:41
>>104
Suignardの言ってることも変。
IVSもnormalizationかけたら、現状じゃ落ちちゃうだろ。
将来は大丈夫って、そんなのウソ。
0110デフォルトの名無しさん2009/05/18(月) 02:05:03
>>109
IVSはnormalizationかけても落ちないよ。
ただ、SPP（14面）の文字は、文字列の等価性の比較のときは無視するべき。
照合アルゴリズムで、それをちゃんとやってるソフトも規定も現状では
整備されてないから、絵にかいた餅だってこと。
0111デフォルトの名無しさん2009/05/18(月) 02:07:48
SPP -> SSP
0112デフォルトの名無しさん2009/05/21(木) 23:34:35
PDAM8はsymbolばっかりだなあ、
と思ったら名前からしてAdditional symbolsが先頭に来ているのか。
0113デフォルトの名無しさん2009/05/30(土) 15:29:44
10646の新版もようやくCDですか
0114デフォルトの名無しさん2009/05/31(日) 03:48:29
ExtBマルチカラム化実現したのか
0115デフォルトの名無しさん2009/06/01(月) 03:39:53
ちゃっかりAmd.8まで入れてあるような。
0116デフォルトの名無しさん2009/06/06(土) 23:00:50
小形さんうまいこと引っ張るなぁ。
0117デフォルトの名無しさん2009/06/06(土) 23:24:51
北朝鮮（KP）のフォントが用意できてないみたいだけど、
規格票用のフォントを作る余裕なんてあの国にあるんだろうか。
なんかこっちが心配してしまうｗ
0118デフォルトの名無しさん2009/06/07(日) 12:27:50
北朝鮮にはウンチの絵文字をあげるよ
0119デフォルトの名無しさん2009/06/10(水) 09:07:45
絵文字ad hocは決定事項の報告が主だから、あれを元に
Peterが中立だったというには無理があるんじゃないかなあ。

Oさんが独自のソース持っているのなら話は別だけど。
0120デフォルトの名無しさん2009/06/28(日) 01:18:10
いつの間にか「祷」(第3水準の正字でなく第1水準の略字の方)と「穹」が人名用漢字に追加されてた。
0121デフォルトの名無しさん2009/06/28(日) 03:56:38
蒼穹のうんたら
0122デフォルトの名無しさん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
0123デフォルトの名無しさん2009/07/02(木) 21:43:02
あと難しいかもしれないけどWebdings、Apple Symbolsあたりをunicodeに入れてほしいなぁ。
0124デフォルトの名無しさん2009/07/02(木) 21:49:08
うるせえだまれ
0125デフォルトの名無しさん2009/07/02(木) 21:54:19
すんません
0126デフォルトの名無しさん2009/07/02(木) 23:24:51
>>123
Apple Symbolsって殆どUnicodeでそれ以外はAppleの私的な記号やん
0127デフォルトの名無しさん2009/07/02(木) 23:31:29
標識類や回路図用の記号なんかは難しいらしい。

ttp://std.dkuug.dk/JTC1/SC2/WG2/docs/principles.html
の34ページ目以降に解説があるから興味があったらどぞ。
0128デフォルトの名無しさん2009/07/03(金) 10:21:49
改正されたJISマークはどうなるんだろう。
というか、旧JISマーク（〄）は何をソースに入ったんだ？
0129デフォルトの名無しさん2009/07/03(金) 13:38:16
まさかデザイン変更するとは予想してなかったんじゃね？　それよりも、かつてのJIS X 0213のドラフト案には

ベンゼン環

があったんだよ。そんなもの一体何に使うんだっていうの。
0130デフォルトの名無しさん2009/07/03(金) 13:45:13
よくわからんが、化学式に使うんじゃねーの
0131デフォルトの名無しさん2009/07/03(金) 14:52:12
有機化学系の書籍では普通に本文中に埋め込まれてる。
0132デフォルトの名無しさん2009/07/03(金) 15:12:23
ベンゼン環はUnicodeには入ってるな。
0133デフォルトの名無しさん2009/07/04(土) 02:50:17
ベンゼン環だけあったって何の役にも立たんのにといつも思う。
0134デフォルトの名無しさん2009/07/05(日) 21:13:11
>>128
Adobe-Japan1-1じゃね?
新JISマーク取り込んだAdobe-Japan1-7まだー?
0135ぎじつしゃ１2009/07/05(日) 21:37:27
中途半端なぎじつしゃです。

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

HP-UXでは　返り値＝１　　WIndowsでは　２　となるようです。

どこか技術文書などがあれば紹介いただきたいのですが・・
0136デフォルトの名無しさん2009/07/05(日) 23:54:56
>>134
AJ1-7 は Unicode 5.2 の制定後になるのかな？
新JISマークが入るかどうかは知らんが
0137デフォルトの名無しさん2009/07/06(月) 01:15:45
Unicodeとは連動していない気がする。1-6が出てからもう5年近く経つし。
どういうタイミングで更新しているんだろな。
0138デフォルトの名無しさん2009/07/06(月) 09:43:01
>>135 マニュアル嫁
0139デフォルトの名無しさん2009/07/11(土) 23:38:41
Adobe-Japan1の非漢字にはUnicodeに入ってないのいっぱいあるよな。
JASマークとか一部の組文字とか。
これらはUnicodeに入れないのかな?
漢字は大半がIVSで表せるし表せないもの(撥の拡張新字体など)は拡張CやDで追加されるみたいだけど。


0140デフォルトの名無しさん2009/07/12(日) 01:16:00
JASマークは別に文章中で文字として使わないしなぁ・・・
まあそんなこと言い始めたらキリがないけど
というか、既に収録されているカタカナの組文字ってどういう基準で採用したんだろう？
http://www.unicode.org/charts/PDF/U3300.pdf
0141デフォルトの名無しさん2009/07/20(月) 06:49:29
そういえば、BETA Unicode 5.2.0でてるね、みんな読んだ？
http://www.unicode.org/versions/beta.html
0142デフォルトの名無しさん2009/07/21(火) 18:16:11
別スレにも書き込んでここで３度目なので、しつこいようですがよろしくお願いします


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

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

曖昧な質問で申し訳ないのですが、ここでは課題の文を晒せないので、よろしくお願いします＞＜
0143デフォルトの名無しさん2009/07/21(火) 18:27:53
>>142
あんた馬鹿?
0144デフォルトの名無しさん2009/07/21(火) 18:58:45
ttp://charset.7jp.net/jis.html
ttp://charset.7jp.net/sjis.html
0145デフォルトの名無しさん2009/07/21(火) 21:00:52
いまどき「JISコード」と教えてるとは感心できない学校もあるもんだ
0146デフォルトの名無しさん2009/07/21(火) 22:32:47
問題のための問題だろう。
おそらくJISの決まり事とか問題文と一緒に書かれている。
スレ違いだな。
0147デフォルトの名無しさん2009/07/22(水) 00:47:27
みんな冷たいな。

>>142
文の格納に必要なバイト数をJISコードの場合とシフトJISコードの場合のそれぞれで計算すればいいと思うよ。
0148デフォルトの名無しさん2009/07/22(水) 02:52:14
>>147
ご親切にありがとうございます

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


こんなこと聞いてホントに申し訳ないです;;
実は大学の選択科目の課題なのですが、基礎知識ゼロで飛び込んでしまったので、問題文の意味すら分からず困り果てている状態です＞＜
0149デフォルトの名無しさん2009/07/22(水) 05:34:37
＞＜
0150デフォルトの名無しさん2009/07/22(水) 05:39:31
今回の皆既／金環日食はトカラ列島中心だけど
2012年5月にはほぼ日本全国で金環日食が見られるんです
0151デフォルトの名無しさん2009/07/22(水) 08:30:50
>>148
友達を作るチャンスだろ
こんなとこ書き込んでないで周りと話せ
0152デフォルトの名無しさん2009/07/22(水) 17:28:05
「JISコードの場合」ってのがわからん。
ISO-2022-JPのこと？
0153デフォルトの名無しさん2009/07/22(水) 18:10:25
違うんじゃないかな
0154デフォルトの名無しさん2009/07/22(水) 18:12:46
>>148
足し算だけでいけると思うよ
文を作って左から数えるだけ
0155デフォルトの名無しさん2009/07/22(水) 20:20:57
You! ダブっちゃいなよ！
0156デフォルトの名無しさん2009/07/25(土) 04:30:38
>>141

どうやらようやくヒエログリフが（＞＜）ノ

これでやっと画像ファイルなくせる
0157デフォルトの名無しさん2009/07/26(日) 01:51:16
Amd.5と6の分か。
日本関連だと拡張漢字CとARIBかな。
0158デフォルトの名無しさん2009/07/26(日) 04:36:39
>>157
Amd.6も収録されるのか。
win7のTVゴシックはPUAにARIB外字が入ってるけど、どうなるんだろ。
AJ1-7あたりにも入るんかな＞ARIB
0159デフォルトの名無しさん2009/07/26(日) 14:54:23
最終的にはAmd.6で決まった符号位置に移動させるんだろうけど、
Unicode5.2とWin7のリリースがほぼ同時期なだけに、
タイミングが難しそう。
0160デフォルトの名無しさん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とは言わずに、ミドルエンディアンと習った覚えがあります。
どちらなのでしょうか？
0161デフォルトの名無しさん2009/07/27(月) 11:03:07
UNICODE って何？
UTF-16 とか、きちんと用語が使えるようになってからまた質問してね。
0162デフォルトの名無しさん2009/07/27(月) 13:37:19
文字列はビッグエンディアン
0163デフォルトの名無しさん2009/07/27(月) 13:39:57
ビッグトンチンカン
0164デフォルトの名無しさん2009/07/27(月) 13:47:44
>>160
文字をBEで表現するかLEで表現するかの違いこそあれ、
文字が逆順に表現されるようなエンコーディングは存在しない。
0165デフォルトの名無しさん2009/08/04(火) 21:24:11
>>148
質問の意図が分からないので、推測するけど、　JIS　＝＝　JIS X 0208でよいのかな？
マジスレすると、一言に漢字と言っても、JIS X 0208では6,355文字しか定義されていないので、
格納する文字列の中の漢字で、JISX0208に含まれない漢字（例：JISX０２１２等）
がある場合は切り替え命令が必要なので、その分必要なバイト数は増える。
半角カナ使用の場合も同様に切り替え命令の分必要なバイト数が増える。
例）"あ" == "<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バイト、その他は３バイトで計算（かなり大雑把だけど）
違う文字集合ごとに切り替える必要があり、その度に三バイト必要になる。
ただ、例外的に格納する文字列の始めがASCIIの場合、<1b 28 42>は必要なく、
新たに[現在の文字集合とは]別の文字集合にぶつかる度に三バイト必要になる。
また、文字列の最後の文字が属する文字集合がASCII以外である場合、<1b 28　42>を追加して
きちんと基本のASCII文字集合に切り替えて末端処理を行わないといけない。
当然、二つの文字列をつなぎ合わせる場合は、もし末端処理が不要（一つ目の文字列の最後の文字と、
2つ目の文字列の最初の文字が同じ文字集合に属し、かつASCII文字集合では無い）な場合、
末端処理として入れられた一つ目の文字列の最後の<1b 28　42>と二つ目の文字列の
最初の切り替え命令３バイトを取り除く必要がある。

粗悪なプログラムの場合、この辺の末端処理とか使われていないとか、切り替え命令の除去がされていないので、
注意する必要がある。
厳密には「文字集合」の意味は違うけど、多分質問者の教材ではそこまで深く掘り下げないと思うので
0166デフォルトの名無しさん2009/08/04(火) 21:25:41
あと、追加（文字数大杉）。
各国（１９２ぐらい？）毎の使用符号化方式と言語一覧表探してるんだけどだれか持ってない？
とりあえず地味に20ヶ国ぐらいググってるんだが、マイナーな国の情報とか乗ってない…orz
例）　日本＝日本語、euc-jp,shift-jis,iso-2022-jp;みたいに。
アフガニスタンとか、Extended Arabic Lettersの前に元々使っていたコードページとか
ある筈なんだけど、だれかエロい人おしえて？
0167デフォルトの名無しさん2009/08/05(水) 01:00:06
ここからたどれない？

ttp://www-01.ibm.com/software/globalization/expertise/index.jsp
0168デフォルトの名無しさん2009/08/08(土) 06:54:27
MicrosoftだとCode Page Identifiersとか。
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
ただ、実際にそこの国の人々がもっぱらどんな体系を使っているかは、
こういうのだとわかんないんだよね。
台湾のUAOとか最近まで知らなかったよ。
0169デフォルトの名無しさん2009/08/08(土) 17:07:22
Historic Kanaって名称は邦訳が難しそう
Kana Supplementの方が汎用性もあるし好都合なんじゃないか
0170デフォルトの名無しさん2009/08/09(日) 00:04:05
ほんとだよな。
それだったら「イ」と「エ」が合体したものや小書き「ヰ」「ヱ」「ヲ」や琉球語表記用の「て」と「ぃ」が合体したものなどの拡張仮名も入れることができるのに。
0171最近まで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
0172デフォルトの名無しさん2009/08/13(木) 21:29:19
今回は今ひとつだったなあ。
あんまりダブリン会議のこと引っ張ってると情勢変わるかもよ。
2～4月と8～10月は一番動きがある時期なんだから。
0173デフォルトの名無しさん2009/08/14(金) 04:13:09
絵文字なんてエスケープシーケンスとかmixiみたく特定の文字列で対応すればいいだろうが。
こんなの認め始めたらキリがないって。
0174デフォルトの名無しさん2009/08/14(金) 05:46:47
遅かれ早かれWEBにもあふれ出してきて、豆腐だらけになるんだろうな。
0175デフォルトの名無しさん2009/08/14(金) 15:25:35
iPhoneでSMSを使ったときのセキュリティー問題で話題になった豆腐も、きっとなにかの絵文字だったんだろうな。
0176デフォルトの名無しさん2009/08/15(土) 17:36:39
>>173
エンコーディングとキャラクタセットを混同している。
01771732009/08/15(土) 20:28:41
>>176
俺は絵文字をキャラクタセットに組み込んで欲しくないから、そうしろと言ってるんだけど。

画像を別に準備(gifでもjpgでも何でもいい)しておいて、表示時に画像を埋め込むようにすれば十分。
0178デフォルトの名無しさん2009/08/15(土) 20:55:50
> 俺は絵文字をキャラクタセットに組み込んで欲しくないから
0179デフォルトの名無しさん2009/08/15(土) 20:58:41
ごめん途中で送信しちゃった

> 俺は絵文字をキャラクタセットに組み込んで欲しくないから
その前提を最初に主張しないと後ろの意見だけ言っても伝わらないって。
0180デフォルトの名無しさん2009/08/17(月) 10:05:42
笑える
http://japan.cnet.com/image/l/story_media/20398174/fig_5-8.jpg
0181デフォルトの名無しさん2009/08/17(月) 10:55:52
アイルランド・ドイツ提案のやつ見てたらアイマスフォントを思い出した
0182デフォルトの名無しさん2009/08/17(月) 11:08:03
>>180
これ直接行けないんだな。
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174-4,00.htm
の図８。
0183デフォルトの名無しさん2009/08/17(月) 11:09:46
え？
直接行けたけどな。専ブラだから？
0184デフォルトの名無しさん2009/08/17(月) 11:10:15
・アニメ風牛の顔
・牛の影絵
が包摂されるわけですね。

僕の書いたべか子ちゃんの顔アイコンも包摂されてしまうとしたら哀しいです
0185デフォルトの名無しさん2009/08/17(月) 22:15:23
クジラの影絵を見てクジラって言い当てられたらすごい
0186デフォルトの名無しさん2009/08/17(月) 23:10:35
動物の顔のマークを動物の全体像で置き換えちゃ
記号の意味が変わるというつっこみを受けて
結局分離することになりました…ってあたりを次にやって連載完結かな。
0187デフォルトの名無しさん2009/08/19(水) 00:31:09
Old Hungarianはpunctuationすら一本化できないのか
本当もめるなあ
0188名無しさん＠そうだ選挙に行こう2009/08/30(日) 04:17:00
WG2 Meeting 55 って東京開催だけど、あれって一般人でも傍聴可？
0189デフォルトの名無しさん2009/09/12(土) 01:45:38
JIPSEとJIPSJの違いを知りたい。
0190デフォルトの名無しさん2009/09/12(土) 02:00:46
NECって昔から糞な会社の代表で、ここのせいで日本のITが立ち遅れたのは間違いない。
JALとともに、さっさとつぶれてほしい筆頭の会社だがね。
0191デフォルトの名無しさん2009/09/12(土) 12:55:17
なんだおめーEかHかFかSの回しもんか
0192デフォルトの名無しさん2009/09/12(土) 15:03:51
NECのお陰で日本のHentai文化が育った。
PC88のおかげで日本は世界一のFM音源大国になった。
PC98のおかげで日本のFDDの出荷率は2倍になった。
0193デフォルトの名無しさん2009/09/12(土) 16:25:10
NECのおかげでJIS78がえんえん生き残った、ぐらいだよなぁ。
このスレの話題的に恨まれることと言えば。
それも、変えたほうが悪い、と言われるような規格だし。

FM音源の普及にはセガのおかげも大きいし、FDDについては単に98が
最大のシェアを持ってたからってだけで、特筆するようなものでもないと思う。
0194デフォルトの名無しさん2009/09/12(土) 16:47:55
いや、PC98のFDDの出荷率2倍は皮肉でしょｗ
当時のPC98はメモリが少なく、HDDも一般的で無かった事から
何をするにも、FDDが2つ搭載されてないと困った。
なので2台搭載されてるのがデフォだったんだよ。


高性能なIBM PCやX68kを見て
「FDD１つしか搭載されてないじゃんｗ」ってPC98ユーザーが馬鹿にするジョークがあった。
これは、2つ搭載しないと性能的に駄目なPCって意味なんだけどね。
0195デフォルトの名無しさん2009/09/12(土) 17:22:10
>194
> 高性能なIBM PCやX68kを見て
ここ笑うところですか？
0196デフォルトの名無しさん2009/09/12(土) 19:13:04
Cドライブから始まるのは正直ダサいｗ
0197デフォルトの名無しさん2009/09/12(土) 19:21:53
仮想FDドライブ懐かしい
0198デフォルトの名無しさん2009/09/12(土) 19:28:10
X68kはＦＤＤ二台あったよ
0199デフォルトの名無しさん2009/09/12(土) 19:29:27
当時の5インチFDの中身が読みたいんだが
USBのFDDとかで5インチって無いのか？
0200デフォルトの名無しさん2009/09/12(土) 19:29:54
日本が海外の進行を食い止めたのは
漢字ROMをはじめとするハードウェアの日本語化の障壁があったからだと思う。
メモリが贅沢に積まれはじめて、ソフトウェアで実現出来るようになっても、
漢字Talkや超漢字みたいに、漢字対応を全面に出したOSが出るくらいだから、
やっぱり海外は日本語のフォント作りに苦心したんだろう。

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

逆に、漢字文化を持ってるからこそ、勝たなければ行けなかった分野で最近負けてるのが気がかり。
検索エンジンなんて、絶対に日本が勝たなければいけなかった分野なのに・・・。
はじめから分かち書きされてる英語圏に、先に様々な問題意識を持たれ、字句解析の技術も先行され・・・
本当に馬鹿な事をしてると思うよ。まぁ、日本は人工知能に偏った思い入れがあるから、いつまでたっても認知科学の分野から頭が離れなかったのも主原因にあると思う。
何十年焼き回し研究をやってるんだと言いたい。
0201デフォルトの名無しさん2009/09/12(土) 20:16:23
研究費で食ってる香具師らにろくなのはおらんよ
理研ですら利権まみれだったからな
0202デフォルトの名無しさん2009/09/13(日) 00:32:27
IBM 5550 には FDD 3台ついてたよ。
0203デフォルトの名無しさん2009/09/13(日) 04:00:16
>>200
「日本語情報処理」を外人が書いちゃうような、そんな後進国だもの＜日本
0204デフォルトの名無しさん2009/09/13(日) 04:45:50
NEC内部コードEとNEC内部コードJとかいう変態のコードとUTFの変換テーブルはどこかにありませんか？
02052042009/09/13(日) 04:50:01
質問が間違えた。
NEC漢字コード体系という変態から逃れたいんですがどうしたら良いでしょうか。
ヘンテコ汎用機で困るんです。
0206デフォルトの名無しさん2009/09/13(日) 05:33:57
     固定機能を排除するにしても、固定機能の代替となるようもう一段ミドルウェアをかまさないとつらいからな
0207デフォルトの名無しさん2009/09/13(日) 08:46:51
>>203
電子情報通信学会編「日本語情報処理」ってのもあるんだけどな。
日本人のやることは、日本人ってバカにするのが好きだからさw
0208デフォルトの名無しさん2009/09/13(日) 11:04:31
>>207
それ内容はどうなの？入手方法は？
0209デフォルトの名無しさん2009/09/13(日) 14:03:49
自然言語処理が日本で人気が出始めたのも、Googleが成功してからだもんな・・・。
NAISTの茶筅やMeCabやNamazuの開発者たちは、とっくにGoogleに持ってかれてるし。
気づくのおせえよ。
0210デフォルトの名無しさん2009/09/13(日) 16:42:16
>>185
一瞬、秋刀魚かとおもたｗ
02112042009/09/15(火) 00:45:06
日本ってコンピュータ言語とか互換性を重視しているわりに、
携帯絵文字コードにみられる非互換で競争してしまう行動はどこからきてるんだろうか。
単に差別化するのが簡単とかそういう理由なんだろうか。
0212デフォルトの名無しさん2009/09/15(火) 08:55:19
ポケベルの頃に絵文字がたくさん使える機種が売れたんです。
ドコモの若手チームの功績とする読み物がウェブにもありますよ。
0213デフォルトの名無しさん2009/09/15(火) 09:28:20
プログラミング言語でも、いざ実装となると規格の踏み外しが多かったりとか、
日本企業製のプロダクトはそういう妙な非互換性をかかえてることが多い。

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

世界的にも、コード共通化について意識したのは早かったのに、企業からの
参加者から縛られたくないだのなんだのの意見が多かった、と、コード会コードの
話にはあるよね。
0214デフォルトの名無しさん2009/09/15(火) 09:51:33
>>211
日本人お得意の、改良をしたがるんだよ。

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

そもそもここがまちがい
0216デフォルトの名無しさん2009/09/15(火) 20:30:45
確かに。どっちかというと自分の理解できないものを無視してあたかもなかったことにすることのほうが
多いような。
0217デフォルトの名無しさん2009/09/16(水) 00:22:54
非互換で囲い込みってアフォだよな。
物理的に良いもので囲い込みとかのほうがよっぽどマシな結果になりそうだが、
それだけ競争が激しいということなんだろうか。
0218デフォルトの名無しさん2009/09/16(水) 01:06:35
DoCoMoとか自民党とかのことを思えば。
0219デフォルトの名無しさん2009/09/16(水) 04:31:09
競争が激しいのは客があほだから
0220デフォルトの名無しさん2009/09/18(金) 04:21:05
非互換に関してひとつには世に出る迄に時間がかかりすぎるから。
そして世に出てしまうとしゃにむにそれにすがってしまうから。

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

で、先に決めて行こうとすると「我れ先に足の引っ張り合い」をするので，うまくいかないと。
0221デフォルトの名無しさん2009/09/18(金) 07:59:27
>>220
> 非互換に関して
< 標準化しないのは

だろ。言いたいのは。
それに先にきちんと標準化しても、非互換の派生は出るぞ。
0222デフォルトの名無しさん2009/09/18(金) 08:09:02
売る側からすれば、ユーザ囲い込み機能を標準化してどうするんだよ・・・って感じだろ。
まあ、日本は欧米と違い、標準化の意識が薄いってのもあるけど。
0223デフォルトの名無しさん2009/09/18(金) 12:41:24
ようするに日本って標準化するという作業工程が下手なんだよな。
競争が激しくて足の引っ張り合いが多いんだろうけど。

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

なし崩し的に物事を進めていく傾向が強いのか、
まぁビジネスだから儲けてナンボではあるんだよね。
0224デフォルトの名無しさん2009/09/18(金) 23:16:20
俗流文化論的に分析してみる。

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

日本では末端の能力が高いから、標準化なしでもなんとか出来てしまう。
また、能力の低いものが束ねる立場に立っても何とかなってしまうことが多い。
0225デフォルトの名無しさん2009/09/20(日) 20:30:16
日本の消費者はメーカー/プロバイダ乗り換えを考えない、自分の選択肢を狭めることに何も躊躇が無い人が多いんだと思うよ。
だから囲い込みが成功しやすいのだと思う。
これは日本のメーカー/プロバイダの品質の高さから来たものだが、消費者が信者化し貶しあう文化が生まれ、標準化の圧力が生まれてないのだと思う。
0226デフォルトの名無しさん2009/09/21(月) 02:34:37
日本人は単一民族だからな
みんなで力を合わせるのが苦手な人種
共通化の欲求よりも
足の引っ張り愛の
我田引水の圧力が勝ってしまう
0227デフォルトの名無しさん2009/09/21(月) 12:06:46
>>171
遅レスだがアイルランド・ドイツ提案に交通標識と地図用記号ってw
>>122とか将棋の全コマとか花札全種とかパソコンで使われる汎用アイコン一式とか企業のロゴとか各名詞や各動詞に対する絵文字とか追加していったらキリが無くね?
0228デフォルトの名無しさん2009/09/21(月) 13:56:41
杭全
0229デフォルトの名無しさん2009/09/21(月) 19:37:40
携帯絵文字は日本文化が色濃く出ててるから、
どの辺まですくい取るかが問題なんだろうけど。

日本の消費者は、あの顔文字じゃぁ気に入らないだろうなｗ
携帯電話は、従来通りキャリアごとに異なる形状でOKなんだろうか。
0230デフォルトの名無しさん2009/09/21(月) 20:02:30
UNICODEをシンプルに全部32bit文字としていれば、
絵文字ぐらい余った空間に簡単に置けれたのに。

一応65万文字分のコードポイントがあまっているとはいえ、
絵文字なんか入れたら足りなくなるかもな。
0231デフォルトの名無しさん2009/09/21(月) 20:38:12
そーいう問題じゃないだろ。
0232デフォルトの名無しさん2009/09/21(月) 23:28:37
世界標準は大事だと思うけど、
実際の形状を該当国・地域に強制するのは本当は良くないことなのではないか。
例えば顔文字で「スマイル」を意味するものがあったとして、
あくまでも受け手の問題なので、該当の国・地域で良い絵柄が選ばれるのが望ま
しいと思う。

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

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

世界標準なったら面白味の欠けるものになりそうなんだよな。
0233デフォルトの名無しさん2009/09/22(火) 23:13:23
今議論している絵文字は、あくまで既存の製品に実装されているものだけだから。
新しい絵文字を作ろうって話じゃないから。
つーか複数言語混在できないようなシステムはダメだろう
0234デフォルトの名無しさん2009/09/23(水) 11:45:36
>>233
アイルランド・ドイツ提案100回読み直せ
0235デフォルトの名無しさん2009/09/23(水) 14:45:26
絵文字といえばPDAM8の投票が終わった頃だな。
さて米・愛蘭独あたりはどんなコメントを寄せたか…
0236デフォルトの名無しさん2009/09/23(水) 18:45:38
文字として認識出るもの以外入れないで欲しいと常々思う。
外字って言うアイデアはシンプルで良かった。
0237デフォルトの名無しさん2009/09/25(金) 00:51:53
ユニコードにも外字エリアあるよね。
昔ほど必要性がなくなったかも
0238デフォルトの名無しさん2009/09/25(金) 10:22:55
いきなりで申し訳ないんだけど、ここの住人ならわかるかな？

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

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

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

これが何なのか、また、どうやったら日本語として読めるのか、知恵を貸してほしいorz
0239デフォルトの名無しさん2009/09/25(金) 11:24:55
JISコード (ISO-2022-JP) のシフトIN/シフトOUT (エスケープシーケンス) が抜けたやつじゃないか
バイナリエディタかなんかで前後にシフトIN/シフトOUTを付加してJISコード対応のエディタかWebブラウザで開いてみ
0240デフォルトの名無しさん2009/09/25(金) 11:33:00
シフトIN、シフトOUTってなんだよ。
このスレの住人らしからぬ...

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

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

その例だと "ＦＲ．６６　ＳＥＣ．" だね。
02412382009/09/25(金) 13:25:50
>>240
例を見てから、自分がわからないと言ってた文字を見てみると
「＃」抜かせば、ある程度わかるじゃん！って事に気づいた。

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

「ド」がつく素人な者で、アドバイスを生かしきれなくて申し訳ないのですが、
どうもありがとうございます！
0242デフォルトの名無しさん2009/09/26(土) 01:22:38
>>241
こんなページを見つけたよ。
http://masaka.dw.land.to/mr/jmr.php

ここで、解読できるみたいだよ。
0243デフォルトの名無しさん2009/09/26(土) 14:58:37
絵文字提案に関係のある国は全部PDAM8に反対ですかそうですか。
N3681は前とどこが変わったのか分からんなあ。Oさんあたりが連載で書いてくれるかな。
0244デフォルトの名無しさん2009/09/29(火) 16:48:55
絵文字に便乗して、各国記号類の追加提案をしまくってるな…
0245デフォルトの名無しさん2009/09/29(火) 17:08:45
もうUNICODEに、国コード＋その国用文字 というコードポイント作れよｗ
何万文字かを国ごとに割り当て、その国で自由に使い方を決める。
0246デフォルトの名無しさん2009/09/29(火) 23:38:23
てらISO 2022w
0247デフォルトの名無しさん2009/09/29(火) 23:51:18
絵文字の話が出ていたと思うけど、これは自然に出た発想だと思うよ
英語圏のサイトにあるチャットには大体絵文字がついてたりするし、日本一国の携帯にクローズアップしてるような印象を与えたのはマスコミに責任があるかなあ
0248デフォルトの名無しさん2009/09/30(水) 00:02:15
だって実際日本一国の携帯に対応するために提案されたんだし。
0249デフォルトの名無しさん2009/09/30(水) 01:02:56
UNICODEって合成文字って概念があるでしょ？
日本語なら、「は」と「゛」で「ば」とか
ウムラウトとかなんとかいうの。

それを拡張して、たとえば、32ドット×32ドットの格子の
升目一個を塗りつぶした形を合成文字にして
合成文字を複数組み合わせて、絵を作るという発想
0250デフォルトの名無しさん2009/09/30(水) 01:15:46
デメリットをよりもメリットがあるのか？それ
0251デフォルトの名無しさん2009/09/30(水) 01:28:53
犬＋首輪＝首輪を付けた犬
こんな合成文字でプレインテキスト書きたいです
0252デフォルトの名無しさん2009/09/30(水) 02:47:06
犬+首輪+横向き+吠える+擬人化 の絵文字ください。
0253デフォルトの名無しさん2009/09/30(水) 09:43:24
 |+-夕胃ノしよ"ぁぃハ合成文字っつーかまmどくせ
0254デフォルトの名無しさん2009/09/30(水) 10:28:24
>>252
人狼ですね、判ります。
0255デフォルトの名無しさん2009/09/30(水) 11:12:14
狼+林檎+横向き+萌える+擬人化 の絵文字ください。
0256デフォルトの名無しさん2009/09/30(水) 20:58:07
ある意味で当事者とも言える、キャリアの人が書いた文書。

世界のケータイ事情「ケータイ絵文字がグローバルに」
http://k-tai.impress.co.jp/docs/column/worldstrend/20090930_318157.html
0257デフォルトの名無しさん2009/09/30(水) 21:05:47
鬼と天狗はさすがに日本も「せめて名前にJapaneseをつけろ」とツッコミ入れてたっけ
0258デフォルトの名無しさん2009/10/01(木) 13:28:28
絵文字より「.日本」をどうにかしろよと思う
レイヤー違う話だけど
0259デフォルトの名無しさん2009/10/01(木) 17:22:35
窓の杜 - 【NEWS】マイクロソフト、Windows 7のMS系フォントをXP互換に戻すパッケージを公開

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

ﾜﾗﾀ
0260デフォルトの名無しさん2009/10/01(木) 19:13:42
>>259
TrueTypeやOpenTypeって字形やglyphを選ぶ機能持ってるのに、これフォントごと入れ替えてるの？
字形選択機能に対応してるアプリはそのままで良いし、そうでない物はフォントレンダラに対して
デフォールトの字形を設定する手段を提供すれば良いと思うんだけど...
0261デフォルトの名無しさん2009/10/01(木) 20:55:28
レンダラで処理されるサイズではなくて内蔵ビットマップを使うサイズのグリフの問題だから、だと思う。

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

こんな話も。
0262デフォルトの名無しさん2009/10/03(土) 00:21:58
WindowsはIVSに対応しないんだろうか…
0263デフォルトの名無しさん2009/10/03(土) 01:03:37
IVSってなんのこと？
0264デフォルトの名無しさん2009/10/03(土) 01:06:22
異字体セレクタ
0265デフォルトの名無しさん2009/10/03(土) 01:09:35
ふーん。初めて聞いた。
0266デフォルトの名無しさん2009/10/03(土) 05:09:39
だっせ
0267デフォルトの名無しさん2009/10/03(土) 05:41:51
おっくれてる～
0268デフォルトの名無しさん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の公開レビューだって最初の締め切り直前に某所でコメントするまで
日本じゃ全くといっていいほど話題になってなかった。
0269デフォルトの名無しさん2009/10/03(土) 19:17:11
Unicode 5.2.0 リリース
http://www.unicode.org/versions/Unicode5.2.0/
今回もちゃんとレビューコメントは反映されてた。
「個別に返事しない」と言っているにもかかわらず返事くれたし
0270デフォルトの名無しさん2009/10/05(月) 23:01:12
age
0271デフォルトの名無しさん2009/10/06(火) 00:11:42
>>269
数年チェックしてなかったけど、Ext.C収録されたのね。ずいぶん数減ったなぁ。
昔は面をまるごと使いかねないくらい大量にあった気がする。
0272デフォルトの名無しさん2009/10/06(火) 08:54:31
>>269
Windows版はどこでダウンロードするの？
0273デフォルトの名無しさん2009/10/06(火) 10:39:11
>>272
0274デフォルトの名無しさん2009/10/06(火) 12:06:30
ステレオタイプというか典型的な質問に、全力でワロタｗ
0275デフォルトの名無しさん2009/10/07(水) 22:49:37
http://mainichi.jp/select/today/news/20091008k0000m030036000c.html
文字コードはどうすんだろう。
0276デフォルトの名無しさん2009/10/07(水) 23:14:53
そりゃ、名前の正式な表記が今やっと分かったって話で、
新しいハングルや漢字が生まれたわけじゃない。既存のでOK。
0277デフォルトの名無しさん2009/10/08(木) 01:27:28
275が言ってるのは、北朝鮮の文字コード規格KPS 9566のことだと思われ。

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

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

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

しかし日本もこの機会に入れたい記号類、何かないのかね。
0281デフォルトの名無しさん2009/10/08(木) 23:00:21
ぜんぜん日本語と関係ないけど、電源スイッチの記号は入らないのかねえ
上が切れた○に棒が刺さってるようなやつ
0282デフォルトの名無しさん2009/10/09(金) 09:55:21
こんな顔だったかい?
□□□■□□□
□■□■□■□
■□□■□□■
■□□□□□■
■□□□□□■
■□□□□□■
■□□□□□■
□■■■■■□
0283デフォルトの名無しさん2009/10/09(金) 11:24:17
メニューキーもきぼん
■■■■■■■■□□□□
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□
■■□□□□■■■■□□
■■■■■■■■■□□□
■□□□□□□■□□■□
■□■■■■□■□□□■
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□
0284デフォルトの名無しさん2009/10/10(土) 00:31:01
文字コードのことわかってないおとこ大杉。。。
0285デフォルトの名無しさん2009/10/10(土) 01:12:17
良くわからないけど、結局、全世界の文字を集めたら32ビットでたりそうなの？
0286デフォルトの名無しさん2009/10/10(土) 01:49:15
最近絵文字が流行り出したから32bit空間は枯渇したらしい
0287デフォルトの名無しさん2009/10/10(土) 09:03:20
ここいらで絵文字が絵なのか文字なのかはっきりさせとくべき
ちなみに俺は絵文字は絵であって文字コードに入れるのはナンセンスだと思ってる
0288デフォルトの名無しさん2009/10/10(土) 09:23:01
Unicodeの空間は21bitsですよ
0289デフォルトの名無しさん2009/10/10(土) 14:17:07
21bitあれば210万近く文字使えるんだから
10万文字ぐらい絵文字にくれてやっても良いじゃないか？
0290デフォルトの名無しさん2009/10/10(土) 14:26:45
だがことわる
0291デフォルトの名無しさん2009/10/10(土) 15:30:06
21bit全部に文字が割り当てられるわけじゃなくて、実際に定義or予約されているのは110万程度。
10万は面をまたぐことになるのでアレだけど、1面丸ごとpictgramsに割り当てるのはアリかもね。
0292デフォルトの名無しさん2009/10/10(土) 16:33:19
何か基準がないとなしくずしに絵文字！絵文字！絵文字！
0293デフォルトの名無しさん2009/10/10(土) 23:11:38
今回限りにしてくれるんなら多少こういう妙なものが入ってるのも
おもしろいかなあと思うけど、
このまま今後ずるずるとこういうものが入り始めるのは御免こうむりたい
0294デフォルトの名無しさん2009/10/11(日) 03:41:07
絵文字を入れるのは変体仮名と平仮名・片仮名の合字すべてを入れてからにしてくれよ。
そっちの方が先だろうが。
0295デフォルトの名無しさん2009/10/11(日) 03:51:39
n3695渋いねえ。簡体字って歴史浅いくせにもう廃止された字があるのか。
しかしよくこんなの見つけてくるわホント。
0296デフォルトの名無しさん2009/10/11(日) 07:21:17
ユニコードの体系変わったら
OS側も合わせなきゃ意味ないよね？
フォントとかも
0297デフォルトの名無しさん2009/10/11(日) 07:41:08
>>295
1935年の第一批簡体字、シンガポールで使われていた簡体字、それと二簡字か。
二簡字はわりと有名だけど、1935年の第一批簡体字の方は見たことなかった。
ソースのスキャンが欲しいな。
02982972009/10/11(日) 08:05:33
ってPDFの後ろに画像ついてたわ。俺あほす
0299デフォルトの名無しさん2009/10/11(日) 13:37:45
将来、漢字みたいに使う絵文字だけの言語もできるかもしれんしな。ないけど
0300デフォルトの名無しさん2009/10/11(日) 13:48:04
象形文字とか、古代の文字はそんな感じじゃね？
0301デフォルトの名無しさん2009/10/11(日) 13:50:18
文字の退化。
0302デフォルトの名無しさん2009/10/11(日) 14:14:41
脳の退化
0303デフォルトの名無しさん2009/10/11(日) 22:29:43
中国のナシ族のトンパ（巫師）が使う文字は、
一応現役の象形文字だろうね
0304デフォルトの名無しさん2009/10/11(日) 23:02:28
よし、ここで俺が、
数式文字と音符をUnicodeに含めることを提案する！
0305デフォルトの名無しさん2009/10/11(日) 23:08:08
♪
0306デフォルトの名無しさん2009/10/11(日) 23:13:15
>>305
ちげーよ。

音階ごとだよ。
0307デフォルトの名無しさん2009/10/11(日) 23:23:04
じゃあ聞くが、音階ごとだと何個必要なんだ？
0308デフォルトの名無しさん2009/10/12(月) 00:11:51
たしか全角で911とかをwindingsで表示すると
0309デフォルトの名無しさん2009/10/12(月) 00:38:20
911って緊急通報用電話番号か？
0310デフォルトの名無しさん2009/10/12(月) 00:40:35
>>307
しらね。

楽譜で表せる程度なんだから
たいした数じゃないだろ？
0311デフォルトの名無しさん2009/10/12(月) 00:45:10
>>310
数えてみろよ
たいした数じゃないんだろ？
0312デフォルトの名無しさん2009/10/12(月) 01:16:48
まあまあ、楽譜って世界共通だという印象だけど、
それが入っていないってのはなんか不思議な感じがする。
アナログ的なものだからあんまりコンピュータと同時に利用する場面がないのかしら。
0313デフォルトの名無しさん2009/10/12(月) 01:21:34
音符はもうあったはず
0314デフォルトの名無しさん2009/10/12(月) 01:22:55
だから具体的に音階ごとだと何種類入れればいいと思ってんだ？
それに、例えば32ｘ32程度のドットで表現できる？64でもいいよ？
ていうか、楽譜みたことあんの？
03153122009/10/12(月) 01:32:21
音階について詳しく知らないのだが、
もしかして低音と高音ともに限界のない表現方法だったりするの？

まぁ普段の生活で必要な程度の記号の範囲で良いとおもうけどね。
0316デフォルトの名無しさん2009/10/12(月) 01:37:02
人間の可聴範囲でも20,000Hzなんだから
1Hzに1文字割り当てたとしても、
2万個もいかんだろ？たったこんだけ。
0317デフォルトの名無しさん2009/10/12(月) 01:41:07
文字コードはあくまで文字コードであって
グリフは規定されて無いから、32×32ドットといわれても意味が無い。
0318デフォルトの名無しさん2009/10/12(月) 01:41:29
使わない文字に２万も浪費するって時点でフォント屋がキレそうだが
楽譜でふつうに使われる和音と長さ、連符休符など組み合わせるとウンザリするな
0319デフォルトの名無しさん2009/10/12(月) 01:43:47
>>317
素直に負けをみとめろよｗ
0320デフォルトの名無しさん2009/10/12(月) 02:07:29
楽譜ってそんなに体系化されてないだろ
人によっても色々書き方違うし
だからってITの分野とちがって標準化すればいいってもんでもないしな
普通に記号だけでいいと思うよ
0321デフォルトの名無しさん2009/10/12(月) 02:16:16
音階が欲しいって言ってんじゃん。
03223122009/10/12(月) 02:20:51
まぁ、あれだ。
単一の記号で表現できるものと、できないものがあるから、
文字コードとして適正のあるものと無いものがあるというところかな。
0323デフォルトの名無しさん2009/10/12(月) 02:24:31
なんだこいつ
0324デフォルトの名無しさん2009/10/12(月) 03:25:47
>>323
ふぁびょるなよw
もうちっと楽しませろクズw
0325デフォルトの名無しさん2009/10/12(月) 06:54:49
「五線譜とその第一線上の四分音符」なんてのは
音楽系の平文に埋め込まれた利用例あるだろな。
0326デフォルトの名無しさん2009/10/12(月) 07:26:45
そういうのはXMLの仕事だったはずでしょ。
0327デフォルトの名無しさん2009/10/12(月) 08:25:12
携帯絵文字が入って、化学記号や数式記号が入らない理由が見つからない。
0328デフォルトの名無しさん2009/10/12(月) 09:01:59
♪ とか♪とか欲しい
￣　　　・
0329デフォルトの名無しさん2009/10/12(月) 10:37:12
>>328
文字化けしたらスマン
𝅘𝅥𝅮𝅽 U+1D160 + U+1D17D
𝅘𝅥𝅮𝅭 U+1D160 + U+1D16D
0330デフォルトの名無しさん2009/10/12(月) 12:41:29
一度でもまともに楽譜を見たことがあるなら、音階ごとに四分音符を並べるだけのものなんて無意味に近いと判りそうなもんだが。
MusixTexのマニュアルとか読んでみろよ。
0331デフォルトの名無しさん2009/10/12(月) 18:45:48
コルトレーンとかもうね...
http://www.youtube.com/watch?v=2kotK9FNEYU
0332デフォルトの名無しさん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");
のように変換を行ったのですが、うまく変換されてないのか成功しません。

変換ができてないのか、それとも文字コードの指定事態が間違ってるかすらも検討がつかなくて
どーすればいいかわからない状況です。
0333デフォルトの名無しさん2009/10/13(火) 01:02:39
>>321
音階にも種類があるでよ？
0334デフォルトの名無しさん2009/10/13(火) 01:16:44
12平均律だけならいいけど、31とか53平均律なんてものも世界には存在してだな
0335デフォルトの名無しさん2009/10/13(火) 01:20:14
まだやんの？その話
0336デフォルトの名無しさん2009/10/13(火) 01:25:04
>>332
webprog板だかで聞くべし
0337デフォルトの名無しさん2009/10/13(火) 11:21:41
絵文字は文字で（絵じゃない）、音符は絵の一種に見える（文字でも記号でもない）俺は異端かなぁ……
0338デフォルトの名無しさん2009/10/13(火) 11:31:07
敢えて言おう。音符を入れるくらいなら気象記号を入れてみろ。
どちらも手書きであるが故の美しさがあると言う点で、絵のようなものだ。
0339デフォルトの名無しさん2009/10/13(火) 14:46:20
地図記号が絵文字関連で幾つか入るようだから、天気図記号が入っても悪くはないはず。

ただ、こういうのってXMLとかでの実用が前提じゃなかったっけ？知らんけど。
0340デフォルトの名無しさん2009/10/13(火) 15:01:12
国ごとに微妙に違うからなあ
0341デフォルトの名無しさん2009/10/13(火) 20:26:24
>>338
手書き故の美しさを言い出したら、
文字全部そうじゃね？
0342デフォルトの名無しさん2009/10/13(火) 20:28:43
地図記号って、おまんじゅう工場も入るのか？
0343デフォルトの名無しさん2009/10/13(火) 20:47:41
おまん工場
0344デフォルトの名無しさん2009/10/16(金) 00:37:32
シフトJISの外字領域とMS932の外字領域のコード範囲は同じなのでしょうか？
0345デフォルトの名無しさん2009/10/16(金) 11:47:37
JISのシフトJISに外字領域は無い。
0346デフォルトの名無しさん2009/10/21(水) 09:33:11
>>47
CJKV Information Processing の２版がgoogleブックに登場してた。
Ebook Release: June 2009
この時期に登場したのか？

ttp://books.google.co.jp/books?id=SA92uQqTB-AC
ttp://oreilly.com/catalog/9780596514471/preview
0347デフォルトの名無しさん2009/10/22(木) 18:17:37
最近更新がないと思ったら、小形さんこんなの準備してたんだ。
とうとう単なる傍観者じゃいられなくなりましたか。
しかし来週はこりゃ絵文字の議論だけで終わりそうな勢いだ。
0348デフォルトの名無しさん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です．
0349デフォルトの名無しさん2009/10/22(木) 21:23:02
どこに貼り付けたんだ？
貼り付けた先のアプリケーションがUnicodeに対応していないのでは？
0350デフォルトの名無しさん2009/10/22(木) 21:29:49
テキスト文書utf8_1.txtというファイルを作って貼り付けたんですけど
クリップボード他入出力がダメなんでしょうか
03513482009/10/22(木) 21:39:53
すいません、
ブラウザからそのファイルへのリンクを右クリックしてとりあえず
情報が失われないように保存は出来たんで、また自分で
色々やってみますお騒がせしました
0352デフォルトの名無しさん2009/10/26(月) 06:17:08
あれで参加者の反発を買わないよう配慮したつもりなのか…
0353デフォルトの名無しさん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
0354デフォルトの名無しさん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
0355デフォルトの名無しさん2009/10/26(月) 06:55:44
顔だけじゃなくて胴体も入れようぜ→それなんてサウスパークジェネレーター?
0356デフォルトの名無しさん2009/10/27(火) 13:19:23
PSOのシンボルチャットを連想したのは私だけではないはずだ。
0357デフォルトの名無しさん2009/10/28(水) 01:00:41
グリフ変更というeditorialな部分は通ったけど
その他のtechnicalな部分は全部預かられてしまったと

んーどうだろ、一応顔は立ててもらえたようだけど
0358デフォルトの名無しさん2009/10/29(木) 00:05:59
>>356
確かにPSOのシンボルチャットっぽいｗ
0359デフォルトの名無しさん2009/11/01(日) 18:37:16
EUCもSJISもJISも面倒見てくれるktermが、UTF-8以外は排除するxtermに駆逐されたのは納得いかない
0360デフォルトの名無しさん2009/11/03(火) 07:24:03
javaでWindows31-J⇔Unicodeの変換で、外字領域を含めて変換できない文字はあるのでしょうか？
0361デフォルトの名無しさん2009/11/03(火) 12:17:25
バージョンによっても違うからここ読め
http://www.ingrid.org/java/i18n/encoding/
0362デフォルトの名無しさん2009/11/03(火) 17:00:14
>>361
お答えありがとうございます。
Java5なのですが、のっていなかったです。
Shift-JISでいうところの外字領域は対応しているのは実際に確認しました。
変換に失敗するとまずいので、保障が欲しいのです。
また、変換できない文字があれば事前にチェックをしたいので、変換できない文字を知りたいのです。
0363デフォルトの名無しさん2009/11/03(火) 17:07:45
全部変換してみりゃいいだろう
0364デフォルトの名無しさん2009/11/03(火) 18:22:33
>>362
想定する文字セットが提示されていれば、
その中で変換できない文字を調べられるけど
漠然と変換できない文字って言われてもな……
0365デフォルトの名無しさん2009/11/03(火) 18:27:53
Windows 31Jってデーヴァナーガリー文字とかも含んでるの?
0366デフォルトの名無しさん2009/11/03(火) 18:32:31
Windows31JからUnicodeに行って戻ってこれれば十分なのか
⇔記号の見た目通り相互変換を意味しているのか
0367デフォルトの名無しさん2009/11/03(火) 23:50:44
Windows3.1Jってまた懐かしいなｗ
0368デフォルトの名無しさん2009/11/04(水) 01:11:03
>>365
ないよ。要はシフトJISだし。
0369デフォルトの名無しさん2009/11/04(水) 01:33:56
外字ありだぜ？
0370デフォルトの名無しさん2009/11/04(水) 04:24:15
>>367
3.1・・・ってまさか・・・


勘違いしてる気がするｗ
0371デフォルトの名無しさん2009/11/04(水) 18:25:03
OS（XP）の外字エディターで、U+21336の文字（土並）を参照表示させる事は可能？
0372デフォルトの名無しさん2009/11/08(日) 21:23:05
外字エディタってそういう風に使うものなの？
0373デフォルトの名無しさん2009/11/09(月) 10:59:59
単？
0374デフォルトの名無しさん2009/11/09(月) 20:02:26
>>372
Windowsの外字エディタは字形の原形として既存のフォントからグリフを読み込んで
そのビットマップをちょこちょこいじって外字を作ることができるんですよ。読み込み
インタフェースがBMPの符号位置しか選択できないように見えるので、何かSIPの
文字を読む方法ない?っていう相談なんじゃないかな。

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

この漢字はHKSCSにも入っているようなので、HKSCS対応のフォントだと
強引にBMPのどっかの符号位置にマップしてたりしませんかねえ。。。
0375デフォルトの名無しさん2009/11/09(月) 22:38:02
>>374
＞既存のフォントからグリフを読み込んで
なるほど、知らなかった。ありがとう。

>>371
374の言う通り、HKSCS対応のフォントでU+EB00に[土並]があった。
フォント名で言えばMingLiU_HKSCSとかDfSongStdとかMing(ISO 10646)とか。
0376デフォルトの名無しさん2009/11/10(火) 21:25:30
Oさん意気揚々ですな
03773712009/11/17(火) 00:59:07
>>374>>375
thx
試してみます
0378デフォルトの名無しさん2009/11/18(水) 18:21:34
UTF-8をSHIFT-JISに変換するコードどこかないでしょうか？
iconv UNIX,LINUX系統以外


C/C++
Windows VC++ 環境で
0379デフォルトの名無しさん2009/11/18(水) 20:24:41
MultiByteToWideChar()
WideCharToMultiByte()
0380デフォルトの名無しさん2009/11/19(木) 00:30:54
自分で書けばええやん
0381デフォルトの名無しさん2009/11/19(木) 00:57:52
>>378
http://pc12.2ch.net/test/read.cgi/tech/1214657360/715
メモリ解放は自分でやれ
0382デフォルトの名無しさん2009/11/29(日) 15:50:10
Win7では異体字セレクタ対応してた。
対応フォントは付いてないけどY.Ozフォント入れてメモ帳とOpenOfficeで出来た。
モンゴル文字や数学記号のBMPの異体字セレクタを使ったものは使えるかどうか知らんが、とりあえずU+E0100～の漢字用異体字セレクタは使えるみたい。
0383デフォルトの名無しさん2009/11/29(日) 19:44:29
fdam8の1F61Dはこういうデザインなのかはたまたゴミが混じっているのか…
0384デフォルトの名無しさん2009/11/29(日) 19:46:03
fdam8じゃないやfpdam8だった
0385デフォルトの名無しさん2009/11/30(月) 01:52:14
>>383
見てみた。ﾜﾗﾀ
0386デフォルトの名無しさん2009/11/30(月) 11:26:47
毛が抜けてｼｮﾎﾞｰﾝな波平
0387デフォルトの名無しさん2009/12/04(金) 08:10:10
unicode対応でWindowsプログラムを作成しているのですが、
英語以外、日本語やアラビア語などすべての文字が使える
フォントを教えてください。
0388デフォルトの名無しさん2009/12/04(金) 22:54:15
ない。
0389デフォルトの名無しさん2009/12/04(金) 23:02:43
フォント作成の会社に問い合わせればいいんじゃない？
0390デフォルトの名無しさん2009/12/05(土) 00:24:02
ttf/otfの仕様上、全部込みのフォントを作ること自体無理。
ただ漢字以外全部なら作れるかもしれない。
0391デフォルトの名無しさん2009/12/05(土) 00:57:16
まずはArial Unicode MSから。
0392デフォルトの名無しさん2009/12/05(土) 06:10:41
code2000でも使っておけ
0393デフォルトの名無しさん2009/12/07(月) 20:30:47
失礼致します。

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

未収録の具体的な文字とそのGB18030の文字コードを1文字でもいいので知りたいのです。
ご存知の方がおりましたらどうかご教授して頂けないでしょうか。
0394デフォルトの名無しさん2009/12/07(月) 21:58:06
中国人にでも聞けば？
0395デフォルトの名無しさん2009/12/08(火) 07:29:21
Adobeの中の人あたりとかが知ってそうだな。
小形さんあたりに知ってそうな人紹介してください、って頼めば、教えてもらえるんじゃないか？
0396デフォルトの名無しさん2009/12/08(火) 08:04:35
なーんか、ろくすっぽ英語も中国語も読まない上に、
ネットで漁ることだけを「調べる」と言い切ってる某ブログの人みたいだな。。。。

OPACで関連文献がありそうな図書館に足を運んだり、または
赤坂の日本規格協会の海外規格ライブラリとかはちゃんと調べたの？
0397デフォルトの名無しさん2009/12/08(火) 20:00:54
>>393
全部入ってるだろ。
0398デフォルトの名無しさん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番目のフォント調べればあるんじゃないの？
0399デフォルトの名無しさん2009/12/09(水) 11:41:44
それはテーブルもフォントも2000年版ベースだな。
いずれにせよ全部Unicodeに入ってるだろ。
0400デフォルトの名無しさん2009/12/09(水) 17:45:53
>>393
もしかしてGBKの
A98A→到底漢字には見えない点々の集まり
FE5D→常の冠の部分チョンチョンチョンみっつ
とかの文字の事じゃない？
GBKでは未定義だけどGB18030では全ての文字がUnicodeで定義されているよ(A98A→U2FF0のように)
0401デフォルトの名無しさん2009/12/09(水) 18:09:01
393です。

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

長々と失礼しました。改めまして、皆様方有難うございました。
0402デフォルトの名無しさん2009/12/16(水) 15:24:16
シフトJISのGB2312版（シフトGB？）みたいなコードセットってあるの？
0403デフォルトの名無しさん2009/12/16(水) 18:41:44
安岡センセのあれはつまりGoogle以外はBMPしか通らないってことなのかな。
0404デフォルトの名無しさん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
だと。
0405デフォルトの名無しさん2009/12/17(木) 00:22:32
>>402
高電社の日中翻訳ソフトとかは、Windows 98時代までは
GB 2312 をShift_JIS流にして日本語Windowsで無理やり中国語を使ってたね。
0406デフォルトの名無しさん2009/12/17(木) 09:25:58
>>405
てことは、中国語版MS-DOSやWindowsでは、GB18030以前ないしUnicode以前は
ふつうはEUC-CN使ってたの？
0407デフォルトの名無しさん2009/12/17(木) 10:32:56
なぜ「てことは」になるのかわからん。
Shift_JIS流だとあるのに、なぜEUC-CN?
0408デフォルトの名無しさん2009/12/17(木) 22:41:58
>>406
こんな低レベルな質問をする人が402だったなんてショックです。
てかコードページも知らないで>>402の質問をする本意はなんなんだ？
0409デフォルトの名無しさん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
0410デフォルトの名無しさん2009/12/17(木) 22:59:59
>>405
Shift_JIS流って、
Shift_JISのJIS X 0201 kanaに相当する部分は何が入っていたの?
0411デフォルトの名無しさん2009/12/17(木) 23:01:11
うるさいな
04123122009/12/17(木) 23:07:42
そういえば、常用漢字表が2010年に改訂するって小耳に挟んだんですが、
具体的に困ることってあるんですか？
0413デフォルトの名無しさん2009/12/17(木) 23:11:55
つ http://itpro.nikkeibp.co.jp/article/COLUMN/20091209/341831/
0414デフォルトの名無しさん2009/12/17(木) 23:20:00
この記事わかりずらいですね。だれか簡単に翻訳してｗ
0415デフォルトの名無しさん2009/12/17(木) 23:22:37
ならば、君には関係の無い話なんだよ
0416デフォルトの名無しさん2009/12/17(木) 23:28:52
要約:「常用漢字にシフトJIS範囲外の文字が入る。困った」

そんな文字使わなきゃいいんだけど、常用漢字に入ると名前に使えるよ
うになるので人名を扱うシステムでは将来困るね。
0417デフォルトの名無しさん2009/12/17(木) 23:34:56
無知で申し訳ないけど、
常用漢字という定義は、公共なシステムで例えば住民基本台帳とかそういうので
サポートされるという意味になるの？
0418デフォルトの名無しさん2009/12/17(木) 23:36:46
違う
プログラム的にはまったく関係が無い
0419デフォルトの名無しさん2009/12/18(金) 04:15:01
>どうしても「??」がサポートできそうにないなら、その旨を文化審議会国語分科会に陳情する、という手も残されている。

何で一OSメーカーの怠慢を文化審議会が肩代わりしないといけないんだよ。
0420文字化けしちゃったよ2009/12/18(金) 04:22:04
上の引用文中にある
??　は　��
0421デフォルトの名無しさん2009/12/18(金) 05:00:47
「XPのメモ帳はサロゲートペアを2つの文字として扱ってしまう」というのが
何のことかよく分からん。
今XP sp3のメモ帳で試してみたけど、ちゃんと1文字扱いされてる。
0422デフォルトの名無しさん2009/12/18(金) 08:04:33
>>419
常用漢字表の標準字体に、
使われてないタイプを採用する文化審議会がおかしい。
0423デフォルトの名無しさん2009/12/18(金) 08:51:01
>>421 確かにXPはサロゲートペアにはだいぶ前から対応してた気がするな。
0424デフォルトの名無しさん2009/12/18(金) 10:45:17
>>423
確かに気がしますね。
0425デフォルトの名無しさん2009/12/18(金) 13:03:30
MSはサロゲート対応早かったよ
XP+Word 2000という組み合わせでもサロゲートペアの文字が使えてた
0426デフォルトの名無しさん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

関係ないけど、改定常用漢字表の記事その２
ttp://internet.watch.impress.co.jp/docs/column/jouyou/20091217_336436.html
0427デフォルトの名無しさん2009/12/19(土) 02:02:32
文章を書く時に、常用漢字表という枠組みを意識している人って
どれぐらいいるんだろうね。
0428デフォルトの名無しさん2009/12/19(土) 02:11:21
役人、新聞編集、教科書ライター、学校職員
0429デフォルトの名無しさん2009/12/19(土) 04:14:01
Unicodeのメジャーバージョンアップに、10646の改訂に、
Shift_JISでは扱えない字を含む常用漢字表。

来年は色んな点において節目の年になりそうだ。
0430デフォルトの名無しさん2009/12/19(土) 04:25:20
大抵のかな漢字変換ソフトには常用漢字や学年別学習漢字での制限があるしな。
0431デフォルトの名無しさん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に申請したんだっけ？
0432デフォルトの名無しさん2009/12/19(土) 13:41:42
JIS X 0213:2004 のほうが後なの？
0433デフォルトの名無しさん2009/12/21(月) 13:15:07
Extension B（Unicode 3.1）は2001年。
20B9Fは康煕字典ソースで53F1とはnon-cognate。
0434デフォルトの名無しさん2009/12/21(月) 14:44:53
他人の空似なのか。やっぱり無理筋だ。
0435デフォルトの名無しさん2009/12/22(火) 15:58:13
>>426
この記事、パソコンから携帯へはどういう設定で送ったんだろ。
utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
JIS X 0208の範囲に押し込む手もあると思うけど。
0436デフォルトの名無しさん2009/12/22(火) 17:59:57
絵文字の場合は送信側のサーバで一括変換してるけど、
Unicode対応は機種によって違うから、サーバで変換しちゃまずいだろ。
0437デフォルトの名無しさん2009/12/23(水) 03:03:35
>>435
> utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
> JIS X 0208の範囲に押し込む手もあると思うけど。

似た字に変換しちゃえって事?
0438デフォルトの名無しさん2009/12/23(水) 11:06:56
携帯に限って言えば、キャリア側で勝手に包摂しちゃえばいいんじゃないの
わざわざ常用漢字表の側で配慮すべきだとは思わない
0439デフォルトの名無しさん2009/12/23(水) 22:06:14
>>438
包摂で済むなら苦労しないし、できるんだったら第2水準を作る時点で新字旧字にそれぞれ別コードを与えない。

「常用漢字表と字体が違うYO!」　と言ってくる人が必ず出てくる。
今後>>438が「常用漢字お客様相談センター」の窓口を一手に引き受けてくれるのであれば別だが。
0440デフォルトの名無しさん2009/12/24(木) 20:39:55
「口匕」と「口七」は元来別字だったからややこしい。現代文では両方とも「シカる」の意味で使う。
本当に字形の差の問題だけだったら、Unicodeでは中国の字体と統合されている「将」や「直」の方が問題だろう。
0441デフォルトの名無しさん2009/12/25(金) 08:32:30
CJK統合の問題は言っても始まらない、というか終わっちゃう、というかw
0442デフォルトの名無しさん2009/12/25(金) 18:00:26
俺は生粋の日本人だけど、日本と朝鮮と越南が中国領になれば解決するアルよ。
0443デフォルトの名無しさん2009/12/25(金) 20:21:12
visciiを巻き込まないで
0444デフォルトの名無しさん2009/12/26(土) 11:49:18
今回のパブコメは募集要領でわざわざ
>今回は，「「新常用漢字表（仮称）」に関する試案」からの変更点に関連する御意見を中心に
と断っているから、out of scopeではねられるものが大量に出る予感。
0445デフォルトの名無しさん2009/12/29(火) 23:49:54
cnetの絵文字の話は越年か…
0446デフォルトの名無しさん2010/01/09(土) 23:50:29
文字コードじゃなくてフォントの話なんだけど、
「礫」をMS明朝の16ポイントで表示させると旁の「白」が「自」になるのに気づいた。

これって有名？
0447デフォルトの名無しさん2010/01/10(日) 02:17:32
そのくらいの省略(ヒンティングでかもしれんが)はいくらでもあるんじゃないか?
0448デフォルトの名無しさん2010/01/10(日) 08:06:54
いや、画数が足りないならともかく、多いんだからバグだろ。
0449デフォルトの名無しさん2010/01/10(日) 13:10:55
まったく、フォント作成までもが中国に丸投げかよ
0450デフォルトの名無しさん2010/01/10(日) 13:52:36
16以外は大きくても小さくても白だなｗ
0451デフォルトの名無しさん2010/01/10(日) 14:35:57
16ポイント埋め込みビットマップのみの問題か。
こんな名前にもポスターにも使わそうにない漢字良く気づいたな。
0452デフォルトの名無しさん2010/01/10(日) 15:56:11
礫は砂礫・礫岩の礫か。
あとは、東京都文京区小石川は礫川とも書く。

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

8ポイントの「預」が「矛頁」になるのは比較的有名だと思うんだけど、
これは最初の発見者になれたかなｗ
0454デフォルトの名無しさん2010/01/14(木) 17:02:05
文字コード界隈もついったーばやりだなぁ。
0455デフォルトの名無しさん2010/01/17(日) 01:05:32
Twitterといえば、Webインターフェイスからつぶやくと、
サロゲートペアはキッチリ2文字としてカウントしてくれるせいで140字打てない
Twitpicってutf-8を文字境界ではないところで切っているせいで
よく文字化けをおこしている
まあたとえサロゲートペアを1文字としてカウントしたり、utf-8を文字境界で切ったとしても
結合文字の問題もあるんだけどね。
0456デフォルトの名無しさん2010/01/17(日) 03:37:14
結合文字はちゃんとやろうとするとテーブルが要るから
処理を端折りたくなる気持ちは分かるけど、サロゲートはちゃんとやってほしいな。
0457デフォルトの名無しさん2010/01/17(日) 12:48:25
16進数で3xが0-9まで数xになる文字コードってなに？
0458デフォルトの名無しさん2010/01/17(日) 13:13:41
ASCII
0459デフォルトの名無しさん2010/01/17(日) 13:51:05
＾＾ｂ
0460デフォルトの名無しさん2010/01/26(火) 17:07:08
当方はXP SP3でMSのJIS2004フォントを適用した環境です。

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

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

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

この現象を解決する方法、何方かご存じでしょうか？
0461デフォルトの名無しさん2010/01/26(火) 19:44:57
エディタやブラウザでMS 明朝の該当グリフが表示されるかどうかを試してみて、
ATOKの問題かOSのフォント認識の問題か切り分ける。
04624602010/01/27(水) 09:33:29
>461
エディタやブラウザでも「・」や「・・」で表示されるのでOSのフォント認識の問題と思われます。
念の為、IME2002に切り替えて確認しましたが同じでした。
0463デフォルトの名無しさん2010/01/27(水) 15:17:31
文字コードについて誤った情報が掲載されているPDFを探しています。
なかなか見つけられないので協力してください。
0464デフォルトの名無しさん2010/01/27(水) 15:25:21
なぜPDF？
0465デフォルトの名無しさん2010/01/27(水) 15:35:05
PDFと指定されたからです。
何が誤っているかも分らない分野で、明日までに提出と言われたので困り果てていました。
ここの方なら分るかと思い質問しました。
0466デフォルトの名無しさん2010/01/27(水) 15:51:01
>文字コードについて誤った情報が掲載されているPDF

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

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

で簡単に作れるべ
0467デフォルトの名無しさん2010/01/27(水) 15:52:56
http://www.google.co.jp/search?q=文字コード+filetype%3Apdf
こんなかから、うそっぽいのをさがせ。
0468デフォルトの名無しさん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 -
0469デフォルトの名無しさん2010/01/27(水) 15:56:13
>466
自分で作るのも考えたんですが、
それらしいものを作る自信がなくて諦めていました。

>467
ちょっと見てきますありがとう。
0470デフォルトの名無しさん2010/01/27(水) 15:57:44
>468
これも見てみます。ありがとう。
0471デフォルトの名無しさん2010/01/27(水) 16:09:04
「漢字は2バイト」とあり、それがUnicodeの文脈で、
にもかかわらずエンコーディング方法に言及してないとかなー。

半角カナは1バイト、とかも似たような(EUC-JPだと…)
0472デフォルトの名無しさん2010/01/27(水) 17:17:46
そりゃnikkeibpだもん
仕方ないよ
0473デフォルトの名無しさん2010/01/27(水) 22:55:34
>>470
あんた赤点決定ね。
0474デフォルトの名無しさん2010/01/28(木) 01:59:24
>471がよくわかりません。
詳しく教えてください。
0475デフォルトの名無しさん2010/01/28(木) 02:10:33
ちょっとは自分で調べましたみたいな姿勢を見せないでただ質問するだけって嫌われるよ。
0476デフォルトの名無しさん2010/01/28(木) 03:47:31
数年後日本の開発者は文字コードの乱立を知らない世代ばかりになって
ますますソフト業界は世界から立ち遅れると思われ
0477デフォルトの名無しさん2010/01/28(木) 08:37:02
欧米か！
0478デフォルトの名無しさん2010/01/28(木) 09:44:48
>>476
オライリーのCJK本の事を思い出してしまった
0479デフォルトの名無しさん2010/01/28(木) 10:34:41
>>476
IMEの開発を朝鮮に丸投げしてるからなぁ
0480デフォルトの名無しさん2010/01/28(木) 10:40:09
ttp://www.amazon.co.jp/dp/4873111080
0481デフォルトの名無しさん2010/01/28(木) 11:07:29
むしろShift_JIS的発想から抜け出せないことの方が、立ち後れの原因になりかねない。
一行あたりの文字数をバイト数から算出しようとするような。

某有名国産テキストエディタが、合成文字をちゃんと表示できるようになるのはいつの事だか…
0482デフォルトの名無しさん2010/01/28(木) 18:19:21
固定ピッチフォントでは全角は2倍の幅という慣習も、今後どうなるんだろう？
0483デフォルトの名無しさん2010/01/28(木) 19:02:25
そら、「全角」は「半角」の倍の幅に決まってますがな。
0484デフォルトの名無しさん2010/01/31(日) 12:09:58
画面上では2倍だが、ドットプリンタの世界では全角は半角の1.5倍だったけどな
0485デフォルトの名無しさん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面の私用面を使ってるのもあった。
これらが普及する前に早く修正パッチ出てほしいもんだ。
0486デフォルトの名無しさん2010/02/05(金) 01:01:27
>>462
コントロールパネル-地域と言語のオプション-[言語]タブで
「複合文字や右から左方向に書く言語 (タイ語を含む) のファイルをインストールする」
にチェック。
レジストリを直接いじる方法もあるようだけどたぶんこれが一番簡単
0487デフォルトの名無しさん2010/02/06(土) 00:48:23
いずれ絵文字もAdobeJapanに収録されるのかな。
AJの採集基準ってどうなってんだろ。
0488デフォルトの名無しさん2010/02/06(土) 15:38:32
基本的には国家規格の文字を収録してるだけだよ
ただ日本に限ってはそれだけでは使いものにならないというだけ
0489デフォルトの名無しさん2010/02/09(火) 23:19:10
結局、絵文字にまつわるUnicode改訂ってどうなったん？
0490デフォルトの名無しさん2010/02/09(火) 23:23:05
すぐに巷に流れたらメシの種がなくなるじゃねえか
0491デフォルトの名無しさん2010/02/09(火) 23:30:15
そか、じゃあもうちょっと待ってみる
0492デフォルトの名無しさん2010/02/10(水) 00:40:51
絵文字を含むAMD8は3回中2回目の投票中。後はこれに各国が意見を言って、
4月の会議で摺り合わせして終わり。
絵文字にかんしては対立点がほぼ解消されたので、もう大波乱はないんじゃないかな。

Oさんもうワントライするようだけど、実際は前回のフィードバックを
どこかの国が投票コメントで拾ってくれるかどうかが鍵だと思う。
会議に出るのはNB本体の意向を代弁する人たちだから。
0493デフォルトの名無しさん2010/02/10(水) 00:48:26
携帯キャリアの連中、支持を表明しただけで自分たちじゃ何にもしてないのな。
0494デフォルトの名無しさん2010/02/10(水) 01:04:50
ミーティングには日本の代表団もいたはずなのに
なんでこんなに影薄いんだ
0495デフォルトの名無しさん2010/02/10(水) 01:14:20
毛が薄いから
0496デフォルトの名無しさん2010/02/10(水) 11:38:26
電話屋って、ITU-T以外の規格はなべてバカにしてよい、っていう意識があるからな。
0497デフォルトの名無しさん2010/02/10(水) 22:54:19
ISO/IEC JTC1/SC2/WG2/IRG か
0498デフォルトの名無しさん2010/02/12(金) 00:04:53
ttp://www.unicode.org/roadmaps/smp/
U+1B000～U+1B0FFがHistoric Kana(歴史的仮名)からKana Supplement(仮名補助)に変更されてた。
ということは今後このブロックには昔の仮名だけでなくイとエが合体したものや小さいヰヱヲなどの拡張仮名が追加される可能性もあるということかな。
0499デフォルトの名無しさん2010/02/12(金) 00:34:20
小さいヰヱは、NDL-70とかいう国会図書館の文字コードにあるらしいので、
典拠としてそのコード表が示せれば比較的すんなり追加されるんじゃないか。
0500デフォルトの名無しさん2010/02/12(金) 04:49:55
前のブロック名でぐぐると、変体仮名と結びつけちゃってる人も結構いるなぁ
0501デフォルトの名無しさん2010/02/13(土) 00:05:25
変体仮名用のエリアじゃないのか。
0502デフォルトの名無しさん2010/02/13(土) 21:53:21
変態かな
0503デフォルトの名無しさん2010/02/14(日) 05:06:19
変態だよ
0504デフォルトの名無しさん2010/02/14(日) 17:53:24
サプリメントの中にヘンタイがみっしりと
0505デフォルトの名無しさん2010/02/14(日) 18:42:23
きそば
0506デフォルトの名無しさん2010/02/19(金) 16:33:18
チェックボックスにチェックの入った文字コードってある？
0507デフォルトの名無しさん2010/02/19(金) 16:59:04
U+2611 (BALLOT BOX WITH CHECK) って答えでいいの?
0508デフォルトの名無しさん2010/02/19(金) 18:39:21
合字で作れないのかな。
0509デフォルトの名無しさん2010/02/22(月) 12:26:14
(´･ω･`)やーだお
0510デフォルトの名無しさん2010/02/26(金) 19:03:31
グリフウィキって変体仮名にも着手してたのか
一通り完成したらその先の展開も色々ありそうななさそうな
0511あああ2010/03/04(木) 19:24:40
ﾊﾞｶｽｷﾞﾃｱﾀﾏｷﾁｬｳﾈ～～～~~ﾌｪﾌｪﾌｪﾌｪｴﾌｪﾌｪﾌｪﾌｪﾌｪﾌｪﾌｪ
0512あああ2010/03/04(木) 19:25:50
fｇｔｈｔｇﾇｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳﾃﾞｴfｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｒｆゲｗｇｒｇｒギウウウウｇｇｇｇﾂﾊﾞｶﾔﾛｳdｿﾌｨｴｲｵﾍﾟｦｴﾌｪr
0513あああ2010/03/04(木) 19:29:21
ｱｱｱｱｱｱｱｱｱｱｱｱｱﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞｶkkkｯｶｱｱｱｱｱｱｱｱ
0514あああ2010/03/04(木) 19:30:14
sfﾍｳfｳﾞｨﾈｵﾂｳｳｳｳｳｴjmgfdsvmcdslc、エコfk派wk度kpwkでﾐkﾑyｼﾞｭyrtytryrytrytryt
0515デフォルトの名無しさん2010/03/06(土) 17:22:06
Annexだけ先行してUnicode 6.0のPublic Review始まってるのか。
この間5.2が出たとこだと思ったのに。早いなあ。
0516デフォルトの名無しさん2010/03/06(土) 21:36:17
順調に行くと２０１０年末にはUnicode 6.0になってるのか。
と、思った記事があった気がする。
0517デフォルトの名無しさん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スレでこちらを進められてきましたよろしくお願いします。
0518デフォルトの名無しさん2010/03/07(日) 03:02:26
Ctrl+cしたときの、クリップボード中に保持してるテキストの文字エンコーディングと、
エディタのクリップボードで想定してるエンコーディングが合わないんだろうけど

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

ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/45006
0520デフォルトの名無しさん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
05215172010/03/08(月) 23:25:35
解決しました、ありがとう
0522デフォルトの名無しさん2010/03/09(火) 20:14:04
Rubyになんかキタ。
ttp://github.com/ruby/ruby/commit/62f8df2d3c95816028c006ecbe70bc51704eec4b
0523デフォルトの名無しさん2010/03/10(水) 03:59:01
携帯キャリアがこのタイミングでなあ
しかしたとえ名前の上だけだとしても色なんて飲めるのかねえ、WG2的に
FPDAMの段階でこれだけ問題提起されたら、もうぬるぽな悪寒
0524デフォルトの名無しさん2010/03/10(水) 04:35:52
ぬるぽにするためにあえてこの段階で言いがかり付けてきたとか。
だって今までもさんざん携帯キャリアには何やってるのか言ってたけど
反応なかったって言ってたにょ

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

フリーダイヤルマークはやっぱり商標問題が火を噴いたか。
0525デフォルトの名無しさん2010/03/10(水) 04:56:52
前にキャリアから取り付けたコメントがポストされてたもんね。
Google/Appleにしたら、なんであの時言わなかったんだってなるだろうなぁ。

WG2としちゃ文句のついた"Symbols"を棚上げすりゃ済む話だろうけど、
「絵文字対応」が目的のUnicodeとしちゃ、それじゃ駄目だろうし。
0526デフォルトの名無しさん2010/03/10(水) 07:29:29
失礼、FPDAM8読み直してみたら、すでに色の名前入りの絵文字あったわ
それほど難題でもないのかな
0527デフォルトの名無しさん2010/03/10(水) 21:26:01
>>523 >>524
ｶﾞｯ! ｶﾞｯ!
0528デフォルトの名無しさん2010/03/13(土) 00:14:02
こういう名前にしてくれ、それが駄目ならうちの絵文字とマッピングしないで
くれってのがいやらしいな。
0529デフォルトの名無しさん2010/03/13(土) 10:56:53
国内のメーカーはそういうことを言って標準化の、ひいては利用者の足をひっぱってきた。
コード会コードの昔から。
0530デフォルトの名無しさん2010/03/13(土) 13:11:23
>>528
> それが駄目ならうちの絵文字とマッピングしないでくれ

「～の絵文字インスパイヤード」って位置づけにして、
変換テーブルに突っ込めば問題なし。
0531デフォルトの名無しさん2010/03/13(土) 17:26:52
>>532
ガラパゴス
0532デフォルトの名無しさん2010/03/13(土) 17:50:27
http://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/787bc8429b2ef1fd247b59b5515e5321_400.jpg
0533デフォルトの名無しさん2010/03/19(金) 00:32:32
もうdocomoとKDDIの担当者にもサンノゼ行ってもらうしかなかんべ
ただ合意できてもそのままFDAMに行けるのかって問題は残りそうだけど
0534デフォルトの名無しさん2010/03/21(日) 00:07:23
Amd.6フリーになったー
と思ったけどここら辺はすでにUnicodeに入ってるんだっけか。
0535デフォルトの名無しさん2010/03/23(火) 08:29:45
>>533
http://slashdot.jp/%7Eyasuoka/journal/
＞正直なところ、NTTドコモよりKDDI(au)の方がひどい
KDDIは色がどんどん変わっていってるらしい
0536デフォルトの名無しさん2010/03/24(水) 21:54:20
>>524
フリーダイヤルの商標だが、現在はNTT東・西(0036・0039)ではなくて、
NTTコミュニケーションズ（0033）が持っているんだよな。
0537デフォルトの名無しさん2010/03/25(木) 03:45:28
フリーダイヤルは削除かなあ。あとはマッピング変えたり新しいの足したりで
対応できなくもなさそうだけど、KDDIのジョーカーが少し厄介だな。
黒だの赤だの区別しない包括的なジョーカーを求めているんだとしたら、
落としどころが難しそう。
05385392010/03/25(木) 13:08:45
test
0539デフォルトの名無しさん2010/03/29(月) 22:15:24
1F609と1F60Aは本当にkiddingでいいのかなあ
「失敗しちゃった、テヘ」で舌出してるのならともかく
「あかんべー」で舌出してるのなら「拒絶」だろうし
0540デフォルトの名無しさん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化ここに完了ってとこか。
サロゲートや合成文字も、今後はきっちり対応していかなきゃならんのだろうな。
0541デフォルトの名無しさん2010/03/31(水) 00:15:52
> Group-Plane-Row-Cellという概念が消え
マジっすか？
0542デフォルトの名無しさん2010/03/31(水) 07:16:58
確かにPlaneくらいしか使わないけど……全体的に思い切ったな
0543デフォルトの名無しさん2010/03/31(水) 13:31:17
久しぶりにIVDの登録申請ががが
ttp://www.unicode.org/ivd/pri/pri167/
0544デフォルトの名無しさん2010/03/31(水) 23:20:12
>>543
日本が>>30で互換漢字の提出をあきらめてIVDの登録申請に切り替えた奴だな。
ついにｷﾀﾜｧ.*･゜ﾟ･*:.｡..｡.:*･゜（n‘∀‘)ηﾟ･*:.｡. .｡.:*･゜ﾟ･*!!!!!☆
0545デフォルトの名無しさん2010/04/05(月) 08:00:59
CP51932の登録申請がietf-charsetに来てた。
mohtaも村田真も安岡先生も途中でほっぽりだしたわけだが
今度こそ最後までやってくれるんだろうかねえ。
0546デフォルトの名無しさん2010/04/07(水) 18:29:30
西夏文字帰ってきたのか…！
0547デフォルトの名無しさん2010/04/11(日) 07:50:28
FPDAM8はあちこち炎上してますな
Agendaも議題の量がエラいことになってるし、現地行く人は大変だ
0548デフォルトの名無しさん2010/04/15(木) 00:16:14
汎用電子のプレフィックスはどういう意味なんだろうか
KS=戸籍統一文字番号
らしいというのだけはわかった
0549デフォルトの名無しさん2010/04/15(木) 13:41:45
HG=法務省外字とか？
安岡センセに聞けば一発な気もする。
0550デフォルトの名無しさん2010/04/15(木) 23:30:09
IPは安岡先生の日記でネタばらしされてた
http://slashdot.jp/~yasuoka/journal/504963
JAPANESE IDEOGRAPHICS SUPPLEMENTの平成明朝体による実装がソースらしい
0551デフォルトの名無しさん2010/04/16(金) 20:54:44
欧州各地の空港が麻痺しているらしいけど、欧州組は
週明けのWG2に無事参加できるのかな。
0552デフォルトの名無しさん2010/04/18(日) 08:26:02
米vs欧の案件が多いのに片っぽ来られないんじゃまずい罠
0553デフォルトの名無しさん2010/04/18(日) 08:27:40
ロシアあたりまで鉄道で抜けてから飛行機で飛ぶしかないのか
0554デフォルトの名無しさん2010/04/18(日) 08:28:32
ネット会議でいいじゃない
0555デフォルトの名無しさん2010/04/18(日) 09:02:26
ジェットエンジンの欠陥だろ
ヘリコプターなり
ロケットエンジンなりの
航空機なら飛ばせるぜ
0556デフォルトの名無しさん2010/04/18(日) 09:14:16
>>555
ヘリコプターもジェットエンジンなんだが？
0557デフォルトの名無しさん2010/04/18(日) 09:22:34
ヨーロッパ組のいない間に好きにやって、FDAM8投票が万一コケたら
洒落にならんなあ。係争中の字は全部取り除こうフラグが立ったかこれ。
0558デフォルトの名無しさん2010/04/18(日) 09:32:50
投票にならんだろ常考
延期だな
0559デフォルトの名無しさん2010/04/18(日) 09:59:36
Eversonだけはネット会議ででも参加すべき
0560デフォルトの名無しさん2010/04/19(月) 12:05:19
>>555
ロケットエンジンの航空機で実用的な例があるとでも?
間抜けにも程がある。

>>556
レシプロエンジンのヘリもなくはないがw
そもそもヘリなら低高度を飛べるから問題ないし。
0561デフォルトの名無しさん2010/04/20(火) 23:43:08
で、結局ヨーロッパ組はたどり着けたのか?
0562デフォルトの名無しさん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
0563デフォルトの名無しさん2010/04/21(水) 19:43:25
構わない
芸能界

2chでは文字化けしないのか。
0564デフォルトの名無しさん2010/04/22(木) 00:19:02
code pageという単語含んでるのは、
EDBIC？(IBM)か、DOSかWINDOWSなんでそうなってんのか。
まあ、重なることがなければ特に問題無いんだろ
0565デフォルトの名無しさん2010/04/22(木) 23:35:26
もういろんな意味でぬるぽ
0566デフォルトの名無しさん2010/04/23(金) 00:40:46
やっぱり
「BLACKとかWHITEは文字通りの色を表してるわけじゃねーよ」
で突っぱねるつもりみたいだな
0567デフォルトの名無しさん2010/04/24(土) 00:44:18
ドイツの
「ブロンドと西洋人を結びつけるのはナチズムだ」
ってのもすげーな
0568デフォルトの名無しさん2010/04/24(土) 03:37:24
まあナチの優生学的ってことでわからんでもないがな。
0569デフォルトの名無しさん2010/04/24(土) 09:40:20
実際ユダヤ人はゴキブリ並み出汁
0570デフォルトの名無しさん2010/04/24(土) 13:24:35
テメーゴキさんディスってんのか
0571デフォルトの名無しさん2010/04/25(日) 09:25:37
投票制度変更の件は、会議の開催を今後は8ヶ月ごとに
することで解決したのか。
0572デフォルトの名無しさん2010/04/27(火) 01:27:52
NEUTRAL FACEがN3769由来で、USも支持してるってこと見落としてるのかなあ
0573デフォルトの名無しさん2010/04/28(水) 12:58:10
Nさんも気づいたね。

pipelineにStage 7が出現してますな。最近じゃレアだ。
0574デフォルトの名無しさん2010/05/01(土) 17:21:59
せっかく新10646の全容が確定したのにfdisは秋か…
Unicode6の方が先かな
0575デフォルトの名無しさん2010/05/05(水) 00:38:31
BabelStoneによると、2nd editionはフォントの問題でExtBだけマルチカラム化見送り。
そのかわりamendmentなしですぐ3rd editionの作成に入ってこれを修正するそうだ。
0576デフォルトの名無しさん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
0577デフォルトの名無しさん2010/05/08(土) 02:58:29
>>576
宣伝乙
http://gihyo.jp/magazine/wdpress/plus/978-4-7741-4164-0/0002
0578デフォルトの名無しさん2010/05/08(土) 03:44:22
このスレ読むような人なら十中八九既知だと思う。
0579デフォルトの名無しさん2010/05/08(土) 13:04:09
でももうucs-2ってdeprecatedになるのよね
0580デフォルトの名無しさん2010/05/08(土) 17:51:16
わざわざUTF-16ではなくてUCS-2を持ち出すあたりに恣意的なものを感じる
著者の名前を見るとある意味納得なんだが
0581デフォルトの名無しさん2010/05/10(月) 15:07:59
ひゅるり
0582デフォルトの名無しさん2010/05/10(月) 15:32:09
ひゅるりらら～
0583デフォルトの名無しさん2010/05/11(火) 14:27:32
>>580
恣意的というか思想に偏りがあるから、この本に書いてあることを信じて実装したら死ねると思うなー。
0584デフォルトの名無しさん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独自のもの？一般的な方法がある？
0585デフォルトの名無しさん2010/05/11(火) 14:42:00
東京→UTF-8→urlencode
0586デフォルトの名無しさん2010/05/11(火) 14:46:29
ageすま
0587デフォルトの名無しさん2010/05/11(火) 14:47:31
ありがとうございます
なんかすごい簡単な質問だったようですんません
0588デフォルトの名無しさん2010/05/11(火) 14:53:07
マルチ死ね
http://pc12.2ch.net/test/read.cgi/tech/1271996751/
0589デフォルトの名無しさん2010/05/11(火) 16:04:54
はふ
0590デフォルトの名無しさん2010/05/11(火) 16:15:53
UTF8ってBase64エンコードと紛らわしくて厄介。
0591デフォルトの名無しさん2010/05/11(火) 20:33:15
さすがにそれはだいぶ違うと思う
0592デフォルトの名無しさん2010/05/16(日) 07:14:45
なかったことにされつつあるUTF-7とごっちゃにしてないか
0593デフォルトの名無しさん2010/05/16(日) 08:47:56
「Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディング された文字列の脆弱性」ってやつか・・・
0594デフォルトの名無しさん2010/05/19(水) 00:23:19
JISコード群にはJISロゴが入っていないが
UnicodeにはJISロゴが入っているふしぎ
0595デフォルトの名無しさん2010/05/19(水) 14:40:26
asciiコードにasciiのロゴが入っていないが如し。
0596デフォルトの名無しさん2010/05/19(水) 16:54:17
ロゴを直接Unicodeに入れるのは今もう難しい希ガス
0597デフォルトの名無しさん2010/05/19(水) 21:44:36
ああ、こんなことならもっと早くうちの家紋捻じ込んでおけばよかった。
0598デフォルトの名無しさん2010/05/19(水) 22:19:47
ワロタ

いやでも、Googleの絵文字の件みたいに、誰かが家紋を入れるとか言い出したら楽しいことになりそうだ。
0599デフォルトの名無しさん2010/05/19(水) 22:33:11
Unicodeだもん、家紋も当然包摂なんだろうな。
菊紋だろうが桐紋だろうが葵紋だろうが、細かいデザイン上の違いはばっさり切り捨て。
0600デフォルトの名無しさん2010/05/19(水) 23:10:37
丸に違い矢なら、違い矢＋丸の合成文字で。
0601デフォルトの名無しさん2010/05/19(水) 23:10:57
そこでTronコードの出番だ
0602デフォルトの名無しさん2010/05/19(水) 23:18:48
丸囲みの三つ葉葵紋については葉形によって指し示す人物が全然異なるという事実があるから、
すくなくともIVSの適用は期待できると思うぞ。徳川一門全部含めたら足りるかどうかわからんけどな。
ttp://aal.msis-net.com/kamon/tokugawa_1.html
0603デフォルトの名無しさん2010/05/19(水) 23:39:43
しかし特定個人と結びつけてしまうと逆にジョンイルメソッドで却下される悪寒
0604デフォルトの名無しさん2010/05/20(木) 01:15:29
明治・大正・昭和・平成は入ってるからそこは政治力次第
0605デフォルトの名無しさん2010/05/20(木) 01:32:20
確かに。現天皇を元号で呼ぶことこそなくても、在位と元号が一致してるのなら実質個人名相当か。

てか、将来平成の次の元号が出来たときもちゃんと扱いやすいところに確保してもらえるんだろうか
0606デフォルトの名無しさん2010/05/20(木) 01:58:38
日本国の書類(市役所とか法律関係とか)は西暦じゃないんだよな
当たり前だけど
0607デフォルトの名無しさん2010/05/20(木) 05:36:04
>>605
次の元号がもし入るとして、平成とかのあるCJK Compatibilityは埋まってるから
収まりのよさそうな場所はEnclosed Ideographic Supplementあたりかな、Enclosedじゃないけど
0608デフォルトの名無しさん2010/05/20(木) 07:25:36
天皇を元号で呼ぶのは死後だけどな
0609デフォルトの名無しさん2010/05/20(木) 08:00:29
諡号だけに
0610デフォルトの名無しさん2010/05/20(木) 08:47:03
平成のあと意味ありげな空きがあるのはJIS第三だっけ？
0611デフォルトの名無しさん2010/05/20(木) 17:01:19
6.0.0ディレクトリ下が慌ただしくなってきた
>Unicode 6.0.0 (Scheduled September, 2010)
らしいのでそろそろベータレビューかな
0612デフォルトの名無しさん2010/05/20(木) 18:17:27
>>607
むしろ元号のほうが、既存の組文字採用すればよくね？㌍とか、例の㌬とか。
過去にも神護景雲とか、漢字2字じゃない変てこな元号もあるしさ。
0613デフォルトの名無しさん2010/05/20(木) 19:40:45
けんさんAJ1-7の話題なんか出すんじゃなかったと
いまごろ後悔してないかな…
0614デフォルトの名無しさん2010/05/21(金) 00:48:41
汎用電子(のうちAJ1-6までと重複しないもの)もやっぱりAJ1-7に入るんだろうか
0615デフォルトの名無しさん2010/05/21(金) 01:05:42
こういうの追っかけてるともうascii基本だけでいいような気がしてくるぜ
0616デフォルトの名無しさん2010/05/22(土) 01:12:02
株の自動売買プログラムを自作中なんですが、証券会社の配布してるツールの中で
株価の情報をソケット通信で要求している部分を調べてみたところ、
文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコードをしているんです。
これって一般的に使われるものなんですか？
0617デフォルトの名無しさん2010/05/22(土) 02:17:32
株やってるギャンブラーには教えてやらん
0618デフォルトの名無しさん2010/05/22(土) 06:07:41
ヌルターミネートの1バイトすら貴重な時代にはよく見かけたな
SYMDEBのシンボルテーブルとか
0619デフォルトの名無しさん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
0620デフォルトの名無しさん2010/05/22(土) 20:18:00
>>619
何が起こるの？

IVSの登録方法が変わるの？
0621デフォルトの名無しさん2010/05/22(土) 21:17:19
>>620
汎用電子とAJ1の重複問題を何とかしたいということらしい
0622デフォルトの名無しさん2010/05/22(土) 21:29:28
もともとアメリカは、AJ1にないグリフだけ登録するか、いっそのことAJ1に
組み込んでしまうことを提案してたからねえ
ここへ来てAJ1-7の話がちらほら出てきたのもこれがらみかなと邪推
0623デフォルトの名無しさん2010/05/22(土) 21:46:40
なんかこっちが('A`)な気分になってくるな
0624デフォルトの名無しさん2010/05/22(土) 23:14:14
月と肉月の区別みたいな話ならまだ分かるんだが、
何画目が縦だの横だのってレベルになるとついてけんわ
0625デフォルトの名無しさん2010/05/23(日) 00:45:43
最初から先見性を持って康煕ベース、その他は出自を問わず全部IVSにしてしまえばすっきりしたのに
0626デフォルトの名無しさん2010/05/23(日) 00:57:37
康熙字典は5万字弱あるから、Unicodeの当初設計に収まらないけどね。
当初設計がそもそも悪すぎるわけだけど。
0627デフォルトの名無しさん2010/05/23(日) 01:08:36
せめて16じゃなく24ビット固定ならね。

コンソーシアムは今からでも625の方向へ収束させる気ないのかなあ。
正規化とVSを組み合わせれば出来そうな気もしないでもない。
0628デフォルトの名無しさん2010/05/23(日) 02:16:31
Extension Bで康熙字典の漢字はすべて突っ込んだことになってるらしいな。
実際には漏れがあるようでちょくちょく追加されてるけど。
その頃はまだUTS #37がなくてVariation Selectors Supplementは
あっても使いようがなかったから仕方ない
0629デフォルトの名無しさん2010/05/23(日) 03:17:40
汎用電子の公開レビューが終わるまでには、
新UTS #37候補のレビューも始まるのかな。
0630デフォルトの名無しさん2010/05/23(日) 18:38:17
明日はぶっちぎるぜ！
0631デフォルトの名無しさん2010/05/23(日) 19:02:56
落ち着け
0632デフォルトの名無しさん2010/05/25(火) 10:46:11
WindowsでIBM EBCDIC 930/939をUTF-16に変換するは面倒だ
0633デフォルトの名無しさん2010/05/25(火) 17:11:14
Lundeさんのコメント付いてる>>619
UTCでの議論に参加してたかんじだ。
0634デフォルトの名無しさん2010/05/25(火) 17:32:16
合意によるsharing authorityか…汎用電子はモノがモノだけに厳しそうだな
0635デフォルトの名無しさん2010/05/25(火) 18:48:34
ふとスレタイを眺めて、「あ、ここUnicode専用スレじゃなかったんだ」と気付いた。ほかの話題なんてないものな。
0636デフォルトの名無しさん2010/05/25(火) 19:12:00
つ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
0637デフォルトの名無しさん2010/05/26(水) 06:43:21
>>636
今度はスレタイが限定的すぎて微妙
0638デフォルトの名無しさん2010/05/26(水) 14:05:32
というか埋まっとる
0639デフォルトの名無しさん2010/05/26(水) 14:07:45
うむ。
ファイルの先頭のマークに対して奇数アラインだったらどうすんのとか
アホなこと言ってるやつに一言言いたかったがな
0640デフォルトの名無しさん2010/05/29(土) 22:34:10
気を取り直して、と
0641デフォルトの名無しさん2010/05/30(日) 06:59:01
amd8が済むと、日本に関係ある提案は当面なくなるのかあ
0642デフォルトの名無しさん2010/05/31(月) 22:50:33
うむ，新スレ立ってるな
http://pc12.2ch.net/test/read.cgi/tech/1274937437/
0643デフォルトの名無しさん2010/05/31(月) 23:06:04
まあ不毛な争いは隔離されていただいた方がありがたい
0644デフォルトの名無しさん2010/05/31(月) 23:17:29
誰がハゲじゃコラ
0645デフォルトの名無しさん2010/06/01(火) 07:04:03
すみません頭髪の量をチャレンジされている人に言い直します
0646デフォルトの名無しさん2010/06/01(火) 17:26:39
＞頭髪の量をチャレンジされている人

ハゲに包摂します。
0647デフォルトの名無しさん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以降全滅か…
0648デフォルトの名無しさん2010/06/01(火) 22:48:03
リンク先読んでないけどなんでそんなひどい仕様なんだ
0649デフォルトの名無しさん2010/06/01(火) 23:10:59
この仕様はMS社内のフォント開発部隊が困るんじゃないか。
0650デフォルトの名無しさん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等を犠牲にすることになる。
0651デフォルトの名無しさん2010/06/02(水) 00:18:17
その支離滅裂さは仕様じゃなくて不具合の匂いが…
0652デフォルトの名無しさん2010/06/02(水) 00:49:41
マジでバグであってほしい
MS様がいいと言うまで新しい文字は使えず、MS様がWin7のサポートを
打ち切った場合も新しい文字はもう使えないなんて嫌すぎる
0653デフォルトの名無しさん2010/06/02(水) 01:19:09
てかこれまで誰も気付かなかったのか
0654デフォルトの名無しさん2010/06/02(水) 09:42:45
まだUnicode5.2対応フォントが少ないしXP使い続けてる人も多いから仕方ないか。
でも今MSに要望出しておかないとSP1や次期Windowsでも放置される危険性があるな。
0655デフォルトの名無しさん2010/06/02(水) 18:39:43
困ったなあ
0656デフォルトの名無しさん2010/06/02(水) 23:11:51
なんだ。
会社のPCをまとめてWindows 7への移行を考えて、金も少し使ってたのに振り出しじゃん。
なんて言い訳すんべか。
0657デフォルトの名無しさん2010/06/03(木) 06:36:09
DirectWriteへ移行させるための嫌がらせとか。
いやDirectWriteなら豆腐にならないのかどうかは知らないけど
0658デフォルトの名無しさん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をコピーするだけじゃダメなのはそれでか…
0659デフォルトの名無しさん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を試してみたけど他のブラウザは全滅だった
0660デフォルトの名無しさん2010/06/03(木) 08:47:44
Firefoxはフォント周りの処理が独特で、
どうも自前でグリフを抜き出しているみたい。
0661デフォルトの名無しさん2010/06/03(木) 09:03:20
そんな中Unicode 6.0.0のBeta Reviewがはじまた
0662デフォルトの名無しさん2010/06/05(土) 00:50:31
由仁子！
0663デフォルトの名無しさん2010/06/05(土) 01:29:49
who?
0664デフォルトの名無しさん2010/06/09(水) 12:31:41
うんこマークも入るようだ。2chのAA等で使われるかも。
でもMS明朝/ゴシックやメイリオに収録されないと普及しないか。
その前に>>647に書いてあるWin7のUniscribeの不具合を直してもらわないかんが。
0665デフォルトの名無しさん2010/06/09(水) 16:30:51
うんこマーク入るのかｗ

逆卍とかと同じく宗教的に嫌う人向けにMSがグリフ削除ツールを出したりするのかな。
0666デフォルトの名無しさん2010/06/09(水) 19:28:04
既にBMPに入っているフェイスマークでぐぐっても結果が出ないな。
symbolは弾いているのか。絵文字の人気調査には使えそうにないな。
0667デフォルトの名無しさん2010/06/09(水) 21:08:59
所謂「まきぐそ」は日本の漫画内だけで通用する符牒だと読んだことあるけど、
名前(何になったの？)無しだとどれぐらいの外人が意味を認識できるんだろう。

ファストフードのおしながきにソフトクリームサインとして使われたりしたら楽しいな。
0668デフォルトの名無しさん2010/06/09(水) 21:41:25
フォント屋が泣くわ
0669デフォルトの名無しさん2010/06/09(水) 21:54:27
　　入　　　　　　　∧
　 .(＿)　　　　　　(＿)
　 (__＿)　　　　　(__＿)
　(_＿＿)　　　　(_＿＿)

　　Serif　　　Sans-Serif
0670デフォルトの名無しさん2010/06/09(水) 22:39:38
2chでウンコマークを大量に書き込む荒らし行為が流行りそうな悪寒
0671デフォルトの名無しさん2010/06/09(水) 22:51:44
>>667
まきぐその、ドラフトでの文字名は
PILE OF POO
翻訳すれば、「山盛りのうんち」
要するに、巻いてなくても良いらしい。

>>670
Windowsに、まきぐそのグリフが標準で入る日が来るのだろうか？ｗ
0672デフォルトの名無しさん2010/06/09(水) 23:16:40
Unicode6はドラフトとはいえ、もう名前は変えられないので確定ですな

フォント入れればまきまきだし入れなければ豆腐か…
0673デフォルトの名無しさん2010/06/09(水) 23:20:19
ユーザーの囲い込み目的で無節操に絵文字を考え出してた連中は
絵文字登録の流れをどんな思いで見ているのだろう。

0674デフォルトの名無しさん2010/06/09(水) 23:21:38
今日もまたまきまきうんちのヒンティングする仕事が始まるお…
0675デフォルトの名無しさん2010/06/10(木) 01:14:18
考えたことなかったけど、絵文字ってベジエ曲線で作るとなると
結構面倒くさそうだなあ。
ドット絵だと大した手間じゃないんだろうけれど。
0676デフォルトの名無しさん2010/06/10(木) 01:20:07
ドット絵なめんな
0677デフォルトの名無しさん2010/06/10(木) 03:59:16
>>669はもっと評価されていいと思う
0678デフォルトの名無しさん2010/06/10(木) 04:41:22
おいらも好きだよ
崩れかけにしてcursiveってやろうと思ったけどやめた
0679デフォルトの名無しさん2010/06/10(木) 08:13:44
崩れかけﾜﾗﾀ
0680デフォルトの名無しさん2010/06/10(木) 18:16:38
OSに付いてくれば使う人も少なくないんだろうけど
フォント買ってまで使いたいって人はいるのかなぁ
0681デフォルトの名無しさん2010/06/10(木) 20:21:08
そこで色つきの文字やアニメーションまで完全再現できるSVGフォントですよ。
問題は対応ブラウザがひとつもないことだが
0682デフォルトの名無しさん2010/06/11(金) 03:14:07
そっか。絵文字の場合、OSにインストールして使うフォントよりも
WebFontsの方が需要あるのかもしれないね。
0683デフォルトの名無しさん2010/06/11(金) 08:22:02
>>681
WebKitで使えなかったっけ？
0684デフォルトの名無しさん2010/06/11(金) 19:33:44
>>683
現在SVGフォントに対応しているブラウザはすべてAcid3を通すためだけの実装で、
色つきの文字やアニメーションを再現するための仕様に対応していない
0685デフォルトの名無しさん2010/06/12(土) 00:05:09
普通に単色でグリフ表示できるだけで立派なもんじゃねえの
0686デフォルトの名無しさん2010/06/12(土) 03:30:58
色つき文字のモノクロ化には、hatchingとかいうのが利用されてるらしい。
ttp://en.wikipedia.org/wiki/Hatching_system
0687デフォルトの名無しさん2010/06/12(土) 11:30:08
>>685
それだけならTTFやWOFFのWebフォントに対して何もメリットがない
(Acid3で3点ゲットする以外に)
0688デフォルトの名無しさん2010/06/12(土) 12:39:09
これはとても重要な確認なんだけど、いま色の話をしてるのはうんこマークからの流れなの？
0689デフォルトの名無しさん2010/06/12(土) 13:55:04
せっかく絵文字を実装するんなら色やアニメーションも正確に再現したいじゃん
0690デフォルトの名無しさん2010/06/12(土) 14:30:33
そのうち巻き具合の指定にIVSが使えるようになるのだろうか
0691デフォルトの名無しさん2010/06/12(土) 15:54:21
"Ideographic" Variation Selectorは使えないだろ。
絵文字は表意文字かもしれないが
この文脈でのIdeographは漢字の婉曲な言い回し
0692デフォルトの名無しさん2010/06/12(土) 16:07:46
特定の読みが存在しないんだからむしろ漢字より本来の意味の表意文字に近いな
0693デフォルトの名無しさん2010/06/12(土) 16:36:32
実質IVSというかVSだよねあれ
0694デフォルトの名無しさん2010/06/12(土) 16:40:28
漢字とモンゴル文字以外はU+FE00～U+FE0Fを使うことになってるし
UTS#37は漢字(正確にはUnified_Ideographプロパティを持つ文字)にしか適用されない
0695デフォルトの名無しさん2010/06/12(土) 16:44:47
＞正確にはUnified_Ideographプロパティを持つ文字

はー、そうなのか。
0696デフォルトの名無しさん2010/06/14(月) 16:46:01
U+E0100～U+E01EFは漢字以外には使っちゃいかんのだな。
非漢字で17個目以降のVSが必要になったらU+E01F0～かどっかにVS-257～を追加しないといかんのかな。
0697デフォルトの名無しさん2010/06/14(月) 17:56:56
それを分けてる意味ってそもそも何なんだろう？
0698デフォルトの名無しさん2010/06/14(月) 21:01:15
どちらかと言うと先着16個の漢字のglyphic variantにBMPのVSを使う「特権」を
与えたくなかったんじゃなかろうか。
0699デフォルトの名無しさん2010/06/14(月) 22:16:08
何でVSはBMPとSSPに分けたんだろ?どちらか一方に全部の方がよかったんじゃないかな?
そういやVS-2～16を使うのってまだ1つも無いんだな。パスパ文字以来非漢字のVSの提案全く無いし。
0700デフォルトの名無しさん2010/06/14(月) 22:20:03
すでに240個もVS「ごとき」に使わせられる余裕はBMPになかったと思う
JIS X 0213の300個程度の漢字ですら蹴られてたしな
0701デフォルトの名無しさん2010/06/15(火) 00:08:42
なんでBMPそんなに余裕がないんだよ…誰だよ最初の見込み立てた奴は…
0702デフォルトの名無しさん2010/06/15(火) 00:15:59
Unicodeにはハングル完成形が1万字以上全てBMPにあるけど実際に使われるのは2～3千字とか。すごい無駄だよな。
統合漢字も拡張AからBMP外にした方が良かったのでは?使用頻度の低い字ばかりだし。
0703デフォルトの名無しさん2010/06/15(火) 00:35:20
いつかUCSをデフラグしてほしい。
0704デフォルトの名無しさん2010/06/15(火) 00:44:19
　　　　　[ﾟдﾟ]
　　　 　/[＿]ヽ　　　　　　　　　　デフラグを使うと
　　　　 　|　|
　■■□■■□◇＿◇□□□

　　　　　[ﾟдﾟ]
　　　 　■＿]ヽ□　　　　　　　　ハード ディスクのファイルや未使用領域を再配置し
　　　　 　|　|
　■■□＿■＿◇＿◇□□□

　　　　　　　　□
■⌒　　　　　　ヾ
　　　＼[ﾟдﾟ]ﾉ　　　　　　　　　　プログラムの実行速度を上げることが
　　　　　　＼＼/　
　■■□　/■＿◇＿◇□□□


　　　□　　　（ ）　　　　　　　　　出来る・・・かも知れません。
　　■　　ヽ[￣]ﾉ
　■■□[ﾟдﾟ]■◇＿◇□□□


　　　□　　　　　　　　　　　　　　 デフラグを実行しますか？→YES
　　■
　■■□ 　　 ■◇＿◇□□□
0705デフォルトの名無しさん2010/06/15(火) 00:48:33
使用人口/収録数でいうと多分ハングルがぶっちぎりで悪いよね。一番の優等生は算用数字。
0706デフォルトの名無しさん2010/06/15(火) 00:57:39
>>705
生まれが組み合わせ文字なのに無理矢理全部いれやがって
しかも発音のうち自国で使ってない物はいれなかったせいで、ハングルを採用させられた某国では結局ＰＣ化でふべんを強いられてるし
0707デフォルトの名無しさん2010/06/15(火) 01:25:20
>1万字以上全てBMPにあるけど実際に使われるのは2～3千字

それは漢字にもほぼあてはまるんだが……
0708デフォルトの名無しさん2010/06/15(火) 02:22:27
>>705
いや、優等生はCRだろ。
0709デフォルトの名無しさん2010/06/15(火) 02:55:14
日本もBMPがスカスカなうちに変体仮名入れときゃ良かったのに
0710デフォルトの名無しさん2010/06/15(火) 04:54:14
丸付き数字があっちこっちに飛び飛びで入れられてるのが地味に気持ち悪い
0711デフォルトの名無しさん2010/06/15(火) 05:51:42
>>701
欧米人は「東アジアさえなければ16bitで足りなくなるわけなかっただろJK」
とか思ってるよきっと
0712デフォルトの名無しさん2010/06/15(火) 05:53:51
つか最初は「GB2312とKSC5601とJISX0208合わせても余裕じゃん」とか
言ってたらしいからな。さすがに止めたらしいけど(で、漢字統合とか言い出した)
0713デフォルトの名無しさん2010/06/15(火) 05:59:06
これだな
ttp://www.unicode.org/history/unicode88.pdf
現代の文字以外はPUAを使わせるつもりだったという
0714デフォルトの名無しさん2010/06/15(火) 07:05:46
「16ビットで十分ですか?」「はい」
力強いな
> fixed-length 16-bit character
ときっぱり言い切って可変長にたいする利点を強調しておるな
0715デフォルトの名無しさん2010/06/15(火) 08:08:18
容易に想像できる懸念を無視して美しさにこだわったら、
すぐに破綻して一番美しくないｇｄｇｄ状態になってしまったでござるの巻
0716デフォルトの名無しさん2010/06/15(火) 10:53:03
>>713
そこに入ってるWriting System別のGNP表、今集計しなおしたらかなり変わってるんだろうな…
0717デフォルトの名無しさん2010/06/15(火) 17:52:11
>>707
しかし漢字は合成済み文字と用途の被る偏旁別の合成用パーツが収録されてるわけではあるまい？
0718デフォルトの名無しさん2010/06/15(火) 19:14:29
こういう今となってはちょっとあれな文書も、
堂々と公開しているのはえらい。
0719デフォルトの名無しさん2010/06/15(火) 19:48:24
>>717
なんたらradicalsとかIDSとか
正直この件で韓国叩いてもブーメランが返ってくるだけだよ
0720デフォルトの名無しさん2010/06/15(火) 20:27:02
いくらか青臭くもあったけど　あの頃はみんな若くて輝いていた　みたいな青春の証左
0721デフォルトの名無しさん2010/06/16(水) 02:04:05
>>711
Unicodeなんてもともと、東アジアへの対応に嫌気がさして作った規格だろ。
0722デフォルトの名無しさん2010/06/16(水) 02:12:38
誰がどういう意図でそんな事を言ったんだ？
0723デフォルトの名無しさん2010/06/16(水) 04:34:26
未だに欧米のUnicode化してないアプリだとダメ文字問題とかあるでしょ?
(「表」を含んだファイルが開けないとか)
1バイト文字で用が足りる連中にいくら言っても理解すらしてもらえないから
(似非でも)2バイト固定にしたほうが少しはマシになるってこと。
0724デフォルトの名無しさん2010/06/16(水) 09:26:32
理解してもらえないから、UTF-8なんかにせず、2バイト固定のほうがよかった、というのか？
よくわかんない。
0725デフォルトの名無しさん2010/06/16(水) 19:48:35
アメリカ人はUTF-8のほうが好きだがそれは(連中にとっては事実上)
何も変更しなくてすむから。
プログラマーは基本的にlazyなのです。
0726デフォルトの名無しさん2010/06/16(水) 22:25:48
>>724の頭がよくわかんない。
0727デフォルトの名無しさん2010/06/16(水) 22:27:06
そのとばっちりで日本語が基本１文字３バイトになるんだから
たまったもんじゃないな
0728デフォルトの名無しさん2010/06/17(木) 00:30:44
いや別に。外部表現だし。
0729デフォルトの名無しさん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は避けた方がいい
・そこまででもない場合は、そこまで気にしなくても良い
0730デフォルトの名無しさん2010/06/17(木) 02:13:47
プレーンテキストに日本語の文章を書くような場合は、
utf-8よりutf-16の方がいいだろうね。

ただ(x)htmlの場合は、ファイル中に占めるタグやら何やらの比率が高いから、
sjisとutf-8との差は相対的に小さくなる。
0731デフォルトの名無しさん2010/06/17(木) 10:24:07
今時utf-8のサイズがどうこう、sjisの方がうんぬん、なんて時代錯誤がいるとは驚きを禁じ得ない。

どう考えても、既にsjisやらiso-2022-jpやらの時代ではありません。
0732デフォルトの名無しさん2010/06/17(木) 11:57:44
対案も出さずに文句だけ言う口か
0733デフォルトの名無しさん2010/06/17(木) 11:59:16
世の流れ
0734デフォルトの名無しさん2010/06/17(木) 20:09:30
どうみても UTF-8 一択です
ほんとうにありがとうございました
0735デフォルトの名無しさん2010/06/17(木) 23:45:52
1995年頃ならまだしも今さら「対案」なんか出されても迷惑なだけだがな。
0736デフォルトの名無しさん2010/06/18(金) 00:29:56
合成済み文字は排除する・漢字はIDSで表記する
これなら16bitで行けそうな気がしないでもない。
0737デフォルトの名無しさん2010/06/18(金) 01:50:12
>>731
今も昔も、sjisをutf8に変えると約1.5倍になる事実には変わりがない。
ちょっとしたテキストファイルがHDDを圧迫する時代ではなくなったが、莫大な量のテキストを扱う用途もありうる。
それすらも考えられないのは時代云々以前の問題。

ただ、時代的に、サイズを問題にするならギガバイト越えはしてるんだろうな、
DVDに収まらなくなってからでも全然遅くはないぞ、とは思う。
0738デフォルトの名無しさん2010/06/18(金) 05:52:05
ストレージの価格や回線の速度やSJISで表せない文字の需要がぜんぜん違うだろ。
0739デフォルトの名無しさん2010/06/18(金) 05:53:11
今も昔も円記号問題は変わらんな
0740デフォルトの名無しさん2010/06/18(金) 09:04:50
莫大な量のテキストならなんらかの構造を持ったデータにするだろ。
ベタデータで 1.5 TB じゃダメで 1TB なら OK っていう場合なんて、ちょっと想像つかない。
0741デフォルトの名無しさん2010/06/18(金) 09:13:44
2GB以下でないと圧縮すると壊れるファイルとかあるからな
そういうのにシビアな環境のひとなんだろう
0742デフォルトの名無しさん2010/06/18(金) 09:19:50
通は故・UTF-7
0743デフォルトの名無しさん2010/06/18(金) 10:41:39
なんか痛々しくてどうにもならんな。

そんなサイズを云々するような規模の文書なら、プレーンってことはないだろ。
装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。そうなりゃsjisとutf-8のサイズの差なんて誤差だわ。

あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。
0744デフォルトの名無しさん2010/06/18(金) 11:43:27
文章を書く側が、自分の書くものがSJISで書けると分かっていて
SJIS使う分には別にどうも思わん。

プログラムを書く側が、SJIS前提のプログラムを書くのはさすがに
今となっては勘弁してほしい。
0745デフォルトの名無しさん2010/06/18(金) 12:07:26
とりあえず、難がなくて的確な>>744に同意しておこう
0746デフォルトの名無しさん2010/06/18(金) 12:10:07
>>741
pgr
0747デフォルトの名無しさん2010/06/18(金) 20:37:38
>>743
一般的な用途にはutf-8でいいというのは認めた上での話なのに、全く的外れ。

> 装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。
そんなことするってどこに書いてある？

> あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。
何を表現できるかじゃなくて何を表現したいかが問題。
漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。
0748デフォルトの名無しさん2010/06/18(金) 22:19:37
>漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。

ならば UTF-8 がいいよ
0749デフォルトの名無しさん2010/06/18(金) 22:47:24
なんというどっちもどっちだ
0750デフォルトの名無しさん2010/06/18(金) 23:51:02
>>748
ひらがな、半角カナならsjisで十分だし、容量も少なくなる。
0751デフォルトの名無しさん2010/06/18(金) 23:59:41
いやその前提はおかしい
0752デフォルトの名無しさん2010/06/19(土) 00:05:55
UTF-16にしたら
0753デフォルトの名無しさん2010/06/19(土) 00:55:02
Unicodeに絵文字収録されても「全部」でない以上何の解決にもならん木がするんだが…
0754デフォルトの名無しさん2010/06/19(土) 00:58:10
絵文字
一時しのぎに外字登録みたいなことするとか？
0755デフォルトの名無しさん2010/06/19(土) 01:38:09
>>754
機種依存文字の時代に逆戻りなわけですね。
0756デフォルトの名無しさん2010/06/19(土) 03:36:51
>>755
mixiみたくエスケープすればいいだけの話。
一般の文字と同様にコード空間に割り当てることだけは断固として反対する。
0757デフォルトの名無しさん2010/06/19(土) 04:28:08
>>756
もはや文字コードじゃないね。
0758デフォルトの名無しさん2010/06/19(土) 09:13:02
sjis真理教には何を言っても無駄っぽいなｗ

どうせ何を言っても彼には結論が一つしかないんだし、相手しない方が良さそうだ。
0759デフォルトの名無しさん2010/06/19(土) 09:19:11
エスケープっつーとJISみたいな感じか？
0760デフォルトの名無しさん2010/06/19(土) 09:28:27
mixiの絵文字の場合は、[m:123] みたいな形式。

絵文字だって文字なんだからコード空間に割り当てられるのは当然の流れだろう。
誰も使ってない象形文字にすら文字コードがある時代なのに。
0761デフォルトの名無しさん2010/06/19(土) 09:32:54
図書館の◆とかだろ
0762デフォルトの名無しさん2010/06/19(土) 09:44:40
絵文字は文字じゃねーよ
絵だよ
0763デフォルトの名無しさん2010/06/19(土) 09:51:57
絵文字は象形文字だよ
0764デフォルトの名無しさん2010/06/19(土) 09:53:27
┏━─┓
│　 　 ┃
└┐┌┘
　 ┗┛

こいつらに言ってやれよ
0765デフォルトの名無しさん2010/06/19(土) 10:20:32
>>758
それはユニコード原理主義者の話だろ。

sjis真理教信者は幸い、ここには来てないよ。
ごく限られた用途によってはsjisの方がいい場合もありうるって話
0766デフォルトの名無しさん2010/06/19(土) 10:37:48
携帯とか通信量がシビアな場合はSJISの方がいいように思う
0767デフォルトの名無しさん2010/06/19(土) 10:44:32
通信量というか通信料だなｗ
0768デフォルトの名無しさん2010/06/19(土) 10:47:32
まあどっちでも通じるけどw
0769デフォルトの名無しさん2010/06/19(土) 10:59:58
最近アナタたち元気ね
0770デフォルトの名無しさん2010/06/19(土) 11:01:15
圧縮すれば大差ない
0771デフォルトの名無しさん2010/06/19(土) 12:59:59
どう見てもごく限られた用途の話なんかしてなかったけどな
0772デフォルトの名無しさん2010/06/19(土) 13:05:09
>>771
だよね。>>737, >>747みたいな使用例って極めて一般的だよね。
0773デフォルトの名無しさん2010/06/19(土) 13:21:47
自作自演カコワルイ
0774デフォルトの名無しさん2010/06/19(土) 13:25:04
どっちも落ち着けよ
0775デフォルトの名無しさん2010/06/19(土) 16:32:47
Shift_JISはテキストデータのサイズが小さくなる!(ｷﾘｯ
0776デフォルトの名無しさん2010/06/19(土) 17:39:27
そういうのはやめれ。どっちもどっちだと思ってたけど
議論でさえない煽りに熱中しだすのはただの迷惑行為だ。
0777デフォルトの名無しさん2010/06/19(土) 18:48:42
もうこれでいいんじゃね？

・相当な理由がない限りはutf-8を使え
・相当な理由があるときは、本当にutf-8じゃダメかを再検討せよ
・やっぱりutf-8じゃダメなら、本当に{sjis, euc-jp, ...}が有効な解決方法か検討せよ
・{sjis, euc-jp, ...}が有効な解決方法なんだったら、もう仕方ない
0778デフォルトの名無しさん2010/06/19(土) 19:22:42
まあそれでいいんだが、たまにはutf-16のことも…
0779デフォルトの名無しさん2010/06/19(土) 19:51:57
utf-16を採用しているのは
JavaとJavaScriptと
WindowsとMacOSXだっけ？
qtもUTF16だっけか。
たくさんあるよな。
0780デフォルトの名無しさん2010/06/19(土) 21:19:52
プログラミング言語内では UTF-16、ファイル出力とか外部との通信は UTF-8 ってことで。
0781デフォルトの名無しさん2010/06/19(土) 23:55:46
>>779
linuxはディストリによって違うのか？
まあ大体はUnicode化されているよね。
0782デフォルトの名無しさん2010/06/20(日) 00:20:10
日本語ならUTF-8よりUTF-16の方が良いもんなあ
サロゲートペアが嫌な感じではあるが
0783デフォルトの名無しさん2010/06/20(日) 00:23:20
C言語が癌なんだろうね。
昔から有るC言語のライブラリが
ASCII前提で作られている。

具体的に言うと、文字列の終わりは文字コード0になっていないといけない。
UTF16やUTF32は16bit、もしくは32bitで見れば、文字コード0ではないが、
1バイトずつ見ると、文字コード0が含まれているように見えてしまうことがある。
だから文字列の途中で文字の終わりと認識されてしまう。
0784デフォルトの名無しさん2010/06/20(日) 00:27:22
UTF-8はASCII互換が高いからねえ
検索関数とかそのまま使えるし
0785デフォルトの名無しさん2010/06/20(日) 00:49:32
>>781
そうなのか？
ロケールの話だと日本ならWindowsはsjisだし内部コードの話だと思うのだが、Linux内部ってそんな複雑な振り分けしてるのか？
0786デフォルトの名無しさん2010/06/20(日) 00:54:16
>>783
なんで1byteずつ見るんだ。
wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
0が含まれてなくても、2byteなり4byteなりで考えないと境界が曖昧になる問題は避けられないだろ。
0787デフォルトの名無しさん2010/06/20(日) 00:55:29
×ロケールの話だと日本ならWindowsはsjisだし

WindowsはUTF16。ただし9x系は各国ごとに違った文字コードで、
日本語版ならSJISだった。今のWindowsも9x系用のアプリを動かせるように
互換性機能がありUTF16に対応していない古いアプリを、
どの国の文字コードとして扱うかを設定切り替えられる。
もちろん日本語版はデフォルトでSJIS
0788デフォルトの名無しさん2010/06/20(日) 00:59:07
Macは基本UTF-8なんじゃないの
0789デフォルトの名無しさん2010/06/20(日) 01:01:00
>>786
昔のライブラリは文字列はcharであらわしているから。

> wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
型が変わってる。それじゃ互換性が保たれない。
つまりchar使っているアプリ（ライブラリ）すべて見直しが必要になる。
文字列を使う箇所といえばファイル名。ファイルを使うアプリはすべて見直し。
C言語の関数はcharを使っている。これは決まりだから変える事は出来ない。

C言語で作られているLinuxにとって、それは膨大な修正となる。
だからLinuxはunicode対応といえば、UTF8で、
UTF16やUTF32に対応しているものは無い。
0790デフォルトの名無しさん2010/06/20(日) 01:03:17
>>788
ファイルシステムがUTF8なだけで、
OS内部はUTF16
0791デフォルトの名無しさん2010/06/20(日) 01:08:24
>>790
複雑な事やってんだな
0792デフォルトの名無しさん2010/06/20(日) 01:11:45
WindowsNTやMacOS Xははじめからutf-16だもんな。
後からunicode対応した訳じゃなくて。
0793デフォルトの名無しさん2010/06/20(日) 01:15:48
>>791
.NETもそうだけどね。
内部は（Windows前提だから）UTF-16で、入出力はUTF-8が基本。
入出力用のAPIが標準でUTF-8を使うようにしておけば、アプリ側では特に何もしなくていい。
0794デフォルトの名無しさん2010/06/20(日) 01:23:45
サロゲートペアというレアケース以外固定長なUTF-16を使った方が
処理が早くなるとかあるんだろうか
0795デフォルトの名無しさん2010/06/20(日) 02:21:07
>>794
時代的な問題だよ。

当時は16bitで世界中の文字を
あらわせると思われていた。

wchar_t もそのころの名残だろう。
まさか可変長バイト文字（UTF8およびサロゲートペア）を
使わないとすべての文字が表せない。
wchar_t（16bit）が使い物にならなあい時代になるとはな。
0796デフォルトの名無しさん2010/06/20(日) 02:34:39
規格上は wchar_t の表現ビット数の上限 == 16bit というわけじゃないけどね
実際 gcc とか sizeof(wchar_t) == 4 だったりするし
wchar_t 導入時（規格になる前）は
16bit 決め打ちだったのかもしれないけど（当時の事は知らないので何とも言えない）
0797デフォルトの名無しさん2010/06/20(日) 02:54:05
>>787
だから、それがロケールに当たるものなんじゃないの？

>>789
実際のところ、utf-16にしないことでどれくらい、修正の手間が減るんだ？
修正が必要かどうかを判断するプロセスも含めて。

バグは見つかってから対応すればいいって考え方だったら結構手間が減りそうだけど、
はじめからある程度バグとったものを、と考えるとどうせ見直す範囲は多くなると思うぞ。
0798デフォルトの名無しさん2010/06/20(日) 02:59:37
>>795
1文字、という考え方だとサロゲートペアやらUTF-32ですら微妙。
0799デフォルトの名無しさん2010/06/20(日) 03:03:30
>>797
ASCII → UTF-16 文字列を扱う全ての関数に修正が必要。
ASCII → UTF-8　ほとんどの関数は手を加える必要がない。
0800デフォルトの名無しさん2010/06/20(日) 07:42:35
>>777
>・相当な理由がない限りはutf-8を使え

お役所様がSJISをお望みの場合が多いです。
0801デフォルトの名無しさん2010/06/20(日) 07:46:26
>>797
こういう、問題が起きたら直せばいいじゃん、とか言ってる奴、
いざ自分に問題が降りかかると延々とｇｄｇｄ言い続けるんだよな。
当然自覚はあるよな？
0802デフォルトの名無しさん2010/06/20(日) 12:31:56
>>799
そんなことは分かってる。が、
> 文字列を扱う全ての関数に修正が必要
charをwchar_tに書き換えるだけで修正できるものも多い

> ほとんどの関数は手を加える必要がない。
手を加える必要がないことを見極める必要がある

その上で、具体的にどれくらいutf-8の方が手間が減るのか、というのを聞いてる。

>>801
>>797はそんなこと言ってないよ。ストレス貯まりすぎで文章が歪んで見えたか。かわいそうに。
0803デフォルトの名無しさん2010/06/20(日) 12:34:35
ストレス貯まりすぎで自分の文章を客観視できなくなっているらしい。放置推奨。
0804デフォルトの名無しさん2010/06/20(日) 13:54:21
>>802
いやね、C言語標準ライブラリだから
変えたらいかんのよ。
これは規格だからね。

printfの第一引数はchar*と決まってるのです。
0805デフォルトの名無しさん2010/06/20(日) 13:56:13
fopenの第一引数もchar*なのです。
そう決まっているのです。
0806デフォルトの名無しさん2010/06/20(日) 14:09:50
wprintfの第一引数はwchar_t *と決まってるのです。
0807デフォルトの名無しさん2010/06/20(日) 14:11:58
そこで最後の結論が出るわけさ。
wprintfなんてのは誰も使っていません。
0808デフォルトの名無しさん2010/06/20(日) 14:14:25
ま、printf とかを使ってたら _tprintf に置き換えなきゃいけないから、「charをwchar_tに書き換えるだけ」とは言えないか。
コンパイラで型エラーになるから直しやすくはあるけど。
0809デフォルトの名無しさん2010/06/20(日) 14:15:31
使ってないのなら、世の中のすべての
printfをwprintfにすればいいじゃない。
fopenをwfopenにすればいいじゃない。

wfopenという関数が世の中に無いなら
作ればいいじゃない。

互換性なんてすてればいいじゃない！
0810デフォルトの名無しさん2010/06/20(日) 14:16:47
>>808
_で始まる関数は、標準じゃないので
使わないでください。
0811デフォルトの名無しさん2010/06/20(日) 14:21:18
ここまでいえば理解できただろ？

charに問題なく代入できて、
問題なく処理できるように考えて作られたUTF8と

wchar_tに変えたところで16bitの可能性があるから
UTF16やUTF32を代入できるとは限らない。
じゃあどうしろと？という互換性の差を
0812デフォルトの名無しさん2010/06/20(日) 14:31:14
みんなGo言語使おうぜ！
0813デフォルトの名無しさん2010/06/20(日) 14:46:43
>>802
タダじゃ修正できませんのよ？
タダじゃテストできませんのよ？
タダじゃ見極められませんのよ？
ANSI Cの制定の時の苦労話とか読んでみ？
0814デフォルトの名無しさん2010/06/20(日) 17:29:20
新しい常用漢字表が、採用されて数年経てば、Unicodeで、保存するようになるんじゃね？
役所がSJIS2004を調達基準にすれば、Windowsでも対応するかもしれないけど。
0815デフォルトの名無しさん2010/06/20(日) 17:46:44
>>783
リトルエンディアンで半角英数をUNICODE化すると1バイト目が
0816デフォルトの名無しさん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
0817デフォルトの名無しさん2010/06/20(日) 18:40:01
>>802

簡単にcharをwchar_tに書き換えると言うけど、gccなんか未だに
wchar_tに対応できてない部分が多数あるんだぞ。
0818デフォルトの名無しさん2010/06/20(日) 18:49:06
>>803
もし>>797が>>801のように言ってるなら>>799はなんのために答えたんだー
>>807
誰もってことはないだろーなー
>>811
utf16なら問題ないんだろー
>>813
だからこそ、具体的にどれくらいかを聞いてるのに、何をするとか、誰が使ってるとかの話ばっかりで、
手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー
0819デフォルトの名無しさん2010/06/20(日) 21:20:30
sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。
0820デフォルトの名無しさん2010/06/20(日) 21:48:01
> 手間を定量化して

ソースコードの中のcharの数を数えたら？
0821デフォルトの名無しさん2010/06/20(日) 22:12:04
>>820
それだと、できてない。
charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。
大規模なプログラムでは、機械的な変換でどうにでもなるcharからwchar_tへの書き換えよりも、
真に大変なのは、意味的に正しいかどうか判定しなければならない部分。
(例えば、バイト数を数えているのか文字数を数えているのかでstrlenを使うのが適切か不適切かは変わってくる)

そのへんを加味すると、utf-8とutf-16のコスト差は、圧倒的ではなくなる可能性がある。
utf-8の方が多少はマシだとは思ってるが、圧倒的に楽だとはとても思えない。
0822デフォルトの名無しさん2010/06/20(日) 22:19:23
Qt
0823デフォルトの名無しさん2010/06/20(日) 22:19:42
>>819
レッテル貼りに走るのは、文字の読めない人のすることだ。

> てか、CなんかよりC++を使え。
なんでそういうバカなこと言っちゃうかなぁ。
万人に取って、すべてのソフトウェアに取って、CよりC++の方が適してるなんて限らないんだから。
無駄に選択肢狭めることを、人に押し付けちゃいかんよ。
0824デフォルトの名無しさん2010/06/20(日) 22:23:14
やっぱり単なる馬鹿でした。
0825デフォルトの名無しさん2010/06/20(日) 22:40:08
双方が馬鹿馬鹿言ってるから手に負えない
0826デフォルトの名無しさん2010/06/20(日) 22:45:26
このスレ、ひとつの方法しか認めたがらない人多いの?
0827デフォルトの名無しさん2010/06/20(日) 22:58:13
全部包摂したくなるのさ
0828デフォルトの名無しさん2010/06/20(日) 23:26:39
>>821
> charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。

UTF8でもUTF16でもUTF32でも、同じようにかかるコストは比較しても、
”同じ” になるので、ここで取り上げる必要は無いんじゃないですかぁ？

それ以外のコストの話をしましょうよ。ﾆﾔﾆﾔ
0829デフォルトの名無しさん2010/06/20(日) 23:28:51
>>821
strlenぐらいなのと、
すべて書き換えないといけないのと
比べるまでも無いだろ。アホｗ

物事ってのは少しずつ変えていくもんだ。
一気に全部変えたらどうなるか予想ぐらいつくだろ。
0830デフォルトの名無しさん2010/06/21(月) 00:44:14
>>818
>手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー

中学生の脳内じゃないんだから、それにだって金も手間もかかるんだよ。
0831デフォルトの名無しさん2010/06/21(月) 07:25:53
そもそも utf-8だと日本語文字が1.5倍の容量を食うから
sjis それでなければwcharって主張がこの流れになってるんだろ？

だったら　gccでwcharは4バイトって話が出た時点で終了だろ
0832デフォルトの名無しさん2010/06/21(月) 08:57:50
sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。
0833デフォルトの名無しさん2010/06/21(月) 09:54:10
>>828
なにいってんだ？
utf16で余分にかかるコストの「割合」の話してるんだぞ？

>>829
>>801

>>830
やらないって選択肢もあるけど、やってもいないことを断定するな。

>>831
sjisの話とは別だろ。
0834デフォルトの名無しさん2010/06/21(月) 11:55:57

それ以外のコストの話をしましょうよ。ﾆﾔﾆﾔ
0835デフォルトの名無しさん2010/06/21(月) 12:04:20
放置推奨。
0836デフォルトの名無しさん2010/06/21(月) 12:24:10
>>833
なんでやってないと思うんだろう。
普通やるだろサラリーマンなら。
0837デフォルトの名無しさん2010/06/21(月) 12:51:31
おまいらスレ伸ばしすぎ
0838デフォルトの名無しさん2010/06/21(月) 13:07:07
本人たちが楽しそうならそれでいいじゃないか。
0839デフォルトの名無しさん2010/06/21(月) 16:09:19
よっぽどネタが無いんだな。
0840デフォルトの名無しさん2010/06/21(月) 23:58:09
>>836
なのに、実際にやったって話が出てこないんだぜ。
0841デフォルトの名無しさん2010/06/22(火) 13:37:07
やった人は反対意見の方にまわるからさ
0842デフォルトの名無しさん2010/06/22(火) 19:22:02
>>841
反対意見出す側にも、やったけど全然違った、と言ってる人はいないよ。
0843デフォルトの名無しさん2010/06/22(火) 19:26:18
端から見てるともはや何を言い争ってるのか分からんレベル
他所ん家の夫婦喧嘩見てるみたいだ
0844デフォルトの名無しさん2010/06/22(火) 19:49:45
それだけ仲がいいってことさ
0845デフォルトの名無しさん2010/06/22(火) 19:57:23
>>842
やったけどぜんぜん大変だよ。


というと次はソースを要求するのが中学生。
しかしコストかけたものをただで出すバカはいない。
0846デフォルトの名無しさん2010/06/22(火) 22:19:59
>>845
んなもん、仕事で測定したデータを詳細に2chで晒せなんて思っとらんわ。

動作確認コストの大きさが、大分前から理由として挙げられてるのに、
utf8が圧倒的楽って言ってるレスではその大きさについて触れようともしてないよね。
実際にやってみたなら、そのコストが大きいことは容易に分かるはずなのに。
0847デフォルトの名無しさん2010/06/22(火) 23:07:12
utf8が圧倒的に楽というのはな、
utf8の文字列を普通のC言語関数に渡したら
普通に処理してくれることで十分理解できるよ。

普通のC言語関数が使えなくなるのと
普通のC言語関数が使えることの差は
改めていうまでのこともない。
0848デフォルトの名無しさん2010/06/23(水) 01:46:25
>>847
まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は？
関数が動作することと、そこでその関数を使用することの妥当性の確認は全然違うことも分かってるよね？

その説明は「圧倒的に」楽である説明にはなってない。
0849__STDC_ISO_10646__2010/06/23(水) 02:26:47
「wchar_tは俺の嫁。俺の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」
0850デフォルトの名無しさん2010/06/23(水) 02:26:54
> まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は？
なんのことを言っているの？

たとえば、printfという関数。
これはよく使われている関数だよね。

これが使えなくなったら、大損害。
これはわかるよね？
0851デフォルトの名無しさん2010/06/23(水) 07:39:16
２バイト以上の文字が表示できるとは限らんぞ
0852デフォルトの名無しさん2010/06/23(水) 08:35:23
それは関数の問題？
外形から容易に想像できる機能の見積もりなんか楽なもんだ。
0853デフォルトの名無しさん2010/06/23(水) 08:54:57
>>850
そんなprintfをwprintfに機械的に置換すりゃ済むことを大損害って言ってたの？
0854デフォルトの名無しさん2010/06/23(水) 12:08:23
>>853
釣り？
無条件に置き換えられたら動かなくなるだろ。
ニートと素人は黙っててほしい。
0855デフォルトの名無しさん2010/06/23(水) 12:55:58
本当に毎日楽しいスレだな
0856デフォルトの名無しさん2010/06/23(水) 18:47:37
まるでSJIS用のprintfをそのままUTF-8でも使えるかのような勢いだな
0857デフォルトの名無しさん2010/06/23(水) 20:59:03
sjis用のprintfって何？

printfに渡すのは char *であって、sjisとかutf-8 とか別け隔て
しない良い子だよ
0858デフォルトの名無しさん2010/06/23(水) 21:06:27
printf が特別扱いするのは % だけで、 \ はスルーだし。
0859デフォルトの名無しさん2010/06/23(水) 22:52:06
>>857
（　ﾟдﾟ）ﾎﾟｶｰﾝ
0860デフォルトの名無しさん2010/06/23(水) 23:01:19
>>857
いいか
UTF-8の大きな特長ってのは
従来の検索関数が「実装を全く変更しなくても」そのまま使えると言う事だ
printfは実装の変更が必要になる例だ
0861デフォルトの名無しさん2010/06/23(水) 23:07:08
>>860
どんな変更が必要？
0862デフォルトの名無しさん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に変更してください。
と頼むのは現実的ではない。かといってディストリビューターがパッチとして提供するには
量が多すぎる。
0863デフォルトの名無しさん2010/06/24(木) 00:00:16
>>862
それはUTF-8以外の場合は、printfの実装に変更が必要ってことだろ？
UTF-8の場合はprintfの実装は変更しなくても動くよ。
08648622010/06/24(木) 00:01:18
>>863
そういう話をしたつもりだけど・・・
0865デフォルトの名無しさん2010/06/24(木) 00:01:18
>>862
そんなことは聞いていません。
printf を UTF-8 に対応させるのに必要となる「実装の変更」を聞いています。
0866デフォルトの名無しさん2010/06/24(木) 00:02:46
UTF-8はcharでいいだろう常考
0867デフォルトの名無しさん2010/06/24(木) 00:03:05
glibcにwprintf()は入っているしprintf()は%lsを受け付けるのだから
ライブラリを修正する必要なんかどこにも無いだろ
0868デフォルトの名無しさん2010/06/24(木) 00:04:53
>>865
SJISは２バイト目に\がある場合があるので、
エスケープシーケンスと誤認しないようにチェックが必要
そのチェックが入ったコードはUTF-8では使えない
0869デフォルトの名無しさん2010/06/24(木) 00:05:33
printf は \ を特別扱いしないんだってば。
0870デフォルトの名無しさん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でさえ
型の変更が必要になってしまっている。
08718672010/06/24(木) 00:07:37
wchar_tを使いたいなら、れっきとした標準であるC95で導入された
wchar_t用の関数を使えばよい、もう15年も前の標準だ

localeに応じてwchar_tへ変換したり、wchar_tでファイルを読み書きするための
関数もC標準には用意されている
UTF-8に変換する関数などというものは標準には無いがな
0872デフォルトの名無しさん2010/06/24(木) 00:08:01
>>865 コンパイラ（およびプリプロセッサ）のやることと、ライブラリのやることを混同してるだろ。
0873デフォルトの名無しさん2010/06/24(木) 00:09:13
>>871
規格にあるからといってまともな実装があるとは限らないのだがな・・・
0874デフォルトの名無しさん2010/06/24(木) 00:09:16
アンカを訂正
>>868 コンパイラ（およびプリプロセッサ）のやることと、ライブラリのやることを混同してるだろ。
0875デフォルトの名無しさん2010/06/24(木) 00:10:04
>>869
じゃあどうしてるんだ
0876デフォルトの名無しさん2010/06/24(木) 00:11:02
>>868
> SJISは２バイト目に\がある場合があるので、
> エスケープシーケンスと誤認しないようにチェックが必要

UTF16、UTF32は2バイト目、3バイト目、4バイト目に
\0が、よく使われる英数文字に入るので、今のコードは使えない。

もし、printf((char*)"Hello World") （Hello WorldはUTF16）
なんてことをすると、Hしか表示されない（エンディアンによっては何も表示されない）
0877デフォルトの名無しさん2010/06/24(木) 00:12:24
>>876
今はUTF-8の話してるんだから邪魔しないでくれ
0878デフォルトの名無しさん2010/06/24(木) 00:13:35
>>871
> wchar_t用の関数を使えばよい、もう15年も前の標準だ

そこで俺が止めを刺してやろう。
wchar_tを使うfopenの代わりになる標準関数は無い。

つまりUTF8以外のUNICODEのファイル名は
オープンできませんｗ

だいたい、wchar_t用の関数を使ってないコードが
たくさんあるから、大問題って話だろうが。
みんなprintf使ってるよ？ 知らないの？
0879デフォルトの名無しさん2010/06/24(木) 00:14:16
>>875
エスケープシーケンスはコンパイル時に解決されるので
printfは解析しない
0880デフォルトの名無しさん2010/06/24(木) 00:15:19
ならprintfに変更すべき点はないのか・・・
0881デフォルトの名無しさん2010/06/24(木) 00:16:26
>>878
一体何が「とどめ」なんだ？

Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
char*で扱えばよいだけだ
何でもかんでもwchar_tにしろとは誰も言っていない

もしwchar_tで保持されているテキストをファイル名として扱いたいときは、
wcstombs()などで変換すればよいだけだろ
0882デフォルトの名無しさん2010/06/24(木) 00:16:37
本当に毎日楽しいスレだな
0883デフォルトの名無しさん2010/06/24(木) 00:16:59
>>875
じゃあどうしてるんだって？
そんなもんコンパイラがSJISで書かれたコードだと判断したら、
SJIS用に2バイト目に\がある場合の処理をちゃんとするだけだろ。

ここまでがコンパイラの仕事。

0884デフォルトの名無しさん2010/06/24(木) 00:17:12
printf()には%lsでwchar_t文字列を食わせられるだろうに
0885デフォルトの名無しさん2010/06/24(木) 00:18:42
>>881
> Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
> char*で扱えばよいだけだ

ただのバイト列じゃないよ。\0で終わるバイト列。
UTF16やUTF32は文字に\0が含まれるため、
ファイル名が途中で切れることになる。

つまりchar*でUTF16、UTF32はどうやっても扱えない。
UNICODE系はUTF8だけがchar*で扱える。
0886デフォルトの名無しさん2010/06/24(木) 00:19:08
wchar_t使ってんのは実質Windowsだけだろ。
0887デフォルトの名無しさん2010/06/24(木) 00:20:09
>>885
wcstombs使えばいいで答えが出てる
0888デフォルトの名無しさん2010/06/24(木) 00:21:30
>>878
utf-8でエンコードしたファイル名を受け付けるかどうかは処理系依存だがな。
0889デフォルトの名無しさん2010/06/24(木) 00:22:28
>>887
じゃあwcstombs使ってファイルオープンするコード書いてみｗ
0890デフォルトの名無しさん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
0891デフォルトの名無しさん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がだめだって話の流れ。
0892デフォルトの名無しさん2010/06/24(木) 00:28:21
（しばしばゼロ終端された）バイト列を扱うコンテキストにはUTF-16やUTF-32は
向かない
ファイル名や入出力などだ

が、プログラムのメモリ上で扱う内部エンコーディングとしては何の問題もないよ
特にUTF-8と16, 32はただの表現形式の違いに過ぎないのだから
容易にかつ無問題に相互に変換できる
0893デフォルトの名無しさん2010/06/24(木) 00:37:34
自分のアプリだけで完結するのなら
文字コードは好きにしろって話だけど、
ま、普通は既存のライブラリを使う。
そして既存のライブラリの多くはchar*が使われている。

これを変更するとなると影響範囲が大きすぎる。
そこで作り出されたのがUTF-8。UTF-8を使っていれば、
外部のライブラリからはまるでASCIIで渡されたような感じで処理できる。
これが互換性。

ファイル名や入出力だけでなく、
外部のライブラリを使う場合もUTF-8が優れている。
もしすべてをUTF16とかに変えようとすると、多大なコストがかかることになる。
0894デフォルトの名無しさん2010/06/24(木) 00:54:47
今日になって1時間足らずで30も伸びていてマジ驚愕
0895デフォルトの名無しさん2010/06/24(木) 06:13:31
printfスレでやれ
0896デフォルトの名無しさん2010/06/24(木) 07:19:02
誰が誰と何を争ってるのか全くわからん。
0897デフォルトの名無しさん2010/06/24(木) 07:48:55
>>860

だすらprintfは、sjisだろうがutf-8だろうが関係なくてchar *を
淡々と扱うだけで、sjis用printf だのutf-8用printfなんてのは
ない。　だからsjis用printfって何？って問うたんだよ。
0898デフォルトの名無しさん2010/06/24(木) 07:51:52
>>871

そのlocaleとwchar_tに関してgccなどは地雷を抱えてたりするわけだが
0899デフォルトの名無しさん2010/06/24(木) 07:53:19
文字コードと直接関係ないんだからC言語のスレでやれよ。
0900デフォルトの名無しさん2010/06/24(木) 09:57:57
>>891
つけられたってしょうがないだろ。
無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
今までのソフトウェア資産を捨てるか改造して、全部UTF-8にするってのなら別だけど。
0901デフォルトの名無しさん2010/06/24(木) 11:13:45
>>900

それはUTF-16だって同じ事だろ。

ASCII前提の処理系でASCIIで名前を付けたファイル名を扱うプログラムを
そのまんま、UTF-8前提の処理系でUTF-8のファイル名を扱うプログラム
として使用できる（ごくわずかな修正で）って話なんだから。
0902デフォルトの名無しさん2010/06/24(木) 13:48:19
晴れてるけど土砂降り
0903デフォルトの名無しさん2010/06/24(木) 14:02:40
このスレの情景か
0904デフォルトの名無しさん2010/06/24(木) 15:01:51
C++は第一引数にwchar_tを使えるfopenあるよ～
0905デフォルトの名無しさん2010/06/24(木) 20:58:01
>>901
勝手に処理系を仮定されてもなぁ。
0906デフォルトの名無しさん2010/06/24(木) 22:01:43
勝手に処理系を仮定って言うけど、
EUCも同じだろ。　あとはEBCDIC とかEBCDIKとかかw
0907デフォルトの名無しさん2010/06/24(木) 22:59:08
>>906
別にEUCじゃなくても文字化けするよ。
>>891が
>EUC-JP対応なら当然8bitで処理しているので、
>何の問題も無く、UTF-8のファイル名をつけつけられる。
なんて面白いこと書いてたから。
0908デフォルトの名無しさん2010/06/24(木) 23:10:22
UTF-8を引き摺りおろそうとする気持ちはわかるが
UTF-16の方がもっとひどいという事実は変わらないよｗ
0909デフォルトの名無しさん2010/06/24(木) 23:17:22
>>900
> 無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
うん。文字化けに見えるよね？
人間としては正しいよそれは。

だけどね、バイナリとしてはどちらも同じなんだ。

文字化けというものは二種類ある。
一つは、化けてしまったら、元に戻せない文字化け。
もう一つは、化けても、元に戻せる文字化け
（ブラウザとか。エンコード切り替えするだけでちゃんと表示できる）

化けても元に戻せる文字化けというのは、処理の段階で文字化けは発生してないんだよ。
単に表示する段階で違う文字で表示されているだけ。データとしては一緒。
ようするにASCIIを扱う関数にUTF-8を渡しても正しく処理してくれる。ま、ごくわずかの例外はあるが。
例外というほど、少ない事例。そしてUTF-16をASCIIを扱う関数に渡したらほぼすべて動作しない。
0910デフォルトの名無しさん2010/06/25(金) 10:40:08
>>908
別に誰も引きずり下ろそうとしてないよ。

>>909
fopenにおいては、それじゃダメだろ。そしてremoveもrenameも例外か。
標準ライブラリ関数は例外か例外でないかのリスト用意すれば見分けが着くが、
人が作った関数はリストなんて作ってられないからなぁ。いちいち中身みないと。

そのまま渡したら動作しないことには誰も反論してないのに、なんでそれをまた主張するかなぁ。
0911デフォルトの名無しさん2010/06/25(金) 15:20:38
プログラムの側で実行環境のlocaleは仮定しちゃだめだし、仮定できないだろ
localeがUTF-8なら上手く動きますよ、じゃダメ

（大した内容でなくとも）なんらかのテキスト処理をするプログラムは
事実上エンコーディング変換は必須だろ
8bitクリーンにしとけばいいなんてのは、バイト列をそのまま右から左に
流せばすむプログラムだけだ
0912デフォルトの名無しさん2010/06/25(金) 22:34:45
>>910
なんか勘違いしてない？

fopenにUTF-8の文字コードのファイル名を渡したら
正常に処理されるよ。

実際にfopen使ってコード書いて、
UTF-8のエンコードに設定してある
Linuxで動かせばわかるじゃん。
0913デフォルトの名無しさん2010/06/25(金) 22:52:10
fopenにUTF-16のファイル名を与えたら・・・・
型が違うから与えられないけどなｗ
UTF16は互換性が無い。
0914デフォルトの名無しさん2010/06/25(金) 23:41:37
>>913
お前は前々から誰と戦ってんだ。
UTF-16がマルチバイト系のエンコーディングと互換性がないのを理解していない奴なんて誰一人いないじゃないか。
0915デフォルトの名無しさん2010/06/26(土) 00:13:50
> お前は前々から誰と戦ってんだ。
wchar_t野郎ｗ
0916デフォルトの名無しさん2010/06/26(土) 00:52:25
文字コード方面は処理系ごとで違いがありすぎるからな。
wchar_tもwindowsではutf-16だかucs-2だか、glibcではutf-32だかucs-4だか、
それ以外じゃ下手すると非透過で>>849みたいな話になるし。
ファイル名とか言い出し始めるとOS/実行環境にも依存するべ。
現実的には標準関数のレベルで汎用的にはしよーとしないのが吉じゃね、本気でやるなら。
使い捨てのコードなら用が足りる程度に動きゃ何でもいい。
0917デフォルトの名無しさん2010/06/26(土) 02:26:01
>>912
何も勘違いしてない。君が混乱してるんじゃないのかい？
utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？

みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
そうじゃないことも分かってるんだよね？
0918デフォルトの名無しさん2010/06/26(土) 08:17:32
Subversionスレから導かれて来ました。
git,Mercurialで日本語だとsjis,utf-8混在環境は簡単に出来ちゃうわけで。
日本以外でも、latin-1やロシア東欧のコードとutf-8の混在が問題になっているわけで。
sjis,euc混在という先輩でもある日本としては、パス名として厄介な'/','\'が含まれず、
無効の判断が容易なutf-8が現時点での妥協点では無いでしょうか？
Linuxでは、ロケールutf-8じゃないと動かないアプリが多くなってきましたし。
0919デフォルトの名無しさん2010/06/26(土) 09:11:14
誰だ召喚したのは
0920デフォルトの名無しさん2010/06/26(土) 11:02:38
>>918
他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」って主張は受け入れる気にはなれないけど。

いきなりなんでそんな話を？
0921デフォルトの名無しさん2010/06/26(土) 11:02:53
>>917
> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？
どうなると思ってるんだ？
0922デフォルトの名無しさん2010/06/26(土) 11:05:49
utf8なバイトってのもよくわからんな。

16進数で考えれば、UTF8もそれ以外も
0x00～0xFFのバイトの並びでしかないだろ。
0923デフォルトの名無しさん2010/06/26(土) 11:21:07
>>922
latin1ならその考えでいい。utf8はそれなりに考えられて作られている。
0924デフォルトの名無しさん2010/06/26(土) 11:36:57
> utf8はそれなりに考えられて作られている。
その中身を言えって。お前何も言って無いじゃん。
0925デフォルトの名無しさん2010/06/26(土) 11:37:04
>>920
> いきなりなんでそんな話を？
・ファイル名がunicodeというのはマルチプラットフォームでないということ
・そういえば、Javaってどうだったけ
・cygwin utf-8という曲者も出てきた
0926デフォルトの名無しさん2010/06/26(土) 11:38:27
> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？
重要なことだからもう一度言います。

どうなると思ってるんだ？（笑）
0927デフォルトの名無しさん2010/06/26(土) 11:43:30
>>917
俺は>>912ではないが
lsなどで表示したらそのファイルは文字化けして見えるだろうが、
それでfopen()では何の問題も無く開ける

あくまでそのロケールで「テキストとして解釈できない」だけだ
fopen()のような関数は名前をテキストではなく単にゼロ終端されたバイト列として
扱うので、テキストとして解釈できないことは何も問題ではない

0928デフォルトの名無しさん2010/06/26(土) 11:47:48
一方、Javaあたりだと、ファイル名をテキスト(String)として扱うので、
そのファイルを開けないと思う
0929デフォルトの名無しさん2010/06/26(土) 12:00:09
それがUTF16やUTF32だと文字の一部にゼロが含まれるので
ゼロ終端されたバイト列として解釈できないんだよね。

だからLinuxはUTF8のロケールには対応しても
UTF16等には対応していない。LinuxはC言語をベースに作られているので
対応しようとなると大幅な変更が必要になる。
0930デフォルトの名無しさん2010/06/26(土) 12:02:20
localeをUTF16化しろとは誰も言っていないんじゃないの
UTF16や32は、基本的にプログラムの内部で（ワイド文字で）使うための
エンコーディングでしょ
0931デフォルトの名無しさん2010/06/26(土) 12:08:27
そんな話だっけ？
UTF16に簡単に変更できるとか言う話じゃなかったか？
09329172010/06/26(土) 14:26:02
>>927
そのとおり。

そして>>917の後ろにも
> みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> そうじゃないことも分かってるんだよね？

って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
(それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)
0933デフォルトの名無しさん2010/06/26(土) 14:26:50
>>931
そんなこと誰が言った？
0934デフォルトの名無しさん2010/06/26(土) 14:46:56
一体UTF8の人は誰と戦ってたんだろうって思ってたが、ようやく疑問がとけた。
UTF8の人はUTF8にするのに、本当に何も手間がいらないと思い込んでいる。

そして、それはコンパイル通ってアプリケーションが落ちなければ、文字化けしてもどうなっても構わない、
という観点でいうのなら、正しい。


UTF16持ち出してきた人はUTF8にするにしても、文字化けしないなどの動作としての正しさを検証するためには
どうせソースをひっくり返して読まなければならず、それをする手間はあまりに多いので、
ついでにcharをwchar_tに、printfをwprintfにするくらい大したことじゃないと考えている。
そしてUTF8なら変更不要って、検証コストはどこにいった、それを評価した上で言ってるのか？と言っている。

wchar_tへの変更がついでにできてしまうほどに検証が大変だというのは大げさだろうが、
検証コストの大きさが無視できないのは確かだろう。
実際に、UTF8の人が勿体つけて出してきた「fopenはchar*しかうけつけない」というのも、
そのまんま渡すと文字化けする代物だったし。
0935デフォルトの名無しさん2010/06/26(土) 14:52:05
つまり、結局のところ、UTF8 vs UTF16って構造は間違いで、
UTF8だと手間なし派 vs UTF8でも手間はかかる派　　なわけだ。にもかかわらず

UTF8でも手間はかかる派：　UTF8でかかる手間を指摘
UTF8だと手間なし派：　UTF16でかかる手間を指摘
してるから、手間なし派は見えない敵と戦ってるようになってしまってる。
0936デフォルトの名無しさん2010/06/26(土) 14:52:06
>>932
> >>927
> そのとおり。
>
> そして>>917の後ろにも
> > みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> > そうじゃないことも分かってるんだよね？
>
> って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
> そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
> (それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)

IMAP UTF-7 ってのがあってだね・・・
0937デフォルトの名無しさん2010/06/26(土) 14:54:25
>>935
あー、だからお前はあんなこといってたのねｗ
今やっとお前がずれていることがわかったわ。
0938デフォルトの名無しさん2010/06/26(土) 14:56:47
UTF8が文字化けするというのはあくまで表示の話で、
処理の内容は何も変わっちゃいないというのが
理解できてないんだから笑っちゃう。

fopenが何一つ修正なしに、UTF8の文字のファイル名を
受け取れるということが、理解できないようだね。
0939デフォルトの名無しさん2010/06/26(土) 15:25:43
極端な話、fopenの中で動くファイルシステムのコードが正規化を考慮するかって話の時に
知るか馬鹿って側と気になってしょーがねえって側の戦いみたいな。
あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか？
0940デフォルトの名無しさん2010/06/26(土) 15:48:17
>>939
不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
Windowsの場合、fopen_s, _wfopen_s という２つの関数がある。
0941デフォルトの名無しさん2010/06/26(土) 15:48:30
> あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか？
やっぱり理解してないね。

fopenが期待しているのは、
ゼロ終端されたバイト列。
文字コードは考慮していない。
0942デフォルトの名無しさん2010/06/26(土) 16:10:56
>>940
> >>939
> 不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
> Windowsの場合、fopen_s, _wfopen_s という２つの関数がある。
fopen自体はダメ文字は関係ないのか？
0943デフォルトの名無しさん2010/06/26(土) 16:13:30
>>937
匿名掲示板でお前って誰だww
0944デフォルトの名無しさん2010/06/26(土) 16:16:25
>>938
どのレスがそれ理解できてない人？

>>941
その通りで、君が言っていることは
fopenの第2引数が期待してるのがゼロ終端されたバイト列であって、
別にrとかwとかである必要がない、と言ってるのと同じくらい正しい。
0945デフォルトの名無しさん2010/06/26(土) 16:18:12
fopenの第一引数の間違いだろ。アホめ
0946デフォルトの名無しさん2010/06/26(土) 16:19:34
泥沼化したこの闘いに終わりはあるのか
0947デフォルトの名無しさん2010/06/26(土) 16:19:53
>>941
実装が余計な事しないのを保証する規格にもなってないんじゃね？
正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。
0948デフォルトの名無しさん2010/06/26(土) 16:21:32
> 正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。
何の話してるの？

fopenでゲタになんかならないけど。
0949デフォルトの名無しさん2010/06/26(土) 16:22:44
そもそも勝手にゲタになってしまったら、
違うファイル名（もとからゲタになっているファイル名）
を開いてしまうことになるぞｗ
0950デフォルトの名無しさん2010/06/26(土) 16:23:41
>>945
そだね。>>941は第一引数に限定してないよね。
0951デフォルトの名無しさん2010/06/26(土) 16:24:58
なんか文字の1と、数値の1の違いを
理解していない奴を相手にしているような気がしてきたｗ

fopenの中の人がsjis期待してるとか
意味不明すぎで、こいつが何を考えているのかわからん。
0952デフォルトの名無しさん2010/06/26(土) 16:25:30
いやあ、保証があるかの話で具体例は知らんのだけど。
>>949がありえない話なのだろうか？という疑問
0953デフォルトの名無しさん2010/06/26(土) 16:26:01
「ゼロ終端されたバイト列」の説明が必要では？
0954デフォルトの名無しさん2010/06/26(土) 16:27:35
>>952
それは、幽霊肯定派が、幽霊は本当にいないのだろうか？って言っているようなもんだな。

幽霊がいるというのなら、幽霊がいるという証拠をもってこい。
ありえないといいたいのなら、ありえない証拠をもってこい。
0955デフォルトの名無しさん2010/06/26(土) 16:28:33
>>953
え？説明されんとわからんのか？

だから話が通じないのかｗ
0956デフォルトの名無しさん2010/06/26(土) 16:32:00
>>951
fopenのプロトタイプはsjis期待してないけど、中の実装は期待してる。

Windows環境(パスの区切り文字は0x5c)を仮定するとだな。
ファイル"\x61\x5c\x61"は、ディレクトリ./a上のファイルaと解釈されるが、
ファイル"\x95\x5c\x62"は、ディレクトリ./上のファイル表aと解釈される。
0957デフォルトの名無しさん2010/06/26(土) 16:46:31
つまり文字コード厄介だからおまえらナメてかかるんじゃないぞという理解でよろしいか？
0958デフォルトの名無しさん2010/06/26(土) 16:49:34
>>957
うん。あるいはutf-8にすれば全てが嘘のようにうまくいく。どっちか信じたい方。
0959デフォルトの名無しさん2010/06/26(土) 17:01:09
SJIS, Windowsの話は出てきたけど、UTF-8-MACは？
0960デフォルトの名無しさん2010/06/26(土) 17:01:40
MACてなに
0961デフォルトの名無しさん2010/06/26(土) 17:05:45
>>956
だがな。UTF8はその0x5Cを
二バイト以降に配置しないようにしているから、
何の問題も無いんだよ。

互換性問題を解決した文字コード。
fopenを何の問題も無く使える。
0962デフォルトの名無しさん2010/06/26(土) 17:06:40
全てが嘘のようにうまくいくように
考えて作られたUTF8で
全てが嘘のようにうまくいくのは当たり前。
0963デフォルトの名無しさん2010/06/26(土) 17:09:55
LinuxってSJISに対応していないんだな。
ASCII互換ではないかららしい。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=10&topic=17296

逆に言えばASCII互換なら全て問題が解決する。
ということでUTF8が選ばれた。
0964デフォルトの名無しさん2010/06/26(土) 17:14:44
Sambaはutf8にしても安全になったの？
0965デフォルトの名無しさん2010/06/26(土) 17:15:19
>>956
それは、Windowsが特別にそういう実装になっているだけだな。
SJISはMSが作ったのだから、そういう変則的なことに対応していても不思議は無い。

だが、一般的なfopenではそんな実装をするとは決まってないし、
実際に実装されてない。ASCII互換でないものをもってきても
ASCII互換であるUTF8の例えにはならない。
0966デフォルトの名無しさん2010/06/26(土) 17:32:04
というかSJISで開くべきならSJIS使いなさい、
UTF-8で開くべきならUTF-8使いなさい以上の話ではないなという。
0967デフォルトの名無しさん2010/06/26(土) 17:45:31
UTF8の互換性の高さの話だろ。
なにも修正しないでも多くの関数でそのまま使える。
0968デフォルトの名無しさん2010/06/26(土) 17:56:23
>>961
でも0x95が2バイト目以降に来る場合はあるでしょ？
そしたら、その次の0x5cはバックスラッシュを意図しているはずだけど、そう解釈されない場合が出てくる。

>>965
特殊実装扱いにするにはメジャーすぎるよ。
けどそういうのはどうでもよくて、もともと>>956出したのは、
sjisを要求するfopenが存在しないかのように書いた人がいたからなんだけどね。

そして、sjis程度のascii非互換性でutf8神話は崩壊するって思っていいんだね。

>>966
全くその通り。それが一番正しいし、ほとんどの人にとってそれが当たり前。
0969デフォルトの名無しさん2010/06/26(土) 18:06:25
>>968
> でも0x95が2バイト目以降に来る場合はあるでしょ？
ASCII互換のUTF8は無い
そうならないように作られた。
0970デフォルトの名無しさん2010/06/26(土) 18:26:52
>>969
ﾑﾁｬｲｳﾅ
0971デフォルトの名無しさん2010/06/26(土) 18:30:25
ツッコミどころがおかしいんだよ！
SJIS期待してるとこにUTF-8でしかもASCII外の文字食わして何する気だってとこなんだよ！
だから>>966で解決なんだよ！
0972デフォルトの名無しさん2010/06/26(土) 18:40:04
色々な論点がごっちゃになっとるなあ
プログラムの内部エンコーディングと外側でユーザが設定するロケールは
別物だろうし…

UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
ユーザに、UTF-8ロケールにしてファイルも何もかもUTF-8にしなさい
そうでなきゃ僕は知りませんと言いたいのか？
0973デフォルトの名無しさん2010/06/26(土) 18:46:20
>>972
Windowsのような特殊環境以外はfopenは文字コード関係なく'\0'で終わったchar*で問題無いって話なんじゃないの？
0974デフォルトの名無しさん2010/06/26(土) 19:15:25
>>973
char*でやろうがwchar_tでやろうが別にかまわないが
エンコーディングの問題からは逃げられんだろ
一般に、localeや処理するテキストファイルの中身がUTF-8だとは限らないのだし
UTF-8だとしてもテキスト処理においてはマルチバイト処理を必要とする
Shift-JISよりはずっと性質のいいエンコーディングではあるが
0975デフォルトの名無しさん2010/06/26(土) 19:21:02
>>974
fopenの話に収斂していたと思うけど、どこから遡ればいいの？
0976デフォルトの名無しさん2010/06/26(土) 19:27:57
fopen()だけ取り出してエンコーディングの問題を論じるのはナンセンスじゃないのか
まあそういう話ならどうでもいいし、特に言うべきことはないが
0977デフォルトの名無しさん2010/06/26(土) 20:35:47
>>971
必死だなｗ

ASCII期待しているLinuxに
UTF8を食わして問題無いんだよ。
互換性だからな。
0978デフォルトの名無しさん2010/06/26(土) 20:46:57
>>974
> >>973
> char*でやろうがwchar_tでやろうが別にかまわないが
wchar_tじゃだめでしょって話で、
ここまでやって例が１つもないから作った。

#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;
}
0979デフォルトの名無しさん2010/06/26(土) 20:52:14
他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」
0980デフォルトの名無しさん2010/06/26(土) 21:05:47
>>978
内部コードをそのままI/Oに使うとは、アホかｗ
内部のテキストをwchar_tで持っている場合、I/Oでは変換するのが普通だし
Unix系のOSでファイル名をわざわざwchar_tで扱う意味も無い
0981デフォルトの名無しさん2010/06/26(土) 21:12:35
その変換が必要ないのがUTF-8なわけだ。
これも互換性の高さゆえだな。
0982デフォルトの名無しさん2010/06/26(土) 21:24:09
変換が必要が無いのは、外部エンコーディングがUTF-8である場合だけだろ
Unixではユーザが任意にlocaleを設定できるのだし
テキストには多様なエンコードが使われている（メールは今でもiso-2022-jpだ）

単にそうなればいいね、便利だね、というだけの話？
実はそこで話がずれてんの？
0983デフォルトの名無しさん2010/06/26(土) 21:30:28
> Unixではユーザが任意にlocaleを設定できるのだし
だから、Unixで指定できるlocaleは
ASCII互換で無ければならないんだよな。

SJISとかUTF16とかUnixは対応していない。
0984デフォルトの名無しさん2010/06/26(土) 21:30:46
>>977
いつからLinux限定の話になったんだ? euc-jpじゃダメなのか?
0985デフォルトの名無しさん2010/06/26(土) 21:33:38
euc-jpもASCII互換だからね。
日本語だけしか扱えないけど。
0986デフォルトの名無しさん2010/06/26(土) 21:35:03
>>983
だから、EUC-JPとかは普通に使えるし、伝統的に使われてただろ
EUC-JPとUTF-8でテキスト処理を書く場合、同じコードにはならない
EUC-JPではリードバイトと後続バイトの区別がつかないから
文字の区切りが知りたければ先頭から舐めるしかないからだ

それにファイルの中のデータとして使われるエンコーディングならもっと範囲が広い
2chは言うまでも無くShift_JISだ
0987デフォルトの名無しさん2010/06/26(土) 21:40:54
>>986
うん、だけど、EUC-JPは2バイト目に0x80以下の文字を含まないから、
たいていの日本語に特に対応していないプログラムでも普通に処理できてしまうわけさ。
これが互換性の高さ。UTF8も同じだよね。

それに引き換えSJISやUTF16は2バイト目に0x80以下の文字を含むから
別途対応が必要。
0988デフォルトの名無しさん2010/06/26(土) 21:49:49
おまいら>>1にマッタリって書いてんだろ
一日でどんだけ伸ばしてんだよ
シバくぞ
0989デフォルトの名無しさん2010/06/26(土) 21:51:03
> たいていの日本語に特に対応していないプログラムでも普通に処理できてしまう
甘い
EUC-JPもUTF-8もバイト数＝文字幅ではないし
半角カナ絡みで問題を起こすプログラムは非常に多かったし
文字を文字として認識しなければ、文字の真ん中で文字列を区切ることも普通に
有り得る

「たいていの」は言い過ぎ
「ほとんどテキスト処理を必要としないプログラム」ぐらいが本当のところだろ
0990デフォルトの名無しさん2010/06/26(土) 21:53:11
実は共通認識が多いんだけど、喧嘩する為にお互いあえて無視しているスメル
そろそろ次スレでつね
0991デフォルトの名無しさん2010/06/26(土) 22:05:11
うめ
0992デフォルトの名無しさん2010/06/26(土) 22:06:18
2chはどうして糞で最悪のSJISを標準エンコードにしたんだろｗ
0993デフォルトの名無しさん2010/06/26(土) 22:07:39
>>989
だが文字がずれる程度でたいていは処理出来てしまう。
0994デフォルトの名無しさん2010/06/26(土) 22:08:11
うめ
0995デフォルトの名無しさん2010/06/26(土) 22:11:07
>>993
じゃあ、後ろ1文字消す処理はどうするの？
0996デフォルトの名無しさん2010/06/26(土) 22:11:41
>993
半角ｶﾀｶﾅが含まれてると固まったり落ちたりするﾒｲﾙｸﾗｲｱﾝﾄが沢山あったんだよ
0997デフォルトの名無しさん2010/06/26(土) 22:15:40
>>951

だなw

相手がsjisを期待していようがutf-8を期待していようが、fopenは
変わらず、相手の期待する文字列をchar *で渡してやればいい。

wchar_tだと、そうはいかないって話なのにね。
0998デフォルトの名無しさん2010/06/26(土) 22:19:19
>>995
後ろ1バイトが消えるだけ。

>>996
それは8bitコードに対応していないだけだね。
今は普通8bitに対応しているから問題なく動くという。
0999デフォルトの名無しさん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１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。