文字コード総合スレ part6

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、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/
（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/

■前スレ１からの連絡
だれかwiki管理できる？数年単位で保守できる人連絡プリーズ。
あと紳士諸君、常に裸で靴下を心得て、マッターリ議論汁。
コードサイズ、互換性、速度等気になるなら実験して結果をdiffパッチで提出汁。変態紳士は背中で語るべし。
とりあえず次スレ立て忘れごめん。それでは逝ってみようか…

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

漢字袋
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

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
Amd.7のドラフト
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3580.pdf
MacOSでのShift_JISとUnicodeとのマッピング
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
MS-DOS 5.0〜WindowsXPまでのコードページ
http://msdn.microsoft.com/en-us/goglobal/cc563921.aspx
Supported Code Pages （コードページなしは変換）
http://msdn.microsoft.com/en-us/library/aa288104(VS.71).aspx
Code Pages Supported by Windows （コード表）
http://msdn.microsoft.com/en-us/goglobal/bb964654.aspx

■これまでに行われた議論
・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のほうが化けにくい

・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(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% フォルダの下で実際に作ってみて。本当に作成できるかどうかで判断。
・TwitterのWebインターフェイスからだと、サロゲートペアは2文字としてカウント。140字打てない 。
・Unicode 5.2で追加されたUnicodeSMP(第1面)、Unicode 5.1で未定義だったSMPのコードポイントや第15、第16面が
　Windows7では表示されない。　→　和田研細丸ゴシック2004ARIBはARIB外字を含んでいる。
・WindowsXP SP3でMicrosoftのJIS2004フォント環境でサロゲートペア文字が表示されない。→
　コントロールパネル-地域と言語のオプション-[言語]タブで
　「複合文字や右から左方向に書く言語 (タイ語を含む) のファイルをインストールする」にチェック
・URLの%で続く2桁の0-9、A-Fへの変換は、UTF-8→urlencodeによる。RFC1738を嫁。
・菊紋、桐紋、葵紋などは文字か？海栗コードへの挿入は難しい。そこでTRONだ！！
・元号を安置する場所はJIS第三で確保済み。ウニコードでブロックを確保は政治力次第。
・元号は個人名ではない。特定の時間軸基準に数える年号を漢字で指す文字。
　陛下の崩御後必ずしも元号が追号になるわけではない。むしろ違う場合が多い。昭和54年法律43号の元号法参照。
・文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコード。　→　ヌル1バイトが貴重な時代からの負の遺産。
・Windows7出荷時に未定義だったコードポイントはフォント入れても豆腐になる。Unicode5.2は表示しない。欝だ。
・Unicode6ドラフトでPILE_OF_POO文字確定。ウニコードがもはやイミフ。SerifとSans-Serifで幅に違いは出る？
・shift-jisからUTF-8変換でサイズ1.5倍。でも圧縮すれば平均10％増加程度。用途に合わせて使うべし。
・「wchar_tは>849の嫁。>849の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」
・電子演算機では文字化けなんて飾りです。UTF-8/UTF16の人にはそれがわからんのですよ。

■ライブラリ
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/

■単語一覧
・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で
　再変換しているので、それをしなければよい。
・charlenでの文字列長の判定はプラットフォームにより返り値が違う（機種依存文字等）。マニュアル嫁。
・JISのエスケープシーケンスが正しく認識されない本文とか。
　'0x1b, 0x24, 0x42' という3バイトを先頭に、'0x1b, 0x28, 0x42' を末尾に追加汁。
　あるいはhttp://masaka.dw.land.to/mr/jmr.phpとか。

テンプレ終了。
今回はhttp://namidame.2ch.net/test/read.cgi/mitemite/1239039323/　【支援要請】さるさんと闘うスレ【代理投下】
の方に協力いただきました。ありがとうございました。
それではマッターリ開始

このスレ流れ速いね……

　　　　 |
　　（´・ω・） ｼｬｷｰﾝ
　　　ﾉメ、
　 ／一 /
／乙／　彡
＼／

>　U+301C WAVE DASH -> Shift_JIS NA 【MSの問題】

これのどこがバグ？
逆波ダッシュに対応する文字なんて無いからこれでいいだろ

UTF-8がascii互換とのことですが、最上位ビットが立っていないものはasciiだということでしょうか？

そう言った奴にきけばー？

シフトジスやEUC-JPだってASCII互換だべ。

wchar_tにUTF16や32を突っ込みたいのですが、>849まで進まないと許可を得られないのでしょうか？

文字の繰り返しとして使われる踊り字の規格とか、使用制限に関する文献なにかないだろうか。
日本語検索での踊り字　'々'（U+3005）に対応した例外処理が必要なんだが、
できれば既存の検索ライブラリで何か対応しているのは無い？
（例：淡淡と淡々、どちらもあっさりした味わい）
（○○会会長、△△家結婚式式場、これ等は踊り字を使うのは間違い）
やはり単語一覧での禁則処理を通した後、踊り字と文字繰り返しの二パターンで再検索かける必要が？

>>19
確かにUTF-8はそうだけど、「ASCII互換」にそこまでの意味はないだろ。
ASCII文書だけ見るとUTF-8かASCIIか区別つかないってだけ

どこかの言語処理系にローカルな言葉じゃないのか？
少なくとも誰にでも通用するような言葉じゃあない。

Shift-JISは２バイト目に0x5Cなどが出てくるけどASCII互換？

激しくスレ違いなのは承知での質問なのですが・・・

学校で行政が定めているキャラクタセットを挙げよという課題が出たので
インターネットや書籍を使い調べてみても全くわかりません

もしわかる人がいましたら教えてくださると嬉しいです
よろしくお願いします

行政って何ですか？

行政についての詳しい説明は特にありませんでした

行政が定めるということでJISコードなんかが当てはまるのかと思ったのですが
私は文字コードについての知識がゼロに近いので
これであっているかどうかが全くわからなく困っています

JISの奴でいいんじゃね？

うがった答えをするならGB18030とかKPS9566とか

すいません
書き忘れてしまいましたが、日本の行政が定めているキャラクタセットとのことでした

やはりJISでいいみたいですね
返信してくださったかたありがとうございます
JIS以外には何か当てはまるものはあるのでしょうか
わかるいましたら教えてくださると嬉しいです

頭痛が痛い、みたいな言い回しだよねえ。
JIS＝日本の行政が定めたキャラクタセットって。

重ねての質問なのですが「日本生命収容人名漢字」などのような漢字表も
キャラクタセットと呼ばれるものなのでしょうか？

課題を出せれた時の雰囲気からたくさんある感じだったので
これらを含めればかなりの数になると思うのですが

まずはWikipediaで調べてみれ
ttp://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E9%9B%86%E5%90%88

なんとなく、その課題自体が、エンコーディングスキームのいくつかを
回答の一部として想定しているという疑い。

ユニコードと日本の行政によって定められているキャラクタセットとの
関係がどうたらこうたらというような課題で
その第一段階として上記のことを調べよということでした

漢字表をキャラクタセットと呼んでいいかは符号化？がされていれば
呼んでいいのでしょうかね
難しいです

こんな個人的なスレ違いの質問に大して優しく返信してくださって
ありがとうございます
まさか2ちゃんでこんな優しくされるなんて思ってもみなかったです

失礼だな、プログラム板はどこも、まともな質問にはまともに答えるよ

次回のテンプレに追加
フリーグリフデータベース『グリフウィキ(GlyphWiki)』
http://glyphwiki.org/wiki/GlyphWiki:%e3%83%a1%e3%82%a4%e3%83%b3%e3%83%9a%e3%83%bc%e3%82%b8

>>32
勘違いするな。>>30が言っているのは「JIS」じゃない。
JIS X 0201(半角文字)とかJIS X 0208(全角文字)とかのことだ。
これで回答が「JIS」だったらその学校晒せ。

JISは大臣が制定するから行政というのはよしとして、それ以外に日本で行政が絡んだ規格は
無いだろ。

JSAは経産省所管の公益法人だから、行政と言えば行政だが...
常用漢字表とか戸籍統一文字とか住民基本台帳ネットワーク統一文字のことを
調べさせようとしてるのかな？

学校で文字コードまわりの課題出してくるなんて、悪い学校じゃないな。
mixiのどこかのコミュあたりでvoid探して半角カナでコメント付ければ
きっと殺伐と基礎を叩き込んでくれるよ。

Firefox 4のNightlyに素晴らしい機能が入った。
about:configでgfx.font_rendering.harfbuzz.level=1に設定すると、こんなことが可能になる。
<!DOCTYPE html>
<html lang="ja">
<style>
@font-face {
font-family: BodyText;
src: local("Meiryo");
}
@font-face {
font-family: ArialUni;
src: local("Arial Unicode MS");
}
body { font-family: BodyText; }
.hwid { -moz-font-feature-settings: "hwid=1"; }
.jp90 { -moz-font-feature-settings: "jp90=1"; }
:lang(ja) { -moz-font-language-override: 'JAN'; }
:lang(zh-CN) { -moz-font-language-override: 'ZHS'; }
</style>
<p class="hwid">半角ひらがなが使えるよ</p>
<p>葛飾区</p>
<p class="jp90">葛城市</p>
<p lang="ja" style="font-family: ArialUni;">骨</p>
<p lang="zh-CN" style="font-family: ArialUni;">骨</p>
</html>
これはCSS Fonts Module Level 3の先行実装(-mozが付いてるのはまだドラフトだから)。
http://dev.w3.org/csswg/css3-fonts/

>>26
ASCII互換でしょう。
　EUC-JP：　ASCII環境では読めない。2バイト文字はASCII文字と区別しやすい
　Shift-JIS：　ASCII環境では読めない。2バイト文字はASCII文字と区別不能
どっちも読めないことに変わりはない。読めない状態でどっちがマシかを語られても困る。

>>44
ここはフォントスレじゃないよ。たぶん

半角の話なら隔離スレの方がいいんじゃない？voidさんネタもあるし。

>>45
区別不能ってのは微妙な表現だぜ。

＞44
字形なんて一つの段落で混在させたいに決まってるのになんでpなの。spanでも使える？

＞48
Shift-JISを知らない、ASCIIしか知らないプログラムからしたら、81 5Cが
　＜未知の文字＞　＋　＜ASCIIの5C＞
に見えちゃうんだよね。
「2バイト文字は無理にデータを通そうとすると2バイト目が誤判断必至」とか

>>42
> JSAは経産省所管の公益法人だから、行政と言えば行政だが...
> 常用漢字表とか戸籍統一文字とか住民基本台帳ネットワーク統一文字のことを
> 調べさせようとしてるのかな？

俺も最初に「戸籍統一文字」を思い浮かべた。言われてみれば確かに常用漢字表もキャラクタセットだよね。

ありがとうございます
そのへんを課題の解答として提出してみます
返信してくださったかた本当にありがとうございました

>>45
前スレのfopenの続きのここにSJISはASCII非互換って書いてあるけど。
http://pc12.2ch.net/test/read.cgi/tech/1093251312/281

互換性っていっても、いろいろあるからなぁ。
言葉の定義(あるいは文脈)の問題だが、何の文脈もなく互換か非互換かと聞かれたら俺なら互換って答えるなぁ。

汎用電子のレビュー期間がもう終わってるけど登録マダー? (AAry
http://www.unicode.org/ivd/

チ
＼

(読み：ルピー)

>>55 インド通貨の文字として採用されたやつだな。

U+20A8はU+20A0と同様の死んだ記号になるのかね。
日本円と人民元はUnifyしてるくせに。

JC…日中
JK…日韓

J…JSは？(´Д｀；)ﾊｧﾊｧ

>>59
それ犯罪まじヤメロ

確かシンガポールの漢字も入ってたよな

>>57
ルピーはインド以外でも使われてるから、まだ必要なはず。

インドルピー考察
http://typophile.com/node/72290
文字レンダリングの問題点なんかで面白い考察が行われているな。
フォントによっては可読性が失われる場合の処理とか。
U+20A8 http://www.unicode.org/charts/PDF/U20A0.pdf

何でいまだにEUCとかShift_JISとか使ってるの？
みんな自分のキーボードで「りっぽうめーとる」変換してみ？
Unicodeにしかない記号文字が入力できるぞ。
たいていどんなソフトでもIME使って日本語ＯＳから入力可能な文字は、
全部処理できないといけない。その用件を満たすためにはUTFを使う
しかない。

たしかに2chがいまだにSJISなのは問題あるな

>>64
立方メートルのために使える文字コード変えようとは思わないな。
トンパ文字が使えるからってTRONコードにしたいと思わないのと同じで。

立方メートルはともかく、
人名地名の漢字を理由にUnicodeに移ってくれと思う。

トンパ文字と立方メートルじゃ需要が違いすぎるだろ。
とはいえ立方メートルのためにARIB外字に移行するのは勘弁してください＞＜

立方メートルってどこに需要あるの？
一般的な書類ではもはや「立方メートル」って表記するのが普通だし、
理系の文章では立方メートルがあるくらいじゃどうせ表現不足。

表現力を言い出したらプレーンテキストで用が足りることなんかありえないし
マークアップ言語ですら怪しい
PDF使ってろ

>>70
> 表現力を言い出したらプレーンテキストで用が足りることなんかありえないし
そのとおり。だから、立方メートルをわざわざ文字として入れるメリットは薄いし、それのために文字コード決めるなんてことはありえない。

そりゃ、究極はPDF, SVG, PostScriptになるのだろうが、LaTeX程度に強力なマークアップ言語なら大体は事足りるよ。

texファイルを直接読む人にはそれで十分だろうねw

>>72
立方メートルくらいならTeX記法で十分読める

せめてLaTeXでお願いします。

RUPEE SIGN提案だらけ

ファイルやデータベースに文字データを普通に保存するときの文字コードとしてはUnicode
を使わないと、日本語OSで使える文字の一部が正しく保存できないということですね。

は？

へ？

>>76
そう思ったら波ダッシュを使ってみよう。

>>76
日本語だけしか使わないのであれば、euc-jpでも何の不自由もないし、Windowsならcp932をうまく扱ってくれる。

SIPにあるような日本語で使う漢字もeuc-jpで表わせるの？

「日本語で使う」の定義をしてくれないと80さんも答えようがないと思いますけど、
JIS X 0213:2004までの話であればEUC-JP方式の符号がJIS規格にあるので、
euc-jpですむと言ってもまあ嘘ではないですよね。
拡張Cに入ってるやつは現状ではだめでしょうけど、あれを「日本語で使う」と見ない人もいるでしょうし、
「Microsoft Codepage 932にないものは日本語で使うとは言わない」ような極端な人もいると思いますよ。

>>82
実用性とか一般的な環境をベースに考えると、日本語WindowsでIMEを通じて入力可能な文
字が全部扱えることをもって日本語対応なんじゃないか？
いまどき各国語対応（≠国際化対応)の話自体ばかばかしい気もするが、Windowsから入力
出来る文字を過不足無く保存するには基本的にUnicodeじゃないとだめ。
Windowsの標準文字コードがもはやCP932やShift_JISではなくなっているので仕方が無い。

なんでMSはWindowsの日本語ロケールでSJISいつまでも使ってるのかな

>>84
utf-8ロケールにしたら何が起きるのでしょうか？怖くて出来ません。

幸せになれるはず

実際コントロールパネルで変えてる人いる？
ユーザ毎にできるならまだ試せるけど。

>>84
下位互換のためか、ロケールの扱いがUNIX系とちょっと違うのでは？
WindowsNT４以降、API内部の文字データは全部Unicode化されているが、SJIS文字列を渡すタイプのAPIも
残っている(API内で必要に応じてUnicode変換されるためUnicode版APIより遅い)し、NTFSではファイル名も
Unicodeで保存される。
しかし携帯やデジカメのSDカードとかはNTFSに出来ない(性能的にキツく、一部仕様が非公開、FATは版権
フリーに等しい状態だがNTFSは違う)。FATで日本語ファイル名を使うにはSJISが必要なので、
SJISを完全に消すわけにはいかない。そこでOS内の文字列処理を出来るだけロケールに依存しないように
改造した上で、ロケール上は日本語＝SJISの設定を残したんじゃない？
FATを置き換える可能性のあるUnicodeファイルシステムとしてはDVDやBDで使われるUDFがあるが、
2GB以上のファイルを扱うHDDレコーダーとかでしか使われてないのが現状。

もっと単純な話だよ。
WindowsのDBCS系のAPIは、1文字2バイトまでの設計になってる。
だからUTF-8にしたくてもできない。Q.E.D.

>>89
なるほど。だからWindowsではUTF-8では無くてUTF-16を使うんだね。
これなら一部の４バイト文字を除けば半角文字も全角文字も全部２バイトだ。
NTFSもUTF-16(リトルエンディアン)だったろ？

ついでに言っとくとブラウザのJavaScriptやMicrosoft Officeのファイル内に記録される文字もとっくに全部Unicode。
業務用のWebアプリとかでは何が面白いのかいまだにShift_JISを使っているやつを良く見かけるが、
ASP.NETやJavaもプログラム内の文字列は全部Unicodeだ。つまり、Shift_JISのWebアプリの多くでは、
多くの場合次のような馬鹿げた変換が行われている。

�@サーバー内でUnicode文字によるHTML文が作られる。
�Aネットワークに出る前にShift_JISに変換される。
�Bブラウザが受信したHTMLデータをUnicodeに変換しながら読み込む。

HTMLページをUnicode化するのは(半角英数字が多いから)現実的じゃない
が、UTF-8だったらUnicode(UTF-16)と高速に相互変換できるし、元になる
文字集合が一緒だから一部の文字が変換失敗なんてこともありえないのにねぇ。
ついでにデータベースの文字コードがSJISだったりすると、さらに面白いことになりますｗ

>>90
UTF-16を採用した当時、UTF-8は表には無かったからだろ

ここは勉強になる

FATも8.3じゃないのはUTF-16のような？
FATもVFATやらFAT32ってのもあるから全部そうかわからないけど。

>なんでMSはWindowsの日本語ロケールでSJISいつまでも使ってるのかな
増す増す謎

互換性のため

仮にDBCSのAPIを3バイト文字以上に対応させたとして、
SJIS決め打ちのアプリも多いというかほとんどそうだろうから、いきなりロケール切り替えても発狂するだけだわな……

>>88
> FATは版権フリーに等しい状態

ロイヤリティ払ってるよ。
フリーのソフトウェアはお目こぼしされてるだけ。

GIFのようなもので、最初から金をとると明言しとかないとボコボコにされる

どこまでサポートしてるか分からんけど、MBCS系API（〜A）でUTF-8使えるはず。>WnAPI
少なくともVista以降はメモ帳でもUTF-8扱えるし。

>>100
WideCharToMultiByteでUTF-8に変換できるだけで、ロケールに設定してSetWindowTextAに
UTF-8直渡しとかはできないよ。
メモ帳はUnicodeアプリ(内部UTF-16)でファイルの読み書き時に変換してるだけだろ。

えっ

C/C++でWinAPI直接叩いていたら問題だろうけど、
もっと上位のライブラリやらJavaなど他の言語なら問題無くね？

>>94
WindowsでフォーマットしたUSBメモリにファイル名に日本語文字を含むファイルを作って、
それをLinuxから文字コード指定でマウントする場合、ファイルシステム側の文字コードとして
cp932(=Shift_JIS)を指定しないとファイル名が化ける。少なくともリムーバブルメディアをFAT
でフォーマットした場合は今でもShift_JISが使われています。

>>91
HTMLの処理ですら文字コード変換より遥かに重い今時、

>多くの場合次のような馬鹿げた変換が行われている。 

>UTF-8だったらUnicode(UTF-16)と高速に相互変換できるし、

と、変換の手間が問題であるかのような主張って、、、

Unicodeの擁護ネタがそれくらいしかないってことだな

>>104
shortname=[lower|win95|winnt|mixed]
ってオプションがあるけど、日本語で読んでもめまいがしてくる。

>>105
そうそう、どうせならサーバー側とクライアント側の変換テーブルが違うとか書けばいいのにな。

というか、Unicode=UTF16前提で話してる人はWindowsとかJavaとかに毒されすぎ。
UNIX系OSなら普通に上から下までUTF-8統一とかだぞ。

>>107
>そうそう、どうせならサーバー側とクライアント側の変換テーブルが違うとか書けばいいのにな。 

いや、それはそれで自爆だから

>>107
> 元になる文字集合が一緒だから一部の文字が変換失敗なんてこともありえないのにねぇ。

普通にってここ数年の話じゃないか
もっと前から稼働してるサーバは多い

FAT12/16/32すべてで、8.3ファイル名はCPxxx （日本語なら当然932）で、長いファイル名 (VFAT)がUTF-16。
NT系WindowsならCP932にないハートマークやつち吉を含んだファイル名を作れる（9xはだめ）。
Unix系でFATをマウントするときにCP指定するのは8.3ファイル名のためのはず。

31ceb41eb6d65669100737e70a50135e

これってどの文字コード？
全然わからない,デコードお願いしますorz

ASCII

1eとか10とかがある時点でまっとうな文字コードには見えんなあ
桁数からハッシュコードに見えるんだが

というかハッシュ以外なさそうな

Base64

まだこんな馬鹿がいたのか…
http://slashdot.jp/it/comments.pl?sid=505301&cid=1814383

また頓珍漢な事を。
  UTF8は日本語と中国語の判別もできない欠陥コードです。

なんて言って周囲を興ざめさせるやつが出てこないか心配です。
ま、UTF8対応は常識になってくるんでしょうね。
中国語と日本語の区別がつかないことがあるなんて、ほとんどの人には
どうでもいい気がする。

データ入力外注したら度々使い物にならん成果が納品されるんだぜ？
最悪じゃないか

「カタカナ」が「カ夕カナ」とか入力されてるんですね。
わかります。

UTF8に限らんけど。

日本人デザイナーでも「ひながな」をやっちゃうご時世だから

女子高生に入力させた日にゃｗ

UNICODE文書の文字誤選択の傾向と対策を構築する前に中国人と女子高生のせいで過労氏する下請校正が大量発生しそうだな

下で請ける女子高生？

レビュー期間が終了したら提案者が [email protected] に送らなければいけなかったのか…
これはちょっと RFC2978 読んでもわからなかった

この業界って本心では昔のまま変わらないでほしいと思っているやつが大勢いるけど、
そういう連中はいずれこの業界を去っていく。
レガシーな文字コードにすがりたい連中は次第に影が薄くなって、そのうち転職する
ことでしょう。

その前に
髪が薄くなって
記憶も薄くなって
それからですよ
影が薄くなるのは

128

0x81

10000010

\u0083

>>128-131
ネタ切れの隔離スレでやれ

%E3%83%8D%E3%82%BF%E5%88%87%E3%82%8C%E3%81%AE%E9%9A%94%E9%9B%A2%E3%82%B9%E3%83%AC%E3%81%A7%E3%82%84%E3%82%8B%E3%81%8B

>>133
%E3%81%9D%E3%81%86%E3%81%A7%E3%81%99%E3%81%AD%E3%81%87

とはいえ別段話題はないけどね。それでいいのさ。

なんかよくわかんないけど絵文字って結局モヤイまで入るの？

万個文字は入ります

なんか、結局何がなんだか分からなくなりつつあるな

CJK統合漢字ならぬ、DAS統合絵文字なんだな。
で、キャリアの絵文字の違いで思わぬもめ事が生じ、DAS統合互換絵文字が定義されると。

Willcom絵文字もあったっけ？
どうなるんだろうね？

こうして、Unicode上の\記号と〒記号はますますバリエーションを増やしていくのであった。

同じソフトバンクでも、キスの絵文字だと思って送ったら相手の機種は解像度が高くてディープキスだったでござる。

>>142
それは明らかに別の文字だから別コードにすべき。ｗ

こりゃもうグリフ毎にコードあてないとエライ事になるな

Lip Symbols Extended-Aとかが創設されるのか

フレンチキッスはLANGタグでお願いします。

CP51932の登録キタコレ
http://www.iana.org/assignments/character-sets
http://www.iana.org/assignments/charset-reg/CP51932

| CP51932 is a variant of EUC-JP
今時EUC？　EUCはいらない子。

しかし珍しくUnicode以外の話題

>>148
そんなことはregistration自身にも
> CP51932 is for use of importing legacy data.
> UTF-8 is preferred to CP51932 for new system.
と書かれているように分かり切ってる。
WebブラウザからEUC-JPのサポートを削除するわけにはいかないだろ

EUC-JPのWebページなんて美乳で十分でござる

広く、といっても資格の勉強などはおすすめしません。資格というのはあくまで仕事に直結したものを取るべきです。
採用時に資格は一切評価しないといった建前も世間ではよく耳にしますが、折角の機会ですから本当の事を言います。評価します。マイナスの評価です。
仕事に就いていないのに資格の取得などに時間を浪費していたという事実は、少なくとも一分一秒を争う企業活動への参加を目指すなら、悪です。
学生時代のいまから時間の使い方をしっかり意識して生活してください。
社会に出れば仕事を覚えるために学生時代の１０倍も２０倍もハードな勉強が求められます。
もちろん必要な資格があればその中で取得します。しかしその学習量は社会人が仕事の中で日々習得する知識量のうちのほんのごく一部に過ぎません。
学生が資格の勉強に貴重な時間を費やすのは、子供が折角もらったお年玉を老後の生活資金に貯めておくようなものです。
子供のお小遣いと大人の生活費では一円の重みが違います。同様に、学生と経験を積んだ社会人とでは同じ一時間でも脳の仕事量が全く違うのです。

>>151
これはFirefoxでEUC-JPの掲示板に補助漢字を投稿すると
IEで読めない問題解決の第一歩

>>153
EUC-JPの補助漢字ってX 0212をSS3だよね。
cp51932は補助漢字含まないのに何で問題解決するのかよくわからん。補足説明ぷりーず

ちなみにX 0212なんて既に死滅していたと思ってた

EUC-JP じゃなくて CP51932 で蓄積された legacy data なんてどこにあるの？

テキトーな想像だがWeb掲示板システムでIBM拡張文字をEUCで投稿して
データベースにEUCで保存するとCP51932相当になるのでは？

why?

え、だってEUC-JPはIBM拡張文字を含まない文字コードで、CP51932は含むから。

例えば「��」。
EUCのWebページでInternet Explorerに「��」を入力してPOSTメソッドで送信するとFC E2が
送られるから、これがデータベースにそのまま保存されたらCP51932のできあがりじゃない？

�ｱ

草�g剛

EUCは要らない子

社員の名前を表示するページがあって携帯対応したら出なくなって困った文字ばっか出てきたな。
ためしに携帯でここ見たらやっぱり見えないわｗ

携帯にはデコメ絵文字という知恵があるじゃないか。
さあがんばって画像を作るんだ。

ASCIIについてなんですが、
ASCIIの配置がこうなった理由とか書いてあるとこ知りませんか?

え？

>164
ASCIIのコード配置はテレタイプに由来してる

契丹文字の追加提案が出てるな

この調子でアヒル文字とか入れてくれないかな

神代文字は絶対入れねえと言い切られちゃってます
http://www.unicode.org/roadmaps/not-the-roadmap/

そんな名指しがあったのかｗ

Klingonを入れないと決めて以来、この種の文字は全部だめになった感じ

一時は実在が信じられてたんだから、
さすがにクリンゴンと同列はちょっと凹むな…

まだ、線文字Aとかインダス文字とか西夏文字とか女真文字とかロンゴロンゴ文字は入ってないんだな。

西夏文字は入る予定？

マヤ文字や梵字も入ってないな。

>>173-174
予定はあるようだ
http://www.unicode.org/roadmaps/smp/

梵字入るとありがたみが薄れるな。

日本語だと、変体かな、サンカ文字、将棋文字（将棋の駒形に駒の名前）とか。
文字じゃないが、家紋なんかどう？

>>177
サンカ文字は神代文字だからだめか…

家紋とかありえん

>>172
一時は、っつーか江戸時代の一部の学者ぐらいだろ。
世間でまともに扱われる人が信じてたのは。

本居宣長なんかは否定してるし。

クリンゴンとの差としてはそれで十二分だろ？

同じ創作文字でもテングワールとかは
なぜか平然とRoadmapに入ってるね

トールキン系はいつもどこでも優遇されがちだよね

変体がなは去年の今頃提案書が出てたような

変体とか神代は普通のかなのバリエーションじゃダメなの？
明示的に区別して扱わなきゃいけない状況が思いつかない。

(「字形そのものについて言及する場合」に困るのはIVS漢字でも何でも同じだし)

表す音が同じだからバリエーションと見なすという考え方は、
多分Unicodeも10646も採用しないと思う。

一つの漢字から複数のかな字体が派生している場合は、
別の字と見なすかバリエーションかという議論は当然出てくるだろうけど。

NBが押せば神代文字だって入るかもよ
ンコマークだって入ったんだから

>>185
元になった漢字が違う
同源でないものはCJK統合漢字ですら分離されることになってるぞ

そうなのか

勉強になった�d

クリンゴンはまだEversonが諦めてないみたいだからなー
どうなるやら

ShavianとDeseretも人工文字だけどさらっと入ってるよな

女子高生の間で流行らせる
→3キャリアをそそのかして実装させる
→AppleとGoogleにガラケーで使えるんだから使えるようにしろとゴリ押し
→どんな文字だってUnicode入り思いのままだぜ！

変体がなよりも前にだな、ヤ行イ、ヤ行エ、の平片とその捨て仮名と、ワ行ウの平片を早よう出せ。

俺は「タイガー于ッズ」とか書きたいのだよ。

イとエがくっついたようなのってヤ行イ？エ？どっちだっけ？

ぽげむたマークさえ入っていないというのに何故モヤイが入ったのか納得がいかない

「誰も提案書を出さないから」でほぼすべて説明できてしまうのが
日本の文字・記号の悲哀

AdobeのKen Lundeのほうが熱心に出してる始末だもんな

小林剣△

人工かどうかだと、ハングルは
どうなのか、となるだろう。

結局、情報交換のために符号化が
必要だと周知できれば、クリンゴンでも
どせいさんでも何でも入るでしょ。

どんな文字も最初は誰かが作るんだから、線を引くのも簡単じゃないよね

どせいさんはフォントじゃないか？

HTML5でCP51932がEUC-JPのreplacement encodingになった。
http://dev.w3.org/html5/spec/parsing.html#character-encodings-0

補助漢字の立場は? w

補助漢字JIS X 0212は全てUnicodeに収録されているので問題なし。
要らない子EUC-JPはそろそろ滅んでくれ。

補助漢字入りの由緒正しいEUC-JPの立場がないな、こりゃ。

EUC-JP環境を破壊してUnicode化を促進する作戦とか？

しっかしHTML5の縄張りって広いなあ。

>>204
EUC-JPが徐々になくなって行くべきかどうかはこの際置いといて、
この仕様だと、EUC-JPを直接サポートしてないブラウザが、
補助漢字を使っているEUC-JPなレガシーページを見ると、
"misinterpreted for compatibility" parser errorになってしまう。

Shift_JIS ⊂ Windows-31Jみたいな場合は問題ないけど。

敗残エンコードEUC-JPは今すぐ無くなるべきだし
そんな異端で古いページが見れなくなっても誰一人困らない
事実上誰一人困らない問題を持ち出して、さも致命的な事の様に言う癖は直した方がいいね

妄想乙

で、何か今から出来ることはあるのか

で、具体的にはどこのサイトが困るんですか？

Shift_JISをWindows-31Jで置き換えるのは、
Shift_JISと言っても、実はWindows-31Jな文字を使っているページがあるから分かる。

けど、EUC-JPをCP51932で置き換えるメリットはなんなの?
Unicode mappingを持っていればそれで済むのでは?
なにかとShift_JISがAPIに出てくるWindowsでは、
相互変換に便利なんだろうけど。

>>212
入出力はCP932で、DBにはCP932を数値変換したEUC-JP(モドキ)
を突っ込む、という実装も過去には少なくはなかったんだけど、
ことHTML5という範疇ではそれをやる意味がわかんねーな。
viewはあくまでCP932なのだし……。

# ちなみに、こういうDBをかかえてると入出力がUTF-8に
# なったとたんに丸付数字とかが化けるという罠がw

Unicode 6まであと10日

あと10日か

replacement encodingはShift_JIS→Windows-31JでもJavaがヤバくね？
J2EEではContent-Typeヘッダのエンコーディング名がサーバ処理でUnicodeからHTMLデータ
へのマッピングテーブル決めるのにも使用されているから、わかわからなくなるぞ。

J2EE使いは"replacement encoding"なんか使わんだろ。

また遭遇する事の無い問題を持ち出して大問題気取りですか
一人だけ勝手にわかわからなくなってれば良いじゃない

IEに補助漢字をサポートさせるのはあきらめたということ。
IEで読めないEUC-JPのページなんて実運用されてない

G3まで使用したEUCより、NEC選定IBM拡張文字を含んだMS EUCの方が
圧倒的に多かったんだろ。だからと言ってHTML 5は余計なことすんなって感じだ。

余計な文字コードにトドメを刺すのが余計な事とは思えないな

CP51932はかなり特殊なEUC-JPなので、
EUC-JPにトドメを刺すわけじゃない。
むしろ内部的に延命することになる。

Unicodeにmappinghしてしまった方がいい。
多くのブラウザが内部的にはUTF-16だろうから。

CP51932はEUC CESに実装が依存している
システムの都合で必要になるもの。

来年になったらUnicode6.0になって、携帯絵文字のサロゲートペアががんがん使われる悪寒。
ほとんど、ＳＭＰに入る予定。

でかいのはもうBMPに入んないから・・

わずかに残った貴重なBMPスペース

これからは一体何に割り当てられていくのかな

かたやSMPは、我々が生きてる内には埋まらんかもね。

最初からUTF32しかなければ、
どれだけ世の中簡単になっていただろうか。

世界共通文字コードなんて大それたものを作り始めた人間に神は怒り、
ちまちまと小手先の嫌がらせをするようになったのである。

半年に一度のWG2も今週のM57で最後か
次からはかなり間が空くなあ
Amdの刊行ペースが遅くなるのはウォッチャーとしては残念

>>227
ばかじゃねーのｗ
UTF-32は最低最悪の無意味エンコーディングじゃねぇかｗ

227は「簡単に」なっていただろうと、事の単純明快さを問題にしてるのに
文字コードごとの優劣に論点をすり替え煽るこの2ちゃん脳。
こわいですね〜

何も簡単にならない事も分からない馬鹿か

32bitあっても結局合成文字は使う羽目になってたよ
文字に色々と補助符号をつけるscriptがあるかぎりは

>>231は符号化方式が複数ある事を難しいと言ってんの？
とんでもない低レベルだな
このスレから失せろよ

少なくとも、UTF-32だけだったら、サロゲートペアの間に改行入れて文字化けさせる「Unicode対応の」エディタw
なんてものは存在しなかったと思う。

それぐらいかな。

>>235
>>233をよく読め。

>>236
だが、結合文字は後ろに付くからセキュリティ問題は発生しにくいと思うんだ。
クソなプログラムだと、マルチバイト文字やサロゲートペアが真ん中でぶった切られたときに
後ろの文字とくっついて各種インジェクション攻撃のとっかかりになってしまう。

そもそもUTF-16に入らない文字をUnicodeに無理やり足したのが一番悪いんじゃないか？
http://itpro.nikkeibp.co.jp/article/COLUMN/20061222/257650/?ST=win
京大 安岡助教授（JIS X 0213:2004策定者の一人）のインタビュー記事読より抜粋。

-----------------------------------------
　ところが2000年12月に，政府の国語審議会（現在は文化審議会国語部会）が，「表外漢字字体表」
という答申を出しました。これは常用漢字以外の漢字（表外漢字）の字体選択の「よりどころ」を定め
たものです。大まかに言うと「現在のワープロでは間違った（正しくない）漢字（JIS X 0208やJIS X 02
12の例示字形）が出るので，その漢字をワープロで出すべきではない」という主張でした。
　JISのスタンスは「文字コードは通信のための規格なので，字体はフォント・メーカーに任せる」という
ものだったのですが，答申を無視するわけにはいきませんので，2004年にJIS X 0213を改訂すること
にしました。
-----------------------------------------
どうでもいい内容で余計な文字なんか足しやがって。
現代では漢字の字形はMSゴシックや携帯電話が決めているんです。国語なんとかはもう黙ってくれ。
JISのスタンスは間違ってないと思うが文科省の子分を無視できないそうな。悪いのは国語なんとかか！

-----------------------------------------
　JISでは，2000年にJIS X 0213を作った後に，新規に追加した文字（1090文字）を，Unicodeにも追
加してもらうよう交渉しました。その結果，残念ながら303文字が「サロゲート・ペア」として追加される
ことになりました。
-----------------------------------------
Unicodeに変換できない、Shift_JISとかだけで使える文字が今更出てきたら困るからな。
そういう状況と知っているなら事前にネゴってほしいもんだが。サロゲートペアさえなければ日本の
業務システムはUnicodeだけで十分幸せだったのに。

MSや日本IBMはBMPに入れようと笛を吹いたけど、
日本NBの他のメンバーは踊らなかったんだと。
ttp://d.hatena.ne.jp/ogwata/20091109/p1

来週リリース予定のUnicode 6には、日本関連の字やらシンボルやらがSMPにも入ってるから、
サロゲート未対応なシステムにはどのみちご退場願うことになるよ。

>>238
どっちみち最初からBMPじゃたりないということはわかってたの。
Unicode3の頃には既に。

妄想でつまらん犯人さがしやっても意味ないから。

>>238
妄想逞しい御馬鹿さんで有名な御仁か

ああ懐かしの16bit width Unicode！

> そもそもUTF-16に入らない文字をUnicodeに無理やり足したのが一番悪いんじゃないか？

UTF-16って文字集合じゃないんだが
「UTF-16に入らない文字」ってどういう意味？

JIS X 0213がなければサロゲートペア自体が存在しなかったわけでもないし、
「サロゲートペアに対応しなくても普段使う文字には十分だから非対応」にするなら
それこそ普段馬鹿にしてる「2バイト文字が通らない化石」の存在とかわらん。

>244
UCS2っていいたかったのではあるまいか？

>>241
じゃあなんでDIS10646を却下して16bit案ゴリ押ししたの?

あんなTRONコードのできそこないのようなもの通らなくて本当によかったとは思うけど

その16bit案の名残たるUCS2も、10646:2011じゃ正式にobsoleteだ。
いまだにFDISの投票に入れていないけど。

Han Unification…

いっそあの記号みたいな文字のあれをＳＮＰに移動させて…

それがダメなら第3面をまるまる奴らにあげて移動して貰ったら？
これがほんとの韓国面。なんちゃって。

>>250
SMP

>>249
なんのためにやったんだろね...

ぐだぐだだなあ

>>252
それこそ16bitに押し込むため

だったら、各国別にコードを持った方がはるかに幸せだったと思うが…

押し込むために無理を通したのに、
結局押し込めませんでしたって言うんだから泣けてくるね

2バイトで全世界の文字を押し込むなんて、言語知識０の欧米の技術馬鹿が考えた妄想だし。

結局、内部コードがUTF-32で、セーブするときにUTF-16かUTF-8にするのが良いんだろうな。

>>257
お前は技術馬鹿ですら無くただの馬鹿だな

言語タグ<笑/>

>>258
64bitのwindowsでプロセスのメモリー空間が64Tbyteもある時代に、
たかだか１Gもないようなテキストが2倍になってもたいした話じゃないですよ。
それより、処理も簡単になるし、4バイト単位でメモリ扱えば性能も期待できる。

それより、早く「2バイトで〜」なんていうくだらない夢をさっさとあきらめて欲しいなあ。
群の私的利用領域も復活して欲しい。

今日から1バイト＝2オクテットと定義します


これで完全2バイト化が可能に

>>257,260
UTF-32でも、1つで1文字表せないことがある。
なので、結局UTF-16とあんまり状況は変わらない。

異字体セレクタとか、合成文字とかをどうにかフラグの形で埋め込んで、
どうせ使ってないUTF-32の上位ビットを使うってこと、できないのかなぁ。

ベトナム語の二重ダイアクリティックの前には無力

>>262
なるほど。上位ビットをフラグにするんですね。
UCS2がobsoleteになるんだから、UTF-16もobsoleteにすればいいのに…

1コードポイント=1グリフであってほしい理由は？
文字の境界を簡単に知りたいとか、画面上の一定の幅の中に何文字おさまるかを
簡単に求めたいとか、そういうこと？

>>265
それもあるが、携帯絵文字がSMPに入るなら、将来、サロゲートペアの文字が使われる機会が
爆発的に増える。何が起きるか正直分からない…何も起きないかもしれないけど…

たとえば、画面上に10文字分入力できる入力エリアを定義して、入力を受ける領域を20バイトとするプログラム
があったとする。
この入力領域にサロゲートペアの文字を10文字（40バイト）入れるとどうなるか？
アホなプログラムだと入力エリアの後ろ20バイトを破壊しちゃうかもしれない。結果、異常終了。

なんてことがあるかもしれないね。ｗ

実際今までサロゲートペアの文字なんてほとんど使われてなかったので、問題が表面化しなかったんだろうが…

言語仕様や標準文字列ライブラリの観点で、
UCS-4お勧めのプログラミング言語環境って何かある？

ないでしょ。標準でUnicode処理系として適合してるのは。
ICUとかライブラリ使いなよ。

AJ1のCID+20156は9FCCに入るのか
日本に関係ありそうなのは今回はこれくらいかな

たとえばIE8みたいなブラウザって、最大文字数＝10とした場合に、サロゲートペア文字は
「１文字」としてカウントするのでしょうか？それとも、２文字と数える？？
古いブラウザでは２文字、新しいブラウザは１文字見たいな数え方になる場合、両方で
等価に動くような入力チェックJavaScriptとかが難しくなるような･･･
Web系で実際に対応された方っていらっしゃいますか？

MSとジャストシステムに「早く携帯の絵文字使えるようにして」ってメールしとくわ。
これで、MSIMEでもATOKでも携帯絵文字が使えるようになるよ。
よかったな。おまいら。ｗ

そのメールは絵文字を使って記述することが重要だ。

>>271
ECMAScript 仕様書よく嫁。その辺はきっちりと決まっているし、ブラウザによる
対応もぶれがない。

絵文字は規格書の例示形そのままのが
symbolaってfontに一通り入ってる

仮にMSが絵文字フォントを用意したとしても配布対象はVISTA以上だろうな…

>>266-267
バグが表面化する可能性は確かに上がるけど、もともとバグってたんだから、表面化するのは仕方ない。
むしろ表面化しないまま、変な使われ方してセキュリティホールにでもなった方が危険。

絵文字フォントって、カラー？モノクロ？二値？
コード割り当てたところで、今のAPIが色付きのフォントを考慮してなかった場合、面倒になりそう。

そこでSVG

絵文字のコードポイントに限らず(そもそも建前上絵文字「専用」のコードポイントは
存在しない)任意の文字をカラーやアニメーション付きで実装してもいいが
義務付けられているわけではない。
みたいな注釈がわざわざISO/IEC 10646の規格の文面に追加された。

うんこは黄色じゃなきゃダメ。
キスマークは赤で。

＞(そもそも建前上絵文字「専用」のコードポイントは存在しない)

これもう少しわかりやすくお願い

フォント専用スレって需要あるかな
OpenTypeの技術的なこととか

プログラム板としては微妙だな

レンダリング関係ならこの板のような気もするけど
WebFontsになるとWeb方面の板のような気も

このスレのように、妄想と愚痴しか出ないスレになりそう
どうせ仕様と実装に口も手を出せるもんでもないわけだし

質問させてください。
現在、truetypeのフォントファイルをWindowsフォームアプリケーションにドラッグしてきて、
それをビットマップフォントに変換したいと考えています。
その時、フォントのタイプフェイス名が必要なのですが、これを取得するには
どうすればいいんでしょうか？

フォントファイルのnameテーブルを
自前で直接parseするくらいしか思いつかん。

禿げしくスレチ

ふむ

287です。
>>288さま
やっぱりnameテーブルをいじるしかないんですね。
.NETにもWin32APIにも、ファイルを読み込んで一発でフォント名返してくれる機能があればよかったんですが。
ありがとうございました。

>>287
Windowsフォームアプリケーションということは.NETだよな？
http://msdn.microsoft.com/ja-jp/library/y505zzfw.aspx
これ見たらできそうな感じがしたのでやってみた。

こんなんでできたよ。
var privateFontCollection = new PrivateFontCollection();
privateFontCollection.AddFontFile(@"フォントファイル");
Console.WriteLine(privateFontCollection.Families.First().Name);

>>292さま

はい。.NETです。
ありがとうございます！！！！msdnは見てみたつもりだったのですが、こんなのもあったんですね。
自分もちょっと試して見ます。

Win7にはUnicode5.1で未定義だったSMPのコードポイントは表示出来ないという致命的欠陥があるんだよな。
だから現状では絵文字の大半がフォントあっても使えない。
あと国旗は合字で表す必要があるからこれにも対応してほしい。

FirefoxならWindows 7でもなぜか表示できる

FirefoxはOSのレンダラ使ってないようだ

そりゃそうだ。

どういうわけかDirectWrite有効でも表示できるんだな
HarfBuzzというのが鍵なんだろうか

>>295
ヒエログリフ（古代エジプト文字）、見えますか？


ㄿ←a(ハゲワシ)

結局X0213のニゴとヒキヅナって、結論でたの？

>>299
ㄿ
U+313F ハングルじゃないの？

失敗した。これならどうだ？

𓀾←ミイラ

なんか変換されちゃうな。残念。

お、>>302はうまくいった。
Firefoxで書き込むとうまくいくんだな。

MacでもFirefoxじゃないと見えない

もう、Firefoxで見えればそれでいいってことにしないか？

>>302
AegyptusインストールしてFirefoxでおもいっきり拡大してみたらそれっぽいのが見えた。
Jane StyleやJane XenoだとなぜかU+303Eが見えるな。
IE9 betaだと箱が2つ、Operaだと点が2つ見えた。
サロゲートペアとさえ認識してくれないのはいくらなんでもひどい。
SafariとChromeでは箱が1つ。

ヒエログリフって動物さんだらけなんだなあ。

13178とか13179とか意味わからないけどすごく素敵。

絵文字のほうでも結構な数の動物さんがあるし、どうぶつビスケットみたいで楽しいな。

>>307
…
お寒い状況ですね。
「パソコンで絵文字」って宣伝できるのは当分先かな？

Unicode 6.0.0がリリースされた。

ISO/IEC 10646:2003/Amd.7:2010の方は、果たして年内にリリースできるのだろうか。

Amd8では？
あれはまだ40.60だから年内はまず無理

Unicode listのみんな!
日本ではクサチュー語やらギャル文字やらでもう2周半くらいしてるぜ!
しかもSMPの文字すら使わないでな!

>>308
シリアに由来するとも言われる獣神信仰がある。

そういえば、どこかに絵文字がUNICODEに入るまで、ヒエログリフを絵文字として使おう
みたいなことが書いてあったけど、こんな状況じゃ絶対無理じゃん。

>>314
絵文字って携帯絵文字のことね。
せめてIE9ぐらいサロゲートペアの文字をサポートしろよと。

なんで同じDirectWriteを使ってるFirefox 4とIE9でさえ差が出るのかわからん
使い方のコツでもあるのか?

Firefoxはフォントから直接グリフを抜き出してる

つーとほぼ全てのアプリと表示上の互換性が無いって事か

Pango使えば同じになるんじゃないかな。

>>318
逆にほぼ全てのプラットホームでfirefoxの表示上の互換性がある。

10646はまだ2nd edが成立していないのに
3rd edのAMD1まで準備中ってすごいなあ

絵文字に隠れてあまり話題になってないが
今回ひっそりExt.Dも追加されてるんだな

曜や職の手書き等でみかける略字「日玉」「耳ム」とか撥の拡張新字体とかが入ってるな。
これらは何で今迄無かったのか不思議なぐらいだし。

いやそれはいらんだろ

AJ16の未収録漢字のうち、字体が違いすぎてIVSで表すのは不適切と
認定されたものが入った。

广マ

がほしい

Unicodeのcode chartに載ってる字形をそのままフォントにすれば
Unicode完全網羅の最強フォントになると思うんだけど何か問題があるんですかね

>>327
ダサい

著作権的にも問題あるけど、そういう話じゃないのかな？

全ての文字を含めた全部入りフォントを何故作らないのって意味なら、知らん

とりあえず、あのPDFに埋め込んであるやつをおすそ分けしてほしい

Unicodeの全文字を入れたフォントって意味なら、残念ながら作れない。
Truetype/Opentypeは、文字を16ビットで管理してるから65535字までしか入らないのだ。

まじかー。そんなところに制約があったとは。

フォントリンク的な機能で補うしかないのかな。
あるいは、そっちにも同じ制約があったりとか

フォントの規格から作り直せと。。

OpenTypeにもサロゲートペア導入の波

TrueType的にはダメなんだよね。
OTFでなんとかなんないの？

Windows自体はフォントリンク機能を持っているんだから、
コンパネから手軽に設定できるようにしてくれればいいのに。

素人にいじらせるとろくなことないからな。

フォントよね〜

>>331
まさかUnicodeの2バイトってそこから来たんじゃないよね？
まさか…

どう考えても逆

>336
Windowsのダイアログはフォントによって表示サイズが変わる仕様になってるから、
下手にフォントいぢると、多くのアプリでコントロールの位置がずれる等の支障が出る。

>>335
CFF Outlineの仕様が追加されただけでTTFとほとんど仕様は変わらないので
制限も同じ。
つーかそろそろOS/2テーブルのUnicode rangeも使い切りそうなんだが
どうするつもりなんだろう

もう使い切っちゃった。残りはReserved for process-internal usageだって。
ttp://www.microsoft.com/typography/otspec/os2.htm#ur

OS/2テーブルもv5になるわけか。
こりゃWindows 7でのUnicode 6.0対応はますます望めそうにもない

とりあえずSP1では、Unicode 6の文字が表示できるようにならないと…

Mac OS X 10.7 では Unicode 6 対応してますように…

423 名前: 393 Mail: sage 投稿日: 2010/10/17(日) 21:15:20
そもそも一文字32ビットにすれば、処理が単純になっていいよねって話なんでしょ。

で、結合文字があるから結局マルチバイトのエンコーディングの文字列と
処理の手間は変わらない、一文字一バイトでいいよって反論。

それに結合文字は関係ないって言ってもしょうがない。
実際の処理で無視できないんだから。

429 名前: 393 Mail: sage 投稿日: 2010/10/17(日) 21:29:21
>>426
ま、個々のアプリとかシステムなら、入ってるときに結合文字ははじいて
中身は32ビット固定で処理するとかありかもな。
でも上のほうで32ビットにすればいいって言ってたやつはそういう意味じゃ
なかっただろ。

俺の働いてるようなITドカタの現場だとサロゲートペアにさえ対応しない。
その意味じゃ16ビットでも十分だな。

431 名前: 393 Mail: sage 投稿日: 2010/10/17(日) 21:32:07
でも、一文字32ビットで処理してる処理系ってあんまりなさそうだし、
わざわざ一文字32ビットの処理を手作りしてサロゲートペアのみ対応って
中途半端だな。

434 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/10/17(日) 21:34:26
だから、UTF-8でいいって。

EUC、SJISは滅びろ。

439 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/10/17(日) 21:53:03
UTF-8 が日本で流行ることは無いだろう。
無駄すぎる。

440 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/10/17(日) 21:54:47
国内のユニコードで一番のシェアはUTF8だろ。
unixの標準もこれだろ。

コピペしつこい

>>352
しつこく発言を繰り返してる当人に言って

「C言語なら俺に聞け（入門編）Part 71 」
http://hibari.2ch.net/test/read.cgi/tech/1286717824/

コピペ君って本当に馬鹿だな

「内容」がウザイのではなく、「コピペ」がウザイと言われてるのに気付かないとかもうね

>>355
俺の言ってる意味わかんないの？もしかしてバカ？
やめて欲しけりゃしつこく発言してる当人にやめろって言えってことだよ。

日本国内向けのシステムだったら、日本語Ｗｉｎｄｏｗｓで普通に入力できる文字が
ちゃんと記録できれば問題ないんじゃないか？それ以上が求められるのは国際化
対応して輸出するソフトとか、出版物みたいにＰＣで入力できない漢字も処理できな
いと困る人たちだけだろ。で、日本国内にソフトウエアを輸出してそれなりの商売が
できるメーカーはとても少ないから、実質Windowsが表現できる文字だけ見ていれ
ばほとんどの人は事が足りる。まあ日本語WindowsでIMEから入力可能な文字を
ひととおりサポートするには、Shift_JISではダメだしサロゲートペアも処理する必要
がある訳だけどね。

つまりUTF-8以外いらないと

>356
お前自身、そのしつこく発言してる奴がウザイんだろうけど、
それを他所にコピペした時点でお前も同類になってる事に気付け。
それどころか拡散していると言う点でより性質が悪い。

被害者面した加害者ってのはお前みたいなのを言うんだ。

相手するなよ…

>>358
もう一つ内部コード用にUTF-16かUTF-32がないと…

今UTF-8のかわりにUTF-16を使うメリットってあるかね？
昔のしがらみは置いといて

コードを表引きするときはどうすんのかね？

>363
(案1) UTF-32に変換

>>362
昔のしがらみを放って置けないからUTF-8はASCIIと互換性を持たせているのだと思うのだけど

>>362
BMPのみのサポートでいいのなら、楽かもしれない。
BMPなら、ビット演算しなくてもいい。
ASCIIコードが少なくて日本語が多い文字列だったら、サイズが小さくなるかもしれない。
正規化とか考えなくて済む。
char型に対する関数がほとんどまともに働かないので、一種の型安全のように考えられなくもない。

むしろビット演算だけで済むように設計されたのがUTF-8
UTF-1なんか190で割ったり掛けたりする必要があるとか
ASCII領域の図形文字全てと重複する可能性があるとか正気を疑うような設計だった。
当時はUnicodeを情報交換用に使うことなんてあまり真面目に考えてなかったんだろうな

c = 0x30 + i とかさらっと書いてあるASCIIコードに依存しまくった昔のプログラムを、
「判っていて使う」分には、入出力がUTF-8だとそのまま使えて便利だからね。
英語圏だとぜんぜん昔話じゃないかもしれんけど。

UTF-16に依存して、文字数 = 文字列長 << 1 とかベタ打ちされている
昔のプログラムも、「判ってて使う」文には問題ないけど、そういう地雷満載の
コードはもう維持したくないなぁ。

え？
パソコンってUTF-16のLittle Endianが標準でしょ？
むしろ、UTF-8って何のためにあるの？
互換性保つならANSIでしょ？









すいません。釣りをやってみたかったもんで…
マジでWindowsユーザはそう思ってます。

いつからのWindowsユーザだよそれは。

>>366
> 正規化とか考えなくて済む。

これは「UAX #15: Unicode Normalization Form」のことじゃないんだろうね。

>>368
UTF-8だって、文字列分割、改行挿入とかあればアウトじゃん。
どっちも地雷満載だよ。

>>371
それじゃないよ。
ていうか、それ、あんまり符号化方法とは関係ないじゃん。

SJISよりもUTF-8のほうが無難なんだなあ。

Shift JISなんて完全レガシーで、それ以外何のメリットもない。

Shift_JISは日本語Windowsで（文字コード表などを使わずに）入力できる文字ですら、
全部は処理出来ない。だから日本メーカーが作った日本国内向け携帯電話くらいで
しか使い道がない。大企業がXPを廃止し始める、２〜３年後くらいに、そこらじゅうで
Vista以降の新漢字が扱えない問題が騒がれると思うよ。

JIS90互換フォントはほとんど利用がなかったので
Windows 7で提供を終了するらしいけどな。

>>376
JIS90はJIS2004新漢字のうち、昔から存在した文字の字形を古い形状のままにしただけのやつだろ？
携帯とかと字形が合わなくなるが、読み仮名や意味は同じ文字なんだから別に良いんじゃないか？
昔の仕様書を新しいＰＣで印刷すると、文字が違うとかいったことはあるだろうけど、国語審議会が
正しいとする字形に見栄えが変換されるわけだから別にかまわんだろう。

もともと人名とか地名ぐらいにしか需要がないし。

そういや、携帯のメールとかってずっとJIS X 0208変種のままなのかな

それともスマートフォンにあわせて在来フォンも改良されていったりするのだろうか

もうじき死に絶えるのでは？
官公庁とかでは生き残るかもしばらく知れないけど…

官公庁も汎用電子が登録されたら移行が進むかなー

トンパ文字キター
http://www.dkuug.dk/JTC1/SC2/WG2/docs/n3935.pdf

中国は漢字以外の文字の符号化にも熱心だよね

大一大万大吉とかを入れてほしい

これは字なのか? 家紋でしょ?
まあ文字かどうか怪しいものがすでにいっぱい入ってるけど

あの、漢字組み立てるやつあったじゃん。

あれで十分じゃないかな。

まだどこでも普通に表示できるとは言いがたいけどそのうち。

>>386
もう、全部の文字を直線組み立てで作ったらいいんじゃないの？

変体仮名とか小書きヰヱヲとかイとエの合字とかそのうち入れるんかな?
でないと何でU+1B000〜U+1B0FFに256字分も拡張仮名用の領域とったか理解に苦しむのだが。

多分Hentai仮名がメインじゃない？

じーちゃんばーちゃんだと本名がヘンタイ仮名だったりするから
人名を扱わなきゃいけない場合に地味に必要だったりする＞変態仮名

>>388
イ
┴　は欲しいね。厳密にYEと表記する場合のために。

現状だと、𛀀[U+1B000]をE、エをYEとして扱うことになるんだろうけど、
現代日本人が普通に考えたらエは𛀀[U+1B000]以上にEだもんね。

エは文脈次第でEともYEとも取れる、ハイフンマイナスみたいな文字だと思う。

明らかにイとエをくっつけましたって感じなのが少し引っかかるんだよな
まあ「延」の1・2・5画目を取りましたって言い方もできるんだろうけど

同じ方法でwuも作りたい

うぅ
ウゥ

みたいなの

ワガママばっかり
そのうちアルファベット圏からデスられてUNICODE自体無かった規格に成りそうだな

汎用電子コレクションのもとになったデータベースには変体かなもあっただろうに
なんでそっちは追加提案しなかったんだろ

>393
アルファベット圏にも、アクセント記号付きの文字とかがあるから文字合成のニーズはある。

1B002 JAPANESE HENTAI LOLICON

二次児童ポルノが違法な国のために、
このコードポイントの例示字形は意図的に空白にされている

>>393
Unicodeのおかげで、ソフトウェアの他地域対応が
目を見張るくらい簡単になったのになくなるわけない。
AndroidとかiOSとか新しいOSが一気に広まったのは
Unicodeの貢献も大きい。

ワガママってのは、自国の文字を気持ちよく並べたいから
広いブロックに移し替えさせろとかね。

>>392
「于」だろ？　ちなみにこれの平仮名は単なる「宇」の変体仮名だ

卯 - 卩 みたいなのじゃなかったっけ？

イとエの合字は
U+304A(イ)とU+0332(合成用の下線)の合字で表そう



ってのはちょっと無理があるか…

┬とU+0332を合成するとエが完成？

Win7の例の問題はSP1で直るようだ。
ttp://www.unicode.org/mail-arch/unicode-ml/y2010-m10/0087.html

おお、中の人のコメントか。それは朗報だ。

当然だろ？
ＩＭＥに絵文字登録もよろ。

Win7SP1ベータ版で既に修正されてた。SMPだけでなく15、16面の私用領域も使えるようになってた。
これでARIB外字や絵文字とIVSの両立が出来るようになる。Win7SP1ベータ版のusp10.dllをWin7無印に入れれば無印でも使える。
しかし何であんなバグができたんだろ?

未定義のコードを不用意に使えないようにすることで
セキュリティ性を少しでも上げたかったとか。
やりようによっちゃ攻撃に使えるかもしれないし。

でもそれだったら何でSMPだけそうしてBMPとSIPはそうしなかったんだろ?

BMPは互換性のため
SMPは未知のスクリプトが追加されたとき正しく処理できるとは限らないけど
SIPはすべて漢字で使うことが決まってるのでそういう心配がない、とか?

SMPは最近もroadmapの5-1-5以降、1E8-1EFが新規にRTLになったりと
まだ流動的なところがあるからねぇ。

スクリプト固有の処理をするためのif文で最後のelseを忘れたとか
そんなところじゃないかな。

UnicodeのCJK漢字って自動的に字体が決まるんだよな？
漢字の後ろにコード追加して字体まで指定できる仕組みがUnicodeにあるとかいう
情報をどっかで見たんだが、ググってもそれらしいのが見つからんので

IVS

Win7にSP1 RCを入れてみたが相変わらずFirefox以外は>>302を表示できん…
でもOperaとIE9でも箱1つになったから半歩前進か

箱二つは萎えるよな

VistaだけどFirefoxでも正常に表示されない（箱+CP）。
IE8、Chrome(Iron)だと箱1つ。
Open Jane Doeだと何かそれっぽい記号が表示される。

>>416
Firefoxで表示されないのはフォントが入ってないから。
JaneはBMP外の文字にまともに対応してなくて表示されてるのは
BMPのぜんぜん違う文字

Jane何だそれ

日本語フォントなら確実に入っているだろうSMPの文字ってのが
現時点だとないからこういう時検証しづらいな

VistaからJIS X 0213が全部入ったんじゃないっけ？SIPなら試せるよね
http://www.faireal.net/articles/9/09/#d40626

>>420
SIPの文字はわりとどのブラウザでも対応してる
問題はSMP

>417
把握。
フォント↓入れたらFireFoxではちゃんと表示された。
ttp://users.teilar.gr/~g1951d/
IEやChrome、Janeは相変わらず駄目。

このスレの住民のFontsフォルダはものすごいカオスになってるんじゃなかろうか

>423
Windowsの場合は一々インスコせずとも、フォントビューアで開いている間は
一時的にフォントが利用できるようになるのをご存知か。

>>424
!!!

何その衝撃情報

>>424
あんたのおかげで今世界の見え方が変わった
ほんとだなにこれなにこれ

学問的知識が豊富な割に、一般的知識の無いお前らにワロた。
良くも悪くも学者気質だな。（褒め言葉）

そんなに一般的な知識だったのか…？

今後に役立つ知識を得たというのに、何故か凹むわ…

Win板とかのフォント関連スレではそこそこ知られてるかと。
でもまぁ凹む事はない。人にはそれぞれ得意分野があるってもんだ。
漏れもこのスレでは散々勉強させて貰ってる。

ありがとう。なんだかんだでここはいいスレだ。

今や伝統芸能の部類のUnicode叩き、UTF-8叩きも読めるしな

そういえば絵文字の国旗はU+1F1E6〜U+1F1FFのREGIONAL INDICATORを2つ組合せるんだったな。
例えば日本の国旗ならJに対応するU+1F1EFとPに対応するU+1F1F5というように。
JISX0213のか行に半濁点とかアクセント付き発音記号みたいにOpenTypeの合字機能使うんだろうけど、
BMP外だから現行では対応してないかも? IVSもそのやり方ではダメだったらしいし。
7SP1のUniscribeで対応するかな?

そんなもん、どうやって実装するんだよ...
現実的な方法で、現在のUnicodeの全文字を収納可能なカラー対応のフォントフォーマットってどんなんが考えられる？

SVGフォントとかどう?
文字の並びにグリフを与えられる仕様だし
65535グリフの制限も仕様上はないし
絵文字に必須のマルチカラーやアニメーションにも対応してるし
実装が対応してるかどうかは知らんが(つーかたぶんしてない)

OpenTypeは描画色の指定だけなら拡張可能かもしれないが
2色以上使うのは無理だろうな

マークアップの色指定と衝突したときどうするのかという問題もある

その辺は上位レイヤ優先ということで。

「指定によって色が変わる部分」と「最初から決まってる部分」で分かれるといいんだけどね。

国旗とかは旗竿と輪郭線だけ色が変わり、
旗の図柄は固定(でないと三色旗は判別不能になるし)とか。

携帯電話由来の絵文字で色指定が必要そうなものは
基本的にどれも「輪郭と中身」でデザインが構成されてるようにみえるから、
SVGだかOpenTypeだかにその指定方法が用意されれば問題ないとは思う。

SVGフォントは要するにSVGマークアップそのものがグリフになるから
色を明示的に指定しているところはその色になって指定していないところは
周囲の指定に影響されるんだろう

なるほど

異字体セレクタとか合字とか必要な文字って、どうやってフォントに入れてんの？

え？

>>441
フォント内のグリフは16ビットの内部番号で管理される。
異体字セレクターの組み合わせから内部番号への変換テーブルがフォント内にある。

ほー。

和文の縦書き・横書きは？

OpenTypeの場合「縦書きの時はこっちのグリフを使え」という情報を入れておく。

なるほど

内部番号を32ビットなり64ビットなりの固定長にして、それを文字コードの代わりに使ったら1文字のサイズが固定長になるんじゃね？

一文字64ビットとか許容できるリベラルな環境なら何も固定長にこだわる必要はないんじゃね？

漢字はそろそろ16bitの壁に迫りつつあるから何か考えないとまずそう

サロゲートペアをサロゲートトリオとして使うんだ

サロゲートリオ

猿芸トリオ

何ビットでもいいから、コード表は固定長にした方が明確な気がする。
その上で、UTF-8やらの可変長エンコーディングを用意する。

Unicodeだとコードポイントがその役目を果たしているよね。U+xxxxxのやつ。

>>447->>454
二十年前に逆戻したみたいなこのレス群は一体？

新人教育

珍人教育

>>454
合成文字、異字体セレクタ

漢字が16bitの壁を越えて一つのフォントに収まらなくなっても、
極東以外の人たちには他人事だからIRGが何か案を示さないと解決しないんだろうな…

IRGってそんなとこまで面倒見れるの？

16bitの壁なんて10年近く前のExtension B追加でとっくに突破してるわけだが。

455 名前：デフォルトの名無しさん[sage] 投稿日：2010/11/03(水) 20:54:27
>>447->>454
二十年前に逆戻したみたいなこのレス群は一体？

なんでそこを引用した

Adobeさんがフォント使いに付いては整理してくれてんじゃん。
>>459
「一つのフォントファイル」と言いたいの？

漢字といやぁ汎用電子はどうなった

JIS第5水準とか作るのかな
結構な量の地名漢字が採録漏れの憂き目に遭ってるだろ

常用漢字と勘違いしてないか？
ふつうの第2水準でさえ、存在しない文字まで収録しちゃったくらいだぞ。
補助漢字と第3第4でどれくらい収録してるかわかってて言ってる？

>>466
稀少地名漢字リスト JIS X 0213 / Unicode 外
ttp://pyrite.s54.xrea.com/timei/#other

この流れだと、こっちのスレに行った方がよろしい。
ttp://hibari.2ch.net/test/read.cgi/unix/1243343056/l50

>>467
誤字の疑いがあるのにUnicodeに収録されちゃってる字が…
まあ康熙字典の見出し字を全部入れた時点で譌字も入れる方針になったと
考えるしかないわけだが

>>469
CJK Ext-Dに入った字の日本からの典拠資料読んで凹んだわ
どう見ても手書きの転記ミスですありがとうございましたみたいな字が
平然と「これが使用例です（ｷﾘｯ」みたいに扱われてるんだもん

元が転記ミスだろうと用例ができちゃったものを無視もできないだろ。

誤謬の拡大再生産を広めるのはどうかと

これか
http://www.itscj.ipsj.or.jp/domestic/sc02/IRG_Editorials/IRG29/IRGN1367/IRG_N1367_Ref-1.pdf

日本語そのものにだって独擅場→独壇場や、一の腕→二の腕なんていう例は枚挙に暇がないし
もともと漢字そのものがそういう、半分は人から人へ移る過程で変化を遂げてきたものなんだし
細けえことはいいんだよ！

> 細けえことはいい
なら異体字むやみに増殖させないでくださいマジお願いします

>>473
卯の異体字だって知っていなければふしづくりだなんて絶対にわからんな

この辺読むと確かに「細けえこと」だな。
ttp://ja.wikipedia.org/wiki/%E6%96%B0%E5%AD%97%E4%BD%93

包摂できる誤記を入れているのは馬鹿としかおもえんが、
ゴミも入っていること前提で使うと割りきればいい。

ゴミといえば結局かみがしらに曾の典拠って何だったの?

> 細けえことはいいんだよ！

本当はそうなんだが、人の名前や会社名はとにかく正確に書かないと失礼だ、とか、
メールヘッダの To: に「様」と書くのが礼儀とか言い出す変な人がいるせいで、
変なことに変なことに。

メールヘッダはともかく、
俺が小学生の頃にはそういう風潮があったから、1980 年代ごろから？

名前を正確に書く風潮が出来たのは、「巨人軍は永久に不滅です」からと言ってみるテスト

現役〜1回目の監督時代には普通に「長島」だったよね

ありゃ新聞が漢字制限してるせいだ。

新聞も基準がわからないよなぁ。
篠原がシドニーでドゥイエに負けた時だけわざわざ異体字引っ張り出してきてた。

新聞の漢字制限が緩くなったことと、やたら変に文字にこだわる例が増えたことに相関はあるかもな。

長島が新聞紙面に載ってた頃は「漢字制限」の当用漢字の時代だったから。
常用漢字になってからその反動で漢字の字体に異常にこだわるような風潮が生まれた。
正字正仮名な人は「目安」なんて言葉は欺瞞でしかないと言うけど
ちゃんと影響はあるんだよ。

ここはfj.kanjiですか？

新聞は政府迎合、世論迎合、持論を自由自在に使い分けるからな。
持論なんてあってなきのごときだし。

RFC 6082でUnicode言語タグがdeprecteされたそうな

てか、似たような機能のものをいろいろな階層で俺も俺もと作んないでほしいよね

>>489
なんて素晴らしいw
10年でhistoricか。しかも使われてね─し。W3Cw

最近文字コード界隈の人らがすっかりtwitterにこもっちゃってるなぁ
EPUB日本語拡張の件なんかはブログでもやった方がいいだろうに

小形氏の新連載でも読んで我慢しなさい
http://internet.watch.impress.co.jp/docs/column/yoake/

仕分けられそうなんだって

国際標準であるEPUBの日本語拡張はしっかり官が後押ししてやるべきだと思うが、
中間フォーマットとやらは正直民間が勝手にやればいいことだろうと思うわ

>>493
そういえばcnetの方の絵文字連載ってその後どうしたんだろ
なんかもうちょっとやるって書いてたような

途中で切れたままだよなあ

やっているうちに整理付かなくなったんじゃないかな。
漢字だけでも大変なのに、絵文字なんてさらに枠が広がってるし。
動物顔文字じゃなくて、動物影絵文字でもいいだろって指摘とか。

小形が連載を途中でほっぽらかしにするのはいつものことじゃん。
ビット舟は完結したということになってるようだが何あの尻切れトンボっぷり

最近は電子書籍にかかりっきりっぽいね。
正直コンテンツプロバイダばかりが盛り上がっている感じがして
何が楽しいのか分からん世界だが。

汎用電子登録されたかー

HTTP bodyの文字コードをHTTP headerで指定するのは分かるんだけど
そのHTTP headerの文字コードはどうやって指定する/指定されるの？
ぐぐっても分からんので誰か知ってたら教えてください

http://www.studyinghttp.net/header#Utf8InParam

RFC2047だったかな。基本asciiでその他の文字集合がいる時は
B/Q encodingで埋め込むんだったはず。

>>504
それはHTTP用じゃない。
アプリ間で合意して使うのは構わないが、
HTTP仕様だけでencoding去れているっぽい文字列見つけたら、
decodeしていいと決まるもんじゃない。

やっぱりAJ1との統合/相補の道は選択しなかったか。

ｋｗｓｋ

・なんでAJ1と「重複」するグリフを削除すべきなのか不明
・具体的にどのグリフが「重複」しているのか説明がない
と言ってるな
http://www.itscj.ipsj.or.jp/domestic/sc02/hanyo-denshi/20100331/Responses-0910.pdf

>>507
WG2のn3590でUTC/U.S.は、AJ1と相互補完にするか
いっそAJ1-nとして登録することを勧めてた

これでAJ17に汎用電子の何を追加するかはKen Lunde側の仕事になるわけか

これでもしAJ1・汎用電子両対応のフォントなんかが出てきたら、
字形パレットに同じ字が複数出てくるのか…

あれ、アドビが汎用電子にある字形をAJ1に追加登録すると、
さらにIVD内での重複字形が増えるのか、もしかして。
アドビは手足が縛られてしまった？

>>512
「重複」しているものについては汎用電子のIVSを今までのCIDに追加するんでしょ。
AJ1のU+29FCEとU+29FD7とかAdobe Koreaの互換漢字とかもCIDは共有してる

言ってる意味が分からんが、汎用電子とAJ1で実際に重複してるのに、異体字セレクターが増えてしまったわけ。

おかげで、異体字セレクターは使い物にならなくなったよ？

今後AJ1が拡充されたとき、AdobeがIVCの更新をすると
IVD内の重複字形はさらに増えることになる可能性大だな。

ただAdobeには「今回AJ1に追加されたこのCIDの字形は、IVD内の
このIVSによって表される字形に対応する」と一方的に汎用電子字形への
マッピングを宣言する方法もあって、これならIVD内で重複字形は増えない。

IVD内で重複してないことが、なんか意味あるのか？実際のとこ。

Unicode全体でみて、グリフを一意に特定したいのが需要なわけで、それが使い物にならなくなったのは致命的だと思うんだよ。
別のものを作り直す必要がでてきた。

異なるIVC間での一意性は初めから保証されてない。
Unicode全体で誰ものニーズを満たすように一意なグリフの集合を作るのが不可能だから
IVCというアイデアが出てきたの。

別のものを作ったら同じ字形の選択を達成するのに取り得る手段がまた増えて
問題がさらに大きくなるだけだと思うんだが。
ただでさえOpenType tagと機能重複してるのに。

汎用とはついてるけど、実際は官庁や役所の需要さえ満たせりゃいいって考え方なのかな

電子書籍中間フォーマットの予算は仕分け人の
「国が推進することに意味はあるんですか?」「PDFじゃダメなんですか?」
の前に撃沈したようだな。

だから中間フォーマットっつうのはePubやPDFとは競合しないと（ｒｙ

>>518
今の異体字セレクターを段階的に廃止して、新しいやつに移行させればいいよ。
こないだの言語タグを廃止したRFCみたいに。
まだ全く普及してない今なら間に合う。

もうAdobe ReaderやFlashが実装してるし次期Firefoxでもサポートされるんだが。
実装が1つも存在しなかったUnicode言語タグとはえらい違い。
そもそもこれの何が「問題」なのかすら不明

>>521
大本営発表を垂れ流してるだけの小形の記事を鵜呑みにされてもね。
天下り先確保のためのガラパゴスフォーマットなど仕分けられて当然。

技術面と天下りがどうのってのは別問題だろ。まあ中間フォーマットとかガチでいらないけど。
（俺的には中間フォーマットよりCSS3 WritingがePubに採用されるよう働いてほしい。
それなら税金使っても納得する）

> CSS3 WritingがePubに採用されるよう働いてほしい。
> それなら税金使っても納得する
はげどう。でもRTLすら扱えないしシフトJISベースのXMDFを
国際提案するとか正気じゃないことを考えてるようで…。

>>522
それで済むならAJ1が「重複」するIVSをdeprecateすりゃいいだけじゃん
(汎用電子側が譲るとは思えないというか譲らないからこうなったので)。
規格自体を新たに設計し直さなければならない必然性が不明。

問題は字形の同定を誰がどう行うかだしな。仕様の問題じゃない。

"汎用電子側"って誰？なんで譲らなかったん？

情報処理学会SC2専門委員会

理由は>>508の通り
詳しくはこんな感じ

3.8 AJ1コレクションと似ているグリフの削除

理由は不明ながら、AJ1コレクションからIVDに登録された異体字形と似て見える
汎用電子の異体字形は削除するよう求めるコメント(訳注/単数形)がありました。
さらに言えばそのコメントは、汎用電子のドラフトのどの異体字形が似ていると
目されるかについて言及していませんでした。

登録者は、他のコレクションの異体字と重複して見える異体字の登録要請の
取り扱いを巡っていくつかの意見があること、そして一般原則にもとづく
決定として議論されること(訳注/ここ文意不明)を理解して"います"。

登録者は当面のあいだ、このコメントに対しては何もしないことにしました。

(´‥∀‥`)ほう

>>531
こういうことになるから、ちゃんと、みんなの意見を取り込んでセレクターを割り振るべきなんだよ。
なんで規格自体はそうなのに、異体字だけこんな訳の分からん閉鎖的なところで勝手に決められてしまうんだ。
それを納得する奴がいるってのも信じられないよ。頭おかしい。

パブリックレビューまでやってるんだから閉鎖的ってことはないんじゃないの

Han Unificationが話し合わえてたときには何も言わないで
後から延々と文句言い続けてる連中と同類か。
どうせ規格本体で符号化されてもされなくてもやっぱり文句言うんだろうな。

みんなで規格本体と同じレベルで話し合ってたら永久に何も追加できないよ。
だから登録者は他の登録者が何を登録するかを気にする必要はなくて
そのためにIVCを分けてるの。
http://www.unicode.org/reports/tr37/#w1aab7b1
> In the case of Han ideographs, it is impossible to build a single collection of
> variation sequences that can satisfy all the needs of the users. The requirements
> from scholars, governments and publishers are too different to be accommodated
> by a single collection. Instead they can be met by having multiple independent
> collections. The Ideographic Variation database ensures that a given variation
> sequence is used in at most one collection, to make interchange of text using
> such variation sequences reliable.

>>534
レビューに長々と説明付けて文句言っても、理由不明の一言で、元のまま通してしまう人が現にいたんだけど？
こんなものが規格なわけない。
迷惑だからオナニーは外字領域でやってろ。今のVSは符号位置を変更するべきだ。

IVDの中に、同じに見える字形が複数あって困る状況とは？

汎用電子の件にかぎらず、いい加減JSC2は国内の意見を
吸い上げる窓口を用意した方がいい
最近twitterで変体仮名に就いて面白い議論やってるけど
窓口がないとこれも無駄になりかねない

それは確か似そうだ

>>538
諸橋大漢和の文字をUnicode+VSで表現しよう、みたいな需要では困るだろうね。
その辺に興味があって、まじめに考えてたんだけど、汎用電子とか作ったバカのせいで、いま途方に暮れてるところ。
どうしてくれるの？冗談抜きで困ってるんだけど…

このスレにもマジで激怒してる人いるしねぇ

汎用電子そのものが間違いなの？？？？

1: 諸橋大漢和の字形をIVCとして自分で申請する
2: 諸橋にあってAJ1-6にない字形をAJ1に追加申請して、常にAJ1のIVSのみ使うようにする
3: 字形選択の優先順位を自分で決める(AJ1にない字のみ汎用電子のIVSを使うような方法)

>>542
明らかに既にある文字を、改めて追加したことは、責められても仕方ないでしょうね。

>>536が、議論してたら永久に追加できないとか述べてますが、実際はそうでもないでしょう。
そんなことを言ったら、Ext-A以降全ての文字が登録されてないはずだし。
もし異論が出て登録できない異体字があるなら、それは登録しないほうがいいんですよ。
登録したら何かしらの問題があるから異論が出るわけだから。
それを登録してしまったら、全てが手遅れ。

ま、民主的な議論て必要だよね。

#hengana面白いな
この感じだとKana Supplementは256じゃ足りなそう

>>537
少なくとも「重複するな」というコメントを出すのならば、UTS #37 のIVCが、積極的に
重複を肯定するような書き方になっているから、そこまで踏み込まなければならないだろ。
もしコメント者がIVCをまたがるIVDの使い方を想定しているならば、それはそもそも
>>536 の通り、UTS #37 の想定外の使い方だから、「規格を一回読んでから
コメント出せやヴォケ」と言われても仕方がないだろう。たぶん、 >>531 はそういうこと。
内容からして未来情報産業の人が出したんだろうな。。。

今後台湾や香港からIVCの登録申請があって、その中にAJ1と似た字があったら
それにも抗議するのかな

IVCを跨いで使いたいなら、シンプルに若い番号のIVSを使うとか、
自分でルールを決めるしかないと思うんだけど

IVDが重複を容認するとしても、結局重複したIVCをまとめる何かしらのレイヤは必要になるんじゃないのかな
それを勝手ルールでやれというのも一つの考え方だけど、将来的にはやっぱり標準化しましょうって話になるんじゃないかと

まあその辺は誰かが提案すれば可能性はあるのかも
ただ字形の同定って大変だよ

仕組みだけ作って「はいあとお願いね」じゃだめよ。
>>531にもあるけど、具体的にどの字形が同じに見えるのか
自分で調べてリスト化して、それを提示するまでしないと。

その上でIVDの上位レイヤー(IVC間の正規化?)なるものを提案すれば、
議論が始まるかもしれない。もちろん今後のため、字形の同定方法も
示す必要あり。

大変そうだろうけど、でも自分の考えを規格に反映させるってのは実際大仕事よ。

字形乱発については、電子出版が主戦場になるだろうから、
いろいろ試すには金のかかるテーマになるなあ。
リーダー、端末、クリエーターを揃えきれないよ。

うーむ

フォントにたいする理解が不足しているんだろうなぁ

ふぉんとにそうだね

10646は2nd Ed.がまだなのにもう3rd Ed.のPDAM1登場なのか

Second Editionが発行されたらJIS X 0221も改訂すんのかな。

そういえばそんなのもあったな。
「イェ」はどういう扱いになるのかな。

こんなの見ていると同字形の判定なんて嫌になってくるな
ttp://www.forest.impress.co.jp/img/wf/docs/411/177/html/image1.jpg.html

空とか沈とかはくっついてるくっついてないだけ？すごいな…。

なにこの間違い探しw

むしろ明らかに分かるほど違った方がおかしいが…

これか
ttp://www.forest.impress.co.jp/docs/news/20101202_411177.html

常用漢字表を作るのに使うからとデザイン変更を頼まれて、
その際のフォントを新版としてリリースしたってことなのかな。

IPAexだけなのか。
無印フォントのほうは過去との互換だけのための位置づけになったのかな。

常用漢字表には明朝体しか載ってないから。

？

無印の明朝もexのゴシックもあるんだが

常用漢字表に使われたってことで、今後IPA明朝の字体が
規範みたいにならないといいんだけど。

「規範の一つ」には普通になるだろうし、なって困ることもないだろ。

IVS技術促進協議会って面白そうだけど具体的に何するんだろ

う〜ん、よくわからん。
ttp://ivstpc.jp/

>>558の違いが読み取れる人間を育てる

おっ。汎用電子アップデート予定ありか。

>さらに現在作業中のものも含めると、5000字形がIVSに入る可能性があるとしている。
ttp://internet.watch.impress.co.jp/docs/news/20101206_412176.html

>>558
さっさと、意味上に違いのない異体字の使用を強要する人間をどんどん取り締まればいいのに。
吉野家とか、高島屋とか。

おまいが始皇帝になればおk

都知事が新たな始皇帝になりたがってるみたいじゃん。

IVS対応のメイリオってのはイメージできるけど
IVS対応のMS明朝/ゴシックって何かイメージできない

とりあえず天下りっぽいのはいないな
http://ivstpc.jp/directors.aspx

>>576
そもそも、MS明朝/ゴシックの怪しげなグリフは、IVS付けられないものもあるぞ。

>>577
JSC2の人脈っぽい面子

そこは発想を逆にしてそれを登録するんだ

MS明朝/ゴシックで刷られたものってそれなりにありそうだし、
案外冗談で済まない日が来るのかも。

仮名もIVSみたいな仕組みがあればいいのに。

さいたま市の「さ」を正しく表記したりするのに必要なわけですね。

上が「一」の「そ」と「ソ」の「そ」とを区別するのに必要なわけですね。

でも元となる漢字が違う変体仮名については結局少なくとも1つは符号化が必要なわけで

漢字以外にもVSを使う仕組みは規定されてる。
その場合漢字と違ってBMPのVS(モンゴル文字の場合U+180B〜U+180D、他はU+FE00〜U+FE0F)を使うが。
今のところモンゴル文字とパスパ文字、数学記号が規定されている。

なんで漢字とそれ以外でVSを分けるのかがよくわからない。

別に漢字でBMPのVSを使ってもよかったんだろうけど
VSがBMPになる最初の16個のIVSの取り合いになるのを恐れたんじゃないの。

そういうことか。渡辺さんたちは大変だ。

変体仮名にVSなんて使わない方がいいと思うけどなぁ。
Variation扱いの字形は10646の表に載らないから、どれがprimaryな字形かを
判断しなければならなくなる。

もう、くずし元漢字のバリエーションってことにしちゃえよ＞Hentaigana

JISならともかくUnicodeでscriptの違いを超えたunifyなんて
提案したら多分他国から鼻で笑われる

何というﾏｼﾞﾚｽ

相談させてください。

メルマガ配信システムを使って、メルマガを配信しています。
機種依存文字が文章内にあった時に、送信せずにエラーで教えてくれる仕組みなのですが
文章内に一行余計な空行があったので、消しただけなのですが、「機種依存文字が含まれています」と出てしまいました。

何故でしょうか？どうしたら直るでしょうか？

>>594
すれ違い
こっち行け
http://hibari.2ch.net/test/read.cgi/tech/1291075205/

>>594
この人に聞けば直るよ
http://twitter.com/void_No3

>>594
とりあえずプログラムを書け。

>>594
メモ帳でUTF-16かBOM付きUTF-8で保存したに１ジンバブエドル

0x8FB8B5 は eucJP-ms で「塤」ですが、
0x8FB8B5 が書かれたページをIEで開き、エンコードを日本語（EUC）にすると、「曙ｳ」になります。
しかし、「曙」はCP51932でもeucJP-msでも0xBDECとなっています。
一体どのような文字コード（または変換）が使われているのでしょうか？

CP51932やCP50220はGL/GRの範囲内のコードポイントを
まず計算でShift_JISに変換してからCP932でデコードする。
だから
8F B8 B5
｜8FはGL/GRに含まれないのでそのまま、
↓B8 B5をEUC-JPの1文字としてShift_JISに変換
8F 8C B3
↓8F 8CはShift_JISで「曙」、B3はShift_JISで「ｳ」
曙ｳ

有り難うございます！

＞曙ｳ

発音してみたらなんかかわいかった

>>602が発音してるところを想像したらなんかかわいかった

>>602が発音してるところを>>603が想像してなんかかわいいと思ってるところを想像したらなんかかわいかった

この流れを応用しUTF-8エンコーディングが生まれた

感動した

0xFCEE 0x8FB8B5 を日本語EUCで表示した時、
MSIEだと「�K曙ｳ」になり、
MSIE以外（Firefox, Opera, Chrome）だと「�K塤」になります。
※0xFCEE は CP51932 で「�K」（eucJP-msでは「」）
※0x8FB8B5 は eucJP-ms で「塤」（CP51392 には存在しない）

これらをPHPで再現しようとしているのですが、中々思い通りにいきません。
（試作品： http://www1.axfc.net/uploader/Sc/so/187780.zip）
正しく再現する良い方法は無いでしょうか。
iconvやnkfなどで処理できればいいのですが…
よろしくお願いします。

>>607
©�K塤
8F A2 ED FC EE 8F B8 B5
↓8Fはそのまま、EUCのA2EDはSJISで81EB、EUCのFCEEはSJISでEEEC、
↓8Fはそのまま、EUCのB8B5はSJISで8CB3
8F 81 EB EE EC 8F 8C B3
↓8F81はSJISで「潤」、EBEEとEC8FはCP932で未定義なので「・」、8CB3はSJISで「元」
潤・・元

何が難しいのかわからん。
強いて追加でアドバイスするなら1パス目と2パス目では文字が違う場所で
区切られる可能性があることに注意しろというくらい(だから2パス変換が必須)

あと1パス目のEUC→SJIS変換は未定義のコードポイントでも8145にしてしまわず
計算で変換してくれるようなものが必須。
(PHPのmb_convert_encodingがそうなってるのかは知らん)

有り難うございます。
0xFCEEをCP51932としてCP932に変換すると、0xFC4Bになり、
EUC-JPとしてCP932に変換すると、0xEEECになるようです。
MSIEで使用されているのはCP932だと聞いていたのですが…
混乱してきました。そもそもPHPでのEUC-JPが一体何なのかよくわからない…

× CP932だと聞いていたのですが
○ CP51932だと聞いていたのですが

ああそうか
CP932ではNEC選定IBM拡張文字よりIBM拡張文字が優先されるんだった
それでEEEC→FC4Bに変換されるけど、>>608の1パス目の変換ではこの規則を
適用しちゃダメ。あくまでも計算でコードポイントを置き換えるだけ。
しつこいよーだがmb_convert_encodingでそれができるかどうかは知らんので
最悪、自分で計算する必要がある。

うぅ　計算式がわかりません
%systemroot%\system32\*.nls がMSIEの変換表っぽいですが、どう使えばいいのやら…
c_932.nls, c_20932.nls はあっても、c_51932.nls は無いし

少しは自分で調べろよ…。
<?php
function euc2sjis($e) {
$e = unpack('C*', $e);
$h = $e[1];
$l = $e[2];
$c = ($e[1] - 0xa1) * 94 + ($e[2] - 0xa1);
$h = (int)($c / 188);
$h += ($h < 31) ? 0x81 : (0xe0 - 31);
$l = $c % 188;
$l += ($l < 63) ? 0x40 : (0x80 - 63);
return pack('C*', $h, $l);
}
echo preg_replace("/([\xa1-\xfe]{2})/e", 'euc2sjis("\1")', "\x8F\xA2\xED\xFC\xEE\x8F\xB8\xB5");
echo preg_replace("/([\xa1-\xfe]{2})/e", 'euc2sjis("\1")', "\xFC\xEE\x8F\xB8\xB5");
?>
PHPインストールしてぐぐりながら40分で作れたぞ。

> c_932.nls, c_20932.nls はあっても、c_51932.nls は無いし
mlangはCP51932を内部計算でSJISに変換して(「1パス目」)、c_932.nlsを使ってるから。

(´‥∀‥`)ほう

2chニュースは時事ニュースがとんでもなく面白く理解できる。
難しそうではあるが気になるニュースタイトルに飛んでみると記事に対する2ちゃんねらー達の面白い書き込みによってニュースの内容があっという間に理解出来る様になる。
おれは今まで半ば義務感でニュースをサイトなどに目を通していただけなのだが、2chニュースのお陰で仲間の誰よりも時事問題の先端を行く様になってしまった。もはや中毒気味になる位にニュースが毎日楽しくて仕方ない。
ここでは敢えて四つしか取り上げないが、2NNサイト内であればどの掲示板でもRSS生成が可能。
サイトを覗くだけでも良いがRSSリーダーで効率良く情報収集する人ならばこちらがオススメ。(RSSリーダーは各デバイスに応じた専用アプリ・ソフトがある)

またTwitterでも2ch botがある。Twitterは各デバイスに応じた専用クライアントソフト・アプリを介して使用するのが便利。興味が有る人は各々調べて貰いたい。

●2ちゃんねる ニュースサイト(RSS生成可)
2NN新着http://www.2nn.jp/latest/
2NNトップページhttp://www.2nn.jp/
2NN今日のニュース http://www.2nn.jp/ranking/today/
2NN祭級ニュース http://www.2nn.jp/matsuri/

●2ちゃんねる ニュースサイト(RSS生成不可)
2ちゃんねる BBY(各ニュース板における前日までの新着スレッドが一望出来る)http://headline.2ch.net/bbynews/
2ちゃんねる 全板縦断 勢いランキングhttp://2ch-ranking.net/index.html?board=zenban
?page=click_linklog_view.daily_ranking&

何？

2ch に書かれることこそがニュースの真実とか思ってる情弱だろw

マルチポストにレスしちゃう男の人って……

男とは限らないぞ

えっ

なんかかわいいな

…///

>>614　有り難うございます。
半角カタカナの処理が抜けているようなので、
/([\xa1-\xfe]{2})/e を /(\x8e[\xa1-\xdf]|[\xa1-\xfe]{2})/e に置換して、
euc2sjisの頭に
if (preg_match('/^\x8e[\xa1-\xdf]$/', $e))
return preg_replace('/^\x8e[\xa1-\xdf]$/', mb_convert_encoding($e, 'SJIS-win', 'CP51932'), $e);
を追記してみました。
まだまだ知らないことだらけですが、精進します。

ああすまん半角カナのことをすっかり忘れてた
> return preg_replace('/^\x8e[\xa1-\xdf]$/', mb_convert_encoding($e, 'SJIS-win', 'CP51932'), $e);
return preg_replace('/^\x8e([\xa1-\xdf])$/', '$1', $e);
でいいんじゃね? 試してないけど。

つーかpreg_replaceもいらんな
if (preg_match('/^\x8e([\xa1-\xdf])$/', $e, $matches))) return $matches[1];
どうしたらあんな冗長なコードを思いつけるのか非常に興味がある

