文字コード総合スレ part8

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/

待ってたよ！
http://www.youtube.com/watch?v=oFt9z2b2BVQ

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

■これまでに行われた議論
・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の人にはそれがわからんのですよ。

テンプレ乙でござるよ

もうひとつの過去スレ:
文字コード統一スレ 1文字目
http://pc8.2ch.net/test/read.cgi/tech/1109171258/

隔離スレ:
UnicodeとUTF-8の違いは？
http://pc12.2ch.net/test/read.cgi/tech/1177930957/
UnicodeとUTF-8の違いは？　その2
http://hibari.2ch.net/test/read.cgi/tech/1274937437/
UnicodeとUTF-8の違いは？　その2
http://toro.2ch.net/test/read.cgi/tech/1291075205/
UnicodeとUTF-8の違い4(インディアン隔離スレ)
http://toro.2ch.net/test/read.cgi/tech/1342963035/

■ライブラリ
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とか。

JTC1/SC2/WG2 - ISO/IEC 10646 - UCS
http://std.dkuug.dk/JTC1/SC2/WG2/

ISO/IEC JTC1/SC2/WG2/IRG
Ideographic Rapporteur Group
http://appsrv.cse.cuhk.edu.hk/~irg/

日本の委員 (JSC2)
http://www.itscj.ipsj.or.jp/meibo/020000.pdf

スレ立てサンキュ

西夏文字、女文字、インダス文字、女真文字なんかはまだなんだな。
日本や中国の研究者頑張れ。

ところでさ、U+1F5FEの日本列島絵文字なんだけど、
例示図形に普通に北方四島が入ってるんだよね。
これロシアとかからクレームなかったのかな。

あるいは、奄美と沖縄が単独の点として描かれてるのに
北方四島が本土とくっついてるのはあえてどうとでも解釈できるようにしたごまかし？
でも佐渡とか壱岐対馬はそもそも存在さえ描かれてないわけで、なんかちょっと変。

では、そもそもの元になったと思われるau絵文字#214「地図」ではどうだったのかと見てみたら、
なんと日本領部分は「本土4島だけ」のシンプルなものだった。
ここからどういう経緯で北方四島と奄美沖縄が加わったんだろう。

>>14
日本列島という島の絵文字であって、日本という国の絵文字じゃないということだと思う。
でないと、国旗の絵文字でアレだけ揉めたのと整合性がつかなくなる。

ただ、国境以外の理由で4島と千島を区切る理屈ってのもちょっとなさそうなのよね

南樺太も日本です
台湾も日本です

U+1F5FCが固有名詞的な「東京タワー」じゃなくて「電波塔」という曖昧な名前で規格化する案もあったことを考えると
U+1F5FEも「弧状列島」とか表現されることになっていてもおかしくなかったかも

尖閣諸島を入れて欲しかった

>>18
まあ、MOYAIさんが通った時点でそのへん曖昧だよね。

これに自由の女神と並ぶレベルの公共性なんてないと思うｗ

>>20
あれって元の携帯絵文字ではモアイ像そのものの姿で描かれてるんだし (文字名はモヤイ像なのに)、
「モアイ像」として入れたほうがユニヴァーサリティがあって良かったんじゃないかと思うんだけど
まあ渋谷とかの意味で使われる絵文字として解釈できなくなるからやっぱダメか

あるいは新島

>>21
> あれって元の携帯絵文字ではモアイ像そのものの姿で描かれてるんだし

まじだ……一体どうなってるんだこれ

http://slashdot.jp/~yasuoka/journal/559968/
＞JTC1/SC2/WG2/IRG N1883
＞(大正新脩大蔵経「外字」のISO/IEC 10646追加提案)

これ結局、日本提案から外されたのね

>>5
>・Unicodeは言語情報を直接扱わない。 多言語の混在表現は（unicodeでは）できないか

ISO2022なら楽勝でできる多スクリプトの混合表記がunicodeではできないってスクリプトレベル
の問題を、多言語問題にすりかえるなよ

言語情報が中国語でも、それを日本漢字で表記しても何も問題はない

それどころか、日本の漢文の教科書では、言語は中国語だが、字体は日本の教科書体で表記
しないといけないっての

正則漢文は中国語ではない

>>25
文書そのものの言語よりむしろユーザーが理解可能なスクリプトの方が重要、
なのかなあ。

とりあえず自分のお仕事では、文書の言語情報が中国語だったら中国語のフォントを
割り当てるようにしてますけどw
例えばOSの言語設定を優先するようにしたりとかしたら... って?
...ちょっと無理かなw （ちょっと持田香織を意識してみた）

現実問題として例えば普通の日本語フォントは中国語の簡体とか持ってないから、
下手にやるとつぎはぎの脅迫文状態になってしまう。そういうのでも見たいかな?

漢字のフォントって今も全部手作業で作ってるの？

偏旁の情報流し込んだらざーっとバリエーションつくってくれて、細部だけ手修正、みたいな感じなら
せっかくだから和文で使わない文字も全部含めてくれればいいのに。クオリティ落ちてもいいからさ。

じゃあおまえがやれよ

e漢字というプロジェクトがあってだな

つまんね

結局GlyphWikiみたいに人肉制作が一番成果物につながりやすいのかな

Glyphwikiは曲線を実現する方法が改善されたら無敵かも。

現状のGlyphWikiで作った記号とかネタレベルだもんな。

花園は非漢字だけ別のフォントから借りてきた方がいいと思うんだけど
明朝だとなかなか選択肢がないのかな

IPA明朝丸取りで良いやん。

さて年の瀬なわけだが

年の瀬くらい、おとなしくしてなさい

年の瀬だから、いいじゃん

こんなの始まってた
www.ipa.go.jp/about/kobo/tender-20121228-2/
>今回、変体仮名⽂字の字形を調達し、今後のフォント拡張及び文字符号の国際標準化の
>素材として使用するものとする。

変体仮名の符号化が動き出したか

良くも悪くも、今回デザインされた字形が「正しい変体仮名」として未来に残っていくんだな。

だろうなあ。変体仮名の字形に熟知したデザイナーなんてどれだけいるやら…

3月〆切ってことは早ければ春先にもまずIPA明朝に収納される可能性ありか。
どんなのが出てくるかちょっと楽しみ。

さて年が明けたわけだが

「謹賀新年」「迎春」とかは一つの文字コードを与えていいんじゃないだろうか

#あけおめ #ことよろ

あけおめー

縦組み専用のワープロソフトも出てくるんだろうか

blog.query1000.com/archives/21819386.html
>日本は今まで（他の国の提案を）撃ち落とす方で頑張って来たのに、

WG2/IRGへ邪魔しに行ってるのを認めちゃったよ

>>44
戦前に「天皇陛下」の一体活字を作った新聞社じゃないんだから。

ひょっとしてそれって、文選で間違えると打ち首にされるとかの回避策？

文中の「陛」文字頻度が低い上に特定の熟語にしか使われないからでしょ

>>48
http://blog.query1000.com/archives/21798078.html
http://blog.query1000.com/archives/21819386.html
http://blog.query1000.com/archives/21848658.html
http://blog.query1000.com/archives/21886099.html

四連作なのね。結構、裏話っぽくて面白かった。

ああ、例の本の深沢さんか。参考になったわ。

>>52
安岡も耄碌したな。トイレと天気の話しか出来ないのか。

>>50
北朝鮮方式か

あと、4文字の途中で改行することが許されないから、
（というか、直前で改行して必ず行頭に置くことになってるから）
という事情もあるな。

JIS Z 8903廃止なのね

ああYさんとこね

変体仮名字形の入札、濁点/半濁点つき字形のことを忘れているような

>>59
戸籍にも住基にも濁点/半濁点付き変体仮名は無いから
とりあえず最初のうちは作らないみたい
でも今後どうするかは謎

>>59
自分自身を指してしまったorz

そうなのか…じゃあ本当に行政専用になりそうだな

合成でなんとかしろって事ではないのかな。
アイヌ語の表現みたいに。

欧文のストロークみたいな感じで

>>63
kwsk

ふむ

ほう

すべてが順調にいったとしても
使えるようになるのは2015年頃かのう

拡張Fきてるし

irgはいつの頃からか記念写真やめちゃったのね

Ext Fまで来ると、もうIPAmjとGlyphWikiくらいしか
実装されないんじゃなかろーか

ExtFどこにきてるの

あなたのうしろよ

中国語の漢字もう疲れた... 偏が簡体になったやつがやたらコードポイントを
消費しているような。
もう簡体と繁体もunifyすればよかったんじゃんw

繁体：簡体が多対一で対応してるのとかへのルール作りを考えるとユニるのがめんどくさい

Ext.Fどこで見られる？

unicode とか JIS X 0208 だと、ASCII文字(記号含む)の全角版って、互換性維持の為にあるものだよね？
JIS X 0208 だと、ほぼ使うなと同等なことが書いてあるけど、
今の unicode standard だと使っても全然問題ないみたいに書いてある。

現実的に、フォントと多くの表示環境では、レンダリングされるときのマージンとかスペーシングを考えると、
日本語を書くときは全角を使った方が見栄えが良くなると思う。
ASCII文字の全角版を使わないという選択はとれないんではないの？

日本人は分かち書きなんてしないから、マージンとかスペーシングを気にしないのかもしれないが、
ラテン文字を使う外国人はマージン・スペーシングに関して全角の方が見栄えがいいから、
unicode standard で禁止されてないし、全角文字を使う風潮が流行るんではないかな。このままほっとくと。

実際、CJK文字を含むテキストで何で半角記号(括弧とか、＆とか))を使うのか？全角記号を使うべきではって外国人に言われたし。
まともな反論できなかったわ。

英数字に全角文字使えよ

>>77
まあ、日本語で書くときの話をしてるから。それに解決になってないし。

追記しとくと、
（日本語）
みたいに全角括弧でくくった場合、括弧の前後にマージンがあるフォントとないフォントがあると思う。
これを半角にしてしまうと、ほとんどのフォントでマージンがないから、前後に空白文字を入れないと、マージンが無くなってしまう。
これが見た目に影響してしまうんだよね。

また、縦書きの場合に
おしっこ＆うんこ
みたいに書くと、全角＆は正立するが、半角&は90度回転する環境がほとんどだと思う。(？！とかもそうかもね)
じゃあ、CJKだと普通の文字は正立するから、全角で書かないといけないよねってことになる。
今すぐ役に立つものを作る場合は、規格より、現実を優先させないといけないしなぁ。

っつーか、なんでunicodeの互換エリアって使っても問題ないみたいになってしまったんだ？

>>78
全角って単にコードの話で、
マージンやスペーシングがどうかなんて規定されてないだろ。
横幅が半分でもコードが全角ならそれは全角だよ。

>>79
そりゃそうだけど、じゃあどうするべきなの？
俺はマージンとか縦書きの時の配置はレンダラが適切に処理しろと思うけど、
現実PCの表示環境でそんなの気にしてないし。

フォント制作者も文字の効用に合わせて作ってるんだろ？
半角と全角でグリフもマージンとかも全く同じフォントなんてほとんど無いし。

現実に合わせても将来がない上に、規格にそってもまともなレンダリングがされない現状って。

NEC PC-98シリーズには、2バイト半角文字がある。

括弧とかは全角版を「スペースが予め含まれた括弧」みたいに再定義しておくべきだったかもしれんね。

縦書きの時に何を正立させて何を回転させるかは今UTR50でやってる。
もっとも、外野が口を突っ込みすぎて座礁しかかってるけど。

どうせSJIS⇔Unicode変換には演算入るんだから英数やキリルのJIS全角文字はダイアクリティカルマーク様にコンバインで収録すべきだった

East Asian WidthがAmbiguousなやつどうすんだよって問題も未だ解決されてないし
どんなとき縦中横にするのかとか文字コードだけで解決できる問題とは思えないよな

>>80
それは単にあんたの使ってる環境やフォントの機能不足だろ。
>半角と全角でグリフもマージンとかも全く同じフォントなんてほとんど無いし。
ヒラギノは文字幅の設定８種類持ってて切替えられる。
OSX上でプロポーショナルにも全角/半角側に統一とかも設定次第で好きにできる。

「ＡＡAＡAA」が全く同じ文字の連続に見えるようなフォントって話だと思ってたけど
OSX+ヒラギノの環境ではそれが可能ってことであってる？

>>87
そう、OpenTypeの機能。
OSXは標準のテキストエンジンでサポートしてる。
他のプラットフォームでも真面目にサポートしてれば使える。

WinだとDirectWriteでやることになるのかな

同じ文字には同じコードを割り当てるべきだと思うの

あれ、なんか話題のレベルが落ちてきてない?

ンとソのちがいは、日本人ならわかるけど
カタカナのベ
ひらがなのべのちがいは、日本人でもわからん

シとツのちがい
うとラのちがい

>>93
これだね
http://livedoor.blogimg.jp/conbul/imgs/9/7/97efb758.gif

>>92
何故へとヘではなくべとベなのか

>>86
OSXは使った事ないし知らなかったわ。すまん。
その外国人もマックユーザっぽいから、そういう風なレンダリングできるのを自分で見れば納得するかも。
You & I も あなた&わたし も ひろゆき(2ch管理人) も hirokyuki (the founder of 2ch) も
前後の文字を見て適切な字形とマージンを自動選択できる表示ソフトがあるってことだよね。
その外国人は上みたいな文字列を適切に表示させることが出来る環境なんて見たことないって言ってたから、
なにか適切な設定してやらないといけないってことかな。どうすればうまく表示させられるの?

Unicode Consortiumの内部文書へのパスワードを解除するって
ものすごい決断だなあ。これまで水面下でしてきたことも
これからすることもすべて丸裸か…

>>90
思うね。ふたつあるΩに、つい「オメーガ悪い！」と叫んじまったぜぃ

ユニコードは日中韓の同じ文字に同じコードを割り当てた所に問題が有った訳だが・・・

iモードはなぜJIS X 0208にすでにある♪を絵文字に追加したのかw

http://www.nttdocomo.co.jp/service/communication/imode_mail/function/pictograph/
「るんるん」であって八分音符じゃないから
まあ意味も同じな「！」まで追加してるし色つけたいとかアイコンのかわりに使いたいとか
絵文字の水増ししたいとかそういう理由なんだろうな
どちらかといえば「黒ハート(赤)」のほうが納得いかないし