n3698は文字鏡の丸パクリかよ…。これだから外人が無造作に出してくるものは(ry

誰かが出さなきゃトリガーにすらならんからなぁ
もっとも出典は書いといた方がよかったけど

今年になってから元気がないなここわ

>>628
日本NBは人の足引っ張るだけだしな

それは本当にそう思う

さっきからコメントに出ている「NB」て何？日経ビジネス？

↓面白いボケを

Non-Breaking space
別名 nbsp;

それが面白いと思った>>634に脱帽

一同脱帽

かぶってねーよ

漏れの棒は被ってる

http://groups.google.com/group/boost-developers-archive/browse_frm/thread/deed8f95125dce02
多少の移行の問題は受け入れて std::string は基本 UTF-8 ってことにしちゃおうぜ、
って話がこないだから boost の ML でさんざん飛び交ってる。

具体的に何とは言えないけども、不安だ。

localeであるべきだよ

しちゃうまえに、とりあえず作れよと言いたい。

日本ＩＴ界の鬼っ子「外字問題」解消を　経産省が着手
ttp://www.asahi.com/national/update/0120/TKY201101200591.html

>>642
> 法務省が幅広い電子化を目指して０４年にまとめた「戸籍統一文字」（５万
> ６０４０字）をもとに５万８７１３字のデータベースを作る。世界共通の文字
> コード体系「ユニコード」に反映させ、あらゆるコンピューターで人名や地名
> を網羅する狙いだ。

VSでやるのかね?

>法務省が幅広い電子化を目指して０４年にまとめた

年金記録の消失と名寄せで騒いでた時期と一致するな

>>642
>　外字の存在はネット上の同じサービスを大勢の個人や企業が共有する「クラウド」化を妨げ、
>日本が世界的な流れに取り残される原因にもなりかねないとされ、解決が急がれている。
>政府側でプロジェクトを統括する経産省の平本健二さんは「１９８０年代から続く問題を解決したい」と語った。

まずは Windows の日本語 locale の mbcs を UTF-8 にすることから始めようか

汎用電子とは違うの？

新手のプロジェクトじゃないかと。

>>642
> プロジェクトを進めるのは経済産業省と大手ＩＴ企業。民間側の協議会は昨年
> １２月６日に発足し、コンピューターで日本語を扱うのに不可欠なソフトを作っ
> ているマイクロソフト、ジャストシステムなど９社・団体が加わった。マイク
> ロソフトの加治佐俊一ＣＴＯ（最高技術責任者）は「外字問題という、世界で
> も例のない日本固有の問題が解決に向かう」と語る。

新たな不幸の始まりの気がする

これのことだよな
ttp://internet.watch.impress.co.jp/docs/news/20101206_412176.html

民間のってのはそれだろうね
ってかJSC2の連中はやりたくないのかよ>>642

Adobe入ってるなら今よりひどくはならないだろうな。

Googleは入ってないのか

ttp://www.asahi.com/national/update/0120/TKY201101200591.html
の２ページ目

>　一方で、懸念の声もある。

>　国立国語研究所の高田智和准教授は「戸籍や地名にはすでに使われていない異体字や誤字も多い。
>いたずらに使える字を増やすのでなく、使われているかどうかで仕分けるのが先ではないか」という。

>　プロジェクトが完了すれば、パソコンの日本語変換で「渡辺」の候補は現状の３から一気に２２に増える。
>ＪＩＳ規格を決める際、多くの異体字を集約した東京外語大の芝野耕司教授（言語学）も
>「多くの漢字が画面上に並ぶ中から、延々探せというのか。漢字を増やすことはコンピューターにとって
>意味のある行為かも知れないが、人にとっては使い勝手が悪化するだけだ」と話している。

二人ともUNICODEの異体字を誤解しているような発言だぬ


ttp://internet.watch.impress.co.jp/docs/news/20101206_412176.html
こっち読めば良いのにね

その二人はJTC1/SC2の日本の委員だよ
ttp://www.itscj.ipsj.or.jp/meibo/020000.pdf

使える字を増やしたくないのに、文字を追加するプロジェクトにいる不思議

ttp://ivstpc.jp/directors.aspx
IVSの協議会はMSが割と乗り気なのかな。
いずれIVS対応の明朝版メイリオみたいなフォントが来ればいいけど。

Win7はIVSの枠組み出来てるから、
データの蓄積をしたいわけだよね。
それも役所が使ってくれるやつ。
MSジャパンは官庁、教育機関への食い込みに力入れていて、
現地法人では唯一CTO置いているくらいだし。それが>>647の人。

>>653
>「多くの漢字が画面上に並ぶ中から、延々探せというのか。

例えば異字体選択パレットの字形の並び順を、現代の日本で最もよく使われているものの
順に表示するようにすればいい。
他には、あまり使われていない字形は [その他] をクリックするまで表示しない、でもいい。

んで、それは文字のコード化レイヤーの話じゃなくて、アプリケーションのUIレイヤーの
話なのだから、それをもって異字体のコード化をすべきでないという議論はおかしい。

>　国立国語研究所の高田智和准教授は「戸籍や地名にはすでに使われていない異体字や誤字も多い。
>いたずらに使える字を増やすのでなく、使われているかどうかで仕分けるのが先ではないか」という。

国語研究所のひとなのにこんな暴言吐けるとは・・・
古典に載ってる地名なんかどうするつもりなんだろう

字形の上では AJ1 ∪ Hanyo-Denshi ⊆ 経産省新外字、を満たすが、マッピングが単射
でないとか、親字のコードが違うとか新たなカオス発生の悪い予感が…

>>658
まあ、戸籍統一文字は大漢和なんかで「誤字」とされていないものを
片っ端から収録しているだけで実際に使われているかどうかは調べていないので、
戸籍の電子化だけが目的ならオーバースペックなのは確か。

>>654
> 使える字を増やしたくないのに、文字を追加するプロジェクトにいる
なるほど、増やしたくないから足を引っ張るためにそこにいるのか。
>>630-とつながった

>>658
だよな。たとえ誤字であろうが今使われていない字であろうが、
過去に使われたことがあれば、必要になってくる場面というのはありうるわけだし。

安岡さんとこにリンクあった
ttp://ossipedia.ipa.go.jp/article/9/

ふむ…

>>662 現在も過去も使われた形跡なんかない文字、おそらくそこにしかない誤字でもなんでも
登録されてたりするから問題なの。

あと常識として、国研ってのはもともと漢字制限の研究のために設立されてるから。

移管じゃなく完全に解体すべきだった

JISに親字すら登録されてない文字があるから、
IVSの枠組みで全部やろうとすると、
JISに文字を登録する必要があるんだな。

各市町村で勝手に臨時フォント作ってたら品質にばらつきが出るだろ

議事録面白い。発言者名が削除されているのはつまらないけど。

Win7のレンダリングはIVSに対応してるらしいがNLSが未対応なので
CompareStringExなんかがIVSを無視してくれない。
BMPのVSはちゃんと無視するのに

ややこしいよう

>>670
レンダリングが対応しているって言うけど、どのAPIなら大丈夫で、
.NET(WPF)やSilverlightならどうなっているかって情報が、MSのサイト見てても全然わからん。
もしまだ無いなら自分で全部まとめようかと思っているんだが、誰かがすでに
まとめている所ってある？

外字は DNS で管理すれば良くね？

漢字だけで58000字以上ものグリフ集合なんてフォントメーカーは対応できるのかねえ

でもお高いんでしょ？

10万円コースかな・・

安！！

>>674
共通フォントデータベース作るなんて話になってるが。
まあ役所の戸籍の話だと思うが。

フォントは今入札やってるんだっけか
できたフォントを役所の中だけで使うのか一般配布もするのか注目だなぁ

ttp://bizpal.jp/epub/00012
>同じグリフをどのように扱うのかどちらかに寄せるのか？その場合のマッピングは？
>IVS技術促進協議会よりマッピングテーブル、実装ガイドの提供を予定

AJ1と汎用電子とでグリフがダブってる件に対する問題意識はあるみたい

>>672
ないんじゃないかな

>>676
インデックスフォントの価格を考えたら
印刷物クォリティのフォントはそうなるよな

>>672
自分の知ってる範囲だと
DirectWriteはOK
UniscribeもWindows 7かOffice 2010付属のものならOKだが
ScriptItemizeの第4引数にSCRIPT_CONTROL構造体を渡してfMergeNeutralItemsを
1にセットする必要がある。さもないと互換性のため従来どおりIVSの手前でrunが
分割されるので正しく描画できない。
通常はNULLを渡すので修正が必要(DLLだけ入れ替えても対応できない)

>>680
> 別々に登録した背景
> それぞれの出典などの同定、整合性
たとえばCID1125〜7477とJA****はどちらもJIS X 0208-1990が由来で
しかもかつてのAJ1のTechNoteは平成明朝体そのもので印刷されてたんだから
対応することは自明だろ…と思ったら安岡先生に先を越されてた。
http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/

>>684
字形の出所にまで遡らないといけないのか…きっついなー

>>685
むしろ実際の字形を一切見なくてもマッチングが取れるんでかえって曖昧さがなくて
簡単かもしれない。
もちろんCID+8686とJTBE75の起源を実際に確かめようとか思ったらえらいことになるけど。

そういうのを協議会で決めるんだろ。叩き台は安岡さんが既に作ったし。
ベンダーだって、コストがバカにならんから新たに作るグリフはなるべく減らしたい。

安岡氏に限らず、こういう細かいの大量にチェックできる人ってどんな頭してるんだろう(褒め言葉)

( ＾ω＾)

>>588
> 安岡氏に限らず、こういう細かいの大量にチェックできる人ってどんな頭してるんだろう(褒め言葉)

こんな頭してる。

1文字のチェックに15分かけたとして一日に32個
58000個もあれば、1,812日かかるから
7年は食いぶちに困らねぇなw

Ken Lunde氏の対応表
http://lundestudio.com/IVD/hd2aj1-mapping.txt
漢字データベース計画の対応表
http://kanji-database.cvs.sourceforge.net/viewvc/kanji-database/kanji-database/data/hd2cid.txt?view=log
これらは字形ベースでマッチング

>>690
今年度中にフォント完成させろとかいう超強行スケジュールなんだが?

漢字データベースの方はサーバが今落ちているっぽいな。
http://sourceforge.net/apps/wordpress/sourceforge/2011/01/27/service-downtime/
github に退避しているみたい。

JIS X 0208/0212/0213 の規格書字形でAJ1-6と汎用電子が重複するのは由来からも明白だな。

メーカー外字由来の文字もそこそこかぶるだろうけど、住基文字はどのメーカー外字に対応している
かは公表されてないし、一旦平成明朝にする時点でデザイン変更されているものもあるだろうから、
これは目視で確認するしかないな。

問題はやはり登記統一文字とAJ1-6でかぶるやつだな。これは追跡が大変そうだ。

無能な権力者ほど文字をいじりたがるな

>>23
> （例：淡淡と淡々、どちらもあっさりした味わい）
> （○○会会長、△△家結婚式式場、これ等は踊り字を使うのは間違い）
というのが基本だというのは理解できるけど、例外なんていくらでも…

> 同じ漢字を直接繰り返すことは、再婚や不幸の繰り返しを連想させ縁起が悪いため、
> 「結婚式々場」、「告別式々場」と表記することが多い。

ふつう結婚式場じゃね?

△△家結婚式場だと△△家が所有する式場みたいじゃね

おまえんちの本家も式場ぐらい持ってるだろ？

Firefox 4: WOFFでIVS対応、SVGフォントは対応を拒否
Opera: Win7ではWOFFでIVS対応、SVGフォントはHTMLから使えない
WebKit: SVGフォントでIVS対応、SVGフォント以外はIVSどころか結合文字すら
　まともにサポートしていない。SafariにいたってはSIPの漢字すら豆腐になる

結局こいつら協調する気ないんだな。
WebKit/SafariはWindows上の話なのでMacやモバイル端末ではもう少しマシかも

現状ではOpenTypeフォントをそのまま使うのが一番安全
でもFirefoxはなんでSVGフォント拒否なんだろ

どこが安全？？？

Firefox, Opera, WebKit全部対応済みだしIEも9で対応

実際んとこ、IVS含め全部網羅した東アジアフォントってドンぐらいのサイズになるんだろう

glyphwikiの6卍フォントで16MBくらいだったかな
アウトラインをpostscript化して整えればもう少し小さくできそうだけど

ううむとうなるサイズだな

>>702
IVSを使えるかどうかは別問題
つーかFirefox 4以外OpenTypeフォントのformat 14 cmap subtableに対応していない。
WOFFと変わらない

当面は {基底漢字+VS} をリガチャとしてGSUBにも突っ込んどけば

format 14 cmap subtableが提唱される前にそれ試したことがあるけど
少なくともUniscribeはBMP外の結合文字に対応していなかったようでうまくいかなかった。
Win7でもformat 14 cmap subtableを使うことが前提なのかうまくいかないみたい。
VistaではGSUBリガチャを使ってた数学記号やパスパ文字用の異体字も
Win7ではformat 14 cmap subtableを使う方式に置き換えられた

国旗はどうするのかな?
SMPにある符号2つの組合せで表されるみたいだけど。

チャートの説明では、「Regional Indicatorを組合わせたものには、
国旗を表すグリフが宛がわれることもあるかもねー」って感じになってる。

国旗は政治的な問題が絡んできかねないから、多分国旗を直接符号化した
という形にはしたくなかったんじゃないかと。

要はTW問題対策か。

ケータイ会社がテキトーに作った絵文字のおかげで
世界をこんな難題に巻き込んでしまったことを考えると
日本人の一人としてとても申し訳ない気持ちになるが、

……その当の日本の国旗はというと
建国記念絵文字の旗竿付き日の丸としてちゃっかり同時に、
国旗符号とは別枠で入ってるんだから乾いた笑いが止まらないｗ

軍艦旗も入れとけばよかったな

>>711
日本地図や、渋谷駅前のモニュメントを記号化したものまで入ってるしな。
ガラパゴス絵文字をほぼそのまま取り込んだんだからある意味当たり前ではあるが

Regional Indicatorは14面の文字じゃないのか…。
14面の文字だとそれ自体は表示されないんだっけ?

Tフォントついにキター!
http://charcenter.t-engine.org/tfont/index.html
> 3. Tフォントの再配布は、無改変かつ非営利に限り、これを自由とします。
> その際には出所ならびに権利標記を必ず添記して下さい。
> T-Font (C) Sakamura-Koshizuka Laboratory, The University of Tokyo
> http://www.sakamura-lab.org/FONT/
出所を書くのはいいけどそんなURLで大丈夫か?

アパッチはNot Foundと言っている。

2005年12月の発表時はこのURLで公開すると確かに言ってたんで
http://www.t-engine.org/news/pdf/TEP051213_u18.pdf
利用規定の直し忘れじゃないかと思うんだが

Proposal to encode two Right Indic Kana variants in the UCS
イ KATAKANA LETTER GAMEST HA
人 KATAKANA LETTER GAMEST RU
Source: http://dic.nicovideo.jp/oekaki/12242.png
みたいなこといつまで続けるんだろうね。

話のすり替え乙

何が?

誰かの手書きの誤字が「典拠」として収録されてしまうって現状そのものじゃん。

ュ KATAKANA LETTER GAMEST E
ラ KATAKANA LETTER GAMEST HU
ウ KATAKANA LETTER GAMEST RA
上 KATAKANA LETTER GAMEST TO

ラとかウに似たカナを提案するのは危険

また国語審議会の人が怒るのか

「ネ」と「申」を組み合わせて1文字として扱うのは、濁点の仕組み使えばできるかと思うのだが、
「神」という文字を2文字として扱うにはどうすればいいんだ？

NEMOUSU TV

2channeler decomposition mapping が必要だな・・・

ノ＼゛力

>>727
decompositionじゃなくてcollationで
contraction(2文字を1文字として扱う)も
expansion(1文字を2文字として扱う)も可能

悟リ の分解再構築が可能になるのか

フォントの合字でやれよ

まさに'dlig' featureの出番

何だこの流れｗ
みんな蝦を持て余してるんだなｗ

http://www.sakamura-lab.org/FONT/
にリダイレクトが設置されてリンク切れが解消された。
今はリダイレクト先が落ちてるけど

ぐだぐだだなｗ

復旧したようだ

IE9 RCがIVSに対応してた。イヤッッホォォォオオォオウ！(AAry
Firefox同様SVGフォントには未対応なのでWebKitとそれ以外の陣営に分かれたようだ。

どんどん混沌としてくるなあ

>>302やARIB外字の非漢字はIE9 RCでも相変わらず箱だった…。

Win7のレンダラに丸投げしているだけでは。

>>740
SP1 RCを入れてるからメモ帳では花園明朝を選べば表示できるんだよ。
IVSもIE9 betaでは駄目だったのでDirectWrite使うだけでうまくいくわけではないみたい

あ、CSSでフォントを指定したらIE9でも表示できた。
フォールバックがショボいのか。

ふむ

指定されたフォントが、あるIVSに対するグリフを持っていなかった場合のことは、
今のところ実装依存なのかな。
基底文字用のグリフでOKとするのか、別のフォントへフォールバックするのか。

難しいな

今のところWebブラウザでフォールバックするものは存在しない

俺の頭はフォールバック中だ！

http://std.dkuug.dk/jtc1/sc2/wg2/
がNot Foundになっとる
http://std.dkuug.dk/Jtc1/sc2/wg2/
とかわざと1文字変えるとMultiple Choiceになるから
実際には削除されてないと思うんだが
いったい何が起きてるんだ

繋がらなくなることは最近よくあったけど404は初めて見た。

長いね
コンビーナが気づいてないのかな

復活
http://www.dkuug.dk/JTC1/SC2/WG2/docs/n3987.pdf
Adobe-Japan1に収録されている小書き「こ」と小書き「コ」の追加提案キタ

小書きの「こ」もゖの次じゃなくてSupplementの方なのね

その辺の使い分け基準がどうもよくわからない

ワンブロックにひらカタ両仮名が規則性もなく混在ってのも何だかなあ

中黒と長音符がひらがな、濁点がカタカナにある時点で最初からおかしい気がしてならない

そのへんは何であそこに入っちゃったんだろうな。
3000〜303fのが良さそうなのに。文字名にHiraganaとかKatakanaって付いてたせいか。

U+3040,3097,3098はもう永久に埋まらんのかな?

ドイツ人はβの位置で悩んだり愚痴ったりしないのかな

ベータの位置で悩んだり愚痴ったりはしないだろうな
エスツェットの位置で悩んだり愚痴ったりはするかもしれないが

日本は10646 2ndに反対票入れたのか・・

さすが文字を増やしたくない連中のすくつだな

Unicode listでUTF-cにマジレスしてる奴は
日本人のくせにUTF-9 (エイプリルフール版じゃない方)も知らんのか…。つーか
> In your proposal, the maximum length of the coded character
> is 4, it is less than UTF-8's max length.
UTF-8の最大長は(Unicodeでは)4バイトだろ。何言ってるのこいつ

まあJSC2の人だから、と思ったけど今は10646でも4バイトなのか。

5バイト、6バイト長になるとこは使わないことになったんだっけ?

言い分は解るがFDISで反対票ってのはなぁ
3rd ed.がすぐうしろに控えてるんだから
もっと穏当なやり方あったろうに

FDISってことはもうWG2の手を離れてふつーならシャンシャン投票になる段階か。
JIS X 0213:2000のときも親委員会でもめたな

Unicode 6.0のmulticolumn chartもちょっと見れば分かるような間違い満載だし
(U+20534あたりとか)まあ気持ちはわかる。
しかしこれを鵜呑みに実装されたらと思うとワロエナイ

票読みはした上でのことだろうけど万が一否決されていたら
2版そのものがパーになったわけで

棄権してコメントはwg2にポストする方が他国の心証はよかったんじゃ

JTC1/SC2ではMember bodyに拒否権がなくてよかったな

殺伐としているなあ

Unicode 6が全chapter完成したそうだ。

BookmarksはまだだけどもうPDFは読めるね

守岡氏(@MnjaMnja)が何をあんなに悩んでるのかよくわからん。
字体・字形の禅問答を避けて「base characterで表現するのが適切なグリフの集合の
部分集合」と定義しているUTS#37のほうがよっぽど形式的(formal)だと思うんだが。
# 前半の「集合」がwell-definedかどうかはまた別問題

なんかグリフをネット公開するだけでにユニークコードくれる団体とか、そのコードの規格とかってないものかな？

しいて言えばトロンコード？
郵送しなきゃいけないようだけど番号は機械的にくれるみたい

ISO/IEC 10036 (原則有料)
IVDもMember bodyに対して無条件に登録料棒引きとかするなよ。
有料なら無駄に税金使うなと圧力掛けられたのに。
(同じかどうかわからないから無駄じゃないと言い張るだろうが登録料に
引き合うだけの効用があることを証明する必要が出てくる)
まあIVD登録の方に誘導したかった気持ちはわかるんだが

Win7 SP1が出た
ようやくARIB外字フォントや絵文字フォントが使い物になるのか

絵文字フォントついてるの？

付いてないけど今までWin7では作っても(Firefox以外で)表示できなかったのが改善された

とりあえずジョークRFCでいいから、架空文字とかをユニークコードとして扱える規格が出ないものかなあ？

128bitくらい空間を用意しておいて(IPv6のULAみたいに)
ランダムに使うことにすればほとんどかぶることはないって誰か言ってたな

16バイト文字コードに既存のコード全部ぶち込んで、適当な圧縮で改行単位とかでパックすれば縮んて、意外と実用的になったりして？

>>780
ちょっと違うかもしれないけど、こんなのならある
ttp://evertype.com/standards/csur/

Logoで亀に書かせる方式にすれば、どんな文字でもかけるんじゃね？

はいはい、表現したい文字を書く最も短いLogoプログラムが
文字コードになるわけですね？チャイティンさん。

>>764
10646 2ndでは定義域が完全に0000..10FFFFに定義され直して、群(Group)の概念は
黒歴史になった。U-00000000形式の8桁表記も廃止された。
もちろんUTF-8も4バイトまでしか定義されていない。

じゃあ一体存在意義は何なんだ

>>784
ttp://www5.puny.jp/uploader/download/1298007172.zip
turtle

10646 2ndのdecomposable characterの定義がすごいことになってる
> A decomposable character is a character for which there exists an equivalent
> composite sequence.
まず「equivalent」の定義が見当たらないが、話が進まないので
「canonical or compatibility equivalent」のことだと思い込むことにする。
> 4.17
> Composite sequence
> A sequence of graphic characters consisting of a base character followed by
> one or more combining characters, ZERO WIDTH JOINER, or ZERO WIDTH
> NON-JOINER (see also 4.14)
Singleton (互換漢字など)はcomposite sequenceじゃないらしい (one or more
combining charactersが存在しない)。したがってdecomposable characterでもない。

素直に「UCDに分解マッピングが定義されている文字」とかUnicodeと同様の
定義にしておけばよかったのに、どうしてこうなった

> Singleton (互換漢字など)はcomposite sequenceじゃないらしい
Singleton (互換漢字など)の分解結果はcomposite sequenceじゃないらしい。
したがって互換漢字は(10646 2nd的には)decomposable characterではない。
だった

今の10646ってこれ単体で運用できるのかな

UCDとかUAXとか参照しまくり

ううむ

http://slashdot.jp/%7Eyasuoka/journal/525713
＞それでも、「U+1F1FF U+1F1F7 U+1F1FA U+1F1F8」(ZRUS)に関しては、
＞「旧ザイールの国旗」と「アメリカ合衆国の国旗」を表示する実装、
＞という大技があり得るので結構なやましい。
＞うーん、こんなことなら、High/Low Surrogatesをみならって、
＞1文字目と2文字目を別コードにするよう提案すべきだったか…。

ZRはobsoleteですよ、センセイ

ふむ

あ、Mac OS X LionにEmojiフォントが付くってことは、
Unicode 6ベースなんだな。

ヒラギノのIVS対応マダー?

>>796
フォント付くの？
なんか絵文字の表示に対応っていう微妙な言い回しの記事なら見たが

Apple Color Emojiという名前のTrueType fontと書かれている。

ttp://www.appleinsider.com/print/11/02/27/inside_mac_os_x_10_7_lion_font_book_3_emoji_support.html

True Typeって、カラー対応してるんだろうか。良く知らないけど。

フォント付くのかー
カラーは現在のTrueType仕様では対応してないはず
独自拡張かな

502グリフってことは収録文字はiOSと同じくSoftBankのものだけっぽいな

ううむ

ありゃ、docomoとauも入れると何文字？

1000文字以上
iOSにあった同名のフォントをそのまま持ってきただけじゃね

>>803
テンプレくらい見てよ。
http://unicode.org/~scherer/emoji4unicode/snapshot/full.html

http://std.dkuug.dk/JTC1/SC2/WG2/docs/n3992.pdf
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n3910.pdf
日本の将棋雑誌とか新聞では普通に漢字で符号化してるし
先手と後手の記号はJIS X 0213で符号化済みだからいらないのかな

まるお氏がこんなことつぶやいてたんだけど既出？

> 秀丸でDirectWrite対応（2011.02.23）
ttp://hide.maruo.co.jp/hidetalk.html
ttp://hide.maruo.co.jp/software/tkhist_pre.html

IVSとかOpenType Layoutには対応してるの?

>>808
前者については、DirectWrite対応アプリならIVSのOpenType Layout(UVS)はそのままサポートされる。
ttp://msdn.microsoft.com/ja-jp/windows/dd673458.aspx#2b2

後者については、OpenType Layoutならではの高度な文字体裁機能のサポートって意味？
メールとかエディタにそんな機能のサポートが必要なの？
必要ない機能には対応しないんじゃね？
ttp://msdn.microsoft.com/ja-jp/windows/dd673458.aspx#2b1

その他のOpenType Layoutとしては縦書きとか対応させたいようだけど、日本語環境でのDirectWriteはまだバグだらけでいろいろ苦労してるっぽいな。

DirectDrawもいいけど秀丸はちゃんと結合文字サポートしてくれ。
いまだに半濁点付きカ行がちゃんと表示できない。

結合文字サポートしてないならIVSをサポートしてるわけないと思うんだが。
バックエンド(DirectWrite)がサポートしててもアプリがアホなことしてたら
まともに表示できない。
それにエディタなら結合文字の前半だけ削除したり選択したりできないとか
カーソル移動の対応とかも重要だな。1バイト文字しか扱えない欧米のエディタで
マルチバイト文字の文書を扱ってるんじゃあるまいし。
欲を言えば検索にも対応してほしい

安岡さんが変体仮名の話題ねえ
文字情報基盤〜の方でゴーが出たのかな

そっち方面はいろいろタブーがあったりするのか

>>663 に公開されてる。
このへんとか＞ ttp://ossipedia.ipa.go.jp/doc/314/

あひるだかほつまだかって出せるの？

jindaiはだいぶ昔に蹴られてるはず

>>811
底辺IT土方「結合文字サポートしてないならIVSをサポートしてるわけない」ｷﾘｯ
大学講師「結合文字サポートは後回しでIVSをまず先にサポート」ｷﾘｯ
ttp://www.fonts.jp/hanazono/

結合文字とIVSとじゃ潜在的需要の規模がまるで違うだろ
だいたい結合文字をいまさらサポートしてもエディタの売り上げにつながらねーよ
そんなもんより今後注目を浴びそうな先端技術をいち早くサポートすれば宣伝効果があがるだろ
つーかエディタでDirectWrite対応してもIVS以外で売り上げにつながる謳い文句があるとは思えんが

VSは結合文字の一種なんだが?

OpenTypeフォントにおいてはVSはその他の結合文字と違うテーブルで実装されるけど
DirectWriteを呼び出すアプリにとっては別に違いはない。
だから結合文字をまともにサポートしないアプリはIVSもサポートできない

【難しいひらがな】変体フォントが出来たよ〜
ttp://hato.2ch.net/test/read.cgi/news/1299729885/

ゴシック体は文字の骨格をどう捉えてるかがはっきり出るだけに難しい罠。
とりあえず春(す)は、二画目の終わりを左に跳ね上げて三画目に繋げた方が
自然だと思う。

ChromeはIVSの表示には未対応だけど検索に対応してた。
たとえば「葛飾区」で検索するとちゃんと「葛(U+E0101)飾区」にもヒットする。

逆に「葛(U+E0101)飾区」で検索して「葛飾区」はかかるの？

かかる。

素晴らしい

素晴らしいな

Safariも同様だった。WebKitはICUのsearcherを使っているらしい。
http://trac.webkit.org/browser/trunk/Source/WebCore/editing/TextIterator.cpp
ただし単純にprimary weight以外を無視すると「か」と「が」とか「つ」と「っ」まで
同一視されてしまうので(辞書順ソートにおいては正しいweightの付け方だけど
あいまい検索として適切とは言いがたい)、そのへんの補正を行なっている。
何も考えずにcollatorを使えば済むほど甘くはないようだ。

telで検索すると�рﾉヒットしたりキロミリで検索すると�`�_にヒットしたりするな

こっ、これは別に互換分解なんかじゃなくてデフォルトの照合規則なんだからっ
変な勘違いしないでよね！

だね

モヤイで検索するとアホ面の絵文字が引っかかったりするのだろうか

モ「ヤ」イの時点であいまい検索だな。

渋谷のはモヤイが正解

G\"odel, Godel, Goedel
K\H{o}nig, K\"onig, Konig

Unicode 6.1はQ1 2012の予定っすか。

何が変わるんですぞ？

10646の3版に一致させるみたい。

チックタックだなあ

余震が怖い

ttp://www.ustream.tv/recorded/13386889

安岡さん楽しそう

いつのまにかppmからEncode::EUCJPMSがなくなってるんだけど
ActivePerlでCP51932を扱うにはどうしたらいいの?

自己レス。
Strawberry Perlに乗り換えて解決した

>>839
IVSの粒度はIVCごとに異なっていて
常用漢字表に印刷されている「次」 ∉ 6B21 E0100
常用漢字表に印刷されている「次」∈6B21 E0102
常用漢字表に印刷されている「次」∈6B21 E0103
6B21 E0100⊂6B21 E0103
6B21 E0102⊂6B21 E0103
と理解してたんだけど。

つかIPAmj明朝一般公開見送りかよ…。

IPAフォントはヒンティングが今一つなんで、公開しても民業圧迫ってことはないと思うんだけどなあ。

>>843
民業圧迫が理由じゃなくて、たとえば常用漢字表の「次」の字形(6B21 E0102に近い)
を6B21 E0103(チャートでは6B21 E0100に近い)に割り当てていいのか? という
問題が未解決だからだそうな。
>>842に書いたとおりの解釈ならいいと思うんだけど、安岡先生が強く反対しているので
とりあえず公開見送りになったらしい。
考えられるオプションは
・とりあえず「次」などはIVSを外す。
・上記のような問題が起きる数文字をIVDに登録する。
・いっそ常用漢字の2136字すべてを「常用漢字コレクション」として登録する。

これ以上日本発のコレクションを増やすのはあれなんで
汎用電子に追加する方向がいいな

Unicodeのミス見つけた

𪕾（2A57E：鼠+芻）
𪕿（2A57F：鼻+自/冖/儿）
𪖀（2A580：鼠+雀）

別の部首の漢字が紛れ込んでる

そういうのって指摘があったら直されるものなの？

フォントのミスなら直るはず

それふぉんと？

12 名前：1 [sage]： 2010/07/12(月) 17:54:35
・「wchar_tは>849の嫁。>849の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」

>>849 許可ください。

9ヶ月前のロングパスを回収っすか。

10646/2ndのフリー版ﾏﾀﾞｰ?

フリーがいいっすよね

4011-4013は四月馬鹿三連発なんだろうけど
Source欄を見るとちょっぴり本気かもしれないと思えてくるから不思議

おお
エイプリルフール提案文書来てたのか

ヨーロッパでももう4/1って終わってるよな。
unicode-mlでの議論見るに、もしかして本気なのか？

ファイストスの円盤文字も4月1日提案だったのか(N3066)。
こりゃやっぱりPlane 13を異体字セレクタ用に予約してもらうべきだな

IRG36ネタ
・AJ1用に32のIVSを追加するよ！　2011/06から登録手続きをする予定だよ！(IRGN1765)
・汎用電子も2011年末までに第二陣を登録するよ！(IRGN1760)
・UTC自身が簡体字をIVDに登録するよ！(IRGN1757)

乙

今年後半はIVDの更新レビューが2回行われることになるのか。

> The following represent new developments in the realm of IVS support, which demonstrate that acceptance of and
> support for IVSes are becoming increasingly broad:
もしかしてKen LundeがIVSサポートしてるフォントをTwitter上でゆるぼしてたのは
このためか?

簡体字はUnification Ruleによるとほとんどは統合されないことになっているから
IVSでは表せないんじゃなかったっけ? せっかくIWDS作ったのに端からブチ壊しに
してくれるわけ?
(逆に反対する奴は10646 3rdのAnnex SとIWDSを根拠にすればいい)

CSSで「text-rendering: optimizeLegibility;」を指定するとChromeやSafariのWindows版でも
結合文字やBMP外漢字を表示できるようになることが判明。

な、なんだってー！！(AA略

朗報っちゃ朗報だが、Legibilityと何が関係あるんだろう…？

デフォルトのoptimizeSpeedは速度優先
optimizeLegibilityは正確さ優先だから
速度を稼ぐために結合文字の処理を真面目にやってないってことかな。
しかしTwitterを「text-rendering: optimizeLegibility」で検索すると
落ちるだの表示がグチャグチャになるだの旧字体になるだのさんざんな評判だな。
デフォルト設定じゃないからまともにテストされてないんだろうか。

>>858
安岡センセイIRGN1757に反対

漢字を知らない馬鹿と漢字しか知らない馬鹿

1757は連名なのになんでJenkinsだけ名指しなんだろう。

>>867
ふつう反対するよ
安岡センセイに触発されて調べてみたら少なくとも6文字が
Extension Cに収録済み(しかもUnihan DatabaseでkSimplifiedVariantも定義済み)
なんだがいったい何をどうしたらこんな大雑把な提案が作れるんだ…。

特定のグリフがどこそこに収録済って言い方はおかしい
例示グリフに例示以上の意味はないから

じゃあExtension Cに6文字もUROと重複があるとでも言えばいいの?
そんな言葉遊びがしたいわけじゃないんだが

重複じゃないんだったらIVSでは表せない(Annex S的にUnifyできない)
ものを無理に表そうとしているわけで、どっちにしても提案は破綻してる

Unicodeが符号化しているのは抽象化された文字で、
IVSが指しているのは具体的な文字図形。
言葉遊び以前にレイヤーが違う。

漢字しか知らない馬鹿の方が信頼できる

>>871
IRGN1757よく読め。これが収録しようとしているのはグリフじゃない。

うむ

むう

ややこいなあ

しかし、縦に書かない日本語はな・・・

IRGってOracle Boneまで手がけるのか・・

改元したら、何日ぐらいでPCで使えるようになるのかな？

もうその手の互換文字は追加されないと思うよ

根拠は？

「�~」を「偏が平、旁が成の国字」だと主張するんだ

実際に「偏旁」の一文字が存在する元号になるとややこしいな。

火暴 とかか

火暴元年 んー

寧ろ「日暴」で。「

縦書きフォントだと、
冠
旁
になるわけ?

广の中にマが入って麻の略字、ってやつを追加してほしい

>>889
大正はそっちのほうが収まりがいいな

　 　 　 　 　 　 　 ■　 ■
　 　 　 　 　 　 　 ■
　 　 　 　 ■■■■■■
■■■■■　 　 ■
　 　 ■　 ■　 　 ■
　 　 ■■■　 　 　 ■　 ■
■　 ■　 ■■■　 ■　 ■
　 　 ■■■　 ■　 ■　 ■
■■■　 ■　 ■　 ■■
　 　 ■　 ■　 ■　 ■
　 　 ■　 ■■　 ■　 ■■

　 　 　 　 　 ■
　 　 　 　 　 ■　 　 　 　 　
■■■■■■■■■■■
　 　 　 　 ■　 ■
　 　 ■■　 　 　 ■■
■■　 　 　 　 　 　 　 ■■
　 　 　 ■■■■■
　 　 　 　 　 ■
　 　 ■　 　 ■■■■
　 　 ■　 　 ■
■■■■■■■■■■■

>>890
それは魔の略字だろ。
それを言い始めたら、广にKOを入れた字も入れろと言い出す奴も出てくるから嫌。

ラテンとCJK夢のコラボ

「日へんに玉」ってCJKに入ったの？

>>894
http://glyphwiki.org/wiki/u2b782

旧TRON文字収録センターの画像が消されてトップページも移転通知になった
検索CGIはまだ残ってるみたいだけど

10646 2nd ed.の無償版来た！

2003以前は削除されたか

(´д｀)ｴｰ

まあ規格ってのは最新版のみが有効なもので、どっかの国の漢字コード規格みたいに
全バージョン参照する必要があるほうが本来おかしいから。

歴史的経緯を知らないと文字コードは理解できない
って安岡センセイが言ってたよ

今日まで異字体と戦ってきたみんなを、
希望を信じたプログラマを、
私は泣かせたくない。
最後まで笑顔でいてほしい。
それを邪魔する規格なんて、
壊してみせる、変えてみせる、
これが私の願い。

安岡センセイはJISの歴史に詳しい。
安岡センセイとって都合の悪いUnicodeについてはかなりレベルが低い。
認識の誤りを指摘されてもたださずに同じことを言い続ける老害レベル

安岡センセはその昔 sci.lang. とかで漢字のAA貼って奮闘していたからなあ

包摂絶対正義主義の基地外が湧いてます？

Unicodeに関してはちょくちょく「？」なことを言うなとは思っていた。
とりあえず他国の代表をブログで馬鹿呼ばわりするのはやめと毛。

>>901
「理解」がどういうものかにもよるでしょ。
仕様を議論したいなら歴史的経緯は必要だろうけど、
規格に合わせた実装を作りたいだけなら必要ない。

仕様書だけ見て実装できないなんて規格として欠陥品
欠陥品であることを逆ギレして自慢するとかもうね

>>907
文字コードは異なる文字コードとの変換が重要だから、歴史じゃなくて
いろんな文字コードの体系だった知識とか製品固有の知識が必要になると思う。

Windows-31Jの仕様とJIS X 0208の仕様だけみてもJIS変換プログラムは作れないし、
Oracle DB(JA16SJIS)を使用しているJavaプログラムで「〜」が化けるので何とか
してくれと言われても仕様書だけじゃ足りないし、文字コードにShift_JISを指定すると
JavaでHTMLが文字化けするのに対応できない人は多い。
先日はHP-UXでiconvにsjis指定すると文字化けするので何とかしてくれと言われたので
cp932を指定させたらすぐ直った

それ歴史じゃないじゃんw

>>910
そうだな、>>909が言ってるのは歴史じゃないな
……で、それがどうしたんだ？

>>910は文盲

>>906
IRGN1757は馬鹿だと俺も思った

うむ

完璧にそれまでのUnicodeの分離方針と矛盾してるし
あれは馬鹿と言われても仕方ないレベル

しかもPRCに話がとおってないらしい

IVDはコンソーシアムの管轄下にあるから
USが本気なら誰が反対しても登録されるだろう。
問題は背後にどんなシナリオがあるかで。

安岡センセイがJenkins名指ししてるのも
そのあたりなんだろうな

てか狙いがわからない

安岡センセイRegional Indicator Symbol Letterを奇数個とかワケわからん
認識の誤りを指摘されてもたださずに同じことを言い続ける老害レベル

花園明朝UCS漢字完全対応キタコレ

あれは曲線がなあ。直線で擬似的に作っているから引き延ばすと悲惨。

まあ漢字のLast Resort Fontだから品質は仕方ない
IPAmj明朝が公開されていればなあ…

KAGE形式のデータから直線の代わりにベジェ曲線か何かで
アウトラインを生成するアルゴリズムが次の研究課題だな

>>923
IPAmj明朝はCJK拡張C・Dはサポートしてないし
拡張Bも27000字くらいなのでUCS漢字完全対応には遠い

文書いっぱいヘルシンキのagendaもいっぱい

WG2 N3987どうなるの？

IPAmj明朝公開キター
ttp://www.ipa.go.jp/about/press/20110518.html

Tフォントも2月に公開されたし
今年は多漢字フォントの当たり年だな

> 文字情報一覧　文字情報一覧表 ver.000.01 (検証版)
zipでくれ

これってきっとInDesignみたいにグリフを直接呼び出せるアプリじゃないと
フルには使えないよね。

未符号化文字はPUAに入っているわけではなくて本当に何の符号も与えられていないから
グリフID指定で直接呼び出せるアプリでないと使えないのね。

安岡センセイ涙目ｗ

Macの文字ビューアでも使えるらしい

DLしてみたものの使いどころがない…

それでもDLしちゃうのよね

>>934
ヒラギノのCIDしか付いていないグリフを利用するための仕組みの流用だな

DLしてニヤニヤながめてればおｋ

WindowsではSIL ViewGlyphで見ることだけはできるが
他のアプリに貼り付けられないのでほとんど意味がない

Macだと貼り付けも出来るの？

SILってこんなのも作ってたのか。
IPAフォントのイメージしかなかった。

>>940
Glyph Access Protocolに対応しているアプリ(標準のTextEditとか)には
貼り付けできるはず

情報処理推進機構と国際音声記号の頭文字がかぶっているのを何とかしてほしい

同感
前者が改めるべきだな

連坊に頼めば？

>>942
http://ossipedia.ipa.go.jp/ipafont/faq.html#q007-1

>文字セット名を表す場合は少ないことが一般的

固有名詞としてはそうかもしれんけど、普通名詞として
IPA fontって言い方がされることはあるだろうに。

実際IPA(本物)の方も使っている呼び方だし。
ttp://www.langsci.ucl.ac.uk/ipa/ipafonts.html

IPA明朝とあるのを見て、ああ音声記号も収録した日本語フォントなのね、そんなのは別にいいや
とか長いこと思ってた人間が実際にいる。自分とか
というか組織名だと知らなきゃそうとしか解釈できなかった

モリサワ明朝とかAdobeゴシックとか命名するようなもんか

まあMS明朝とかMSゴシックと命名されたフォントもあるし

反省して、メイリオでは何もつけませんでした。

マイクロソフトの社名入りフォント名は
MS なんとか　ってのと　Microsoft なんとか　ってのがあって
これはこれでなんか不統一感

MS Sans Serifはラスタフォント(ビットマップフォント)で、
Microsoft Sans Serifはそれとは異なるTrueTypeフォントだとかもうワケワカメ

>>951
MSとＭＳってのもある。

MSゴシック系はたった3つでこの有様。

ＭＳ ゴシック
MS Gothic

ＭＳ Ｐゴシック
MS PGothic

MS UI Gothic
MS UI Gothic

「ＭＳ ゴシック」と「ＭＳ Ｐゴシック」の場合、
「ＭＳ」「Ｐ」は全角で、その間に挟まるスペースは半角。

ラテン表記の書体名では「MS」と「P」の間にスペースが挟まり、
「P」と「Gothic」は続けて書く。

一方、「MS UI Gothic」にはカナ表記の書体名が存在しないので
上2つのような「ＭＳ ＵＩゴシック」は通らない。
ラテン表記では「UI」と「Gothic」はなぜか離れててPGothicと不統一。

花園明朝のvmtxテーブルひどいことになってるなぁ

縦に書くと文字が全部重なるって奴か

UKもIRGN1757に反対
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4075.pdf

Ken LundeがUTS #37の次の版の話をしているようだが、
まさかIRGN1757を後付けで正当化するつもりじゃなかろうな。

うーむ、まだ実用には程遠いか

縦書き時の文字の高さが15になってる
そりゃ重なるわ

USはなんでNo action is requiredな文書をこのタイミングでポストしたんだろう。

御意見無用？

ご意見無用
でも読め！
真意やいかに

言ってみただけ〜♪

>>744
安岡センセイから返事きた
http://slashdot.jp/%7Eyasuoka/journal/531917

IVSだけじゃなくligatureにも言える問題だよなぁ
英語力ある人はCSS3 Fontsのエディターと掛け合ってみてほし

そもそもfont-familyってフォールバックさせるためのものじゃないんじゃないの？

じゃ何のため？

スンマセン勘違いしてました…

あ、956じゃなくて965だった…

>>963
W3Cメーリングリストに飛び火
ttp://lists.w3.org/Archives/Public/public-html-ig-jp/2011May/0018.html

グリフ探索を2周以上するってのは難しいと思うなあ。
1文字ずつやるわけだし速度的に相当なコストになりそう。

UTS37の新editorsの面子がおもしろひ

現実的にやるのが難しくても、
「正しくはこっちだからね?」と決めておくのは大事じゃないかな。

最近のCSS3 FontsはほとんどFirefox仕様の引き写しになっているから、
Mozillaの中の人を説得するしか。

>>970
現状〜近未来において、IVSを使った文字が大量に連続するのって
それこそ漢字一覧表ぐらいのものじゃないか？

5年も10年も後ならまたリソースの状況が違ってくるだろうし

人名の漢字一つだけ違うフォントで表示されたら
たとえ正しい異体字が出てても違和感があるんじゃないかな

違和感あるなしの問題じゃないだろうｊｋ

　　　　　　　　まもなくここは　乂1000取り合戦場乂　となります。

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）

IVSが65535個を超えたら、どうしてOption 1は破綻するの？

1ファイルに収録できなくなるからじゃない?
互いに重複したbase characterを収録していない複数のファイルに分ければ
いいだけだと思うけど。
個人的にはOption 2を支持したいけど
あんな文字鏡関係者並みの下手くそな言い訳は説得力なくなるからやめてほしいもんだ
http://www.pcc.or.jp/hyojun/1-3hitsuyousei.htm
> しかし、フォント仕様（OpenType等）の制限により240のバリエーションは使用できず、
> 実質的には1〜２桁少なくなる。（フォントが一つの面につき65ｋ字までしか表現できない
> ので、仮にBMPの27,000字の漢字がIVSCを使うとすると65,000÷27,000≒2.4字となる）。

"一つの面につき"は不要

>>980
まさにそこが馬鹿なところ

980超えたので次スレ立てた

文字コード総合スレ part7
http://hibari.2ch.net/test/read.cgi/tech/1306595564/

>982
乙

誘導パピコ

文字コード総合スレ part7
http://hibari.2ch.net/test/read.cgi/tech/1306595564/

まとめを誰か