絵文字なんて、ミクシィみたく数値参照みたいな形式でいいのに。
なんでコードポイントなんか与える必要があるんだよ。

絵文字は、排除すべきだ

無理です

使うものだけを各自subset化する

>>103
排除はどうかと思うが、
Unicodeに日本の3キャリアのみの変換テーブルねじ込んだのは許せん
しかも往復できないし

＞しかも往復できないし

ここだよね。

キャリアの絵文字相互変換はぶっちゃけ「なんとなくこんな感じだよね」レベルなんだから、
ユニコード収録のタイミングで半ば強引に整理して、
キャリアのサーバー側を“権威ある国際規格”にあわせるべきだった。

中の人も「後世まで残すとわかってたらもっとマジメに作ったのに」って思っただろ絶対。

各キャリアの私用領域絵文字は緩やかに廃止して
全部画像ベースのデコメ絵文字に移行すれば何も問題なかったのに
文字コードオタクが調子に乗るから

>中の人も「後世まで残すとわかってたらもっとマジメに作ったのに」って思っただろ絶対。

ないわ

>>88
それってCoreTextでfont featureをセットするみたいな話のことですか?
CoreTextをあまり真剣に使ったことがなかったので後学のために。

>>110
普通にフォントパネルから指定できる。
左下のポップアップメニューからTypography選んでみ。
ずっと前からサポートしてるOSXの基本機能/基本操作だよ。

>>111
はい。
UI的にはそうなんですけど、プログラム的にはNSTextViewとNSFontPanel
の組み合わせで、だけどそれをコントロールするAPIはないような、と。
ちなみにこのメニューってOS Xのどのバージョンからありましたっけ。

「ターミナルでの」半角全角というのはレガシーなエンコーディングにおいて
1バイトか2バイトかで文字幅処理していた名残だから、フォントのデザインという
より文字コードの問題なんだけど、OpenTypeのフィーチャーは有効かな? と。
あくまでもターミナルでの全角半角問題に限定しての話ですが。

で、OS XのターミナルはCoreTextで作られているので... というのが個人的な今ココ。
ちょっとごにょごにょ試してみます。

>>112
フォントによってサポートしてるfeature違うから、適切なオプションを設定すれば良いはず。
>ちなみにこのメニューってOS Xのどのバージョンからありましたっけ。
OSX 10.2辺りからじゃないかな？ 手元で一番古い10.4でも普通に使える。
>で、OS XのターミナルはCoreTextで作られているので...
それは最近の話だね。CoreText以前もfont featureはATSUIでサポートされてる。

「ここに晒しておく。」なんて
あの人は発想がちゃねら並みだな…

実名でやってるだけ俺らよりマシだろ

安岡センセイ
実はバリバリのちゃねらーだろ

>>114
安岡センセイが「晒しておく」って書いてる時は文体にかなり怒りを感じる。
本気で怒ってるんだろうと思う。

http://slashdot.jp/~yasuoka/journal/562403
http://slashdot.jp/~yasuoka/journal/535124
http://slashdot.jp/~yasuoka/journal/514117
http://slashdot.jp/~yasuoka/journal/494946

ふむ

阿辻教授の方へ訊きに行ったのが気に障ったのかしら

>>117
センセイも時々ボケはるからお互い様な感じはする
IVSの時はただの馬鹿かと思った

>>120
kwsk

>>117
「晒しておく」とは書いてないが、かなり怒ってる感じだぞ
http://joi.jlc.jst.go.jp/DN/JST.JSTAGE/johokanri/55.826

？

？？

リンク切れてるぞ

落ちてるのかな

昨日はPDFでダウンロードできたよ

>>113
少し遊んでみました。なるほどヒラギノというのはいろんなテーブルを持ってるんですね。
こういうテーブルのせいでフォントが過剰に大きくなったりしないのかな。

個人的にOS Xからしばらく遠のいていましたが、ふと気がつくとテキストエディットが
縦書き対応に、SafariはIVSに対応しているようで。
しかしIVS->グリフの対応はどのレイヤーで処理しているのかな?

>>122
やっと読めた
怒ってるというよりは業を煮やした感じ

>>128
ヒラギノ角ゴがときどき怪しげな表示をするのは、そのせいなんだろうか。
文字が重なったり、わけのわからんところでボーンとアキができたり。
こういうのはスレチ？　MacとかWordとかのスレでやったほうがいいの？

うん

住基ネットって今年3月廃止なの？

地方自治情報センターが仕分け対象になっただけ。

つまりどういうこと？
改組するだけ？それさえなし？

変体仮名はタイプバンクが作ることになったのか

変体仮名づくり自体が未知数すぎてコメントしづらい

変体仮名はフォントの問題な気がする

納入期限まであまり日がなかったよな
春過ぎには変体仮名入りのIPAmjが出るんだろうか

変体仮名は楷書書体の知識が全く通用しないからな。
金があれば知識ある人を引っ張ってこれるはずだが役所仕事はアレだからな。

これはどうなるのかマジで不安

だめなのが出てきたときにリジェクトってできるの？

外野が物言いを付けるタイミングとしては
・グリフがIPAmj明朝に入った時にフィードバックする
・そのフォントをもとにした符号化提案書がWG2へ回ってきた時にコメントする
のどっちかだと思う。

プロジェクトを指揮してる主体が見えないんでそれぞれ
いつ頃起こるかは分からないけど。

ううむ

漢字6万字の時は
2011/3/14がグリフの納入期限→2011/5/18にIPAmj明朝検証版公開

今回の変体仮名は
2013/3/18がグリフの納入期限→？

内部では基本形はもうできあがってんのかな

入札公告から数えても期限まで80日程
これで200字強か

外字登録についてご存じの方がいたら教えて下さい。

ドコモの絵文字をサロゲートペアのPUA（15面）に外字登録したいのですが、
フリーのツールなどで可能な方法はありますか？

Windowsの外字エディタではサロゲートペアの領域には外字登録できないので。。。

>>146
FontForge使えばできるよ

板の趣旨とまったく関連ないよねこのスレ。

確かにｗ


ただ、文字コードの総合スレってどこに行けばいいのかよくわからんのよね。
「PC」に限ったもんでもないと思うし。

広義の「ソフトウェア」として捉えようにも、あそこは実質Windowsアプリ板だし。

プログラムで扱うデータ構造だからプログラム板で良いのでは

安岡センセイ荒れてるなあ
http://slashdot.jp/~yasuoka/journal/563428

IVSに言及されてるのにUCS-2がdeprecatedになったことや
UCS-4の範囲が制限されてることは知らなかったり
色々とちぐはぐな論文だこと

H立は研究所がすごいという感があるが、F通の研究所はなんかこういうのばかりという印象があるなw

不治痛は官公庁がらみの仕事が多くて
文字setにうるさい割に能力は適当な希ガス

＞現時点での常用漢字と人名用漢字がどうなっているかぐらい

つまり、どうなっているの？

「富士通総研経済研究所研究レポート」ってエッセイ集でしょ？

>>156
査読とかが無いみたいだから
こんなのが出てくるんだな

大学でいうと紀要のようなもんだな。玉石。
10年ぐらい前にも紀要論文で、同レベルの文字コード論があったという記憶がある。

安岡センセイが暴走中
http://opendata.openlabs.go.jp/ja/idea/00089/

00091の方が大事だな

>>160
マイクロソフトの中の人？

それっぽいね。同姓同名の他人じゃなければ

00089も00091もコメントついてるけど
何かやり取りがちぐはぐな気が

うむ

>>147
ありがとうございます。
FontForge（fontforge-cygwin_2012_08_02）をインストールしてみました。
Webで調べて、フォントからフォントへのコピーの方法は分かったのですが
保存しても0バイトになってしまい、ただいま格闘中です。

セキュリティで言えば高木先生に相当するのがその安岡って人？

半年ROMれ

あまり深く考えたことなかったけど
東アジア人文情報学研究センターって何なんだろうな
図書館の凄い版？

Unicode IVS/IVD入門 ―JIS規格の歴史､異体字問題の解説から､Windows 8での対応方法まで
とかいう本がでるらしいのだが

これは買いですか？糞ですか？

「UnicodeによるJIS X0213実装入門」の続編みたいな内容でしょ。
新たに加わった著者はUnicodeの人だよね。

Unicode対応って言うか
Windowsは早くシステムロケール
UTF8に対応してケロ

コマンドプロンプトはutf-8を選べるようになったの?

(´‥∀‥`)ほう

>>172
ttp://fine.ap.teacup.com/hepo/30.html

>>171
むりぽ
blogs.msdn.com/b/michkap/archive/2006/10/11/816996.aspx

今出来ないのはわかるけど
将来にわたって無理？

最後の一節はかなり悲観的ですなあ
7年前の記事ではあるけど

別に全部サポートせんでも
UTF8にする選択肢だけ
用意すりゃええが

UTF-8にしたら、サイズが1.5倍になるんでしょ。アホかとおもう

Unicode使いたくてWindows使ってる人は何かの修行ですか？
posixサポートも廃止なんだからUTF-8サポートなんて絶望的だろ。

Windowsはコンソールを完全にUTF-16仕様にしてくれるだけでいいんだけどな
SJISはcommand.comで対応することにして

というかいい加減にShift JIS捨てろとw

とりあえずcygwinで満足する努力が必要。

Shift_JISですらないよ、未だにWindows-31J
文字化けするのはUnicode使う方が悪いw

マジ同感。
文字化けはWindwosのせい

>>147
できました！ありがとうございました！

minttyいいね

JEFのコードブックって
まだ手に入るの？

(´･ω･`)？

変体仮名グリフの納入が終わったはずだが、さて。

和文モールスと武雄市図書館が
つながるとは思わんかった

住基文字完全変更って大変だな
http://slashdot.jp/story/13/03/31/163258/

4/1やっていいのは午前中までだ

スラドなんて年中エイプリルフールだろ

失礼な
昔の東スポよりマシだぞ

エイプリルフールじゃなかったのか？

＞住基ネットで文字化け　２３１市町村の１万人分　プログラムミス
http://www.asahi.com/shimen/articles/TKY201304020675.html

今気付いたが今月はもう4月じゃないか

原発事故で行政はどこも信用できなくなった

>>198
それまで信用してたなんて奇特な人だね

得体の知れない文字コードで管理されている個人情報

>>198
そこで民間企業が作ったユニコードというわけですね。わかります。

さて

そんなわけで

うん

話題なさすぎﾜﾗﾀ

Javaのnative2asciiが出すエスケープ変換をC/C++のプログラム中でやりたいのですが
簡単な方法はありますかね?
あ、入力はUTF-8なんですが。

そういえばあれって名前はasciiと言ってるけど実際にはISO 8859-1以外をエスケープ
するという噂を耳にしたんですが...

>>206
1.UTF-8をUTF-16に変換します
2.80hより大きなコードポイントをエスケープします

ほらできた！

>>207
んーと、
UTF-8 -> UTF-16はどうしたらいいですかね。何かおすすめのライブラリはあります?
あるいは自前で変換します?
ASCIIより上をエスケープすべきという主張ですね。
あとサロゲートはどうしたらいいんですかね。
できるだけnative2asciiの挙動と一致させたいのですが。

ttp://www.seiai.ed.jp/sys/text/java/utf8table.html
UTF-8は１〜４バイト(初期の定義では６バイトまで)の可変長コード
00-7x １バイト文字 US-ASCIIにおなじ
8x,9x,Ax,Bx 多バイト文字の２バイト目以降
Cx,Dx 2バイト文字の開始バイト
Ex 3バイト文字の開始バイト
Fx 4バイト以上の文字の開始バイト

つまり
00-7fは元の文字
c0-ffなら「u」+バイト列をそれぞれ出せばいいわけだろ

UTF-16なんて必要ないな
native2asciiの挙動?
使いもしねえもの知るかよ

>>208
1.Unicode規格を読みます
2.規格に従い、UTF-8をUTF-32に変換します
3.規格に従い、UTF-32をUTF16にへんかんします。
このとき、サロペも処理します。

ただしJavaがjarで使用するニセUTF-8が入力の場合は
UTF-8を直接UTF-16に変換する必要があります。

ほらできた！

# cl引数を変換
--
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[]) {
unsigned char* b; unsigned char* h = argv[1];
int i, hlen; hlen = strlen(h); memcpy(b, h, hlen);
printf("ori:\n%s\nuni:\n",h);
for(i = 0; i < hlen; i++) {
if ((*(h + i)) < 128) {/* [0-7]*なら元の文字 */
printf("%c", *(h + i));
}else{
if ((*(h + i)) > 191) { printf("\\u"); }/* [cdef]*なら\u追加 */
printf("%02X", *(h + i));
}
}
printf("\n");
}
--
>na r元の8文字
ori:
r元の8文字
uni:
r\uE58583\uE381AE8\uE69687\uE5AD97

馬鹿には無理

>>208 適当に書いてみた。こんな感じ。
http://ideone.com/2StvbL

Windows限定ならこんな漢字
------------
#include <cstdio>
#include <vector>
#include <Windows.h>
using namespace std;

int main()
{
　char const *p_org="\xE3\x81\xBE\xE3\x82\x93\xE3\x81\x93z"; // UTF-8文字列。

　auto len = ::MultiByteToWideChar(65001, MB_ERR_INVALID_CHARS, p_org, -1, nullptr, 0);
　vector<wchar_t> utf16s(len);
　::MultiByteToWideChar(65001, MB_ERR_INVALID_CHARS, p_org, -1, &utf16s[0], (int)utf16s.size());

　for ( auto &ch : utf16s )
　{
　　if ( ch == 0 )
　　　break;
　　else if ( ch < 0x80 )
　　　printf("%c", (int)(ch));
　　else
　　　printf("\\u%04x", (int)(ch));
　}
}

どうせ、UTF8とかサロゲートペアとか順番に解釈しないといけなくなるんだったら、
コードページ切り替え方式でよかったのにな

ブラジルポルトガル語　と　ポルトガルポルトガル語の
アルファベットは同じでしょうか？？

ポルトガルポルトガル語のフォントでブラジルポルトガル語が
表現できるのかを調べています。

ご存知の方回答よろしくお願いします。

同じなので表示できます。

>>217
　回答ありがとうございました。m(__)m

そーゆーのの違いて基本colorとcolourみたいなもんだろ

>>219
　やっぱり、スペルと発音だけの違いですか。

厳密に知りたいならポルトガル語 正書法でググるよろし

>>219
そうか？繁体字と簡体字くらいの違いはあるかも知れんぞ

なんかそういうのあったな。
ダイアクリティカルマークだったか合字だったか忘れたけど、
コードポイントは同じでも国によって微妙なデザインを使い分けないと現地民にプギャられるってやつ。

ちょっと点の向きや形が違うと言って大騒ぎ。
しまいにゃ文字幅がどうこう言い出す始末。
そんな現地民が東アジア方面にいるとかいないとか

ピンインの二声・四声の話かな？
どれぐらい現地民が気にしてるのかわからないけど。

その国には "立" の一画目が横か縦かを真面目な学問として
研究して金をもらっている連中もいるらしい

あまり面白い皮肉じゃないな

研究してる奴らって立たなくなった奴ばっかりなんだろ

>>226
「龍」の方がおもしろいな

「正しい字形」は横なのに縦で教えるダブスタ大杉

>>208
iconv

>>209
＞UTF-16なんて必要ないな
InDesignというDTPソフトにunicodeテキストを配置する場合、
UTF-16BEなんてもんにしなくちゃいけないんざますの。

>>209はutf8を\u****形式に変換する話してるのに>>232
知障ですか?

要るんです、という話をしただけですのよ。ちなみにわたくしエディタで変換してますわ。

そして誰も

今はもう

初夏

5月か
早いな

アレってどうなったんだっけ

ドレ？

何の&#x30FF;?

コト点でないのか

BBS_UNICODE=passは万能ではないってこと？

てすと ヿ

数値参照だと出るの？ヿ

241は & が変換されてる

テスト
&#x30FF;

変換されるなあ

Open2chの文字コードは、UTF-8だ

<html lang="ja">
<head>
<title>宝くじ＠open2ch掲示板</title><style>body{ margin:0; padding:0;}</style>
<link rel="alternate" type="application/rss+xml" title="RSS" href="http://http://engawa.open2ch.net/loto/index.rdf" />
<link rel="alternate" type="application/atom+xml" title="Atom" href="http://http://engawa.open2ch.net/loto/atom.xml" />
<script type="text/javascript" src="/lib/jquery/jquery-1.7.2.min.js"></script>
<script type="text/javascript" src="/lib/common.js?v2"></script>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="/lib/main.css?x" type="text/css" rel="stylesheet" />
</head><body text=#000000 link=#0000FF alink=#FF0000 vlink=#660099 background=/image/ba.gif>

Old Hungarianは泥沼だな…

よく知らない人でもわかるように簡単な解説希望

Eversonが昔出した提案を前進させようとしたらハンガリー国内よりカウンター提案が
出てきた
そっちは稚拙だったのでEversonペースで進みかけたけど、カウンター提案者が
ハンガリーNBの座を獲得したので意向を無視できなくなった

以後ハンガリー国内で支持が割れて、この度ハンガリー国内から「今のEversonベースの
符号化案のまま行ってくれ」という署名リスト(N4420)と、「今の符号化案を投票から
外せ」という署名リスト(N4422)が届いた

おっおおう…頭抱えたくなる状況だな

なんか難しい話だな。
n4368(Everson)とn4367の戦いってことみたいだけど、
一例にdzの話を読むと、(梯子zの横に棒がついた文字)
これはもともとold hungerianになかった音/文字で、
n4368は現代では使わないから必要ないって立場(n4368 1.2)
n4367はこれは単なるd+zじゃないんだよ(n4367 5.4.1)

読み込めてないけど、
n4368は現代ハンガリー語に対応する正書法の提案も含まれていて、
n4367は歴史的な経緯を踏まえた提案になっている感じか。
たぶんold hungerianを、現代に復活させようとしている派(n4368)と、
歴史的な文字として登録しようとしている派(n4367)の戦いじゃないか。
n4420の"everyday use"とか、n4368 1.2の後半読むと。
学校でold hungerianを使わせる計画があるみたいだ。

こういうのっていろんな分野で政治行政と歩調を合わせないといけないからほんと難しいよね。
単に自分(規格がらみ)が各方面と一対一で調整するだけじゃなくて、そいつら同士の橋渡しまで面倒見ないと何もまとまらないし。

254です。
2,3時間読んでみただけで言うのも無責任だけど、
n4367の方がよさそうな気がするなあ。
Everson版は目的を限定しすぎてて、文字数も相当少ない。
かと言って合字が定義されてるわけでもない。
最初に網羅的にやっとかないと後で公開することになるはず。
あと、n4422によれば間違いも多いと書かれている。
実際どうか検証する知識はないけど、
n4367の方が引用している資料も多いし、一文字に対する検証も徹底的。
Eversonさんは膨大なスクリプトについてUnicodeに多大な貢献があるのは事実だけど、
専門家の意見も謙虚に聴くべきではないか?
まあUnicode専門家の意見も尊重しないといけないがね。

＞最初に網羅的にやっとかないと

日本人が言うとすごい説得力あるよねこれ

Character encoding poetry
ttps://www.facebook.com/cmb/posts/619241744770551

>>252は勘違いで、Everson案がUnicode的稚拙さで、
専門家が本格的な改正案を出してきたってところみたいだな。

そういうものなのかね

過疎ってるな

ねたが無いからね

坂村健みたいな逸材が必要とされている

http://d.hatena.ne.jp/akane_neko/20130621/1371766405
これ読む限りだと安岡センセイもネタ切れなのかと

安岡は基地外だから もう引退した方がいい

最近のWG2の文書の中だとcedillaと下付commaの件が面白いな
結局下付commaの方は別途符号化することになったようだけど

>>263 >>265 まだ基地外TRON信者いたんだ

さて

来週の

キテレツ大百科は

ツレテキ

スレが凍りついているわけだが

unicodeの歴史について勉強しようと思ったら初めからいきなり2バイト固定にしようとしていてズっこけた。
当時日本人はだれも突っ込まなかったんだろうか
あるいは当時のマシンスペックとの妥協とか政治的な何かとか理由があった？

いろんな人が突っ込んでたよ

スペックもあるだろうけどメモリが高価で容量も小さかったせいじゃないかな
当初は日常で使う字だけを符号化して特殊な字や古代の字はPUAを使わせるつもりだったとか
過去スレでそんな話題してるところがあったはず

そもそもUnicodeが使われる日が来るなんてみんな本気で信じて無かった

漢字ROMと文字一覧表(本？)でおk

ちょっと（かなり？）スレ違いなんだけど、
発音記号もそのうちIPA（国際音声記号）に統一されるのかしら。

汎用のものとしてはIPAを改正していくのが正攻法でしょう。
2005年にも唇歯はじき音が追加。

代用になるようなものもないからねえ…

その場しのぎの積み重ねでこんがらがった醜さはUnicodeよりも先輩だな

古文書がIPAで表されるのを想像……できん

想像してもいいんだぜ?

a%20%20%20a

(´･ω･`)？

ここ数ヶ月は話題なしか

http://www.itscj.ipsj.or.jp/domestic/sc02/hanyo-denshi/20100331/

最終更新日：2013年7月26日

情報規格調査会Webサイトの改ざんについて


6月17日(月)、情報規格調査会のサイト（http://www.itscj.ipsj.or.jp）が不
正と思われるアクセスを受け改ざんされたことを確認いたしましたので、直ち
に当該サイトを停止いたしました。

その後の調査で当該サイトに不正な javascript が埋め込まれていることを確
認いたしました。

6月15日(土)箸ｷ6月17日(月)に当該サイトを閲覧された方は、直ちに最新のウイ
ルス対策ソフトで感染の確認と駆除を実施いただきますよう、重ねてお願いい
たします。

現在、セキュリティ専門会社に詳細な分析を依頼しており、閲覧された皆様に
新たな対策が必要となりましたとき、或いは、追加情報が得られた場合には、
改めて情報規格調査会ホームページにてご案内いたします。

当該サイトを閲覧された方、また、関係者の方々にはに多大なご迷惑をおかけ
しましたことを深くお詫び申し上げます。不正アクセスへの対策を講じた後、
安全性を確認した上で再開の予定ですので、今しばらくお待ち頂きますようお
願いいたします。

情報規格調査会 委員長 伊藤　智

ちょっと笑った

紺屋の白袴

違うか、医者の不養生かな

おまわりさんが痴漢

そうか、そっちか

さて

９月になりましたが

2ちゃん落ちるのって今日だっけ？

うそなんでしょう？

よく見ろ　３ちゃんねるに変わってるだろ

　＿, .＿
（； ﾟ ＿ﾟ ） …

>>297
めったなことを言うんじゃありません。
頑張って見る>>298のような素直な人もいるんだから。
って、勝手に文字コードの数字がズレたら嫌だな。
通常の頭では連続していると考える文字（群）のコードが飛び飛びなのもヤだね。

>通常の頭では連続していると考える文字（群）のコードが飛び飛びなのもヤだね。
EBCDICディスってるのか

ディスられて当然のゴミコードがどうかした？

UNICODEも添字系が無茶苦茶

添字系？

字は添えるだけ。

Superscripts and Subscripts

http://www.unicode.org/charts/PDF/U2070.pdf
これか。なるほどこれひどい

小さすぎて読めない

なんでiが1の位置にあるんだろう？

「数字の1を意味する上付き文字」を全部統合するつもりだった？

SuperScript 1〜3は別の場所にある。
2: U+00B2
3: U+00B3
1: U+00B9

oh....

>>307ちゃんとダウンロードして拡大して見ろ＞私　ｺﾞﾒﾝ

まあ、前後とか上中下とか甲乙丙丁とかI II III IV V VI VII VIII IX Xとか、
特定の用法においてナンバリングに使われる文字も位置はばらばらで、
こういうのを名前に含むファイルをソートするとうわあああってなるから
実用上は似たようなもんかもしれん

確かに前後はいつも逆になって鬱陶しい

一九五三四七十二八六

結構イラッとくる

WikipediaのCollationのページに対応する日本語ページってないんだね

欲しければ作れば?

>>314
これぐらいは順番に並べて欲しいわなあ

>>314 >>317
だれが決めたん？
センスないね

あほかい。
漢字の読みの順に並んでいるんだから、寧ろ「一二三四五六七八九」の方がいらっと来るわ。

えぇっ！？

>>319
確かに

読み順で並んでるメリットって何？

読み順以外を選ぶメリットって何？

読み順というか文字コード順でソートしているからこうなるので、
漢数字がいい感じで並ぶ順を定義して実装して使えばいい

メリットって…
他のところが音読み順なのにそこだけ変えるほうがおかしいだろ
というか>>314 >>317 >>322あたりはもしかしてこの十文字が連続して並んでるとか思ってるんじゃないだろうな

CJK Numeralsとかの別枠にしてほしかったってことでしょ

訓呉音漢音の優先順位あやふやにローマ字で並べてある
ような始末におえん状況よりはマシでしょ

Unicodeの漢字って日本読み順なの？

読み順を選べば読み順、画数順を選べば画数順、なんじゃないの？

(´‥∀‥`)？

>>329は見なかったことにしといて

(´・‥∀・‥`)？

>>314 はJIS順なのかな
Unicode順なら 一七三九二五八六十四

漢数字を文字コードだけで機械的にソートするとか、どんだけ

0100
０１００
〇一〇〇
零百
十〇
〇壱〇〇
最適解が欧文の比じゃない数有るからなあ

そういうのはフリガナとかヨミガナとかのソートの種を入れますし。

1024*1024のビットマップフォントにして
黒の数でソートしようず

それが黒だと誰が決めた

黄色でもいいけどよ
モノクロ二値にすんだよハゲっが

意味ない

yes

文字コードについて説明してある本が古くて使いものにならない、ってことになるとは、
最初に書いた人は想像してなかったろうな

>>328
康熙字典の部首順。
だから漢数字が一七三九二五八六十四の順になったりする。

なるほど部首か

>>342
なわけねえべ。

950 名前：あまチゴ ◆TIGOI/DrzHH9 投稿日：2013/09/23(月) 18:35:39.06 ID:i/lAwQriP
&#x9A38;豚か。


951 名前：名無しの報告 投稿日：2013/09/23(月) 18:45:49.59 ID:21igwRGo0
>>950
文字実体参照、16進の数値文字参照を全板で禁止
数値文字参照は10進のみ、BBS_UNICODE=passの板で可


952 名前：あまチゴ ◆TIGOI/DrzHH9 投稿日：2013/09/23(月) 19:38:39.06 ID:i/lAwQriP
せん馬のせんがぁあああ


953 名前：名無しの報告 投稿日：2013/09/23(月) 19:49:53.10 ID:P916m9xr0
せん馬

去勢された牡馬の性別を表す競馬用語。センとも書かれる。
せんは馬に扇で、一部の雑誌やサイトでは騙という字が当てられていることがあるが、それは間違い。


http://qb5.2ch.net/test/read.cgi/sec2chd/1379117300/951 【規制議論板】質問でも雑談でもOKのスレッド★359

何で10進参照だけ生き残ったの？

2chの運営（＝バカ）にまともな理屈を期待しても無駄

この本屋って新宿駅近くにあるんだけど
部屋の区割り自体が迷路のように入り組んでいて
火事で停電になったら出口判らず逃げ遅れて死者多数出ると思う
http://www.dotup.org/uploda/www.dotup.org4535669.jpg

何？唐突に怖いんだけど…よく見たら心霊系、みたいなネタ画像？

文字コード本の棚

どこだよ
ブックファーストか？

ジャンク堂書店？

コクーンのB1やね

どうやらこのスレの住人は５人＋１人のようです。

why?

それはきっと誤認

いや六人だろ

10月ですね

もう今年も僅かですね

あと11月と12月しか残ってないなんて！

てす
¶

『歴博』No.180 けっこうおもしろかった

ここは基地外安岡信者が教祖を持ち上げるスレですね。
安岡用語でレスしないで下さい。

基地外TRON信者はOS板に帰れ

>>363のように安岡の取り巻きしか理解できない
レスをする方が基地外ではないかと

数日ぶりに書き込みがあったと思えばいきなり争いごとか

『歴博』No.180　[特集]文字とコンピュータ2013〜文字コードは踊る〜
＞ 鈴木卓治：文字とコンピュータと人間と　
＞ 安岡孝一：日本の文字コードの半世紀−国際社会との軋轢を越えて−
＞ 小形克宏：Windows外字と、その互換性をめぐる争い
＞ 川幡太一：異体字とIVS (異体字シーケンス)
＞ 上地宏一：グリフウィキ−あらゆる漢字・異体字を集積・共有する文字字形データベース
＞ 高田智和：コンピュータで書き表せる地名漢字
＞ 狩野宏樹：(インタビュー)フォントとIVS〜フォントベンダーの立場から〜

>>368
安岡の取り巻きしかいないだろ

単なる文字コード特集に見える

>>368
http://www.book61.co.jp/book.php/N07886
これか。定価560円ってのは、高いのか安いのか。

＞Windows外字と、その互換性をめぐる争い
丸数字とか時計文字とか？

>>372
「�@」とか「�_」とか「��」とか「�~」とか

�@
JISでシフトJISに定義された文字がどうかしましたか？

(´‥∀‥`)？

３点リーダやダーシには、いまだに悩まされてるわ

薄そう
http://www.rekishin.or.jp/rekihaku180mokuzi.jpg

判ってないな
バベルの塔の逸話は
争ってないで協力しろって意味だよ

できる人がしてください。奴隷は言いなりです。

さて、台風が来るわけだが

買ってきたコロッケをコード番号順に並べ換えてみようか。
ここは雑談スレじゃねえよ＞俺

さて、台風が行ってしまったわけだが

Unicode6.3リリースされたけど誰も話題にしないね。

何だっけ？

んー、7.0.0が出たらネタも沢山あるが...

文字の追加は6.2の時みたいにかなり少ないけどStandardized Variantsに互換漢字に対応するのが追加されたんだっけ。

ああ、例のやつか

ただでさえAdobe-Japan1と汎用電子でVSが分けられて問題になってるのにさらに混乱をもたらす事になりそうだ。
例えば「海」の旧字体はこれまでの6D77 E0100(Adobe-Japan1)と6D77 E0103(汎用電子)で表せてたが、更に互換漢字FA45の置換として6D77 FE00が追加されて異体字シーケンスが3通りになってしまったんだな。

あと「あれ?漢字の場合BMPのVSは使わないんじゃなかったっけ?」って言う人に対してちょっと面倒な説明をしないといけなくなったな。

互換漢字はラウンドトリップ用というのが建前だから
新規文書では使わないのが正解
汎用電子もフォントがIPAmjと花園くらいしかないから消去法でAJ1

字体差でなく韓国のKS X 1001の発音の違いによって分離されてる字や台湾のBig5の誤って重複収録された字に対応する互換漢字にまで割り当てられたんだな。

まるで手書きの戸籍簿のようだ

OS Xって >>96 みたいなことをできるテキストレンダリングAPIが標準でついてるの？
組版ソフトつかっても、フォントに合わせて手動で設定しないといけないことがままあるのに、どうやってやってるのか気になるわ。
これが本当ならmac買いにいく。

組版ソフトは何を使ってる？

>>392=>>96か?
それとも基地外が基地外に反応したのか?

文字コードに対して幅とかマージンが決められてないんだから、スレ違いだろ。
まあ、そもそもフォントとOSで対応できるとか言ったやつが悪いんだけどな。
文字コード的には他のエンコードとの変換のためのコードは使わない。ということは選択肢は1つしかない。
文字コードは文字列の全体的な見た目まで定義してない。仮にmacできれいに表示されたとしてもそれはたまたまってこと。

互換性を考えない、一人で完結ならそれでもいいんじゃない

キャラクターとグリフを分けて考えるようになってからややこしくなってきたよな。
「異体字なのか」「同じ字の字形の違い」なのかとかいろいろ

できる事が増えた。特にUnicodeの異体字は処理が簡単。

Unicodeの場合、なし崩し的にどんどん包摂の範囲が狭くなっていってるから初期のものとの整合性がぐちゃぐちゃで

まあその辺は6以降で。

まあ「文字グリフ分離」はここ数年間での文字コードとフォントの進化の頂点だよな。
あとは包摂の範囲や粒度、字形の問題とか規格で決めることをどう決着つけるのかと
フォントベンダーがちゃんとしたものを手抜きしないで作ってくれるかだよな。

ユーザー次第だと思うね。
メーカーがちゃんとコスト掛けてるものについて、それをちゃんと評価し、使うかどうか。

そうだね、凄い手間とお金がかかっているからね。

フォントのグリフ集合に関してはAJ1の一人勝ちになってるから
その辺Adobe次第なのよね

>>395
スペースを始めとして、半角、全角や幅ゼロやそれ以外の幅の文字もあるよ
http://ja.wikipedia.org/wiki/Unicode%E6%96%87%E5%AD%97%E3%81%AE%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0#.E3.81.9D.E3.81.AE.E4.BB.96.E3.81.AE.E7.89.B9.E6.AE.8A.E7.94.A8.E9.80.94.E6.96.87.E5.AD.97

よくわからんけど、silフォントみたいなやつ？

>>405
で、その幅っていうのは具体的にどれだけなんだい？

等幅フォントを使って
スペース文字で文字間を調節するって
活版印刷みたいだな。

ところで入札までした変体仮名グリフはどこへ行ったんだ

いわれてみれば

ローマ字で長音はサーカムフレックス付けるのに
なんでＪＩＳに全角の「サーカムフレックス付Ｏ（オー）」が無いんだ？

そこでいうJISって何？

文字集合JIS X 0208のことです。

文字コードにそれほど詳しいわけではないのですが
どの日本語文字エンコーディングでも「サーカムフレックス付Ｏ（オー）」は保存できません。
そもそも文字集合のなかに無いのでしょうか？

ローマ字も日本語なのに無いのは変だと思うんですよね。
ギリシャ文字やキリル文字はあるのに。

ユニコードにはあるけど。

ユニコード環境なら使えるのは知っています。
大文字と小文字の２文字を追加するだけで良いのになんで日本語の文字集合に入れなかったんでしょうか？
漢字の異体字みたいに青天井化する恐れも無かったのに。

ちょっとごめん。サーカムフレックスって「^」ですよね？
ローマ字だとマクロンじゃないですか？

交通機関や民間では地名人名にヘボン式ローマ字でマクロンが使われることがありますが

正式な日本語のラテン文字転記である訓令式ではサーカムフレックスが使われます。

＞1947年（昭和22年）の文部省通達[17]（訓令式とヘボン式の両方を解説していた）ではサーカムフレックスとアポストロフィを使うとしており、
1937年（昭和12年）の内閣訓令が事務的な手違いで誤っていたと言われているが、昭和20年代の教育現場（小学校4〜6年生）ではどちらでも良いと教えるように文部省が指導していた。


例：市の公文書でサーカムフレックス付きオーが使われています。
http://www.city.nagaoka.niigata.jp/dpage/kokubun/chikyuhiroba/konnichiwa/newsletter/Vol.252.pdf

歳がバレただけか。言わなきゃよかった

JISに「合成用丸」があることからも分かるように、
アクセント記号は合成でなんとかするつもりだったんだろうよ。

今は合成用丸という名前じゃなくなってるのか…

◯囲い文字は青天井化しそうだから合成するのは合理的かもしれないけど
ローマ字で長音は母音だけだよ。AIUEOaiueoそれぞれにマクロン付きとサーカムフレックス付きを入れても20文字だけじゃん。
なんで入れなかったんだろうね。

JIS X 0213に入ってるんだからええやん

それもそうですね。

昔は「漢字コード」って言ってたくらいだから
みんな非漢字部分にはあまり意識を払ってなかったのかもね

日本人はローマ字なんて殆ど使ってないしなあ。

0208や0212の頃は、漢字でさえまだあれやこれが足りないって議論が盛んにあった頃で、
ローマ字の長音表記に使う長音記号付きの母音字なんてどうでも良かったんじゃない?
変体仮名や西欧のアクセント記号付きアルファベットの方がまだ需要があったんじゃないかと。

和言葉には長音字はないから国語屋も興味薄そう。

これらのカタカナをユニコードに入れてほしい。
一時期存在したわけだし、入れる資格はあると思う。

ヤ行イ - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%A4%E8%A1%8C%E3%82%A4

ヤ行エ - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%A4%E8%A1%8C%E3%82%A8

わ行う - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%8F%E8%A1%8C%E3%81%86

そうすれば
ear 耳　イアー
year 年　⊥アー　（似た記号で代用）
を区別できるのにね。

韓国のわけのわからない試作ハングルよりは実用価値はあると思う。

一定の用例があれば符号化される可能性はあるだろうけど
五十音図だけだと厳しい気がする。文を綴った例がないと

既に入ってる「江」「衣」が有効活用されてるかといえばされてないのよね。
やっぱり、文字コードに入るだけじゃなくて主要な環境でデフォルトで表示できて、入力も出来るというのが普及の最低ラインになるんじゃなかろうか。

> 普及の最低ライン

何の話だ?

金属活字の活版印刷の時代にそれらのカナの活字が造られて使われていたかどうかが大きかったのかも。

フォント屋向けにUnicodeの日本語用サブセットみたいなのが必要なんだろうな
今だとAJ1がそれに近いか

どのフォントでも対応するレベルの現実的な規模のサブセットは0213なんだろうな。
だからそこから外れてるKana Supplementはほったらかされる。

JIS X 0213もAdobe-Japan1も最後に改訂されたのは9年前だっけ
後者は汎用電子がトリガーになって1-7が来るかなと思ったもんだけど

JIS X 0213は今後もサブセット集合として存在意義があると思う。Shift-JIS200Xとかはお笑い種になっちゃったけど

そうだね
JIS信者 安岡信者の心のより所として必要だね

>>435
JIS X 0213なんて意義はもうほぼないだろw
文字コード屋以外には。
世間では既にUnicode+Adobe-Japan1で廻ってる。

> Adobe-Japan1
< Adobe-Japan1フォント

JavaScriptにようやく正規化とサロゲートペアのメソッドが入るみたいで安心

>>436 TRON信者は電波お花畑板という適切な板に行ってください

>>439
Unicodeすらまともにサポートしてなかったのか

Adobe-Japan1フォントは、欧文がダメだからなー

JavaScriptは仕様を巡る争いで数年無駄にしたからなあ

仕様を巡る争いなんてないよ。
そもそもネットスケープの独自言語だったわけだし。

単に標準化委員会が、XHTMLなんかはやらせようとしてて
JavaScirptに見向きもしなかっただけ。

標準化委員会が最低限のDOM以外なにも決めようとしないので
各ブラウザベンダーは独自で便利な機能を実装していった。
この時代に標準はない。

それに業を煮やしたブラウザベンダーがJavaScriptを
ふんだんに取り入れたHTML5を作り出した。
ここからやっとJavaScriptの仕様の話に入る。

ECMAScript 4でググるよろし

図解雑学文字コードは分かりやすくて良い本なので
2002年以降の動向を追加した改訂版を出してほしい。

グリフ集合のデファクトを一企業に握られてるというのは
あんまり健全じゃないよな

Adobeのことかー！！

Winも8.1でAJ16フォントを採用したもんなー

ん、そうなのか

ノリで言っただけで
>>447がどの企業のことを指していたのかはわからないんだけどね。

WG2更新されてゅぅ
でも日本に関係あるのは梵字くらいか

ユニコード戦記の新古書を神田古本まつりでゲット

安岡信者がこんなところにも
http://www.mishimaga.com/tonarimachi/26.html

ここはお前個人の閻魔帳じゃないんだからせめて何が気に入らないのか第三者に伝わるようなレベルで具体的に説明してくれ。

マジ基地のTRON信者だから、何を言っても無駄です

安岡センセイも最近はマイナンバーとタイプライターばかりだからな

安岡は最近は2ちゃんで自分への否定的なレスを見つけては
TRON信者だ！とか騒ぐだけ

良くも悪くも特別視することないと思うけど
別にJSC2の委員ってわけでもないし>>11

タイプライターの件で必死に噛みついてた狂信的坂村信者以外に、
安岡氏のやることなすことケチつける奴なんて考えられんw

>>445
4で数年も無駄にしてない。

ルーブル記号が決まったらUnicode 7.0の前に6.4が来るかな…

>>459
1997からJIS委員対反JISの戦いなんてないしな。
文句ある奴は意見出せって流れになったので。

争点としては残った包摂基準の良し悪しについても、今はIVSがあるし。

争点がほとんどないのがこのスレの伸びにも現れてる。

ITU定義の電話ボタンの*(star)と#(square)が、それぞれ、
U+26B9 SEXTILE
U+2317 VIEWDATA SQUARE
に包摂される模様。
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4495.pdf

しめす偏の「ネ」の字形も「示」の字形差も包摂しちゃって書体のデザイン差にしてしまえば良いのだ。

>>464
いいから、その埃だらけの画像はやめてくれw

>>464
一昨年の話↓が、やっと決着するのか
http://slashdot.jp/~yasuoka/journal/537609

なんと、そんな経緯が

電電公社のプッシュホンの#も
a/bが凄く小さかったり、
αが90度じゃないがあるんだな。

よく見ると目の前の内線電話も#だけ傾いてるな。

経緯を無視して特定の時期のデザインを基準にしちゃうのもなんだけど
今更☆と◇には戻せないしなあ。

IVSで好きな字形選べるしなw

>>167
半年ROMったがお前がクズだということがわかった
とっとと死ね

半年ROMれとか何様だよこの老害
まじむかついてきた
くたばれ

すべったか

>>473
半万年ROMれ

>>464
ITU-T E.161だな。
>>469
推奨値にすぎないが、斜めになるとa/bが0.18になる。
a/bが大きいのに90度なのは、推奨ではない独自のシェイプということになる。
http://www.itu.int/rec/T-REC-E.161-200102-I/en
ISOだと、ISO/IEC 9995-8。

どうしてa/b、90度を標準的なグリフに変更するように求めているんだろう。

ところでISO/IEC 9995-10に関する提案も出ているんだけど、
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4464.pdf
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4444.pdf
を見るとびっくりするような記号までキーボードに関連付けられているのだけど。

ドイツ人は、コンマ付きのアポストロフィとか、
ダブルレフトアングルとか、比のスラッシュとか、割り算のスラッシュとか、
いちいちキーボードのキーに割り当てていたんだね。

来週からIRGだってのにあまりドキュメントがポストされませんな

U+26B9　⚹
U+2317　⌗

これらを含む日本語フォントがどれだけあるやら

SEXTILEはWebページならスタイルシートでアスタリスクを90度回転させればいいな。

いや、見た目だけでいいなら画像貼ればいいんじゃねと思う。
アスタリスクは回転させてもアスタリスクだし、なんとも中途半端じゃないかね。

じゃあ×もいらないな。＋を45度(ry

今はWebFontで特定の文字だけ好きな埋め込みフォントで表示させられる時代ですよ奥さん

盲人用読み上げソフトや
全文検索エンジンが困るだろう。

現段階じゃ実質的にWebFontってフォントを自作できる人にしか活用できん罠

○度回転させる制御文字をUnicodeで定義しておけばいいんじゃね？

IRGN1959＜AJ1・汎用電子に続く第3のIVDを登録するよ！
だって

IPAの文字情報基盤か。
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg41/IRGN1959_Japan_Activity.doc

なんや！

ラニマル文字

>>489の母体はこれかな
ttp://mojikiban.ipa.go.jp/

議事録面白い
変体仮名の検討つづいてたんだ

なんの議事録？

492の委員会活動状況ってところ
何をどう符号化するかみたいな話がのってる

変体仮名ってどんだけ使用実績あるの？
戸籍統一文字と相互変換することなんてありえないし。
またゴリ押しして複雑化するのだけはやめて欲しい。

またというのは？

変体仮名は和歌の世界では日常茶飯時で当然活字もある。

古典を電子化するために必要ってことだよね。
でも変体仮名ってゴシック体とか明朝体の活字が使われる頃には既に使われなくなっていたから
楷書体の字形しか無いよな？
ゴシック体の変体仮名ってマヌケそう。

散々言われ尽くしたことを何故いまさら

>>500
結論出たならいいけどさ
登録するなら必要な話でしょ。
手書き限定ならそもそも活字化出来ない→誰も実装しない→登録する必要性なし
って判断されるかもよ。

>>498
活字なんてあったっけ?

行政で必要なものだけ符号化すりゃいいんだよ的な話になってるのは気になるけど
どのみち於可古志八みたいな有名どころは入ることになるか

>>502
当然あった。例えば「築地活文舎　変体仮名」でググれ。
基本的なことも知らないのだから活字には無知だろうに、
どうして「あったっけ?」なんていい方が出来るのか...

この会社ならいい感じの変体仮名のフォント作れそうだな。
http://fontworks.co.jp/font/tsukushi/tsukushiboldmin/R.html

そもそも常識的に考えて「変体仮名の活字はなかった」なんておかしいだろ

弘道軒清朝体が出てきて懐かしくなった

>>4-6
UTF-8に統一しろよって言いに来たけどテンプレ読んで頭が下がりました。
すいませんでした。

>>4
>・PC-98x1シリーズのMS-DOSはShift_JISだが漢字ROMはJIS、変換は何処で行っていた？

テキストVRAMに書き込むのは、BIOSかコマンドの仕事。
直接書き込みたければコマンドが自分で変換する必要がある。
ちなみに1byteごとに色等の修飾属性1byteがつくから、漢字は4byte。

98のbiosは文字描画無いんじゃなかったっけ?

そもそもMS-DOSはShift_JISじゃないし。
>>4の様な安岡信者は相変わらず気が触れているな。

学参明朝などという八百長書体のせいで
字形の違いとデザイン差の問題がでたらめになってしまった。

学参明朝を撲滅せよ！

>>511
安岡のおっちゃんもCP932とShift_JISくらい区別ついてるよ

安岡はCP932とShift_JISの区別は付いているけど
シフトJISとShift_JISの違いがついていなくて
Shift_JISを妄信しているから困る

意味のわかんないことを一人で必死に連投してるのは何？

勉強してきて、どうぞ

「シフトJIS」なんて厳密な定義ない。>>514は馬鹿。

厳密な定義のない広義のシフトJISとShift_JISとが
区別できてないってことだろ

http://slashdot.jp/~yasuoka/journal/334730
↑この話な

MS-DOS全盛の時代にWindows-31Jがあったとは思えないんだが

>>519
これ読むと
誤解されてる方の意味での
「シフトJIS」ってのは
EUCにふさわしい名前だな

>>519
これは「シフトJIS」と「Shift_JIS」を混同している(>>514)んじゃなくて、
世間的にASCII+Microsoftが起源と思われている「シフトJIS」が
実は漢字CP/M由来であるという話の中で、
Shift JIS系のコードの総称として「シフトJIS」と言う言葉を使ってるんじゃないのかな?

>Shift JIS系のコードの総称として「シフトJIS」
というのが世間の認識なんだけど、
安岡氏は代表であるMSのそれを「MS漢字コード」
という別物としてとらえている感があるような

「完敗」って書いてるじゃん

>>523
なんか前半と後半で文書繋がってないけど。
・総称をシフトJISと呼ぶことが多い
・CP932を安岡はMS漢字コードと言ってる
・シフトJISにCP932は含まれる
ってだけじゃないの。

で、スラドに書いてあるのはシフトJIS起源はどの会社かって話でしょ。
これに関しては安岡説は間違ってたと当人が認めてる。

読解力ないな
スラドのテーマは
「誤解されてる方の意味」の

>「Windowsの前身にあたるMS-DOS開発時にマイクロソフト社などによって考え出されたのが
>「JIS漢字のコード領域をごっそり1バイト文字の領域と重ならないコード領域にズラしてしまえ」という方法、
>すなわち「シフトJISコード」でした」

を言ったのはどこの会社の誰かソース出せ
ってことだろ

誤解されてる方
って何だ？

「これを読む限りでは」って限定してるじゃん
しかも今じゃ読めないし

安岡はともかく>>4あたりがよく分かっていないのは間違いない

4がっつーか当時の書き込みがそのまま使われてるだけだろ
www.bookshelf.jp/2ch/tech/1143375639.html

質問なのですが
CP932のNEC選定IBM拡張漢字と、IBM拡張漢字の領域で
重複している漢字がいくつかありますが
UTF8から変換した時、どちらに変換するのが正しいんでしょうか？

例) �\(U+7E8A)

NEC選定IMBだと
0xED40

IBMだと
0xFA5C

自己解決しました
Wikipedia先生に答えが書いてありました

> 「NEC選定IBM拡張文字」「IBM拡張文字」が重複する場合は、「IBM拡張文字」に統一

ありがとうございました

ふむ

ほう

へえ

ところでPRI 259は

TwitterでNさんが夜中にキレてたね

文字コードの判定の精度を確かめたいのですが
よく使われているテストセットみたいのってありますか？

>>536
IPAmjフォント専用みたいな感じだから
良くも悪くも一般ユーザーには関係なさそう

>>538
テスト用にサンプル集めてるところだわ
パスはUTF8で
http://www2.age2.tv/rd2/src/age5249.zip.html
どれもウェブページとかウェブから拾える

KOI7-switched windows-125[2347] IBM-12{61|64|65|68|76} ISO-2022-KR Big5-HKSCS辺りは見つけられてねえ

Encode::Detect::CJK
Unicode::Japanese
CharsetDetector
Lingua::DetectCharset
activeperlで使えるこの4つ総合してもcp1256とkoi8が判別しにくいようだが
ファイル単位でなら80-ff調べれば一目瞭然だね
totalとの差は80-bfの分
cp1256: 0xc0-0xdf:229, 0xe0-0xff:178 total:422
koi8r: 0xc0-0xdf:62356, 0xe0-0xff:976 total:63359.
koi8u: 0xc0-0xdf:6341, 0xe0-0xff:96 total:6455.

Encode::Detect::CJKの判別能力はかなり高い
>>540の不足分(はテストできないのでそれ)以外だと
koi8とcp1256を区別できないのと
big5とiso-2022-cnとcp1251とgb2312とiso-8859-6とiso-8859-11で誤判定がある程度

ちなみに
Encode::First Lingua::ZH::HanDetect Lingua::DetectCyrillic Lingua::RU::Detect Encode::Guess
は使い物にならなかった

文字コードの判定の"精度" という言い方が引っかかるんだよなぁ。
なんでかって考えてみたら、品質が良くなれば精度があがるみたいな
ことを思ってしまうからかな？精度が悪いものはダメみたいな。

文字コードの判定っていうのは、仕様なんだよね。
あるバイナリ列があったとき、それがAという文字コード、
Bという文字コードの両方の当てはまることはあるんだよ。
こういうのは「AかBの文字コード」というのが正しい答えになる。

この場合にどちらを答えるかというのは、精度の問題ではなく単に仕様でしかないんだよ。
例えば、日本語にしか対応していないやつなら外国の文字コードに
当てはまる場合でも答えないだろう。これは精度ではなく、外国の文字コードに
対応していないという話。考え方によっては、低機能と言える。

多くの文字コードに対応していればいるほど、判定の精度は低くなる。
というか精度ではなく、対応しているものが多いから、
多くの文字コードに当てはまることを正確に教えてくれる。

だから判別能力が高いとか低いじゃなくて
迷った時は○○コードよりの判定をしてくれるとか、
日本語だけしか対応してないから、外国の文字コード
判定されることはないとか、そういう話にしなきゃ。

1文字で調べても意味ないからね。1文字では正しく判定できたとしても
その文字が含まれている2文字、3文字だったら誤判定することもある。

> Encode::Detect::CJK
> Unicode::Japanese
> CharsetDetector
> Lingua::DetectCharset
> activeperlで使えるこの4つ総合してもcp1256とkoi8が判別しにくいようだが

こういうのもね。ライブラリの精度の問題じゃないんだよ。

cp1256とkoi8が区別しにくいのは、文字の問題。
同じバイナリ列にかぶってるんでしょ？

区別しにくい（誤判定する）のは文字自体の問題で、
それをどのように判定するのは、ライブラリの癖というか仕様。

Encode::Guess が使いものにならないというのは、
Encode::Guess が日本語以外の多くの文字コードに対応していて、
対応しているもの全てを列挙するからだよ。一番正確。

ベイズ推定かな

>>545
うん、そうそう。そういうこと。

結局のところ、文字で判断している以上
それは精度ではなく仕様という話でしか無い。
複数の文字コードで解釈できるというのは事実でしか無いからね。

精度という話をするのなら、文字ではなく文字列、文章として考え、
それがどの文字コードであれば意味が通る文字列、文章として解釈できるか？
っていう話に持っていかないといけない。

まあその場合の精度も、どんな辞書を使っているかって所が
差が出る一番の要因で、アルゴリズム的なところではあまり差は出ないだろうけど。

文字列、文章で判断するのなら高い精度で判定できるようになるけど
1文字だったら誤判定する確率はやっぱり高いだろうな。
その文字をよく使っている文字コードはどれ？という程度の判断基準になるからね。

Encode::Detect::CJKはデフォでcharset指定見てるからで
判断材料にしないようにするとかなり落ちるな

精度に反論してる奴がいるけどさ
実際はとりあえず選択して試してみる必要があるわけで
実用面ではある程度当たればいいわけだよ

Encode::Guess が全てを列挙するというんだけど
それが本当なら良いけど実際列挙しないしな

用途にも拠るかね。
100%の精度が必要な自動データ処理系か、
ブラウザやエディタのように人の目で判断して文字コードを修正出来るものか、とか。

組版ソフトだと設定で勝手に換えてくれちゃったりするから、
他のところに持って行くとぐだぐだ

Mac Binary 最強ですねわかります

なんでMac Binaryやめたんだろうね。
糞だったのかな？

>>551
意味分かって喋ってる?

>>552
はい、わかっていますが
言いたいことがあるのならどうぞ。

>>553
MacBinaryはtar等と同様の単なるシリアライズフォーマットだが、
どこが文字コードと関係するのかね？

>>554
Macバイナリの話を始めたのは>>550ですよ？
変なことをいいますね。

>>555
意味分かってないじゃん

これ立てたのお前かよ

Apple固有技術のMac Binaryは復活するべきだと思う
http://anago.2ch.net/test/read.cgi/mac/1387205359/

検索結果にでてきた
https://groups.google.com/d/forum/emoji-working-group

CNETで絵文字コラムをやってたころのかな
あの連載って完結したんだっけか

確かに最終回を見た記憶がない

小形さんの連載の最終回はどれも見たことがないような…

それでも仕事が取れるのか…

某氏が呟いてた葬り去られるフォントって入札のあれかな

カタカナの「ツ」が海外で顔文字になってるの知ってた？ - ねとらぼ
http://nlab.itmedia.co.jp/nl/articles/1312/20/news111.html
2013年12月20日 15時43分

それ聞いたとき、へー日本語使えるんだぁ、と思った。(´･ω･`)も行っちゃえ〜w

utf-16って一文字で表せる文字と２文字で表せる文字があるらしいじゃないですか？
そういうばあい
char16_t x[2]="一文字で表せない文字"
ってやらないといけないんですか？

サロゲートペアとか結合文字とかIVSでググれ
もっと面倒だから

ユニコードの文字って全種類IMEで出せますか？

無理。
なぜならUnicodeというのはバージョンアップするものだから。
分かりやすく言えば、今も文字は増えている。

直近だと
2010年10月11日　　Unicode 6.0.0　　109,449文字
2012年1月31日　　Unicode 6.1.0　　110,181文字
2012年9月26日　　Unicode 6.2.0　　110,182文字
2013年9月30日　　Unicode 6.3.0　　110,187文字

更に言うのならIMEでは全種類出す能力はあっても
フォントが用意されていなければ表示されない。
IMEだけの話では解決しない。

フォントあっても表示系が対応せんといかんし。
複数のフォントを組み合わせてできるだけ多くの文字に対応したり。

お前らなら知っているかもしれないと思って質問するんだけど

多角形（三角形、四角形、五角形　…）
星型多角形（五芒星、六芒星）
はキャラクターも英語名もそんざいするけど

1本（ある意味放射状2本）―　｜
2本（ある意味放射状4本） ＋ ×
放射状6本(sextile)
http://en.wikipedia.org/wiki/Sextile
はわかるんだけど

↓この図形を何て呼ぶか（和名、英名）誰か知らないかい？
http://i.imgur.com/0gPjO4B.gif

分位数と同じでよければ
3ならtertile
5ならquintile

　　　∧_ ∧　　　　喰らえ！
　　（´∀｀　）
　　　 （⊃⌒*⌒⊂)
　　 　　/__ノ''''ヽ__）

>>572
うーん、sextileから判断して分位数で表しても、「本当にそう呼ぶのか」が疑問ですよね。

占星術でもquintileは別の記号ですよね。
http://en.wikipedia.org/wiki/File:Quintile-symbol.svg

ちなみに前述の記号って文字集合にはあるのかな？

Quintileは天文のでっかいボールドQ
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Astrology/Glyphs

だからそういうことじゃなくて
http://i.imgur.com/0gPjO4B.gif
この記号は何て呼ぶのかな？っていうことなんだけど…

左はsplit decision

大

文字としては3本のほうはわからないが、5本はアスタリスクのデザイン差と
いうことになってる。Unicodeの例示図形ではU+FE61のsmall asteriskが5本。

確かに5本はよく見かけるな。

5本って鶏の足の形のことか？

にわとりって足指5本もあるの？

アスタリスクを文字ビューアで見ると，フォントによって字形がさまざま。
中には８本のものも。Helveticaは５本，Timesの類は５本だったり６本だったり。

小塚さんも明朝とゴシックで向きが違うのね

あら，ふぉんとだw　安定のヒラギノ

字にはヒラギノール

>>586
くそ、お前が俺の初笑いだわ

みんな同じこと考えてんだな
https://www.google.co.jp/search?q=%E5%AD%97%E3%81%AB%E3%81%AF%E3%83%92%E3%83%A9%E3%82%AE%E3%83%8E%E3%83%BC%E3%83%AB

Unicodeを送られてLINEを初期化されたんですけど、強力なUnicodeありませんか？
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11116062531

裏技コードみたいなものになってるんだな

https://twitter.com/good_dezaiso

結局誰もわからないのかよ…

>>583
欧文書体の世界では
セリフ（明朝体）は６本
サンセリフ（ゴシック体）は５本
が標準のようです。

記号じゃなく図形聞きたいのかね

記号でも図形でも名称があるかどうかが知りたいのですよ。

自分で勝手に名づけても通用しないわけでしょ？

おれはそもそも詳しくないからあれなんだけど、
たとえ知ってる人がいてもきっと質問意図を測りかねてると思うんだな。

画像の図形を本か何かで見たのならもっと具体的に文脈を明らかにしたほうが助けになると思うし、
あるいは「こういう形の図形って世界のどこかにあるのかなあ？」という素朴な疑問なのか。

質問の意図としては
同じ長さの棒が一点から等角度で４本放射状に棒が出ている「十字」
同じ長さの棒が一点から等角度で６本放射状に棒が出ている「セクスタイル」
があるのだから３本、５本なども記号として存在して名称があるのではないかと思ったのです。
http://i.imgur.com/0gPjO4B.gif
この図はPohotshopで自分で描いたので引用元の図書などはありません。

お前が勝手に作っただけじゃん
そういうのが混乱のもとになるっていうのが分からないの？

この程度の幾何学図形は創作でもなんでもないだろ。
なんて呼ぶかわからないから検索のしようがなくて自分で描いただけで
俺が描くまでは地球上に存在しなかった図形のわけないじゃん。
誰もわからないのならこのスレではもうやめるよ。

6本がそれでいいなら>>572でいいんじゃないのか…?
1週間以上前だけどUnicodeの表はどこまでチェックしてみたんだろう…?

わかってるとは思うけど「6本の図形の名前=セクスタイル」ではなく、
「6本の図形を占星術で使う場合の名前=セクスタイル」。
まったく同じ図形でも使われかたによっては「アスタリスク」にもなるし、そのへんはほんと文脈次第。

すでに出てるように5本のは「アスタリスク」として通用するので答えは「それの名前はアスタリスクだ」でおｋなんだけど、たぶん聞きたいのはそういうことじゃないよね？
もしそうなら3本のは「うーん、“ダイムラー”とかでいいんじゃないかな」と答えれば済むんだけど。
http://www.daimler.com/Projects/c2c/channel/images/762972_1391486_389_328_713349_1290685_389_328_1998M389.jpg

いやアスタリスクで調べたらわかると思うんだけどなｗ
十字でいいなら(逆)Y字でもいいと思うけどｗ

地図用の記号で「三叉路」でもいいかな

アスタリスクは small star という意味のギリシャ語由来だから、星に見えれば
なんだってアスタリスクだぞ。5だろうが6だろうが8だろうが。

>600なら、3 pointed starだけどね。
ただ、ある程度の幅のある図形を想定しているから、5 pointed starはpentagramになっちゃうねぇ。

あまり一般的な図形じゃないから汎用的な名前はないでしょ。
五本はたしか線文字Aにあったはず。
線文字っていうくらいだから太くない。

>>571
さすまた、菊

一人十大木光米

×
大
水
氷
※
永

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10117115845

LINEでUnicode相手に送って重くさせた場合犯罪なの？

相手から送ってこいって言われて送ったんだけど

犯罪犯罪ってうるさくて

* ベストアンサーに選ばれた回答

oretyan_0928さん

Unicodeでの攻撃は
電子計算機損壊等業務妨害という
犯罪になります。
5年以下の懲役または
100万円以下の罰金の重罪です。

相手が訴えればの話ですが…

「ユニコードは犯罪だからやめてください」の衝撃
http://yanok.net/2014/01/post-301.html
Unicodeを送られてLINEを初期化されたんですけど、強力なUnicodeありませんか？
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11116062531

UNICODEのコードポイントとUTF-8のバイト列の対応表とかってありますか？

arimasuyo

>>612
どこにあります？

ユニコードの攻撃か... ここに新たなユニコード戦記が

>>611
そういうのは Unicode から UTF-8 のコードをどうやって作るかを調べれば自作出来ると思うが。
まあでもそれが分かればそんな対応表作る気なくなると思うなあ。

Wikipedia に書いてあった。要するにビット単位で抜き出して配置してるだけ。
1バイト目の上位ビットを見ると全体が何バイトかが分かる。
http://ja.wikipedia.org/wiki/UTF-8

C#だったら、
char ch = Convert.ToChar(128); // コードポイント 128の場合
byte[] bytes = Encoding.UTF8.GetBytes(new char[]{ch});
でUTF8のバイト列が得られるな。

ucs2とutf-8のバイト変換ツールをexcel関数で作ったことが有るな。
DEC2BIN関数使って２進数に変換してMID関数でビット毎に取り出して判定して、、というやつ。

ありがとうございます．
勉強のためunicode同士でコード変換するプログラムを作ったのですが
そのテストのために必要でした

西夏文字はようやく符号化提案書の段階までたどり着いたのね

よくわからんがいろいろ大変なんだなあ

日本語の文章にいわゆる半角括弧(U+0028,U+0029)を使ったら、全角括弧(U+FF08,U+FF09)を使えと言われました。
ほとんどのフォントでは、全角括弧はひらがなと漢字と調和するデザインになっており、
半角括弧はいわゆる半角英数字に調和するデザインになっているからだそうです。
文字コードに対して、フォントの字形を定義する規格があるのでしょうか。

前から、いろいろな人に言われてたんですが、フォントが駄目なだけだろと思っていたので、無視していました。
ですが、言い負かすか、言い負かされるかを決断しないといけなくなったのでお願いします。

JISの文字コード規格でも、組版規格でも全角括弧を使え見たいなことは書いてないので、
個人的には全角括弧を使いたくないです。

そのへんはまだ「コレダ!」という結論が出るほど成熟してない気がするね。

きれいに見える括弧の幅は和文欧文で違うから、フォントが「駄目」とも言い切れないし、
かといってレンダリング側で機械的に和文欧文を判断してグリフを割り振って問題が出ないレベルのものでもないし。

ほんとは全角・半角がそれぞれ「和文用・欧文用」と定義されてれば有無を言わさぬ現実解になったと思うんだけどな。(括弧以外の記号や全角ラテンを含め。)
今後、電子出版が広がるなかで「あれ、これどうすんの？」って改めて注目されて何らかの仕組みが出来ればいいな。

>>622
半角括弧にこだわっているようだが句読点は気にしていない時点で
ただのあなたのわがままに過ぎないことがわかる。
横書きでは公文書は「，。」（技術文書は「，．」）という指針がある。

そこまで半角括弧にこだわるなら半角カンマと半角ピリオドも使えや。

括弧は半角がいいよ派と全角だよ派、いやいや半角の外側に半角スペースを入れるよ派の三つ巴だな。

括弧の中身に合わせるのが見やすいかな
>>622 のように半角英数記号だけの場合は半角括弧使う

出すときに一括置換するだけだろ

「アプリはアプリケーション（application）の略である。」
みたいな文章があったとして（）を半角にするのか全角にするのか

それなんだよな。一概にはいえない。

>>622
＞半角括弧はいわゆる半角英数字に調和するデザインになっているからだそうです。
むしろ半角の括弧類は全角文字に「調和しない」と考えたほうがいいでしょう。
ベースラインが異なるからです。（横組みの場合、半角は少し下がって見えませんか？）
太さや位置などを確認するのには、
国国（国）国(国)国[国]国［国］国<国>国＜国＞国〈国〉国
などを、フォントを変えて見てみるのがいいと思います。

>>628-629
まあ、そうですね。不統一は避けたいですが。

確かWikipedia日本語版あたりは「半角も全角も禁止はしないが、全角を半角に修正するのは禁止」みたいなやや全角寄りの微妙なルールがあった気がする。

というより、こいつメンヘラだろ

半角カッコを使うときは、
あああ (hoge) みたいに
括弧の前後を空白で開ける。

>>633
括弧の中に入るものが1文字とかだとどうするか少し悩む

たとえば (i) こんなのか？

>文字コードに対して、フォントの字形を定義する規格
それは知らないがJISX0213にはU+0028,U+0029を使えって書いてあるし
JISX4051を参照してもU+0028,U+0029だ
よかったな

>>625 半角の外側に半角スペースを入れるよ
絶対にやめてください。

>>633
やめてください

>>638
お前のレベルまで落ちるつもりはない。
勝手に変なことしていれば良い。

トルツメ

Wikipediaの表記ガイドに従ったら？
http://ja.wikipedia.org/wiki/Wikipedia:%E8%A1%A8%E8%A8%98%E3%82%AC%E3%82%A4%E3%83%89

Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）のほかに、全角形の（……）・｛……｝・［……］が規定されています。
括弧の中にいわゆる半角の文字だけがある場合は、いわゆる半角の括弧を用います。
括弧の中にいわゆる全角の文字のうち、漢字・仮名・和文記述記号がある場合は、全角形の括弧を用いるべきだという意見と用いないという意見の2つがありますが、目下の合意はありません。
未了 これについては、当ガイドラインのノートで議論されています。
いわゆる半角の括弧を用いる場合は、以下の例外を除き、括弧の外側に空白を入れます。
直前に、ほかの開き括弧類がある。直後に、句読点やほかの閉じ括弧類が続く。
直前や直後に、和文の句読点や和文の括弧類がある。
括弧が固有名詞や型式番号などの一部で、括弧の前や後を空けずに表記される。
段落の始まりや終わり。

> いわゆる半角の括弧を用いる場合は、以下の例外を除き、括弧の外側に空白を入れます。

なるほど

> いわゆる半角の括弧を用いる場合は、以下の例外を除き、括弧の外側に空白を入れます。

うん、なるほど

括弧の外側にスペースを入れるのって、
ソフトウェアのUIなんかで「アルファベットと和字の間にスペースを入れる」のとかとも絡んでくるのかな。

トルツメだな

>>644
単なる英文の文化だからだろ？

半角英数字 = 英文
全角英数字 = 日本語


半角 ＝ 英文を使うなら、その文化に従えってだけの話。
英語は単語をスペースで区切ります。言い換えると単語の前後にスペースを入れます。
そして括弧の前後にもスペースを入れます。

＞半角英数字 = 英文

ちょっと待て誰が決めた

やっぱりこの種の話題は宗教戦争化しやすいな。

>>647
昔から。

そもそもコンピュータの文字なんてのは
最初アルファベットしかなく。
それは日本ではなく、外国（アメリカだっけ？）で
生まれたものなんだよ。

そのアルファベットというのは当然半角で
その文字は英語のために作られた文字。

ローマ字表記は英文じゃない派

英文は訂正しよう。

英字

ローマ字も英字

>>649
いろいろぐちゃぐちゃすぎﾜﾗﾀ

│
│
J

>>652
反論はなさそうだねｗ

12 月 31 日みたいにいちいち空白入れるとか馬鹿げてるだろ
こんなものは詰めた方が見やすいし

>>646
jisc6220は英語だったのか

みんな英字と呼ぶけど、あれはラテン語のものだからラテン語のルールに従うべきだな。

コイン(10円硬貨など)3枚

とか開始と終了で全半角での挟まれ方が異なる場合でも
矛盾なくできるならローカルルールで使いわけてもいいんだろうがな

>>657
そして漢字は中国式で、算用数字はインド式を要求されるのだ。なんという悪夢。

＞外国（アメリカだっけ？）

ﾜﾗﾀ

>>658
やっぱ一概に「こうするのが正しい！」は無理だよなあ。

なに、インド産のくせにアラビア数字と詐称していたのか　ゆるせん

英でもcharacter(s)みたいな場合にはスペース入れないしねえ。

>>662
インド産のものがアラビア数字と呼ばれ、
アラビア産のものがインド数字と呼ばれている悲劇

>>645
?

最初の質問は、>>630の言うベースラインのズレがUNICODEとかの
規格で決まっているかどうかじゃないの?
リファレンス字形みたいのを示せば一発では。

> 文字コードに対して、フォントの字形を定義する規格があるのでしょうか。

質問自体はこれだがunicodeなんかにはそのようなものはないと思う
しかし他の規格に無いとは言い切れない悪魔の証明と化すので
そこへは立ち入らない

なんで同じ字形で全角と半角との２種類の存在が許されてるの？

は？

表記の添削希望
http://toro.2ch.net/test/read.cgi/tech/1390104181/

>>623
どうも、わたしの近辺では全角括弧が和文用、半角括弧が欧文用としてデファクトスタンダードになっているようです。
>>630
MS ゴシックだとベースライン一緒なんですよね。だからあんまり問題にならなかった。
Windows Vista以降のメイリオとかAndroid他を考えると、文字コード規格や組版規格に従えといっても現実的には無理なんですよね。
あと、全角括弧のベースラインをひらがなや漢字に合わせると、全角英数字のベースラインはどうなるんだっていうところも気になります。
>>633
OSの文字列レンダラに渡すとスペースを入れた方が見栄えがいいけれど、
ワープロソフトで入力すると勝手に前後にアキを入れてくれたりして、なかなか共通にしにくいですね。
>>636
これを言ったら、お前はJIS規格のコードじゃなくて、Unicodeを使っているはずだとか言われました。
あと、昔のfjによくいた、現実を無視したキモイつっこみを入れる奴と一緒だなみたいなことを言われました。
まあ、実際そういう性格に近いですが。

>>622
> 日本語の文章にいわゆる半角括弧(U+0028,U+0029)を使ったら、全角括弧(U+FF08,U+FF09)を使えと言われました。
> 文字コードに対して、フォントの字形を定義する規格があるのでしょうか。
それがUnicodeだろ

>>672
字形という言い方が正しくなかったかもしれません。すいません。
ある文字が他のある文字と調和する形状・位置であるかどうかを定義する規格と言ったらいいでしょうか。

それは言語そのものであって繁体字と簡体字の関係あるいは極論アルファベットが全部同根であるようなもの

>>671
絶対ルールでなく、あなたのコミュニティーのルールに従うのが良いと思います。

グリフイメージ（字形）
フォントイメージ（実際に表現されたデザイン）
の話を混同している上に
そもそもどちらも文字コードが扱う問題じゃないんだよな。

ああ、言っちまったぁ

文字のないところに文字コードはないとでも言えばわかるのか

組版については，
「日本語組版処理の要件」
http://www.w3.org/TR/jlreq/ja/
を見たらどうでしょうか。
括弧などの約物処理について詳しく書いてあります

>>679
クラの編集者に見せたい

>>676
じゃあ、例示字形ってなんなの？

> じゃあ、例示字形ってなんなの？
例として示す字形に決まってるじゃん。
^^^^^^^^
絶対これにしろ、と決めるものではない。

>>679
それの元が>>636のJISX4051で結果が>>671なんだし無駄なことだろ

その文章にルールが必要なら決まりに従う、または、決めればいい
入力は誰しも間違うから verifier を用意すること
間違ったからお前が悪いとかあほなことは言わない

不統一なものを一括処理するスクリプトでも書いておく、と

ああ、それがいい

二階建てのaとgの文字コードが欲しいよな。
フォントが指定できない環境で一階建てのaとgとの違いを説明するのに必要だから。

純粋な字形の説明なんて文字コードの守備範囲外だろう。
それやりだすと「下に棒のある1とない1」「上が閉じている4と開いている4」「横棒が1本の\と2本の\」みたいに収拾がつかなくなるぞ。

「$」の中の棒を２本にしろとか言われるしorz

どうしてもプレーンテキストでやりたいなら↓これでどうにかなる

＿■■■
＿＿＿＿■＿＿＿＿■■■
＿■■■■＿＿＿■＿＿＿■
■＿＿＿■＿＿■＿＿＿■
■＿＿＿■＿＿■＿＿＿■
＿■■■＿＿＿＿■■■＿■

そもそも、JIS X 0208で英数記号をISO 646と重複符号化したことが問題。
便宜上全角・半角と呼ばれて字形を区別しているフォントが多いが、本来は全角・半角なんて概念は文字コード自体に存在しない。

半角２バイト文字とか、いや〜ん

流石にそれは98機種依存だけどなw

>>625
つ mathモードのカッコを好みのサイズに引き伸ばして使う派

>>628
(applicationが好き)だとどうなるのだろうか?

>>691
けどomicronとかEPWINGみたいな使い方を想定したんでしょ?

一応一階建てのaとgはU+0251とU+0261に符号化されてる。
発音記号用に符号化されてる(特にaについては一階建てか二階建てかで別の発音を表す)がそれ以外の字形の説明等の用途に使ってもいい筈。
でも二階建て専用コードは無いんだな。活字系のフォントではU+0061とU+0067は二階建てであることが多いが。
一部のフォントでは一階建てになってしまうから、厳密に二階建てであることを示さなければいけないときの為に符号化してほしいよな。
VSを使ってU+0061 U+FE00,U+0067 U+FE00とかでもいいから。

二階建てa用のコードポイントがなくても発音記号用途は現状うまくまわってるの？

「そ」の上が「ソ」と「フ」どっちなのか「き」「さ」「り」繋がっているかとかは割と話題に上るが
「え」「ん」の「〜」部分の山は角なのか丸なのか直前の斜線と一部同化するのか
「ね」「れ」「わ」の「フ」が「｜」にかかるのかあたりはあまり聞かないな
漢字だったらさぞ大騒ぎすることだろう

固有名詞が平仮名で字形が厳密に決められてる例というと、「さいたま」の「さ」（繋がってる字形）ぐらいか。
でも離した字形使って間違ってるから直せと言われたとか怒る人がいるという話しは聞いた事が無い。

明朝体だと「お」の左下とか「や」の右上も気になる

>>695
成り行きの改行で閉じの丸括弧を行頭に来させたくないなら、全角で。

コード表で Unicode ラテン1補助（aとeがくっついてるの<00E6>があるあたり）見てるんだけど、
こんなところに"×"が入ってるんだな。だから○×と並べるの×が小さく見えるの？　関係ない？

バツではなく掛け算記号だからしょうがない

まあね。ﾃﾍｯ

×✕✖

脱法ハーフスナック報道車

脱法ハーフスナック報道車

脱法ハーフスナック報道車

脱法ハーフスナック報道車

このサイトの文字コードはほんと悩まされた、何でこんな珍しい文字コード使ってるのかってのない？
基本はShift-jis,euc-jp,utf-8で終わってしまうけど

昔、x-macjapaneseを見た記憶がある。
もうないと思うけど。

エディタのエンコーディングリストに
「無損失ASCII（Non-lossy ASCII）」ってのがあるんだけど、これなんだろう。

>>696
規格票読む限りはその意図はない。
JIS X 0208はJIS X 0201のスーパーセットを作ろうとしただけのはず。

>>711=アスペ

X 0201のAとX 0208のＡが重複してるだろ。

認定厨死ね。

重複は問題じゃない。

確か、ほんとうはちゃんとスーパーセットにするつもりだったのに、
結局スーパーセットになってないのが問題。

>>708
2chがいまだにutf8化せずにcp932なのがアレ

他スレに質問したのですが、このスレ見つけたので移動してきました

[\u3000-\u9fff]とは何を意味しているのでしょうか?
u3000はユニコードの全角空白のようですが、
u9fffは分かりません
おそらくユニコードによる漢字の最後の文字じゃないかと思うのですが

CJK統合漢字
http://ja.wikipedia.org/wiki/CJK統合漢字

>>711
スーパーセットつくろうとしたなら、
JIS X 0208を単独で使う意図があったんじゃないの?
実際使われていたし。

mohta氏はそのように運用してはいたけど...

今みたいにプロポーショナルフォント環境が多ければ、あれも違和感無く受け入れられたかも

ISO 2022で言うところの、
G0にJIS X 0208に指示して、GLにG0を呼び出しっぱなしにした
文字エンコードはあちこちで使われていたよ。(G1-3, GRは使わない)
古くはJISコードというのはこういうもののことを言った。
JUNETコードを指す狭い使い方はずっと時代が下ってからの話。

いわゆるKI/KOコード？

>>718
加齢臭のする思い出ｸｿﾜﾛﾀ

ja_JP.UTF-8とUFT-8とは何が違うのですか？

>ja_JP.UTF-8
何ですか？それは

>UFT-8
Unicode規格で定められたテキスト円コーディングのこと

ドル建てで

>>724
>>ja_JP.UTF-8
>何ですか？それは

ANSI C ロケール名です。

language[_territory][. codeset] [@modifier]

>>724

>>709
x-japmacanese HAHAHA!

>>726
「ANSI C ロケール名」とは何なのか。
定義を教えて下さい。

書いてあるがな

なるほど。では改めて。

>UFT-8
Unicode規格で定められたテキスト円コーディングのこと

>ja_JP.UTF-8
>>723が考えた書式の文字列。特に意味はない。

君の頭の中では面白いのか?

>>723
文字集合とエンコード方式の違い

なぜかOracleだが丁寧に書いてあるからいいだろう
国際化対応言語環境の利用ガイド
http://docs.oracle.com/cd/E26924_01/html/E27144/glmbx.html

知らない言葉を見れば分からないといって荒らし
知っている言葉があれば関係ないところでひけらかして暴れる

サウイフモノニ
ワタシハナリタイ

>>733
Sun由来のSolarisドキュメント

特定のソフトウェア製品で使われる
あることを意味する文字列と
一般的な文字コードの名称を一緒にするなってことだろ

ANSI Cロケールと無縁なシステムなんてないだろw

>>731 いつまで嘘垂れ流し続けるんだ

>>710
Macのやつね。Javaのnative2asciiと同じ形式（完全に同じかはわかんない）

>>708
ていうか Shift-jisってcp932とは違うと思うんだけど実際には多くのサイトが
cp932の意味で使ってるよね。あと euc-jp にも似たような事情が。

こういうのに悩まされたことが、俺にはありました。

cp932はShift-jisなので問題ない

>>739
ごめん言ってみただけなの、なのに、ありがとう。

CP932はシフトJISだがシフトJISがCP932とは限らない

CP9ってなんだっけ？

9は存在しない(あるいはすでに廃止されている)ようだ。
http://www-01.ibm.com/software/globalization/ccsid/ccsid_registered.html

シフトJISだがShift_JISではないということ。

\xe3って何ですか?
調べてみても、あまりよく分からなかったのですが
Unicodeだと思うのですが

それはどこに出てきたの？

Shift-JISのサイトってどっかない？
有名どころがいいんだけど
ニュースサイトとか

2ちゃんねるっていうサイトがShift-JISで有名だよ

なんてこった、文字通り灯台下暗しだな......
でも教えてくれてありがと、助かった

和んだ

>>747
それが出てきた文脈が大事なんだけど…
何かの処理系で非ASCIIをエスケープシーケンスを用いたUnicodeで表記したものじゃないの?
U+00E3ならãを表してる。

正規表現じゃない？

これが入札した変体仮名グリフなのかな
mojikiban.ipa.go.jp/3467.html

http://togech.jp/2014/02/10/5969

可の符号位置は上の横棒があるのとないのとで2つ必要な気がする

EUC-JPがASCIIの「拡張」であって「上位互換」でないのはなぜ？
8ビットコードで0X7F以下はASCIIそのものなんだから上位互換でないの？

上位互換でいいんじゃないの。
両方ISO 2022に適合してるわけだし。

PHP使ってる人だとわかると思うんだけど
PHPのhtmlspecialchars()の第3引数にエンコードを指定するんだ
本家のドキュメントにこの関数に与える引数において事実上同等のエンコードが列挙されてるんだが
そこになぜEUC-JPが入ってないのがわからない

PHPとか知らんが、http://jp1.php.net/htmlspecialcharsを見る限り、
ASCII, ISO-8859-1, UTF-8しか順序関係はないんじゃないの?

いくつか資料を見てもASCIIをそのままま持ってくるようなこと書いてあるけど
ASCIIの0x5cはバックスラッシュだしEUC-JPの0x5cは円記号だよね

>>762
いいえ、バックスラッシュです。

>>761
うーん　そうなんですかね
マニュアルにこう書いてあるんだから、意味は深く考えなくていいじゃん　
で解決といえば解決なんですけども

>>762
バックスラッシュです
ＧＬ領域はまんまASCIIだったはず

資料疑うなら根拠を書けよw

& ' " < >　これらを変換するためのhtmlspecialchars()は関数なんですね
http://jp1.php.net/htmlspecialcharsに挙げられてる同等に扱われるエンコーディングは
↑の文字をASCIIと同じ符号位置で扱ってるエンコーディングなんです　
符号表的に同じ位置にあるから引数にどれをいれても動作は同等ですよー　とドキュメントに書いてる
でもEUC-JPが入ってないのはどうしてなの？これも同じ符号位置に& ' " < >があるはずなのに！ってのが疑問です

マイナーエンコーディングだからじゃないの?
必要ならpatch書いて送ろう。

むかしむかし、ある男がSafariの中の人に
「どうしてSafariはEUC-JPの0x5cを円記号で表示するんだよ! バグじゃね?」
と聞いてみたそうな。
中の人いわく、「インターネットでメジャーなブラウザに挙動を合わせている」
とのことじゃった。

そうしてそのメジャーなブラウザとSafariでは0x5cが円記号で表示されるのじゃった。
めでたしめでたし

もう一回言って？

むかしむかし、ある男がSafariの中の人に
「どうしてSafariはEUC-JPの0x5cを円記号で表示するんだよ! バグじゃね?」
と聞いてみたそうな。

中の人思った「日本ではバックスラッシュは円記号で表示されるだけで同じ文字なんだよ。
これは国とフォントの問題だ。でもこいつバカっぽいから話もてわからないだろうな。
よし馬鹿向けの回答で」

中の人いわく、「インターネットでメジャーなブラウザに挙動を合わせている」
とのことじゃった。

>>768は納得した。

結局「当人も馬鹿なのでそうなった」というパターンに見えるがw

Safariの場合はEUC-JPの0x5CをU+00A5にわざわざ変換する処理によるもの
なのでフォント以前の問題

中の人思った「でも馬鹿にはその説明は理解できないから」

中の人いわく、「インターネットでメジャーなブラウザに挙動を合わせている」

>>768は納得した。

ﾁｮｲｯ \(..*\)　(/*..)/ ﾎﾟｲｯ

>>770
>日本ではバックスラッシュは円記号で表示されるだけで同じ文字なんだよ。

別に馬鹿による解答はお願いしていませんが

>>770が馬鹿だと納得した。

急にレベル落ちたな

文字コード関連の論文ってどこがメジャーですか？
探しても全然でてこない

>>778

>>3
Unicode Home Page
http://www.unicode.org/
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

論文とはちょっと違うような。
文字コード関連で論文書いてると言ったら
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications.html
が真っ先に思い浮かんだ

UnicodeやISOのTRその他の方が激しい追求を受けると思いますが。

でも上記のリンクはTRじゃないよ
むしろこっちでしょ
http://std.dkuug.dk/jtc1/sc2/wg2/

っていうか>>3から引用しただけ?

はてさて

>>778
文字研究会
https://sites.google.com/site/mojiken/

Unicode の EastAsianWidth.txt について、

00C1;N # LATIN CAPITAL LETTER A WITH ACUTE
00E1;A # LATIN SMALL LETTER A WITH ACUTE

のように同じ文字で大文字小文字の違いしか無さそうなのに
幅の扱いが異なるものがあるのですが、
このようなことになっている理由は何でしょうか？

一方しか含まれていないコード体系があるとかじゃね
知らんけど

そんなのあったっけ？
JIS X 0212から追加されてるみたいだけど

なんで文字に番号振るだけなのに
研究とかしてんの？

「文字とは何か」という哲学的な命題が背後にあるから

>>788
日本の0212はSJIS対象外だから無視w
あれはほぼPC,Macの文字コード範囲くらいしか互換対象になってない。
中国のPCで大文字だけ使えたらしい。

>>787
調べてみたら、 GB 2312 だと小文字の方しか含まれていないようでした。
ttp://zh.wikipedia.org/wiki/%C3%81

JIS X 0212 などが反映されていない、というのは、
そもそも East Asian Width が古い文字コードとの互換性のためのものなので、
比較的新しい文字コードには対応しない、ということですかね。

うーん、ややこしい。

Unicodeで互換用に残されてるけど使うべきじゃない文字ってどこかにまとまってる？

バベルのページ見てたら
「バベルでの変換は特に明記していない限り MS-Windows の IE をお手本にしています。」
ってあるけどIEの変換方法って公開してるんだっけ？探しても見つからないんだけど

バベルってのが分からんが、MS純正の文字コードAPIの変換使ってるだけなんじゃないの?

>>795
えっそういうことなの
バベルは>>9のやつです

さて

cp932 = シフトJIS？
シフトJISっていう名称はどこかに登録されてる？
Shift_JISはIANAで登録されてると思うけど

>>798
されていない

JISの用語は「シフト符号化表現」だっけ？

あと、正式でない用語は、正確に実装されていないものとか、似たものを総称してとか、
そういうものを表現するために便利に使われている。

JIS X 0208:1997ではね。
JIS X 0213:2004移行はShift_JIS-2004だよ。
JIS X 0213で文字増えた文も含むのはShift_JISX0213で。

JISのシフトJISなんて当時の世の中の標準を
無視できなくなって遅れて書いただけだろ。
世間で「シフトJIS」と言ったときには
JISのそれを指すことなど安岡信者とその取り巻きを除いて
皆無に近い

カッチリした規格があるのは重要。

どの文字コードであれ正解は役所とかで実際に運用されている文字コードが正解になる
つまり何が正しいかの探求は役所への取材から始まる

職場の愚痴はマ板行けよ。

やなこったｗ

経産省は役所じゃないのか

>>798
Windows-31JだけどIEが対応していないので事実上使えない
Encoding StandardではShift_JIS = cp932 - PUA

ぷあっ

大江健三郎もびっくり、あいまいな日本のエンコーディング
もう疲れたからユニコードでいいです。
昨日ウブンツを適当に入れて日本のホームページを見たら
一部の漢字が見慣れない形をしていましたが
そのぐらいのことは我慢します。

http://slashdot.jp/~yasuoka/journal/579915
安岡センセイ迷走してるみたいだけど結局何が言いたいのだろう

むしろここで一人で安岡ヲチしてる人こそ何をしたいのかよくわからん…

このスレや過去スレを「安岡」でスレ内検索してみるとものすごく異様。

安岡さんが、キーボード配列の件で坂村さんを「デマ発信源」認定したのが気にくわない、
某方面のアレな信者でしょw

坂村さんは今風に言えば
御用学者だよな

>>813
本人乙

>>815
坂村先生お疲れ様です

アホらし

じゃなきゃ南堂信者か本人

まあそれはともかく「ちゃんとしたIVSがほしいからあえてIVSと呼んでいる」は
本気で意味わからない。名前が気に入らないってだけ?

スラドにコメントしろよ

うむ。

本人認定とか、完全にまじキチ君だな。

どうでもいいよもう。

とりあえず安岡叩きしてる人はどこか味方のいる場所を見つけてそっちで好きなだけやってくれ。
ここで叩いても誰も賛同せずに今回みたいな流れになるだけだからさ。

ネットのテキストをコピーすると、たまに文字コードの異なる半角スペースがあるのが困る。

？

どちらかというと「安岡」という単語に猿のレベルで脊髄反射して
トロン信者認定のレスを貼る安岡信者の方がすごいと思う

>>825
過去ログに残る執拗な叩きの痕跡という前提がまるで存在しないかのように、
件の彼に対する反応を「『安岡』という単語に猿のレベルで脊髄反射」ってことにするのはどうかと。
あなたが同列に「どちらがすごいか」を比べてるのが奇妙に思えるほど、件の彼の行動は異質。積み重ねがあるからね。

そしてもちろん、件の彼について話している人は
「この人はなぜ、疎まれることがわかっている場でなお1人で叩き書き込みを続けるモチベーションを持っているのだろう？」
という点を不思議に思って集まっているんであって、書き込みの動機は明確。ここから「安岡信者」と解釈はしづらい。

また、仮にもしそのなかに「安岡信者」が紛れ込んでいたとして、
その信者はこのスレで執拗に「敵」を叩き続けたりはしていない。
件の彼と違って人畜無害なのだから、ほうっておけば良い。

おれなんでこのスレ常駐してんだっけ……

>信者はこのスレで執拗に「敵」を叩き続けたりはしていない。

これには同意。
安岡信者は被害妄想が激しく
単発のレスで偏執に被害を主張するのが特徴だからね。

>>823
NBSPが紛れこんでてイラっと来るやつかな

信者とか言い出す時点でどの発言も議論として無価値

> 被害妄想が激しく
> 単発のレスで偏執に被害を主張するのが特徴だからね。

安岡さんに対して執拗に粘着している君の特徴じゃないかw

安岡センセイもビットコインに走っちゃったから…
…おっと誰か来たようだ

誰も来てない

よそでやれよ気違いども

サロゲートペアがらみで文字化けとか文字落ちは未だに良くありますか？
合成文字（アイヌ語表記用）などがうまく処理できないんですけど、完全にサポートをしないと割り切った人はいますか？

サロゲートペアかどうかの判定なんていちいち入れないし
固定長に可変長混ぜたら何の意味もない

何か誤解してる様だが、元々Unicodeの文字表現は可変長

はじめは16bit固定じゃないの？

「元々」って「当初は」って意味で書いてないのか
すまん

「か」と「゛」で「が」みたいに
二文字で一文字を表す合字があるんだから、
言語機能かライブラリを使うしか
現実的な対応方法ないだろ。

逆に言えば、それらを使っていれば
無視できる問題。

UTF-8あたりとごっちゃになってる？

最初から UTF-16 も UTF-32 も可変長だけど
未だに固定長と思ってるやつなんかいるんだ？
そりゃすげーや

そりゃ日本の官公庁相手に仕事してる分には
たいていそれで許されるからな

>>842
「code pointを複数組み合わせた可変長で文字(grapheme)を表現する」っていう
Unicodeの基本をどうしても理解できない(認めたくない)人がいるんですよ。

>>843

お役所が扱う人名なんて、それが許されない筆頭じゃなかろうか。

Unicode1.0の頃はUCS-2。UTF-16は2.0から。
UCS-2はBMPの固定長エンコーディング。
まだ固定長原理主義者が多い頃だったから。

けどそれじゃBMP以外や合成文字どうすんねん、
規格の中で矛盾してるだろ、固定長原理主義無理だろってことで、
その辺入れたUTF-16になった。
たしかUTF系はベル研のケン・トンプソンが考えた8が最初。

うろ覚え書き込みだから、修正よろ。

修正不可能なくらい間違いまくってるよ。
そもそもUCSは文字集合を定めるものであり、UTFは個々の文字を
どう表現するかを定めるものであってまったく別の概念だし。

CPUのエンディアンが複数あるため、UTF-16にはBEとLEがあります。
どのサイトも説明見ると大体こんなような事書いてあるけど意味が分からない
エンディアンがどうこうってエンコーディングの内部で解決されるべき問題でしょ？
CPUに合わせてLEを使うと速いですよって事？

絵文字統一か

>>848
確かにその説明はおかしいと思う。
画像フォーマットでもtiffにはエンディアンの指定があるが、普通はどちらにも対応する。

>>848
ちゃんとエンコーディングでBE,LEが考慮されてるでしょ？
それともBEとLEの存在自体が問題だといってんの？
何がおかしいかわからない

何を悩んでいるのかしら無いけど、
初期のUTF16の話として16bit固定っていうのはわかるよね？

C言語風に書くならば、WCHAR型（16bit）となって、
WCHAR *text = "あいうえお";
こういう定義になる。

この時のメモリ配列はC言語の仕様によりCPUのエンディアンによって変わる。
このメモリ内容がUTF-16BEやUTF-16LEなんだよ。

ファイルに保存するときはどちらかに統一してもいいが、
処理を速くするためにCPUに合わせた形式でメモリには格納しないといけない。
だからUTF16-BEかUTF16-LEというものが生まれることになる。

メモリ内で使うために、UTF16-BE と UTF16-LE の存在を無くすことは出来ない。
そのメモリ内容をそのまま保存することもある。テキストファイルではなくて
構造体データの一部としてテキストが含まれている場合とか、一項目ずつ保存するのではなくて
メモリの構造体データを丸ごと保存したりするからね。

だから、UTF16-BEかUTF16-LEという存在はCPUのエンディアンの存在によって生まれ、
それを保存するファイルに格納されたデータの呼び名にもなる。

テキストファイルで保存するときでもLEとBEを選べるエディタがあるんだが
それはおかしいのか？

世の中に二つの形式があるのなら、
二つの形式を選べるのが普通でしょう？

エンディアンが違うCPUとの間でもファイルの交換や、
ネットワーク通信できるんだから。

> C言語風に書くならば、WCHAR型（16bit）となって、
> WCHAR *text = "あいうえお";
> こういう定義になる。
WCHAR *text = L"あいうえお";
じゃね？

別にC言語風だからどうでもいいよ

たまには。PDPエンディアンのことも思い出してあげて

エンディアン嘘つかない

>>847
UCSとUTFの区別は最初はなかった。
最初はUCSのみ。
>>846も書いてるけど。

>>848
UTF-16文字列はuint16_tの並び。
uint16_tだからCPUによってバイト順が違う。
だからエンコーディングのバイトオーダーが決まってると、
逆順のシステムはネットワークにデータを流す時にバイト順を毎回変えないといけない。
それを防ぐためにバイトオーダー順違いのエンコーディングが定義されてる。
こうしておくと必要なときだけバイト順を変えればいい。
DCE/RPCみたいに接続時にバイトオーダをネゴしてもいいし、
どちらを送られても必ず扱えるようにしてもいい。

レスありがとう
2つの(代表的な)エンディアンがあってだからBEとLEがありますだと理由付けとして弱い、何か他にあるんじゃないの？？って疑問でした。
だから
>処理を速くするためにCPUに合わせた形式でメモリには格納しないといけない。
という事情があると知り納得しました。

2つしかない。

Unicode規格のエンコーディングフォームと
エンコーディングスキームの区別が全く
ついていない人が集うスレはここですか？

>>863
あなたもその一人です。

キター
パーソナルメディア、Unicode　IVS／IVDを活用する異体字検索入力ツールを発売
http://itpro.nikkeibp.co.jp/article/ActiveR/20140422/552244/

IVS流行るんかねぇ
今3000字くらいだっけ？登録されてるの

有料なのかよ
babelmap使えばいいな

先月までレビューをやってた新しいIVDはその後どうなったんだろ

>>867
しかも10ライセンス単位
それでも一般販売されるようになっただけ一歩前進

20年以上前に MS-DOS で
grep "\["
ってやって、関係ない漢字が大量にヒットした時の絶望感。
Microsoft を捨てる理由になり得るということを
理解してくれる人は少ない。

ほー。

へー。

MS-DOSにgrep有ったのか

アスキーの Software Tools for MS-DOS 他、いろいろあったよ

マイクロソフト以外のツールの出来が悪いと
Microsoft を捨てる理由になり得る　のか

「Microsoft漢字コード」って意味じゃねーの？

「Microsoft漢字コード」って意味です。
それ以外にも理由は山ほどありましたが。
その後、Pentium マシン買ってとっとと Linux 入れて
Microsoft を捨てました。前世紀のことです。
エンコーディングは当初は euc-jp , 後に utf-8 。

プリインストールされていた windows 98 を有効利用しようと
一応は努力したんですよ。10日間くらい。

>>874
特に緑の256本にお世話になりました。

まあバカには難しいからな

UTF-16 で、+2D 91+A9 52 7D 00+9F 53+ って何ですか？
tp://headlines.yahoo.
co.jp/hl?a=20140427-00000009-asahi-int

Internet Explorer を外したら上手くいきました。(._.)

utf-1のオリジナルの仕様書はどこかに無いですかね？

>>882
なにそれ？ 1bit encode?

8bitだな

数字の付け方が途中で変わったからねぇ。