文字コード総合スレ part7

1 ：2011/05/29 〜 最終レス ：2012/11/01

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/

2 ：

■参考サイト
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm
IANA: Character Sets
http://www.iana.org/assignments/character-sets
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
CP50220
森山さんの説明
http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-March/000002.html
JISX4061
日本語文字列照合順番
http://www.jisc.go.jp/

3 ：

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

4 ：

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

5 ：

リンク集も古くなっちまったな・・

6 ：

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

7 ：

・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(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サニタイズが面倒になるのか

8 ：

・SJISとUNICODEの判別はどのようにすればいいですか？BOM。無ければ、統計判断。 ライブラリを使うが吉
・ところでケータイのUnicode対応度って実際どうよ？　→　Rマークも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の人にはそれがわからんのですよ。

9 ：

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

10 ：

■単語一覧
・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とか。

11 ：

今となっては>>3-4はもういらないんじゃないか
あとWG2方面のリンクがないので追加
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

12 ：

前スレdat落ち

13 ：

甲乙丙丁戊己庚辛壬癸
癸だけが第二水準

14 ：

　　　＿＿＿　 　 　　　　　 　　　　
　　/　||>>1 .|| 　 ∧_∧　　
　　| 　||乙＿||　（・ω・｀) 　
　　|￣￣＼三⊂/￣￣￣/ 　
　　|　　　　|　( ./　　　　 / 　

15 ：

あちゃー前スレ落ちちゃったかー

16 ：

ほー、日本は小書きコに反対か。
汎用電子IVDに続いてアドビとしちゃ面白くないだろうな。

17 ：

反対するのが生きがいのような連中がWG2に居座ってるからな。
つーかIRGN1757にも反対しろよ。普通なら真っ先に反対してるだろ。
返す刀で汎用電子の追加登録に何か言われたくないのか?

18 ：

汎用電子で思い出したけど
ttp://twitter.com/ogwata/status/48519614107357184
↑これってMSやAdobeみたいな実装する側の意向すら差し置いて
ああいう決定したってことでしょ
よっぽど声のでかい理屈屋がいるんだろうな

19 ：

n4091
>some discussion in Japan on the possibility to have a standard set of hentaigana.
おっ!?

20 ：

Japanって常々どうも理解しがたい主張ばかりしてる気がする

21 ：

小書きコの運命やいかに

22 ：

もういっそ五十音全部小書き版作っちゃえよ

23 ：

http://slashdot.jp/%7Eyasuoka/journal/532369
「ネ申」と「示申」でいいよ

24 ：

ねもうす
しめしもうす

25 ：

UTCは小書きこを受理済みなのね
てことは日米での殴り合い確定か

26 ：

カゲながら米を応援したいと思ってる

27 ：

日本が何らかの決断するまで変体仮名は前に進められなくなっちゃったかも

28 ：

ヘルシンキかあ。ちょうど白夜の時期なんだろうなあ。

29 ：

377 ：SIM無しさん：2011/06/09(木) 06:40:25.91 ID:7+dIaRVO
Segoe UI Symbol を担当した Agfa Monotype の人間出てこい…
気になる点を調べたが…
おでんの具の刺さり方がとんでもなかったり、ひな祭りの人形が百合祭り (性指向) の人形になってたり、
出来れば製品版で直っていてほしい。

30 ：

どこで見たんだろ。SDKには入っていなかった気がするけど。

31 ：

AppleはAppleで絵文字専用フォントフォーマット作っちゃったようだし
結局プラットフォームごとにバラバラな見え方することになるんだろうな

32 ：

うむ

33 ：

安岡センセイ、文字コード関係で編集合戦の結果、ウィキペディア無期限ブロック
ttp://ja.wikipedia.org/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85%E2%80%90%E4%BC%9A%E8%A9%B1:%E5%AE%89%E5%B2%A1%E5%AD%9D%E4%B8%80&oldid=37835032

34 ：

安岡先生どこで編集合戦したの？

35 ：

ttp://ja.wikipedia.org/wiki/QWERTY

36 ：

直接ウィキペディアをいじっちゃ駄目だろ
ウィキペディアの出典になりうる文書を書くほう(本業)を頑張ることだな

37 ：

お前ら反応する前に確認しろよ。濡れ衣だったとかで既に解除されてるぞ
http://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85%E2%80%90%E4%BC%9A%E8%A9%B1:%E5%AE%89%E5%B2%A1%E5%AD%9D%E4%B8%80

38 ：

自著を典拠にして自分でwikipediaの記事書いてた/るってこと？

39 ：

なにか問題あるの?

40 ：

アンチ安岡の病人がネットには何人かいるようだから、そのうちの一人だろ。
相手にすんな。

41 ：

>>39
別に問題はないけど>>36と同じような感想は持った。

42 ：

小書きこ入らなかったか…

43 ：

http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4108.pdf
> Moreover, Japan national body is not comfortable with the idea to encode such
> ad-hoc inventions in UCS. Generally speaking, authors can do anything he/she
> considered appropriate, and most of those novel usages are just forgotten
> without any followers. We should not encode new characters unless they are
> considered to have some established usages.
JIS X 0213は吉本隆明のためだけにU+2A437「??」を収録したけどな。

44 ：

Janeから書いたら「𪐷」が文字化けした

45 ：

こんなにいっぱい矢印が入ることは見過ごせても
ちっちゃいコが二つ入ることは容認できないのね

46 ：

Jane（笑）
俺のV2C△□×

47 ：

>>46
しかも>>44がU+A437に文字化けして見えるんだぜorz

48 ：

>>45
一度入れたらなし崩しになるとでも思ってるのかね。
その観点ではもう手遅れもいいところだろ

49 ：

これが漢字なら、写研の文字セットにもある(ｷﾘｯ
って逆に典拠として使いそう

50 ：

漢字はいろんな意味で特別扱いされてるよな
雪だるまとか包摂されまくりなのに

51 ：

写研といえばBA-90のUnicode収録マダー? (AAry
ログインとかうる星やつらで使用実績もあるぞ

52 ：

U+1F31Dに包摂されるんじゃないの

53 ：

(笑)が使われる以前はインタビュー記事とかでも結構使われてたな。

54 ：

今見ると{ﾊﾊｯ ﾜﾛｽ}って吹出しがつきそうな顔だ。

55 ：

　　　　　　　　　＿＿＿_
　　　　　　　　／　　 　 　＼
　　　　　 　／　　─　 　 ─＼
　　　　　／　　　　⌒　　⌒　　＼ 　　　　ハハッワロス
　　　　　|　 　　 　 ,ﾉ(､_, )ヽ　 　 |
　　 　　 ＼　　 　　 ﾄｪｪｪｲ　 　／
　　 　 　 ／　　　_　ヽニｿ,　 く
よく雰囲気出てるな

56 ：

>>37
火のないところに煙は立たず

57 ：

ウィキペディアの管理者は一般利用者に対しては火のないところにも煙を立てるけど
CheckUserの靴下疑惑は「同棲してました」で済ませる人格者ぞろいだからな

58 ：

火のないところに火を付けて煙を立てる2ちゃんねらーが言うなw

59 ：

先週のWG2で日本に関係ありそうなのは
・コンソーシアムがUTS37などを改訂する時はWG2の意見を尊重すること
くらいかな
あとは
・Wingdings/Webdingsの記号がいっぱい受理された
・線文字A受理
・Amd8から先送りされ続けているA78Fがまた先送り
・USがこれ文字じゃないだろと言い続けて同じく先送りされてきた1BFA-1BFBがとうとう削除
・三つ巴の提案で暗礁に乗り上げていたOld Hungarianがようやく決着
・ミーティングの間隔が空きすぎているのでためしにオンライン会議を導入

60 ：

オンライン会議って動画をやりとりするの? チャットじゃなくて

61 ：

discussion list and teleconferencing facilities
って書いてあるねぇ。

62 ：

>>57-58
マジレスするが2chと同等かそれ以上にdqnのｽｸﾂ

63 ：

安岡センセイのWikipedia投稿記録、自著の宣伝ばっかり
http://ja.wikipedia.org/wiki/%E7%89%B9%E5%88%A5:%E6%8A%95%E7%A8%BF%E8%A8%98%E9%8C%B2/%E5%AE%89%E5%B2%A1%E5%AD%9D%E4%B8%80

64 ：

著書にすらできない脳内ソースを延々書き連ねるよりよっぽどマシだな

65 ：

>>59
UTS37の改訂って↓コレ？
ttp://www.unicode.org/review/pri184/

66 ：

それも含めて10646からnormativeとして参照している文書すべて
らしい

67 ：

確かにUnicode側の都合だけで参照文書コロコロ変えられたらたまらんよな

68 ：

一度手にした白紙委任状をコンソーシアムがそう簡単に手放すかな〜

69 ：

>>65
俺の英語力がないのか、内容がわからん
何のためにこんな改訂するの？

70 ：

glyphic subsetが集合であることを明確化するため

71 ：

後から追加可能だったら閉集合にならないじゃん

72 ：

glyphic subsetに何が含まれないかはもともとはっきりしていない
何が含まれるかがより明確になるだけマシ

73 ：

「私の知っているKen Lundeなら必ずやる」にﾜﾛﾀ

74 ：

互いに素？

75 ：

無理だろうな

76 ：

>>74
2つのglyphic subsetが共通部分を持たない、って意味じゃね?

77 ：

向こうしばらくの主戦場はIVSか。

78 ：

PRI 183キター

79 ：

＞互換漢字「�氈v(U+FA20)はIVSの基底文字になれない
IVSの基底文字になれなかったら
艸カンムリ3画・4画の差をどうやって分けるの？

80 ：

>>79
U+FA20はバグだと主張して新たに統合漢字として追加提案する

81 ：

>>79
U+8612に艸カンムリ3画・4画のIVSを両方追加する

82 ：

うむ

83 ：

U+2B789とU+2B78Eみたいなことになりそうなのが微妙

84 ：

文字コードとRFC（2822）の関連性について、どなたか教えてください

85 ：

なんでRFC 5322に廃止された2822?

86 ：

UTS #37でdeprecationも規定してほしい

87 ：

>>85
すいません、今は更新されてRFC5322なんですね。
文字コードとRFC（5322）の関連についてのレポートを書かなければいけないのですが
いまいち良く分からないので、こんなの書いたら良いよっていうのがあれば教えてほしいです。

88 ：

文字コードのことわかってない土方大杉。

89 ：

>>87
質問が漠然としすぎててなあ。
・RFC 5322ではContent-Typeヘッダフィールドで本文の文字コードを指定する
・日本ではRFC 1468に従いふつーISO-2022-JP
・最近はUTF-8も増えてる
　(とくにRFCに根拠はないが強いてあげればIMC勧告から参照されているRFC 2277)
・添付ファイルの内容の文字コードはMIMEのRFC(2045〜2047)に従う
・添付ファイル名の文字コードはRFC 2231に従う
あとは適当にふくらませてくれ

90 ：

>>89
> ・添付ファイル名の文字コードはRFC 2231に従う
ちょっと表現が微妙ですね。

91 ：

２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな
ゴミグラマは社会底辺

92 ：

>>91
Rubyみたいに糞遅いもの使えるか。
どーせメンテしないなら、呪文みたいなperlのコード書く。

93 ：

荒らしはともかくそれにコメントしようとする前にせめてスレタイをみてくれないか

94 ：

>>93
何お前まだ表示してるの？
人生無駄にしてるな

95 ：

汎用電子第二陣もう来たのか。早かったなあ。

96 ：

>>95
安岡センセイが指摘したU+2B751
さっぱりわけわからん

97 ：

文字エンコーディング変換を自前で作ってしまう人はあとをたたない
http://fallabs.com/blog-ja/promenade.cgi?id=137

98 ：

全員が職業プログラマーってわけじゃないから別にいいだろ。
でもこのセンスの無い糞コードは何とかしたほうがいい。

99 ：

コンバータが大きくて不恰好なのは、過去あんまりにもめいめいに勝手な変換が行なわれたせいだ
だから、iconvが大きいと文句を言うのなら、変換にはiconvを使わなければならない
自分で文字コード変換なんて絶対にやってはいけない
ましてや公開とかありえない

100 ：

>変換にはiconvを使わなければならない
>ましてや公開とかありえない
はいはい。オマエは黙ってろ

101 ：

既存の何を使うかはともかく、自力で絶対にやってはいけないのは確かだな
自力でやって「どうしてこんなことをライブラリに頼らなければならないのだろう」と感じたならなおさら

102 ：

UTF間の変換ごときで外部ライブラリをリンクしたくないってのは同意できる。
せめて標準ライブラリが使い物になればいいんだけどな。
char16/32_tも、mbrtoc16等の関数群はあるけどこれってもしかしなくてもロケール依存だよな……？

103 ：

Unicode 6を読んでもISO/IEC 10646:2011を読んでもUTF-8は最大4バイト
としか読めないんだが、6バイトとか言う奴はなんなの？

104 ：

まあ、ライブラリの粒度がもうすこし細かければ全員ハッピーなんだと思う
そんな世界なら、わざわざ自分でやろうと考える人もおるまい

105 ：

>>103
31ビット整数値をUTF-8で表現しようとしたら最長6バイトになる。
今んとこ21ビットしか使ってないからとりあえず4バイトでおkだけど
文字が割り当てられてないコードをUTF-8に変換しても維持しようとするなら6バイト対応が必要。

106 ：

>>105
>31ビット整数値をUTF-8で表現しようとしたら最長6バイトになる。
それはUTF-8じゃないよ。ill-formedと書かれてるんだから。
3.9『Any UTF-8 byte sequence that does not match the patterns listed in Table 3-7 is
ill-formed.』

107 ：

サロゲートを思い出すんだ。今illだからといってry

108 ：

>>103
> 6バイトとか言う奴はなんなの？
ただのジジイ。放置でおk。

109 ：

でも最大4前提で確保したバッファを最大6前提の変換ルーチンに渡したりすると……

110 ：

どんなルーチンも、バッファサイズ等の要件は仕様に明記し、両者それに従うべきで、UTF-8がどうとかは別問題

111 ：

安岡センセイは8バイト必要って言ってる
http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343783/

112 ：

base (3〜4バイト) + vs (4バイト)で最大8バイトってだけの話がどうかしたか?
ちなみにUnicodeは結合文字列の長さや組み合わせに何の制限も設けていないので
よろしく

113 ：

この記事見た時いやーな予感したんだよな。
これ読んで「じゃあ8バイト分のバッファを確保すればいいのか」みたいな解釈する
プログラマが出ないかって。

114 ：

VSに関しては例外的に「複数付けられない」「合成済み文字には付けられない」
「結合文字には付けられない」という制限があってむしろ簡単な部類なんだよな

115 ：

安岡はもう引退した方がいい。既に頭が老人ぼけずぎ

116 ：

「漢字1文字につき」って書いてあるが、漢字で２つ以上結合し、それがフォントのテーブルでサポートされてるグリフってある？

117 ：

２つ以上って、ベースを除いた数ね

118 ：

VSは2つ以上くっつけられないけどその他の結合文字はいくらでも付けられる。
たとえば濁点・半濁点付きの異体字なんかも可能だし
それをさらにCOMBINING CIRCLEで丸囲みすることも可能。
実装がサポートしているかどうかは知らない

119 ：

>>115
「互換漢字にVSを付けられるようにすればいい」とか何も考えてないにもほどがあるよな

120 ：

>>118
フォントにない文字を合成しても表示できないんだし、UTF-8だと（世間一般でいう）漢字は
最大4+4=8バイトの説明でいいんじゃないかなあと。実装されたグリフがあれば別だけど。

121 ：

当然、世間一般的な説明の範囲で。

122 ：

JIS系のコードからの変換で、なんやかんや付きまくってコードポイントが3つ以上になったりするものはある？

123 ：

>>120
> フォントにない文字を合成しても表示できないんだし
なことはない。美しくないだけ。

124 ：

>>123
一応、OpenType だと ccmp の話なんだけど。他のフォーマットだとそう？

125 ：

ラテン文字のダイアクリティカルマークなんかはすべての組み合わせ済みグリフが
あらかじめ収録されているわけじゃないぞ
濁点だってそういう実装は可能だし漢字に付けるなら現実的に言ってそういう
実装しかできないだろ

126 ：

Firefoxは正しく表示できなくても基底文字+結合文字をちゃんと選択や編集の
最小単位として扱う

127 ：

>>125
すべて収録されてないのは当然そんなことわかってる。
今は漢字の話だが、表示されないってところは認めてるわけだな。

128 ：

>>127
お前わかってねーじゃんw

129 ：

>>128
お前こそ話がわかってない。
いままでの話、もう一度読んでくれ。

130 ：

>>122
JIS X 0212の11-80とか？

131 ：

MIME導入前のメールの文字コードの区別ってどうやってしていたんですか

132 ：

エスケープシーケンス入っていればISO-2022-JP
8bitならISO-8859-*のどれか
どれでもなければASCII
さらにFrom:の人間に対する知識を合わせて。
いろいろ調べてShift_JISで送ってきたことが判明したら「おまえRぞ」と返事。

133 ：

>>130
それ漢字じゃないだろ

134 ：

>>119
＞「互換漢字にVSを付けられるようにすればいい」
http://slashdot.jp/%7Eyasuoka/journal/533227 のこと？
＞ただ、私(安岡孝一)個人としては、
＞これらのカウンターアクションを必ずしも望まない。
って書いてるんだから、これ安岡センセイのブラフだろ。

135 ：

EBCDIC
SJIS変換どうやったらいい？

136 ：

漢字入りのEBCDICか？

137 ：

>>134
U+FA20は互換漢字から外すべき
とは俺も思った

138 ：

せめてどのメーカーのEBCDICかくらい指定してもらわないと答えようがない

139 ：

google先生にebcdicで問い合わせると...

140 ：

邪魔だからわからない人は書き込まないでくれないか？

141 ：

iconvとか使えばいいだけだろうに

142 ：

じゃまだから質問の仕方がわからない奴は書きこまないでほしい

143 ：

>>137
U+FA20を互換漢字でなくすのと互換漢字にVSを許すのはまったく違う

144 ：

うむ

145 ：

KEISのSJIS変換は？

146 ：

むう

147 ：

SKFのソースを見るといいかも
http://sourceforge.jp/projects/skf/

148 ：

サンキュ。とりあえず読みかけた。

149 ：

௵

150 ：

>>149
これの読み方教えて。

151 ：

TAMIL YEAR SIGNだとさ
つ ttp://www.fileformat.info/info/unicode/char/bf5/index.htm

152 ：

>>151
どうもありがとう！

153 ：

௵これより大きな文字や記号はあるのだろうか？

154 ：

‱

155 ：

ミス

156 ：

中国は通用規範漢字で表外字への簡化の適用を廃止してたのか。
ますますIRGN1757はアホだな。
類推適用されるなら少しは気持ちがわからんでもなかったが

157 ：

>>156
でもUTC-00071とかUTC-00677とかは、通用規範漢字なんだろ？

158 ：

>>157
y-variantは独立に符号化すべき
現在符号化されていない通用規範漢字は130文字くらいあるみたいなのに
その一部しか取り上げていないんだから通用規範漢字に対応するのが
目的でもなさそうだし

159 ：

しかもUTC-00071はExt.Eに提案RUTC-00677に至ってはU+2B5AFに符号化済み

160 ：

MingLiUのU+8BDEはバグってるな(U+4725と同じ字形が入ってる)

161 ：

どうすんだよもう

162 ：

もうすんだよどう？

163 ：

MSゴシックの昴の字形みたいにいつの間にかこっそり訂正されてたりして。
その結果IBM拡張文字の昴の字形が入れ替わったわけだが
誰も話題にしていないところを見るとやっぱりほとんどの人にとっては自分の
名前に使われていない限りどうでもいいらしいな

164 ：

>>163
kwsk

165 ：

>>163
同じくｋｗｓｋ

166 ：

H・Kとかいうアホに戦争中の東大生の文字中毒の話を予備校の日本史講師にされたと言われた
俺もそんな感じはある
と言ったらあのアホでバカで境界性人格障害のクズはため息つきやがった
文字への強迫性は悪い部分もあるんだろうが　いい部分もたくさんあるんだよ　だからH・Kに対して言わせてもらう、R、死んじまえ！

167 ：

>>164-165
昴じゃなくて昂だった。
JIS83で昂の字形がCID7680相当からCID1993相当に変わったんだけど
IBM拡張漢字の0xFAD0にはもともとCID1993相当の字形が収録されていた。
MSゴシックでは苦肉の策としてU+6602とU+663Bの両方にCID1993と
同じような字形を収録してIBM拡張漢字の0xFAD0はU+663Bに対応
させていたけど、JIS2004対応のついでにU+663Bの字形がCID7680
相当に変更された。結果としてIBM拡張漢字の0xFAD0の字形も変わった。

168 ：

フォントといえばWin7のTVゴシックシリーズって、SP1でもまだ隠し扱いなの？

169 ：

字形の細かい違いを拾いたい人と、捨象するのを是とする人とじゃ
話は噛み合わんだろうな。

170 ：

長さnのUTF16の文字列wchar_t[n]を、UTF8のchar[m]に変換した場合、
mはどのくらいの大きさであれば十分なのでしょうか？
自分程度の知識だと、UTF8は最大6バイトで1文字を表すので、
m=6nとすれば十分な大きさになるだろうと考えているのですが、
実際はもっと小さい容量でも足りるのではないか？と思っています。
また逆に、UTF8からUTF16にする場合、nはどのくらいの大きさが
あれば十分なのでしょうか？
UTF16はサロゲートペアで最大2要素で1文字を表すので、n=2m程度の
領域を確保してあげれば十分だと考えているのですが、実際は
どの程度あれば十分なのでしょうか？
よろしくお願いします。

171 ：

UTF-8とUTF-16で各コードポイント値が必要とするオクテット数は次の通り。
（左がUTF-8、右がUTF-16）
000000..00007f 1 2
000080..00007f 2 2
000800..00ffff 3 2
010000..10ffff 4 4
wchar_tが16bit以上ある環境なら右の値は半分になるので、
UTF-16→UTF-8の場合はm=3n、逆方向はn=1/2mとなります。

172 ：

wchar_tが32bitでUCSだったら普通はUTF-32を採用するんじゃね?

173 ：

>>171
どんな場合でも、m=3n, n=1/2mだけの領域を確保してあげれば、十分
という認識でよいでしょうか？

174 ：

>>171-172
逆方向はn=mじゃね？

175 ：

> UTF16の文字列wchar_t[n]を、UTF8のchar[m]
という前提のはなしだったら
UTF16 ⇒ UTF8: m = 3n
UTF8 ⇒ UTF16: n = m + 1
じゃないの? (ヒント UTF-16LE ではなくて UTF-16)

176 ：

変換後のサイズ知りたいなら実際にスキャンして調べたら？
自分で数えても良いし、処理系にAPIあればそれでも良いし。
まさか固定サイズのバッファ使ってるから、大風呂敷広げておこう戦法？

177 ：

LionのヒラギノはIVS対応か?
SafariはIVSちゃんと表示するようになったのか?

178 ：

>>176
1文字単位で変換するときのバッファサイズぐらい固定で取りたいとかじゃね？
どっちにしろwchar_tではなくてchar16_tをだな

179 ：

>>175 がFAかな

180 ：

ヒラギノはAdobe-Japan1-6にフル対応しないのかな

181 ：

皆さんありがとうございます。
m = 3n, n = m（LE or BE なので）、で作ります！
自分でも調べてみて色々勉強になりました

182 ：

ICUを使ってファイルの文字コードを調べたいのですが、
ファイルの先頭何バイトを使って調査するのが普通でしょうか？

183 ：

文字コードの自動判別に王道無し。

184 ：

HTML5では1024バイトと定めているな

185 ：

マジか
じゃあ1025バイト以降にUNICODEとかあったら、誤認識すんのか

186 ：

HTML5のケースは1024バイト目までにmeta charsetタグが現れることを期待してるんじゃないかな

187 ：

あぁ、なるほど
じゃあ一般の文字認識とは様子が違いそうだ

188 ：

美R

189 ：

>>185
するよ
Firefoxは最後まで読んでたけど
HTML5 parser導入後は今まで化けていなかったページで文字化けすることがある

190 ：

PRI #184のレビュー期間が終了したようだな
識別子に間違って'+'と'-'を使っちゃった件のつじつま合わせが6月30日に
追加されていたようだ

191 ：

あの改訂はレビュー中のAJ1と汎用電子2陣にも適用されるのかなあ

192 ：

Webアプリケーション経由で、データベースから取得する文字コードと、
ブラウザに出力する文字コードが違う場合、マルチバイト文字が文字化けします。
文字コードの変換をしてから出力すれば問題ないのですが、
変換処理を全てに行うと重くなるため、マルチバイト文字にのみ行いたいのですが、
1バイト文字だけで構成されているものについても、変換処理は行わないと、
何かセキュリティとかに問題がありますか？
16進ダンプの結果が同じものなら、変換処理は必要ないですよね？

193 ：

1バイト文字というのは正確ではないな。Latin-9だって全部1バイトだし。
それはともかくバックスラッシュとかクオーテーションとかで地雷踏まないとわかってるなら別にいいんじゃね

194 ：

>>193
ありがとうございます。
Latin-9については全然わかりません。
調べてみてそれらしきものの16進ダンプみてみましたが、6バイトになってました。
http://www.eki.ee/letter/chardata.cgi?ucode=0178
http://charset.7jp.net/dump.html
文字コード難しいですね・・・
本題ですが、SQLインジェクション対策は入力可能なものを固定値か数値にしていて、
数値カラムに対してはint型に変換してから問い合わせしてるので、平気だと思います。
;' DELETEとかうたれても固定値と一致しないので排除されるか、int変換で0になるので。
特に問題はなさそうなので、intカラムはとりあえず変換をしないことにします。
英数字で構成されてるcharカラムは一応現状維持で変換することにします。

195 ：

>>192
>変換処理を全てに行うと重くなるため、
それは10文字程度を100万回ループして、何ミリ秒ほど重くなるの？
>SQLインジェクション対策は入力可能なものを固定値か数値に
えー。Perl CGIでサニタイズ処理をコリゴリ書く人ですか？

196 ：

マルチバイト文字を構成するバイトを探すのは、
テキストを全部舐めないといけないはずだけど、
そんな事やっている間に変換できちゃわないかな。

197 ：

マルチバイトが入ってないって最初から分かってるのでは？
データベースのintカラムなんでしょ

198 ：

jis委員たちはいつまで南堂久史さんの私案を無視するんだ？
sjis改訂で本質的貢献を果たしたはずなのになんの見返りもなしとか、
どうなってるの？
http://hp.vector.co.jp/authors/VA011700/moji/code00.htm
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm

199 ：

一私案を考慮しなきゃならない理由なんて、どこにもないだろ。
規格に修正を加えたいならしかるべき手続きをとらなければならない。それだけ。

200 ：

いつまでもシフトJISにしがみつくような案は無視されて当然。
JIS X 0213のShift_JISX0213が世間でdisられてるの知ってんだろ

201 ：

>>198
いつまで南堂の妄想をまに受けてんの?
http://slashdot.jp/~alp/journal/313207
http://d.hatena.ne.jp/m-hiyama/20060608/1149725701

202 ：

アンチ南堂の意見を見るほど、安岡をはじめとするスラッシュドットの住人って
変人だとしか思えない。
スラド信者は南堂の字形変更がJIS規格に採用されて正常な判断能力を失った

203 ：

安岡は本当に2004JISの委員だったのに対して南堂はただの空想家ですが何か?
頭おかしいの?
本人降臨ですか?

204 ：

スラドの日記に書かれているだけでスラド信者とか
どう考えても正常な判断能力を失ってるな

205 ：

どこの世界にも基地外っているんだなあ

206 ：

>>202
そう、南堂の案は結局採用された。
本質的貢献をはたした。
なのに、委員会は南道の案を誤読し、
いざ、南堂案が正しいとわかったら、
徹底的に無視し続ける。

207 ：

南堂案って委員会に提出されてないよ
http://opac.ndl.go.jp/recordid/000003624020/jpn
そもそも南堂がアレを言いだしたのは委員会終了後

208 ：

2004年の規格が南堂案という話をしてるのに、
2001年の情報を出されても・・・

209 ：

どこの誰だか知らない人の話を延々とされても・・・

210 ：

あらま。JIS信者は南堂を無かったことにしたいのね

211 ：

あらまじゃねぇよ南堂信者
2004の委員会に提出した記録があるなら出せってんだよ

212 ：

>>207
それは違う。
南堂私案は池田委員の個人アドレスに個人メールとして送られてきた。
委員会としては公開レビュー窓口に送るよう促したが、彼は委員会を「敵」だとみなしていたらしく、
公開レビューには参加を拒否したし、もちろんヒアリングにも出席しなかった。
結局Shift_JISX0213には、レビューに参加した中島私案が採用された。

213 ：

>>212
誰？

214 ：

で、結局南堂案のコンセプトが正しかったことが証明された。
にもかかわらず、南堂を無視し続けた。
それどころか南堂の案の重要な点である、字体の変更をトンデモ扱いした。
そんなことをすれば南堂が委員会を敵だとみなすのも無理は無い。
万死に値すると思うが。

215 ：

で、委員会に提出した記録は？

216 ：

>>214
南堂案のキモは字体変更じゃなくて包摂分離
南堂案を擁護するなら中身ちゃんと読めよ

217 ：

Lionのカラーフォントって、どういうフォーマットなの？

218 ：

png入ってるね

219 ：

だとすると、国旗とかKEYCAPとかは、合成後にpng処理？

220 ：

そういうこと
morxでリガチャのglyphID拾ってからpngで表示

221 ：

>>216
いずれにしても、
本質的貢献をしたのに無視するのは異常。

222 ：

安岡センセイがsbixテーブルを解読
フォントのバイナリを読める人たちってどういう頭してんだろ

223 ：

TrueTypeのテーブルの基本構造は共通だし、多分解読用のフレームワークか
何か持ってるんだと思う。

224 ：

↓これのこと？
http://kanji.zinbun.kyoto-u.ac.jp/%7Fyasuoka/publications/otf.html

225 ：

URLが化けた orz
ttp://kanji.zinbun.kyoto-u.ac.jp/%7Eyasuoka/publications/otf.html

226 ：

それはFontForge使ってるだけじゃん
これのことだろ
http://slashdot.jp/~yasuoka/journal/536365
バイナリ眺めてれば普通に大体見当つくよ

227 ：

>>221
単なるあれおれ詐欺を本質的貢献と思える頭の作りが異常

228 ：

PNGかぁ。実装の簡単さを取ったんだろうけど、
ラスタ画像ってのは将来性という点でどうだろうなあ。

229 ：

CFF/Type2のカラー化ってのも難しそうだし
今ならSVGがいいのかなあ？

230 ：

҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉
テスト

231 ：

>>230
これ何て読むか教えてください。

232 ：

>>231
R

233 ：

҉҉҉҉҉҉҉҉ ̨ͨͤ̊͒̅̒ͪ̽͂͆̓ͤ̈̊̋ͫ̿̒͏̵̡̼͔̲̺͘ !

234 ：

>>232
なるほど。

235 ：

>>233
では、これは？

236 ：

҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉҉
　イボ痔

237 ：

R系が人気のようですね。

238 ：

sbixググってみたけど、それらしいのは↓しか見つからなかった
http://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontRef/CTFontRef.pdf
もうちょっと詳細な情報キボンヌ

239 ：

>>214
南堂案骨子は字体変更。当時は字体変更はトンデモだと思われていたが、
あとで字体変更が必要だとわかって、
南堂案が正しい事が証明された。
だから、委員は南堂案の肝が字体変更だとは意地でも言わないつもりなんだよね。
南道の手柄ってことがバレるから。

240 ：

>>238
安岡センセイの日記が今の時点では最も詳細な情報

241 ：

>>987

242 ：

>>239
そんな誰でも独立して思いつくことで手柄とか言ってるのが自意識過剰の馬鹿丸出し

243 ：

おや、JIS信者が南堂の存在だけは認めたようです

244 ：

http://www.unicode.org/review/pri201/
↑これ、レビューが実質1週間しかなかったんだけど、何だったの？

245 ：

>>240
それも何だかなー

246 ：

>>244
来月最終投票入りする予定の10646の3版に間に合わせる必要があって、
そのためには今週開催中のUTCで審議する必要があって、それで
こういう極短期の公開レビューになったんだと。

247 ：

そういう形だけのレビューなら、やらない方がマシ

248 ：

大注目している時期に見逃す方がどうかしてる。

249 ：

PRI 201が公開されたのは7月27日の昼前だった。
漢字を943字も収録してるのに、それで8月3日〆切ってのは、
チェックするための時間があまりに短か過ぎる。

250 ：

943字くらい半日もあればチェックできるだろ
字形が変わってるのもUTC-00919とUTC-00929の2つくらいだし

251 ：

>>249
締め切り前に短すぎると意見すればよかった。

252 ：

>>228
データの種類はシグネチャで見てる感じだからpdfでも構わんのでしょ。
それだとOSX/iOS以外で表示が難しいのと、ちゃんとしたグリフ作るのも
大変だから、取り敢えずpng入れてみましたって所じゃないかな。

253 ：

>>250
UTC-00919とUTC-00929の字形変更って…
じゃあU+FA15とU+FA20に出てる字形はどうなるの？
http://www.unicode.org/charts/PDF/UF900.pdf

254 ：

>>225
> URLが化けた orz
なぜにDelete w

255 ：

>>253
ISOの最終投票で字形変更

256 ：

>>251
後ろがつかえてるんだから
どうせ聞く耳もたないだろ

257 ：

愚痴ですね

258 ：

だってオレ英語かけないもん

259 ：

英語が書けたらあんな提案こんな提案…

260 ：

アン　アン　アン

261 ：

>Unicode 6.1.0 (Planned for February, 2012)
フム

262 ：

ムフ

263 ：

フムゥ

264 ：

なかは、膣はらめぇ〜

265 ：

結局南堂さんの実績は認めるの？認めないの？

266 ：

JIS信者は認めないみたいだね。
字形変更はもっての他とか言っていたのに規格が通って発狂した

267 ：

UTCは小書きコに関しては取り下げるでもなく様子見か。

268 ：

>>265
南堂信者は発狂して相手のせいにして自分を慰めてる

269 ：

「お盆」をあらわす絵文字ってないの？

270 ：

どうやってあらわすんだよ
風習は地方によって様々なのに
（という文句が付けられそうなものは他にもあるだろうけども）

271 ：

○＋盆。

272 ：

盆⃝

273 ：

山に大の字だな。

274 ：

>>272
すばらしい

275 ：

解説希望

276 ：

閲覧環境によっては囲い文字になってるんだろ

277 ：

U+20DDはCOMBINING ENCLOSING CIRCLEという結合文字。
ttp://www.unicode.org/charts/PDF/U20D0.pdf

278 ：

◎にそれ重ねたら三重丸と看做していいんかな

279 ：

二重丸を三重丸とみなしてもいい。あなたの勝手。

280 ：

結局南堂の業績は認めるの？認めないの？
はっきりさせろ・

281 ：

>>280
結局って何だよ。JIS信者は南堂の業績は認めない。
これはこのスレで一貫しているだろ。
業績認めて欲しいなら南堂が貢献したというソースを出してみろ。

282 ：

今さらJISなんてどうでもいいよ

283 ：

UTS #37 v3リリース。

284 ：

グリフウィキに繋がらん

285 ：

次からといわず移せばいいのに

286 ：

>>285
kwsk

287 ：

>>286
ttp://twitter.com/kamichikoichi

288 ：

復帰したようだ

289 ：

OT版フォント復活したのかー

290 ：

>>281
ソース→ >>212

291 ：

ソースは２ちゃんの書き込み

292 ：

SEXTILEって、Unicode 6.0で追加されたみたいだけど、ソースは何？

293 ：

5.1だぬ
ソースは不明

294 ：

汎用電子のレビューコメント全然来ないのか…

295 ：

いっそ俺がレビューしてやろうか

296 ：

はにょでんし

297 ：

はにゃ〜

298 ：

LionでせっかくヒラギノがIVSに対応したのにSafariやChromeが対応してないのは勿体無いな
辻󠄀
辻󠄁

299 ：

フォントまわりはFirefoxの一人勝ちだぁね

300 ：

今使ってるCGIプログラムの文字コードがShift_JISだったから別の文字コードに変換したいんだけど
このスレ的には内部文字コードも出力もUTF-8なの？

301 ：

もしかして、内部コードって、ソースコードを表現するコードという意味で使ってる?

302 ：

このスレ的には、って？
このスレは基本、あらゆる論者が屯ってると思うが。

303 ：

内部文字コードを自由に替えられる処理系って、
BSD系のC+libc以外だと何があるんだろ?

304 ：

>>301-302
ごめんソースコードを表現するコードという意味で合ってる
ダメ文字から逃れたくて質問したけど
色んな説があるみたいだからEUC-JPにするよ
ありがとう

305 ：

いまどきEUCはないわ
SJISは論外

306 ：

好きにしろよ。スレ違いだ。

307 ：

黙ってUTF-16普及に努めるんだ

308 ：

分かりやすいデータ型の分類と役割を教えて下さい
intとかの
言語はjavaです

309 ：

スレ違い

310 ：

>>308
intは文字
charも文字
w_charも文字
とにかく文字に使う

311 ：

String s;
s = "Javaは、Unicodeです。漢字も1文字。わかりやすくて安心だ。";
t = s.substring(i, i + 1);

312 ：

そしてサロゲートペアに嵌る。

313 ：

"?田(よしだ)です。Java使いはアホが多いですね".substrin(0,1);

314 ：

サロゲートペアを解決した後は、合成文字にはまって、
合成文字を解決した後もVSが待ってるんだよな。
最初に16ビットに収めようと言い出したやつは刺されてもおかしくない。

315 ：

32bitなら合成文字も解決すると思うのか?
何文字分までの合成を想定してるの?

316 ：

合成文字ったって理論上はいくらでも繋げられるけど実際そこまでのものは無いだろ。
16bitぐらいバリエーション表現用に取って、意味は言語ごとに変える。
大文字小文字、ひらがなカタカナ濁点小書き、異体字、全角半角の違いなんかも全部詰め込めば
そこをマスクするだけで曖昧検索もできてウマーと勝手に思ってるんだが甘いかな。
ASCIIとも互換性なくなるけど。

317 ：

brainf*ckみたいなもんだな

318 ：

はっきり言ってお前らの議論は南堂先生のレベルには遠く及ばない。

319 ：

合成を使わないと某半島のアレがウン十万字分のコードポイント占めるんだよ

320 ：

タイ文字なめとんのか？

321 ：

>>319
合成済みのが追加済みじゃなかったっけ？
あまりにも数が多いので規則的にして計算式で求められるようになってて表からは除外されてる

322 ：

感じも部首に分けて登録するか

323 ：

それいいな。ついでに部首ごとにキーを振ったら新しい漢直になるぞ

324 ：

>>316
> 16bitぐらいバリエーション表現用に取って、意味は言語ごとに変える。
どこが今のUnicodeに比べて優れているのかと…

325 ：

合成文字を常態化するなら慣用や拗音も文字コード充ててしまえと

326 ：

だって全文字共通で装飾にビットを振っていくと何ビットあっても足りなry
まあそれはいいよ。
とりあえず今のUnicodeは、何をするにしてもUCDのテーブルを抱え込まないといけないので
もうちょい全体的に範囲をまとめて欲しい。
なんで新しめの仕様なはずのVSですら散らばってんだよ。連続領域に取れなかったもんだろうか。

327 ：

どうやって並べても不満の出る射影はあるのだから、
テーブル実装技術の方で頑張ってください。

328 ：

>>321
コードポイントのどのあたり？

329 ：

>>328
http://www.unicode.org/reports/tr15/tr15-33.html#Hangul
AC00から11172文字かな。

330 ：

>>329
それだと、>>319と数が合わない。
>>319は現代では使われていない古文字の合成のことじゃないのか?

331 ：

Win8プレビュー版の日本語フォント、1F2xxがちょっとアレだな。
ただのスタブならいいんだけど

332 ：

MS3フォントに325のIVSが入っているのを確認。

333 ：

シングルバイト文字しかない文字列をエディタで保存したとき、
内部文字コードをUTF-8にしてもUTF-8にはならず、SJISとなってしまいます。
単にエディタが識別できないだけだと思いますが、気にしなくてもいいですか？
例えばhtmlでContent-Typeをtext/html;charset=UTF-8と指定してるにも関わらず、
マルチバイト文字がないため、内部文字コードがSJISになってる感じです。

334 ：

と、書いてから気づいたんですが、
こういうときのためにBOMがあるんですかね？

335 ：

BOMはバイトオーダーを識別するためにあるんですよ。

336 ：

>>333
円記号については問題が発生する

337 ：

>>333
> 内部文字コードがSJISになってる
というのはどういう状態? なぜそう判断したの?

338 ：

レスありがとうございます。
>>335
一般的にはそうみたいですね。
UTF-8には無意味とも書いていました。
ただ判別するためにUTF-8でも使うみたいなことは書いてました。
>>336
よくわかりませんが確かに\は発生しそうですね。
>>337
エディタで文字コードを指定して保存する時UTF-8で保存しますが、
再度開いたときにSJISで開かれてエディタもSJISと判断してるということです。
バイナリエディタなんかで開いたとき、
シングルバイト文字は、SJISでもUTF-8でも、16進数ダンプで同じ値になるので、
エディタにはそのへんが判断できないんじゃないのかなぁと思ってます。

339 ：

そのエディタのスレで聞いたほうがいいのでは。
エディタ名伏せられたままじゃ何とも言えん。

340 ：

>>338
適合する文字コードの中でSJISを優先して選ぶエディタか、
環境(ロケール等)ってだけでは?

341 ：

>>339
とりあえず手持ちで確認したところ、
Windowsメモ張、サクラエディタ、TeraPadなんかはそんな感じです。
Windowsメモ張でUTF-8で保存した場合、UTF-8として開かれますが、
あれはBOMついてるので、BOMなしでUTF-8で保存した場合、
どれもSJISで開かれます。
>>340
そうですね。
UTF-8と判断する材料がない場合、優先してSJIS選んでるんでしょうね。
>>333の例であげたhtmlにしても、文字化けするというわけではないので、
気にしないのが一番なんですかね。

342 ：

ASCII範囲の文字しかなければASCII=UTF-8(BOMなし)=SHIFT_JIS=ISO 8859-1にしかならんだろ。
このなかのどれを選ぶかはエディタを作ったやつ次第。メモ帳はANSI=現在のコードページだろうし。

343 ：

PRI 183(AJ1の追加分)は明日までか

344 ：

去年ちょろっとAdobe-Japan1-7の話が出たけど、
結局とくに意味はなかったのか。

345 ：

意味のないことは多いからな

346 ：

グリフの内訳はバラバラなのに、Glyphwiki発だからって理由で
何でもかんでも花園フォントとしてリリースするのは紛らわしい。

347 ：

もう少しｋｗｓｋ

348 ：

本家版にOT版にKDP実験版に。
全部花園明朝名乗ってるけどグリフの内訳はバラバラ。

349 ：

そろそろ問題だらけのUnicodeはもう捨てて新しい文字コード体型考えようぜ

350 ：

どうぞどうぞ

351 ：

まさかの一人目上島

352 ：

うにコードより先にJISコードを時代に合わせて綺麗にしようや
円記号とバックスラッシュの分離
2・1バイト幅英数アルファベットの別を無くす
囲い文字コードを無くし付加記号の仕組みを入れる
異系文字の定数引き
現行コードから変換指針の提示

353 ：

誰得

354 ：

オマエ以外

355 ：

どんな得があるわけ？

356 ：

とりあえず携帯電話を早くUnicodeに対応させてくれ

357 ：

ガラケーは死んだ

358 ：

なぜだ？

359 ：

IPAmj明朝の正式版キタコレ

360 ：

文字コードスレとはあまり関係ないよね。

361 ：

これ以外に汎用電子対応のフォント出てくるのかねー

362 ：

1週間止まってたスレが動き出したか

363 ：

IRG N 1812って何だろ
またスケジュールを遅らすことになるのか

364 ：

>>361
そういえばIPAex明朝すらIVSはAJ1だったな

365 ：

>>360
オレオレ文字コードを発明しないでISO/IEC 10646の枠組み上で
できる限り符号化しようと努力しているのを評価対象にするとか

366 ：

今日電話で話した人が「テンプレが出てるんだよ」「テンプレになっちゃうんだ」と連呼するものだから、
一体何のことなのかと首をかしげていたら「豆腐」のことを「天ぷら」と間違えて覚えているらしいことに気付いた

367 ：

ブログのログインみたいな感じの部分を想像してほしいのですが、
データベースやファイルに入っているログイン情報がUTF-8以外、
ログインするためにフォームから入力する値がUTF-8で、
これらを比較するとします。
基本ログイン情報は半角英数字だと思うので問題は起きにくいとは思いますが、
もしこの状態のまま、ログイン情報にマルチバイト文字を入れた場合、
ログインが出来なくなる以外に何か問題は発生しますか？
例えば情報があってないのにログイン出来たとか、
そんな感じのはありえますか？

368 ：

＞基本ログイン情報は半角英数字だと思う
これ次第じゃね。

369 ：

そうなの？

370 ：

UTF-8の入力がそれ以外の文字コードの何かにマッチする可能性があるのは、
Ascii文字セットの領域以外の文字に限定されるでしょ。つまり、ログイン情報に
Ascii文字セットの文字しか使っていなければ間違ってマッチすることは避けられるかと。

371 ：

[ce b1] UTF-8: α, Shift_JIS: 留
[ce b2] UTF-8: β, Shift_JIS: 硫
[ce b3] UTF-8: γ, Shift_JIS: 粒

372 ：

る？

373 ：

りゅう、だろ。

374 ：

りゅう

375 ：

　　　　　　　　　　　　　　　 　　＿＿, 　-──┐
　　　　　　　　　｢￣￣::／ ￣ 　 　 　 ｀丶::::::::::|
　　　　　　　　　!:::::::／,　- ､　　　　　　 　 ＼::/
　　　　　　　　　i:::::/ /:::::::::::::i　　　　　 ●　 　}　　　　　　　　うりゅーっす！
　　　　　　　　　 ∨　{:::::●::::l 　　　　　　　 -┼-､
　　　　　　　　　　{　 ゝ::::::_ノ └〜┘ 　 　 ｀Ｘ
　　　　　　　　　　 Ｘ´　　　　　　　　　　　　<＿ヽ
　　　　　　　　　 /　　>　　　　　　　　.....:...::..::::　　＼__　　__
　　　　 　 　 　 　 _／　.　＼　　／　　.:.::..:.:::::::::::　 ::　　￣　｀ヽ
　　　　　 , --―'´;.:.､　　... .: .:i :i::　:　 .:::..:,.‐''". 　 　.　　 .:､　 :.:::}
　　 　 ／　　 . :.:.ﾉ:. ..＼.　ヽ:　　, -‐''´ ..::: ..　 　 :　　　　 .::l . :.:.::|
　　　/　　 . .:.:.:./:. 　 　 ｀ヽ､::／　　　　 .:::､:.. .. .　:.　　 　 .::i ...:.:∧　
　 　 |　　 .:.:.:;ｲ::　　　　　　.:i::.　　 　 　 . .::｀''‐-=､ヽ、.:.. . .:: .:ノ:　:!　
　　/{::.　　 '´.:.i::.　　 　　　. :|:　　　　　 . .:: :.::::::::::::/ﾞ"ヽ､:..:.::´::..:　:|　
　 ,'　｀: :...:.:.:.::.::;!::.. .　　　　.:.:|:　　　　　　 :: :.:.:::::::::{::.　.::;'｀　　.::.: ;!:|　　
　｛　　:.　｀''''ﾞ´|:::.:　　　　 .:::l::. 　　　　 .:.::..:.:::::::::::|::. . ::i　　 ..:::iく ::|　
　 {:.:..　.:..　. .:.:::ﾄ､:.:.. . .　 . .:.:;!､::.. . . .　... .:.::..:::::::_;;.ゝ、..:|　　..:ノ :. ヾ、
　/｀'''　 ､,,,___:ノ　＼::. :.....:.:ノ::..｀'ｰ::.....;;;＿;;:.-‐''....:...:::,＞'=､　　.::i　:.::}
. {:.:. .　　 _＿_＼ 　 ｀ ‐-=､:::.:.. ..::r　ｰ-=､.....:...::..::::／　 　 　 . .:::! :; ::|
　!ｰ: . ／　＿__;＞┐　　　 ＼:..　:! ,.-―:‐､:: ,,.:‐''´　　　　. . :__;ﾉ.ｲ
　';.:../　 /´、 　￣）ヽ. _,ｒ―‐亠- ､!　　　 |｢:　　　　 . . - '''´. : :.:/
　 ヽ!　 { :..　￣￣厂:く__,.-‐''　 　 ..|　　　 |!:. .　　 . .. ... - =_ヲ'

376 ：

最初が「う」ならもっと前のほうだろう

377 ：

この流れは367に責任があるんだろうか

378 ：

>>367
>例えば情報があってないのにログイン出来たとか、
>そんな感じのはありえますか？
yes

379 ：

みなさんありがとうございます。
とても参考になりました。
修正しにくい箇所に記述してしまったので、
バグとわかってても修正はできませんが、
ASCIIの領域内に限定して何とかやり過ごすことにします。

380 ：

パイプラインに新規追加されたtext style, emoji style用vsって何だろ。

381 ：

ハートとかを、普通の文字として表示するか絵文字として
表示するかコントロールするものじゃないかと、元見ずに予想してみる

382 ：

ドコモ式au式みたいなのじゃ？みたいな

383 ：

そのうちwg2のページで内容見られるだろー
と思ってたんだけどなかなか公開されんね。

384 ：

どうなってるんだ

385 ：

で、どうなのか

386 ：

日本語の文字コードがいくつもある理由
http://qpon.at.webry.info/201112/article_14.html

387 ：

>文字コードの１文字目のコードに１２８を加えてアスキーコードの３３〜１２６
>と重複しないようにした「Shift_jis」や「EUC」文字コードが作られました。
わかってないなこのひと

388 ：

>なぜsiftと言うのかというと２進で１桁繰り上がる（１２８が加わる）ためです。

389 ：

>そこで世界の主要な文字全部にダブらない文字コードとして作られたのが「utf-8コード」です。

390 ：

十数年前はこんな感じのページがいっぱいあったけどねえ。
いまどき珍しい。

391 ：

これはひどい

392 ：

>以上を理解したうえで各文字コード
>を見比べるのもいいのでは

393 ：

もうやめたげてー

394 ：

>>392
http://qpon.quu.cc/unicode/index.html

395 ：

WebKitのIVS対応ｷﾀﾜｰ.*:.｡.:*･ﾟ(ｎ‘∀‘）ηﾟ･*:.｡.:*!!
https://bugs.webkit.org/show_bug.cgi?id=50999

396 ：

そういえばまだだったんだっけ

397 ：

>>386
てか、そのページいろいろと酷いな

398 ：

高度経済成長の時期に大会社で働いて、還暦を過ぎても今の技術に詳しいつもりの
俺が世界に向けて解説する、ドヤ顔ページか。
年金をちゃんともらいながら死んでいくんだろうね。
老害ってこういうのを言うのかね。

399 ：

ここで問題になってるのは「“今”の技術」でさえないぞ

400 ：

老害ってのは権力者がいつまでも実権を握って離さんこと。
無名の個人サイトによくそこまで熱くなれるな。

401 ：

まさに老害

402 ：

>>400
いや、ぐぐってそのページ見て納得されても困るだろ
嘘やいい加減を世界に解説はいかん

403 ：

文字コードでぐぐったら http://ash.jp/code/ 行っちゃうだろ

404 ：

http://jp.reuters.com/article/marketsNews/idJPTK804571420111219
KPS 9566の4行78列〜80列に金正恩が符号化される日が来たようだ

405 ：

あれってすごく不思議なんだけど、「金」「日」は親子共用で1つでことたりるよね？
ただでさえ王家専用符号位置なのに、なんで「金」「日」「成」「金」「正」「日」って6つも使うの？
組み文字として「金日成」「金正日」を符号化したなら分解できないから仕方ないし、
「“金日成”はポップ体、“金正日”は相撲体を使う」とかの儀礼があるなら意義がわかるんだけど。
「金」「日」「成」「正」だと付け足しみたいで金正日に不敬、みたいな価値観があったりする？

そうなると、うっかり「金正日」の「日」に「金日成」の「日」を使ってしまったらお仕置きがあったりするの？

406 ：

WindowsのIMEって単語変換いまいちなのに金正日は一発なんだよな

407 ：

ある国には過去、
天皇陛下　という 1x4 の活字が過去存在してたんだ。
別にどうだっていいだろうそんなもん。

408 ：

㍿

409 ：

>>405
「金同志」をハングルで書いた時に文字コードで誰だかわかる
のが基本なので、「金」は共有できないよ
「日」を共有しないのは、「金」を分離して「日」を共有すると面倒だから

410 ：

入力時にどうやって見分けるんだろう…

411 ：

理屈が全然わかんねえ。
普通の「金」で検索したら出てこねえのか? 検索も許されてないのか?

412 ：

左右上下一直線の書字方向という考え方をを改めて
欧文約物や濁点は時々上下や右上隅へ移るとした文字列処理系が出来ればいいんだよ
あー例のグチャグチャなハングルとかもサポートするかベタ直線的に字母を並べるかどうかは処理系依存で

413 ：

>>409
北朝鮮の人が書く/言う場合には例えば金正日同志とフルネームのことが
多い気がする。

414 ：

>405
ソートしたとき、金日成→金正日の順番で並ぶようにするため。

415 ：

まさかUnicodeに入れるとかしないよな?

416 ：

>>415

417 ：

>>415

418 ：

>>415

419 ：

VSを使って区別するようになったりして。
例えばU+AE40(ハングルGim)は
VS1(U+FE00)を付けると金日成の、VS2(U+FE01)で金正日の、VS3(U+FE02)で金正恩の、
VSを付けないと一般用のハングルGimになる
とかで。

420 ：

すみません、CGI質問スレが無いので、どなたか教えてください
sitemixで、メールフォームのchamamailを設置したのですが、http://www.chama.ne.jp/download/mail/chamamail/index.htm
送信の確認画面に�と出たりメールを受け取った時のメールフォームの中が
----------------------------------------------------
縺雁錐蜑&#65533;＝縺&#65533;
email＝doostynahin@gmail.com
---------------------------------------------------
の様に文字化けしてしまいます。サクラエディタ使用でファイル転送ソフトはFFTPです
ローカルの文字コードはEUCにしているのですが、ホスト側の漢字コードもどう設定したら良いのでしょうか？
ホスト側をJISやSJISにするとエラーが表示されます

421 ：

>>407
Unicodeにも歴代陛下のお名前があるよ! (U+337B〜U+337Eあたり)
収録を拒否された独裁国家とは格が違うね

422 ：

おまいらなんでそんな朝鮮事情に詳しいんだ
在日か？

423 ：

>>420
CGIならこっちで
http://kohada.2ch.net/php/

424 ：

>>412
それってUnicodeの結合文字と何が違うの?
もちろんハングル字母もあるというかむしろ韓国のゴリ押しで
BMPを1万字以上も食いつぶしたのは完成形のほう

425 ：

>>422 Rよ

426 ：

>>425

427 ：

>>423
CGIが時代遅れなせいかそこではCGIスレ無いんですよ
有っても2ヶ月以上レス無かったりするスレばっかで

428 ：

この板にはひとつもない
どっちが妥当な板かは明白

429 ：

日本語の文字コードの保存形式を聞きたいだけなので
こっちのほうが専門かと思ったんですが・・・

430 ：

違います

431 ：

>>429
ソースをダウンロードしてみたら、chamamail.cgi(perl code)はシフトJISで書かれていた。
更に改行コードがCR+LFなので、Windows環境で開発された物と思われる。
>■設定設置方法
の部分を見るに文字コードについては一切の指定が無い。
どうやら作った人間は、そういう事まで頭が回らない人間と思われる。
ソース中に、
print "<META http-equiv=\"Content-Type\" content=\"text/html; charset=Shift_JIS\">\n";
というハードコーディングがなされているので、シフトJISのままサーバーに設置する物なのだろう。
ソースに書かれた日付を見ると、どうやら最後にメンテナンスされたのは2001年頃らしい。
2001年頃に、サーバー側にインストールされていたperlのバージョンを考えると、
最新でも5.6.0、ちょっと古ければ5.5.0、5.0.xxx、下手すればperl4の可能性だってある。
シフトJISのまま動かない理由としては、perlはバージョンが変わると、
使用可能なリテラルが変わったり、エスケープしなければならない文字が変わるので、
シフトJISで書かれたコードは上記の制限に該当しやすいのでエラーが発生し、
それはCGIでは結果的にInternal Server Errorを引き起こす。
これは元々シフトJISに対応していないperlで、
無理矢理シフトJISを使う事による弊害なので、perlが悪い訳でも無い。
修正したいならエラー出力に、問題となった箇所が出力されている筈なので、
httpdのerrorログを見てソースを修正すれば良い。
あとは↓のスレに行ってやれ。
http://toro.2ch.net/test/read.cgi/tech/1319953460/

432 ：

この手の物のエラーの最大の原因は改行コードだろ。

433 ：

>>431
めっちゃいい人や・・・
ありがとうござます＞＜

434 ：

>>431 の罪は重い

435 ：

>>431 >>433
まずは板ルール読もう。
> CGI は Web プログラミング板へ。
そして、ここはプログラム板。
行くべきスレはこっち。ただし、学ぶ人のためのスレだから、そこは注意してくれ。
Perlコーディング初心者質問スレ Part 63
http://kohada.2ch.net/test/read.cgi/php/1315559509/
2chが初めてなら、初心者の質問板へ。
http://ikura.2ch.net/qa/

436 ：

>>407
ムハンマドの名前を言った後に唱える「彼にアラーの祝福と平安があらんことを」
を1文字(U+FDFA)に収録させたイスラム教徒に比べたらささやかなものです。
(U+FDFAは普通のアラビア文字18文字の並びと互換等価)

437 ：

それすげえなあ
へのへのもへじ　を突っ込んだとしても7文字相当にしかならないからなあ

438 ：

へのへのもへじはIDSで表したい

439 ：

じゅげむじゅげむごこうのすりきれ……

440 ：

つるにはまるまるむし

441 ：

⿰⿶し⿳⿰⿱への⿱へのもへ゛

442 ：

あめんぼあかいなあいうえお

443 ：

>>436
おお、確かにNFKDしてみると18文字になったw NFDではそのまま。
その手の特殊文字と同じ扱いということなんですかね。
意味は違うけどBill Gates(TM)みたいな感じ?

444 ：

ちょっと助けて欲しい。C++で書いたプログラムで、 cin から getline で日本語入力を受け取ると、そのまま出力しても文字化けする。
ICUで文字コード判定しようとしたんだが、長い日本語を入力しても言語を判定してくれなかった。
で、入力に対してバイト列を吐かせたところ、以下のような結果になった。
あいうえおかきくけこさしすせそ
E7 B8 BA E3 82 85 EF BC 9E E7 B8 BA EF BF BD E2 88 B4 E7 B8 BA E7 BF AB C2 B0 E7 B8 BA E9 98 AA EF BF A5 E7 B8 BA E4 BB A3 EF BC 85 E7 B8 BA E8 BC 94 EF BC A0 E7 B8 BA E5 90 B6 E2 97 8B E7 B8 BA EF BF BD
あいうえお
E7 B8 BA E3 82 85 EF BC 9E E7 B8 BA EF BF BD E2 88 B4 E7 B8 BA EF BF BD
あ
E7 B8 BA EF BF BD
共通点として先頭に E7 B8 BA が、末尾に E7 B8 BA EF BF BD が見当たって、バイト列内部にも E7 B8 BA EF BF BD が何箇所か見当たることは分かったが、原因がさっぱり。
Windows 7 64bit, MinGW + MSYS な環境だけども、原因か或いは解決策は何かないだろうか。

445 ：

あ(UTF-8) E3 81 82
縺(Shift-JIS) E3 81
縺(UTF-8) E7 B8 BA

446 ：

UTF-8専用の文字列リテラルがC++11で導入されたんじゃなかった？

447 ：

>>445
あー、解決しました。
新年早々ありがとうございました。

448 ：

新年早々ここは人が多いな

449 ：

え、なにこれ…
Genuine Han Unification
http://blogs.adobe.com/CCJKType/2012/01/genuine-han-unification.html
http://lundestudio.com/PDF/iuc35-lunde-s12t2.pdf

450 ：

>>449
よくわからないので日本語でｋｗｓｋ

451 ：

繁体字と簡体字で別々のコードポイントを割り当てるの止めようぜ、ってことか？
日本の漢字とか出てくる理由が良く分からんかったけど。

452 ：

unicode正規化の仕様にいれようぜ、と言っているだけに見えるけど。
>>449は驚いているから、オレの間違いかも。

453 ：

将来的にはCJKV(CTJK?)の漢字でコードポイントだけでなくグリフデザインも統一したら
いいんじゃね、 みたいな?
それを真の(genuine) Han Unification と呼ぼう、と。
GB 18030がいいモデルみたいなこと言ってるし繁体と簡体は区別するのかな。
でそういう流れは自然に起こるかもしれないと。例えば中国製のデバイスでフォントが
一種類しか入ってなくてもCTJKの人達で普通に使えるようになるとか...
ということは、UnicodeでHan Unificationしたことは、いいきっかけになったじゃないか、
みたいなw

454 ：

UNICODEに言語プロパティの皮みたいな話ですか？

455 ：

地域で字形が違うとかめんどくせぇから、ジャップは日本語の字形を捨てて中華フォント使っとけってこと

456 ：

Unicodeならこの改革を進められる、やるしかない
ギャーギャーうるさい連中がいるから今すぐはむりでも、25年ぐらいかけて洗脳すればいけるいける
スマホユーザ見てみ、どうせあいつら中華フォントでも気づかず使ってるで
ってこと

457 ：

日本のメーカー、またはキャリアが関わったandroid端末ではちゃんと日本語フォント入ってるけどなー。
海外製品無理やり使ってる連中はまず日本語フォント入れようとするし。

458 ：

ぼくも(´・ω・｀)

459 ：

なんか気にくわんなあ。

460 ：

Han Unif.がレンダラ実装の重荷だってことは分かるけど、
レンダラは主なものに収斂してきているから、
こういう動きが足早に進められることはなさそう。

461 ：

>>460
よく意味がわからないのだが。
純粋なレンダリングの処理にはコードポイントは関係ないし、
フォントの切り替えとかの話なら別にHan Unif.が無くても生じるわけだが。

462 ：

日中台では大過無いがその他の地域では
日本語を簡体繁体で表示してたり
支那語を常用漢字で表示してたりする事態が頻発するようになる

463 ：

>>461
コードポイントでなく、
言語情報でフォント切り替えるのは、
ハンユニフィケーション以外にあるの?

464 ：

>>463
というか普通はコードポイントでフォントを切り替える手間がメインなので
Han Unif.が特に重荷だということはないような、と。
言語情報とやらの切り替えがやたらと発生するならあれだけど。

465 ：

449は非CJKV圏向けのプレゼンで、そのうち字体の統一が起こるかもねー
ぐらいのニュアンスじゃないかな。
まぁかなり書き手の希望的観測が強く混じってる感じするけど。

466 ：

大陸側が繁体字に回帰したらそういう流れも出てくるかも

467 ：

KVは帰ってくることなく、しかし配慮はしなきゃいけない
中途半端な状態がずっと続くんだろうか。

468 ：

CJKVからCHJTへ

469 ：

CHJMT

470 ：

マカオ？

471 ：

CHJMT+カナダ

472 ：

>>464
16bitで済ませたいんじゃないの?
32bitじゃあルックアップテーブルも工夫する必要あるし。

473 ：

WinXPのSimSunがU+4CA0の字形をU+4CADに収録してたって件、
やっぱり0とDを見間違えたしょうもないミスなんだろうか

474 ：

来月か再来月にAJ1-6に情報を追加するよーってことは
まだしばらく1-7は来ないってことか
予定ありゃこんなタイミングで更新せんだろうし

475 ：

ISO-2022-JPのファイルで「ESC ( B ESC $ B」とか「ESC ( B ESC ( B」という並びは形式的に許されますか？

476 ：

single-byte-segment = single-byte-seq 1*single-byte-char
double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 )
single-byte-seq = ESC "(" ( "B" / "J" )
double-byte-seq = ESC "$" ( "@" / "B" )
なので、single-byte-seqの後に1文字以上ないとダメですね。

477 ：

ありがとうございます。
ということは j1.txtがESC ( Bで終わっていて、j2.txtがESC $ Bで始まっているときに
Windowsのcopy /b j1.txt + j2.txt j3.txtでできたj3.txtは、形式的にはISO-2022-JPに
従っていないことになるんですね。

478 ：

WG2更新
ミーティングがもう来月なんですな

479 ：

ああ、もうすぐ6.1.0か

480 ：

来月は他にもUTCとかWin8 βリリースとか色々あるね。

481 ：

>>477
改行文字でも挟んでおけば大丈夫。

482 ：

プードルの眉毛からあそこまで話が広がるのかー

483 ：

どこの話？

484 ：

ISO-2022-JPは、規格的には、テキストの一番最後にCRLFがあってもなくてもいいが、
ESC ( BかESC ( Jの後にsingle-byte-charが来る(0文字でもいい)行末しか許してない。

485 ：

RFC 1468 のバグじゃなかったっけ？
確か修正とかされてないけど。

486 ：

ワザというそういう仕様にしている。
JIS X 0208に文字集合にしたまま行を終わらないように。
規格にもはっきりそう書いてある。
ただJIS X 0201かASCIIかどっちでもいいけども。

487 ：

行の最後はJIS X 0201とASCIIのどっちでもいい。
テキストの最後はASCIIじゃないとダメ。
みたいな、ややこしいことになってますね。
RFC 1468は、よーく読むと、ツッコミどころが沢山あるみたいですね。

488 ：

今時ISO-2022-JPなんてどうでもいい。
半角仮名も使えないようなR。
みんなGmailでUTF-8だろ？

489 ：

半角って何ですか?
それはさて、Gmailはないわ。

490 ：

　　ヘ_ヘ
　ミ ・ ・　ミ
　 (　 °　)〜

491 ：

Unicode 6.1.0リリースって、2月の何日でしょうか。
ソフトウェアリリースのタイミングが掴めない。

492 ：

ttp://www.unicode.org/Public/6.1.0/ucd/DerivedAge-6.1.0d14.txt
によると (January, 2012) に繰り上がっているのでもう出るかも。

493 ：

白背景が6.1で追加されるもの
ttp://www.unicode.org/alloc/Pipeline.html
日本関連だと9fccくらいかな

494 ：

リトアニアの首相からWG2へ直々に符号化要請来たのか。

495 ：

>>491
来週だって。
ttp://twitter.com/unicode/status/161920601345359872

496 ：

>>493
涼に包摂されるかどうかが二転三転したアレか

497 ：

UTR#50締切日

498 ：

さて、今月はどうなりますか。

499 ：

UTR50なんて半年前からやってて一度〆切を延長してるのに
みんな何を今になってバタバタしてるんだ

500 ：

Unicode 6.1正式リリースキター

501 ：

現地だとぎりぎり1月中にリリースできたことになるんだな。

502 ：

それって大事なことなのか

503 ：

それって大事なことなのか

504 ：

事前予告しちゃったからね

505 ：

イワタに就職した某氏も「線の質がどうだとかケチをつける気にもならないトンデモ」
とか絶賛のCode2000がGPLv3で公開されたようだ

506 ：

それふぉんと？

507 ：

代替フォント専用でトーフ撲滅目的なら何でもいいじゃん
どーせ読めないんだしさ

508 ：

URL貼るの忘れてた
https://sourceforge.net/projects/code2000/
OFL 1.1とのデュアルライセンスになった模様

509 ：

>>508
フォントサイズが変わってるね。
unicode 6.0対応とかだったらありがたい。

510 ：

年賀状ソフトとかに付いてくるクラフト書体だっけ？
ああいうのを小学生が作ったらこうなりそうだな

511 ：

ずっと持ち越し扱いになってたN3698は今回のagendaに載ってないな。
N4091で一段落って形になったか。

512 ：

>>509
アカウント乗っ取りの偽物だった

513 ：

んっ！？どういうこと？

514 ：

ポーランドかどっかの知らない人がJames Kassのメールアカウントをクラックして
James Kassのふりをして勝手にGPLで公開したってこと
MLでの言動がおかしくてバレた(技術的な質問に全然答えられないとか)

515 ：

ほえええ

516 ：

N4229は手法論に文句ばっかり言う日本にTCAお怒りの巻かしら

517 ：

code2000より、symbola作ってた人のフォントを誰か引き継いでほしいな。

518 ：

で、今後はどうなるんだ

519 ：

USはつおいなー

520 ：

小書きコ飲まされましたか。

521 ：

Old Hungarianは泥沼っすなー

522 ：

もう小書きは五十音全部作っちゃいなよ

523 ：

実際カタカナは半分くらいすでにあるんじゃないか

524 ：

小書きンはまだないンだっけ。

525 ：

あいうえお
か〓クけこ ←NEW!
〓シス〓〓
〓〓つ〓ト
〓〓ヌ〓〓
ハヒフヘホ
〓〓ム〓〓
や＿ゆ〓よ
ラリルレロ
わ〓＿〓〓
〓
ひらがな表記…平片両方ある
カタカナ表記…片仮名のみある

526 ：

小書きといえばARIB外字の70%サイズの氏副元故前新

527 ：

このスレのお前らは普段どのモジコード使ってるの？

528 ：

UTF-16

529 ：

UTF3

530 ：

Unicode7だろ

531 ：

Unicodeを
学んで分かる
Windowsの
痛々しさよ

532 ：

WindowsはUTF-16なんだっけ

533 ：

Windowsは日本語版だけ特殊なんだよな

534 ：

そうなの？

535 ：

>>525
カタカナしかないやつはアイヌ語用か

536 ：

もう小書き仮名セレクタ作った方が早いな

537 ：

小書き仮名は「大書きの仮名に一対一で対応するバリエーション」というより、
「音素文字がほしかったので間に合わせで用意しました」的なものも多いから、
大書き仮名を親字としてセレクタで表現されると困ると思う。

538 ：

それならFull-Widthもセレクタにしたほうがいいな。
ていうか16ビットに収まらなくなった時点で、上位ビットをバリエーション表現用に予約しとけば
ビット操作だけで曖昧検索にも対応できてすっきりしたと思うんだ。
こんだけgdgdになると、Unicodeを最整理した新コードができても、全文字互換を取るのはもう不可能だよね。

539 ：

http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4246.pdf
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4246-A.txt
また同じ字形を増やすのか。いくつ目だよ
もうこの際だからCJKTVMHUKPそれぞれのソースの字形も
Standardized Variantで表してdisunify完了ってことでどうよ

540 ：

それは既存の互換漢字をBMPのVSで表す提案じゃないか

541 ：

うん、だから互換漢字だけと言わずいっそのこと統合漢字もやっちゃおうぜと

542 ：

タイミング見てそれもやってきそう。

543 ：

言語タグは犠牲になったのだ…

544 ：

今頃になってIVSの存在を知って、おおスゲェと感じ、もしかしたら戸籍管理に役立つのではないかと色々画策してみたんだけど、
これってFirefoxやその他対応ブラウザじゃないと使えないのね。
でもUTF-32を使えばIVSいらないんだぜって会社の先輩が話してたんだけどこれって単純に彼の勘違いであってる？
英語のドキュメント含めて色々調べたんだけど、UTF-32（UCS-4）の情報が見つからなくて…
なんか凄いあほな質問だけどよかったら答えて下さい。

545 ：

勘違いだろうね。よくある最初から32ビット固定にしとけば…って話なんだろうけど。
業務としてやるんなら、ここに参加するのもありかも。
ttp://ivstpc.jp/

546 ：

(´‥∀‥`)ほう

547 ：

むしろ、複数コードポイントが1文字になるのでUTF-32の存在意義すら危うくする存在＞IVS
合成やセレクタをうまいこと区別できるUTF-??出てこないかなあ。

548 ：

>>547
IVSの有無に関わらずUTF-32は複数コードポイントで1文字だから。
合成可能なコードポイントかも属性見れば良い話。

549 ：

来たかコンシューマプレビュー
Unicodeまわりははたして

550 ：

>>547
結合文字なんてUnicodeに最初の最初から存在してたんだから今さら過ぎ。
制定当時の技術水準では非現実的な仕様だったけど

551 ：

>>549
デベロッパープレビューの時点でIVS対応してることは判明してたな
http://ameblo.jp/naoshi1128/entry-11030691791.html

552 ：

UTF64の出番か

553 ：

128にしようぜ

554 ：

UTF-128は合理的なんだよ。
なんと128bitのMD5がたった1文字に収まってしまう。
合理的だろ？

555 ：

収録数保持した512にしようぜ

556 ：

ワタシが現在開発しているUTF-160は、 SHA-1を一文字に納めることができる。
誰か投資しないか？

557 ：

すごい文字コード
http://slashdot.jp/comments.pl?sid=333447&threshold=1&commentsort=3&mode=thread&cid=1022907
これくらいのネタは考えてくれないと面白くもない

558 ：

結合文字は何文字でも無制限に付けていいことになってるから
2^nビット固定長脳の人は絶望するといいと思うよ

559 ：

濁点をたくさん付けたい

560 ：

三濁点、四濁点あたりまえ

561 ：

つゆだくだくで

562 ：

蓮画像を思い出したよ

563 ：

十濁点以上の字はグロ字にカテゴライズされて、
ブラウザーの「グロ字を表示しない」オプションを有効にすると代わりに井桁で表示される。
そうするとなんとか無理矢理表示させようとする悪徳業者が現れて
字の代わりに画像にする高等技術が生み出されて社会問題になるの。
それをNHKなんかが特集組んだりするわけ。

564 ：

十濁点字をうっかり自動読み上げさせようものなら、
変な周波数の音が出て家具がびりびり共振する

565 ：

>>500
http://www.unicode.org/charts/PDF/UF900.pdf
U+FA13の字形はどっちが正しいの？

566 ：

CIDをUnicodeに変換する事って出来るの？
記号(♂)のまっすぐバージョンがCIDにはあるんだけど、これをhtmlで表示させたい（もちろん、フォントには収録してます）。
もし、Unicodeに出来るのであれば、そのコードを指定してやれば表示させられるとは思うのですが、果たしてCIDをUnicodeに変換する事は可能なのでしょうか？

567 ：

个
〇

568 ：

>>566
出来ないのもある。もともとUnicodeとは無関係に作られた集合だから。
フォントの中でそのまっすぐバージョンが♂の異体字扱いになってるなら、
CSS3のfont-feature-settingsでaaltを指定すれば呼び出せるかも。

569 ：

>>566
> 記号(♂)のまっすぐバージョンがCIDにはあるんだけど、
どういう意味？
曲線バージョンでもあるの？

570 ：

ビンビンで上向いてるんでしょ。

571 ：

ヒラギノには「♂」U+2640のグリフ4種類入ってるな。
Macだとrtfやpdf中ではちゃんと区別して使える。

572 ：

IVD新版来たな
http://www.unicode.org/ivd/
http://blogs.adobe.com/CCJKType/2012/03/new-ivd-version.html
汎用電子は228個も却下・取り下げか。これって却下の理由とか公開されないのん？

573 ：

もしやもしや、FirefoxのIVSってTruetypeしか対応してない？
花園明朝のTrueならIVS表示できたがOpenだとIVS表示できてない…

574 ：

あ〜、jp78とかいう属性付けるとIVSではないけど異体字表示できますね。
俺としてはIVSでやりたいんだが、誰か方法を御教授願います。

575 ：

>>572
理由はわからないけど、IRGのレポートだかに
異体字と見なせないものはあとで互換漢字として提案するようなこと書いてあったから、
そっちに回したんじゃないかな。

576 ：

>>574
IVSは漢字用だろ

577 ：

>>576
わかってるよｗ
firefoxでためしに表示させてみてくれ。
Truetypeでは正常に表示されるがOpentypeでは表示されない

578 ：

ttp://senda.shiteyattari.com/aalt.html
何か信じてくれてなさそうなので表示サンプル作ってみた。ローカルに落として、それぞれのフォント指定を自分の環境に変更させた上で
Firefoxで表示させてみて。OTFだけIVSが正常に表示されないから。
もし、俺のコーディングがおかしくて表示されてないのだとしたら、修正稿の提示をどうかお願いします。

579 ：

ここにいる奴はしったか8割だからあまり期待しないほうがいい

580 ：

>>578
FirefoxはCIDベースのOTF対応がまだ怪しいので、Bugzillaに投げた方がいい。

581 ：

>>578
表示されないってwebフォントの場合か。
ここの記事と同じっぽいからコメント欄参考にしてみれば？
ttp://d.hatena.ne.jp/mashabow/20110807/1312725162
試してないから解決するかどうかはｼﾗﾈ

582 ：

https://www.lasdec.or.jp/cms/14,25829,72.html
戸籍統一文字を追加するらしい

583 ：

戸籍統一文字じゃなくて住民基本台帳

584 ：

そういや結局0213って改正するの？ 常用漢字の関係で

585 ：

規格をいじる愚をこれ以上繰り返すのもなぁ

586 ：

常用漢字改訂の影響受ける字なんてあったっけ

587 ：

叱か

588 ：

JISCのサイト言ったらいつのまにか改正されててワロタ
誰も気づかなかったのか…

589 ：

>>584
> そういや結局0213って改正するの？ 常用漢字の関係で
なぜそう思ったのか根拠を述べよ

590 ：

0213は今さらどうでもいいけど、0221はそろそろ改訂する必要ありそう。

591 ：

どこで聞いていいかわからないからとりあえずここで。
N88BASIC(Disk版)の、KI/KOコードで挟まれた中の「JISコード」がどんな風に格納されているのか
具体的な変換式なり表どっかにないですか。

592 ：

そのままだろ。その為にKI/KOで挟んでるんだし。

593 ：

エスケープシーケンスが違うだけで、中身は ISO-2022-JP と同じ、だと思う。基本的には

594 ：

ふむ

595 ：

Unicodeは次は6.2.0か
/Public/6.2.0/が出来てる

596 ：

次は何が変わるんです？

597 ：

IVDチャート来たか。
画像化されて相変わらず重いなー。

598 ：

さっそくバグ
http://slashdot.jp/journal/548379/%E3%80%8CU%2B9415-U%2BE0101%E3%80%8D%E3%81%A8%E3%80%8CU%2B9415-U%2BE0103%E3%80%8D%E3%81%AE%E5%B7%AE

599 ：

>>598
なんでレビューのときに指摘しないの? 指摘してるけど無視されてるの?
(無視したらそれまででそのまま登録するしかない)

600 ：

>>591
NECなので78JIS(正確にはJIPS)である点に注意

601 ：

>>589
JIS X 0213:2012の解説によると、
JIS X 0213の附属書6は第一水準と第二水準についてJIS X 0208の附属書6を
参照していて、JIS X 0208の附属書6には常用漢字を示す[常]マークと常用漢字表に
もとづいた音訓が書かれていたので、JIS X 0213・JIS X 0208ともに改正する必要が
あった。

602 ：

0208だけじゃだめなの＞

603 ：

>>602
これも解説に書いてるけど
・常用漢字との対応がJIS X 0208とJIS X 0213で異なる
・JIS X 0213では一部の常用漢字が第三水準に対応する
というわけでダメだった。

604 ：

>>599
Unicodeのレビューシステムが壊れてて
結局レビューが届かなかったらしい >>294

605 ：

ﾜﾛﾀ

606 ：

それはﾜﾛﾀ

607 ：

さて、四月馬鹿がやってきましたが

608 ：

http://slashdot.jp/journal/548685/
本当にやってくれ

609 ：

しっかし異体字の泥沼に終わりはあるのかしら

610 ：

>>604
Unicodeのレビューシステムは4バイトのUTF-8がとおらない >>608

611 ：

えっそれってどうするの

612 ：

レビューなどしないという事だ

613 ：

中の人は知ってるのかな

614 ：

なんと1ヶ月も書き込み梨か

615 ：

質問なのですが
文字実体参照や数値文字参照を正しくアンエスケープ出来ていない状態は、文字化けと呼んでも差し支え無いのでしょうか？
それとも明確に区別されるべきなのでしょうか？

616 ：

文字化けという言葉に厳密な定義などないのでどうでもよい。
ひとつ言えるとすれば、明確に区別したいなら文字化けというような
あいまいな言葉を使うべきではない。

617 ：

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

618 ：

ありがたいのか

619 ：

Javaがらみなのですが、native2asciiでUTF-16でサロゲートペアになる辺の文字の
逆変換がうまくいかないっぽいのですが、こういうもんでしょうか。
例えばU+21300に対して（以下某専ブラの文字参照のテストも兼ね）
% echo 𡌀 | native2ascii -encoding UTF-8
¥ud844¥udf00
% echo 𡌀 | native2ascii -encoding UTF-8 | native2ascii -reverse -encoding UTF-8
¥ud844¥udf00
そのまんまやんけ、と。

620 ：

おお何それちゅのむ？

621 ：

共同通信社「字形と入力」が見当たらない。
CJKV Information Processing 著者: Ken Lunde
の参考文献に記述があるが、探しても見つけられない。

622 ：

Ken Lunde か共同通信社に問い合わせするっきゃないんじゃないか？
多分一般に販売してない印刷物なんだろうと思う。

623 ：

すまん！
ただいま問い合わせ中。

624 ：

けんちゃんのほうだろうか
これはｗｋｔｋせざるをえない

625 ：

社内のガイドじゃないか？

626 ：

業界向けに配布されたものかrequesterがAdobeに送ったものか
どっちかだろうな

627 ：

10月のUnicode Conference行く?

628 ：

うちから遠いから行かないわ(´･ω･`)

629 ：

場所って決まってんの？

630 ：

UTCはN4246を受理したか
また血みどろの戦いが

631 ：

http://www.oreilly.co.jp/feedback/

類書には記載されていない文献がある。

632 ：

ああ例の互換漢字にStandardized Variantsを割り当てるって奴か

633 ：

恥ずかしながら今だに意味が良く理解できない

634 ：

安岡センセイが微妙な連載開始
http://www.taishukan.co.jp/kokugo/webkoku/series003_01.html

635 ：

いや、これはいいんじゃない？
文字コードオタクじゃなくても読める文書になってるし。

636 ：

文字コードオタクじゃなくても読めるけど、
文字コードオタクとの会話・意思疎通には慣れてないと読めない気がするなあ。
同じサイトのほかの連載を見てみると、果たしてここの読者層が
「U+0000」みたいなのが最初の段落だけで8回、全文で90回も出てくる文章に面食らわずにいられるのか気になる。

637 ：

悪くはないと思うけど
国語教室と言われるとかなり違和感がある

638 ：

馬鹿には無理

639 ：

とりあえず次回を待とうか。
今回の主役のLatin系はメインテーマの「日本の文字」とかかわりが薄いし、
いくつか書いてあるsjis系由来の問題なんかは何もUnicodeに限ったもんじゃない。
まずは本題に入ってくれてからでないと、
「日本の文字とUnicode」というお題で何を展開するつもりなのか想像がつかない。

640 ：

言論系雑誌でもそうだけど、顔写真でてるのはいいね

641 ：

JISに由来する問題もSJIS由来になってなかったか。

642 ：

ttp://babelstone.blogspot.jp/
今年の9月か10月：トルコリラ記号のためだけにUnicode 6.2をリリース
2013年春：annexのupdateや例の互換漢字のVSのために6.2.1を出すかも?　文字の追加は無し
2014年はじめ：6.2の次の定期リリース(Unicode 7.0?)
らしい。

643 ：

₺？

644 ：

インドルピーが「き」でトルコリラが「も」か。

645 ：

そしてカザフスタンはどう見ても〒ですありがとうございました

646 ：

「も」に似すぎなのでグリフの差し替えを要求されます

647 ：

ポイントはたぶん2本線なんだろうな
簡易な形の文字に2本線を引くと仮名っぽくなっちゃう

648 ：

咎
↑これハングルっぽいよね

649 ：

Ю人
↑これもハングルっぽいよね

650 ：

龴
↑これはカタカナです

651 ：

韓国の人名用漢字って、全部Unicodeに入ってるの？

652 ：

入ってない可能性もあるの？

653 ：

Win8がunicode6.0対応なのはなぜ
6.1は10646になったの？
http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/05cd7b61-493d-4384-b709-b319e007332b/

654 ：

windows8RPではUNICODE6.1のemoticonも載っているらしい
http://bardiel-of-may.blogspot.jp/2012/06/windows-8rp.html?m=1

655 ：

>>639
第2回もますます日本語から離れた
http://www.taishukan.co.jp/kokugo/webkoku/series003_02.html

656 ：

ふむ

657 ：

読んだ。結構おもしろい。
しかし、このページ見てると、Unicodeって仕様をバッサリ切れない
ダメなマネージャが要求丸呑みして作ったシロモノって感じがするな。

658 ：

むしろ世界規模の規格がこの程度のカオスで
まとまったことが奇跡に近い。

659 ：

http://www.icelandreview.com/icelandreview/daily_news/International_Day_of_Icelandic_Letter_%C3%9E_Celebrated_0_390746.news.aspx
英語がよくわからないんだけど
U+00DEがUnicodeに収録されたのが1994年6月9日ってこと？

660 ：

わかんないの？

661 ：

わかんねぇよ・・・もう・・・

662 ：

>>659
Unicode 1.0に収録されてたから1994年より前のはず

663 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_03.html
やっと濁点・半濁点

664 ：

見せ方がうまいんだと思う

665 ：

安岡はキティの癖に、
コレじゃまるでマトモな人じゃないか。

666 ：

漢字やキー配列の話題から離れればこんなものなのかも。

667 ：

>>665
キチガイTRON信者乙

668 ：

ﾄﾓは本当にいったいどうして漢字になっちゃったんだろうね。

669 ：

>>666
三省堂の連載も結構マトモ
http://dictionary.sanseido-publ.co.jp/wp/author/yasuoka

670 ：

いや、タイプライターの話題こそ地雷

671 ：

全何回なんだろ
日本の文字に限るともうそんなにネタなさそうな気がするけど

672 ：

次回が最終回

673 ：

最近タイプライターネタになってんのか。
あれはちっとつらい。

674 ：

上下逆順で読みにくい

675 ：

それはブログ型CMS全般にいえる問題

676 ：

http://takagikenziro.blog.fc2.com/blog-entry-145.html
安岡センセイここでも活躍中ｗ

677 ：

バイタリティは見習いたい
遠巻きに見習いたい

678 ：

>>672
http://www.taishukan.co.jp/kokugo/webkoku/series003_04.html
終わらなかったみたいよ

679 ：

日本の文字をUnicodeで扱う際のややこしい点を説明する筈が
どうしてcjkの統一性欠如の説明になるんだ

680 ：

ややこしいじゃん

681 ：

UnicodeってJIS X 2013の文字も全部1:1で収録されてる？

682 ：

JIS X先生の最新作？

683 ：

0213…

684 ：

1:1ってのがコードポイントの話ならno、
ラウンドトリップ可能かって意味ならyes…だったと思う。

685 ：

ということはJISの文字はそのままUnicodeに変換可能。
CJKの問題はあまり影響無いような。

686 ：

>>685
ほう
例えば漢字はどのコードポイントに変換するの？
統一漢字？　互換漢字？　統一漢字の場合IVSをつけてもいいの？
IVS付けてもいいときは、どの字体を使うの？
IVS付けたらダメときは、字体の違いをどう解消するの？

687 ：

へー、影響無いのかー。
＞では、U+6674に統合されている「�ﾘ」と「晴」とを、
＞どうしても使い分けたい人は、どうすればいいのでしょう。
>>685 は使い分けたくないんだろうな。だったら影響ないし。

688 ：

>>684
1-11-69と1-11-70でラウンドトリップが崩壊してる
って例を以前安岡センセイが書いてた
↓の図16あたり
http://itpro.nikkeibp.co.jp/article/COLUMN/20061221/257533/

689 ：

文盲が多いな
「我々が扱いたい日本の文字はx0213以外の文字もあるため
CJKの問題を考慮する必要があります」って言えばいいだけだろ
誰もCJK統合に問題がないなんて言ってないし

690 ：

officeって文字コードはsjisで保存してるんでしょうか？
sjisのテキストもユニコードのテキストもどちらも
貼り付けできるので不思議です。

691 ：

どのバージョンからかは忘れたけど、保存はUTF-8じゃなかったかな。
でもそれと、貼り付けできることとは何の因果関係もないが。

692 ：

1990年ごろから内部はUnicodeだよ。
その作業をしたのは日本人。

693 ：

Office 1 の頃から？
ちょっと信じられんが。

694 ：

受け取る側は UTF-16 でも MBCS でもどちらでも受け取れる。
たとえソフトが片方のエンコードでしか貼り付けなくても。

695 ：

>>689
「神」と「�~」はどうするのさ
JIS X 0213の問題でもあり、CJKの問題でもあるだろ

696 ：

文盲がいるな
コンピューターで文字を扱う際の包摂等の問題だから
「Unicodeで日本語版を扱う時の問題」としては不適切ってだけだろ
だれも包摂に問題が無いなんて言ってないし

697 ：

すまない文盲以外は帰ってくれないか

698 ：

(≧ω≦)ノシ

699 ：

>>693
Unicode対応はWord97からのはず

700 ：

梵字の正式な提案書来たか

701 ：

変体仮名はいつのっかるんだろうねえ。

702 ：

変体仮名は異体字の切り分けと名付けにわかりやすい基準を用意できるんだろうか

703 ：

ようやく梵字がテキストエディタで編集できるようになるのか。

704 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_05.html
安岡センセイ互換漢字とIVSを同列に紹介

705 ：

ようやく日本の文字っぽくはなってきた

706 ：

http://slashdot.jp/%7Eyasuoka/journal/553806
＞U+20F96は誰が提案したのか

707 ：

変体仮名は汎用電子の絡みでいずれWG2にも来そうな気がするけど
すんなりとは符号化されないんだろうな

708 ：

>>706
なんだか言い訳がましいな

709 ：

TCAは形式的には中国の代表ということになってるのか

710 ：

http://slashdot.jp/%7Eyasuoka/journal/553978
この入管外字f10eってCJK Extension E候補00437？

711 ：

有効なUnicodeのコードポイントかどうかを判定する必要に迫られているのですが、
どう調べたらいいですかね。コードポイントのデータベースとか、APIとか。
自分が受け取ったHTMLに文字参照（数値参照）がたくさん含まれているんだけど
どうもデタラメなコードポイントを含んでいるようで、それをチェックしたいのですが。
あ、HTMLから文字参照を抜き出すとかその辺はできてるんですが、数値の判定を
どうするかということです。
まあ実際にはいろんな次元のデタラメがある（たとえばUnicode的には正当でも
文書内容的におかしいとか）わけですが、今はUnicodeのレベルでのチェックを
必要としております。

712 ：

自分が使いたい文字の一覧を作っておけばいいだろう。
君が何を有効としたいかは誰にもわからないわけだし。

713 ：

\p{Cn}

714 ：

>>711
割当済コードポイントの一覧が欲しいってことならこれ。
ttp://www.unicode.org/Public/6.1.0/ucd/UnicodeData.txt

715 ：

どうも>>711です。
>>712 とりあえず最低限のチェックをしたいなと思って。
>>713 perlですね。なるほど。
>>714 なるほど。
というわけで>>713と>>714をまず試してみようかと思います。どうもありがとうございます。

716 ：

>>715
シフトJISだけでいいなら
Unicodeコンソーシアムのcp932を基に一覧作るとか

717 ：

htmlのソースにどの文字コード表が使われてるか
ってことじゃあ
utf-8で書いてあるところの方が少ないような、html

718 ：

perl撲滅するついでにHTML完全UTF-8化も完了した

719 ：

>>716
HTMLの話でcp932なんて出されると。「shift_jisって何だっけ」問題を
思い出すじゃないか...
そこらへんにこだわっていた時期が、俺にもありましたw

720 ：

結局Encoding StandardでWebブラウザにとってshift_jisは単なるcp932の別名
ってことになった

721 ：

x-sjis

722 ：

x-sjisも正式なshift_jisのエイリアスになってたな
あとどうせそういうことになるのは目に見えてるせいか
とうとうRFC 6648で"X-"の使用自体が廃止されてしまった

723 ：

互換漢字用IVSはMark Davis巻き込んだか。

724 ：

小書きコは投票から外されちゃったかー
日本が押し返したかな

725 ：

あっても別にいいと思うんだがなあ

726 ：

AJ1-6をUnicodeへ紐付する作業もこれで一段落か

727 ：

盆休みに出てたみたい
http://www.taishukan.co.jp/kokugo/webkoku/series003_06.html

728 ：

DIS 10646第1版
ttp://ja.wikipedia.org/wiki/DIS_10646
ってもう少し詳しい情報載ってるところある？

729 ：

>>728
そのページの脚注や参考文献にある本にかなり載っている。
10646のDISからISにかけての漢字統合の話なら、中国の1980年代後半の「語文
建設」とか「文字改革」あたりの雑誌を漁ればありそう。
というか、DP→DIS→IS というのはISO時代の呼び方で、JTC1の時は
FCD→FDIS→ISだったけど、最近の体制の変更で、呼び方が
DIS→FDIS→ISに変わったのでこのWikipediaのページはページ名自体が
微妙な気が…

730 ：

一応『文字符号の歴史−欧米と日本編−』には目を通してるんだけど、例えば
DIS 10646第1版の場合にこれまでのASCIIの範囲の文字を表わすのは
20202020 〜 2020207F ってことでいいの？
改行コードは 2020200A になるの？それとも 0000000A になるの？
教えてえろいひと

731 ：

ISO 646 IRV (というかASCII)は、そのまま20202020〜2020207Eに収録で、
コントロールコードは、全部、別の規格で吸収するつもりだったはず。

732 ：

例えばこれまでの通信機器がそのまま使えるように改行コードは0A(1バイト)
のままってこと？
あと『文字符号の歴史−欧米と日本編−』によれば日本のコードは
20 4x yy yy のところに割り当てようとしてた見たいだけど、4x の
ところと yy yy の部分はどう使われるの？
例えば
20 40 21-7E 21-7E は JIS C 6226:1978
20 41 21-7E 21-7E は JIS C 6226:1983
20 41 21-7E 21-7E は JIS X 0208:1990
・・・って具合？
あと半角カタカナ JIS X 0201 はサポートされるの？されないの？

733 ：

ttp://www.itscj.ipsj.or.jp/senmon/11sen/sc02.html
>JIS X0221については前回の改正から5年が経過するということで，
>2012年度は第3版の内容に基づいた改正を検討することになっている．

734 ：

10646じゃなくJIS X 0221を参照している規格ってあるのかな

735 ：

>>734
JIS X 0213

736 ：

>>733
やっと日本文字部分レパートリが本体に入るのか

737 ：

(´‥∀‥`)ほほう

738 ：

すみません、
日本&中国（簡体）の漢字を部首毎にUnicodeのコードポイントでさらう必要が
あるんですが、Unicodeの中の割当ってどの程度部首毎に並んでるんでしたっけ?
extension B 以降 (U+20000〜） なども。
できれば部首毎のコードポイントのリストがあると助かりますが...

739 ：

http://rtk.art.coocan.jp/cjk/rads/index.html

740 ：

>>734
JIS XMLとか

741 ：

>>739
それ便利よね

742 ：

>>739
おお素晴らしい! ありがとうございます。
しかし... 今さらながら字を見ていくと、繁体の文字で偏を簡体にした文字が
大量にあるんですねえ。そりゃあコードポイントが大量にいるわなと。
異体字じゃ駄目... なんでしょうねw

743 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_07.html
第7回でやっとUTF-8登場

744 ：

最後のとこは最低でも8バイトって書き方にしといてほしかったな

745 ：

文字コードと関係ないが、
安岡はバイトオーダーについて
少しは勉強した方がいい。

746 ：

そんなの本筋と関係ないから端折ってるだけだろ

747 ：

TRON信者か？

748 ：

>>713
化石レスなんですがperlが対応しているUnicodeのバージョンって調べられますかね?
自分の環境でやったらどうもCJK Extension C/D の文字が微妙な感じなので。

749 ：

>>748
データベースのバージョンなら
perl -MUnicode::UCD -E 'say Unicode::UCD::UnicodeVersion();'
かな

750 ：

>>749
自分の環境でやったら5.1.0と出ました。なるほど納得、という感じです。
的確なお答えに感謝です。

751 ：

さて

752 ：

>>745
武雄市図書館と喧嘩させとけよ

753 ：

ICUのAPIで偏とか画数の情報は取り出せるでしょうか。

754 ：

Unicodeデータベースの部首画数って(kRSJapaneseを除くと)中国語の字形基準だから
あまりアテにならない。kRSAdobe_Japan1_6が入って多少はマシにはなったが。
せっかく税金かけて作ったんだからこれも使ってやれよ
http://ossipedia.ipa.go.jp/ipamjfont/mjmojiichiran/index.html

755 ：

ossipediaをいつも「おっしペディア」と読んでしまって和む

756 ：

おしりペディア

757 ：

強行貫通

758 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_08.html
第8回が出てた。

759 ：

>そう、IVSを使うのです。
といいつつこのページではIVSを使わずフォントを指定することで対応している

760 ：

二枚舌だあ

761 ：

フォント指定を上書きしてたので気づかなかった

762 ：

別にIVSとフォント指定は排他じゃないんだから
(むしろ現状フォントを指定しないと使いものにならない)
両方やればいいのに

763 ：

いつからここはその連載のヲチスレに

764 ：

フォントのことを書くと怒られます

765 ：

ふぉんとに怒られます

766 ：

さて 気を取り直して。

767 ：

話題ないっすなあ
日本に関係ある字が提案されてこないせいもあるんだろうけど

768 ：

ないっすなあ

769 ：

あるTrueTypeフォントを渡されて「これにはAJ1-6相当のグリフが入ってる。確認して。」
と言われたんだけど、どうしたらいいですか?

770 ：

その種のフォントは、グリフ名がAJ1のCIDを示唆するものになっていることが
多いのでまずそこを確認。

771 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_09.html
住基統一文字の数が「21166字」って書いてあるんだけどホント？
21039字だと思うんだが。

772 ：

(´･ω･｀)知らんがな
少しずつ追加されて数が増えてても不思議はないし

773 ：

差分を見たいわ

774 ：

127文字違いとか意味深だ。

775 ：

もうひと文字増えていたらオーバーフローの危機だったわけだ。

776 ：

nushuの提案(改)が来たか
1b1xxに入る予定だから、日本はkana supplementブロックが
残り254でいいのか早めに答えを出さないとな

777 ：

どうせ足りなくなったらkana supplement extendedとか
kana supplement-Bとか何とか追加されるまでだろ

778 ：

デタラメすぎてどこから突っ込んだらいいのやら
http://www.m-bsys.com/character-code/utf-48

779 ：

10/5の文字情報検討WGで変体仮名を取り上げるらしいから
結論が出れば必要なコードポイントの概数もつかめるかも

780 ：

それは朗報。早くのっけておくれ。

781 ：

そういやUTF-8って同じコードポイントを冗長表現できるけど
誰も、適当に加減算して重複が出ないような定義にしようって言い出さなかったのかな

782 ：

>>779
変体仮名が採用されたとすると、NKFC/NFKDで普通の仮名に変換されるのかな。

783 ：

これっすな
ttp://ossipedia.ipa.go.jp/article/54/

784 ：

>>779
たぶん168字

785 ：

住基かなだっけ
あのデザインのまま上がってきたらちょっとあれだけど

786 ：

>>781
不正と見なされるようになってる

787 ：

>>785
知らないんだけどなんか残念な字形なの？

788 ：

>>786
最初からそうじゃなかったでしょ。
つーか最初からそうするなら(UTF-16のように)そもそも重複が生じないように
設計すればよかったって話じゃないの

789 ：

http://engineer.typemag.jp/trend/2012/10/fukuyuki-html5.php
ケータイ絵文字でさんざんカオスをもたらした挙句Googleに尻ぬぐいしてもらった
日本のほうが標準化がうまいとか面白いジョークだな

790 ：

>>788
演算コストを減らしたかったんでしょ。
UTF-1は重複が出ないようになっていたけど、乗算除算を多用していて演算コストがかかるために破棄され、
新たにUTF-8を作ったんだし。

791 ：

>>789
その人にはそう見えたんでしょ。
こちとら83JISの時代から一部のメーカーの傲慢に振り回されてきたっての。

792 ：

>789
GoogleはAndroidを売るために絵文字を統一したんだよ
日本のガラケーを滅亡させるために仕組んだTPPなの
尻拭いとか日本人の便利のためとか親切心は全く無い

793 ：

俺は絵文字がウニコードに入ったのは今でも微妙と思ってるクチだから、絵文字に関してはあれだが
他の部分でもその人は典型的な「他人と違う視点でもの見れる俺カコイイ」だな
自分的にいい思いつきが浮かんだら嘘を混ぜてでも正当化するタイプ
人のふり見て我がふり直せだな

794 ：

>789
トーハン日販まで読んだ

795 ：

ぼやき漫才みたいな芸風の「総裁」らしい。
これは取り上げた時点で負けなんじゃないのか？

796 ：

ヨーロッパは船頭多くして…をよくやってるような気がするんだがな。

797 ：

日本が加わっても携帯電話の無線部、ATM、HD DVD/Blu-rayとか、
まとまらない時はまとまらないって。

798 ：

>>790
加算一回増えるのと、冗長表現を弾くチェック入れるのとだと後者が重いし…

799 ：

絵文字といえば某連載はその後いかに

800 ：

dankogai

801 ：

>>798
いやいや。
君のコードを見せてみなよ。

802 ：

Hangulのcompose/decomposeなんて除算してるぞ。あんなんでいいのか?
まあ俺は使わないからいいけど。

803 ：

>>801
いやいやもなにも加算と分岐なら分岐が重いに決まってるだろ

804 ：

いつのCPUだよw
80386か？

805 ：

分岐予測は外れるかもしれないし、投機実行はそれだけ資源を必要とする。
加算に比べて分岐が重い処理であることに変わりはない。

806 ：

顔真っ赤だよ

807 ：

別に間違ってないじゃん

808 ：

加算が一番単純だよね。TTLでもできちゃう。

809 ：

>>806 おまえが鏡を見てるんだろw

810 ：

今は加算も分岐も１クロック。

811 ：

>>796 あいつら同一民族ですら一つの国で暮らせないんだぜ

812 ：

チョンの話かとおもたw

813 ：

日本民族は島国に閉じこもっていることしかできないって自慢になるの?

814 ：

当初は分岐など必要ない(重複してたっていいじゃない)と考えてたんだから
1よりゼロのほうが小さいだろ。

815 ：

>810
ビットシフトは？

816 ：

>>810
分岐ってのは減算+条件ジャンプ相当の処理がいるんだぞ

817 ：

>>816
てきとーこいてるやつにマジレスなんかするだけ無駄だよ

818 ：

>>815
http://ocw.ouj.ac.jp/tv/1542109/11.html
23:47 〜

819 ：

>>798
この辺から不正とされてる事をわざわざチェックすると処理が重いとか、
おかしな事を言い出してるから無視すれば良いよ。
話混ぜっ返して荒らしたいだけだろ。

820 ：

>>819
おかしなことを言ってるのはどっちだよ
有名なセキュリティホールじゃないか…

821 ：

普通にcode pointで比較すれば冗長表現だろうが関係無いだろ。
バイナリ比較とか本来ダメな事をやろうとするから、逆に無駄なチェックが必要になる。

822 ：

>>821
それで統一できる環境なら幸せなんだろうけど名
ってかそれで統一できる環境ならUTF-8自体要らないか

823 ：

このままユニコードを拡張に拡張を重ねてみんなが幸せになれるかどうかを知りたい。

824 ：

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

825 ：

WindowsはUnicodeをサポートしてますが、
符号点が定義されている文字って全部表示出来るんでしょうか？
Windowsにおける外字ってどの範囲を指すのかなと気になって質問しました。
XPの場合、
Windows-31jの範囲以外が外字？
Unicode3.0の範囲以外が外字？
ここでの外字はその環境で表示出来ない文字、という定義で書いています。

826 ：

フォントのダウンロードが(ほぼ)自動だから
もう Windows 7 以降なら全部表示可能な気がする

827 ：

htmlやメールヘッダのcharsetって文字集合のことではないんですよね
charsetは符号化方式なのですか

828 ：

はい

829 ：

ISO 646やISO 8859やISO 2022に、符号化スキームを固定した頭で考えると、
文字集合の切り替えだけで済むのでそういう用語になってしまったと思われる。
今はそれを追従する形で公式な用法として認めている。ただし注釈を加えて。
つ http://www.cam.hi-ho.ne.jp/mendoxi/rfc/rfc2277j.html
IETF Policy on Character Sets and Languages
(文字集合と言語に関する IETF の方針)
> 3. 用語の定義
>
> この文書では、「charset」という用語を、符号化文字集合と文字符号化方式の組み合わせのような、
> オクテット連続を文字連続へ写像するための規則の集合という意味で用いる。
> これはまた、MIME の "charset=" パラメーターにおける識別子として使用されるものであり、
> IANA charset レジストリー [REG] に登録されている。
> (ISO などの他の標準化団体によって使用される用語ではないということに注意。)
>
> 「符号化文字集合」(coded character set) という用語の定義についてはワークショップ報告を参照されたい。

830 ：

まあ、そう定義するしかないわな。

831 ：

全部が全部で統一しようと思ったら
間違いなくどこかのグループにキチガイが居るからまとまらないもんな

832 ：

海外のIMEみたいなのがどうなってるのか知りたい。

833 ：

入れてみればいいのに

834 ：

unicodeでハングルの領域が邪魔すぎるんだけど

835 ：

領域は個人で勝手に割り当てられるわけでも無し邪魔になるような要素無い
でもfontセルフコンパイルで容量喰って邪魔臭いハングル抜きは世界常識

836 ：

Jamoだけで機能するのに

837 ：

JIS X 0221の改訂作業始まったのか
この機会にあのガチガチな権利保護やめりゃいいのに

838 ：

JIS全部の問題だからねぇ

839 ：

http://slashdot.jp/journal/557335/
安岡孝一大先生が依拠しようとする 台湾キャラ
現行のU+2051C(T6-353E)の字影は このキャラとしては風前のともし火、
いつまでここにあるか、、

840 ：

CNSの6-353Eと戸籍017290か
これ大漢和1480の作りそこないだろ

841 ：

真言宗総本山からWG2へ梵字符号化に関しての投稿ってなんか凄いな。

842 ：

豆腐代が苦

843 ：

MZCで文字コードの問題が解決する！！(Windows限定だけど)

844 ：

隔離スレ"UnicodeとUTF-8の違いは？"がすぐ落ちるのは何故？

845 ：

テンプレがないから

846 ：

でたらめかくな！

847 ：

1 名前：デフォルトの名無しさん [sage]： 2007/04/30(月) 20:02:37
ビッグインディアンとかなんとかかんとか
◆前スレ
http://toro.2ch.net/test/read.cgi/tech/1342963035/
◆過去スレ
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 (実質3)
http://toro.2ch.net/test/read.cgi/tech/1291075205/
UnicodeとUTF-8の違い4(インディアン隔離スレ)
http://toro.2ch.net/test/read.cgi/tech/1342963035/

ttp://toro.2ch.net/test/read.cgi/tech/1350688952/1
http://logsouko.com/t/toro/tech/1350688952/ UnicodeとUTF-8の違いは？5

848 ：

それ、テンプレじゃなくて過去ログ載せてるだけじゃん
テンプレがないと今はすぐ落ちる仕様だから

849 ：

アイちゃんをちゃんと招喚しなかったからだよ

850 ：

隔離スレならここにあるじゃん。
文字コードの種類は何故複数あるのでしょうか？
http://toro.2ch.net/test/read.cgi/tech/1093251312/

851 ：

http://www.taishukan.co.jp/kokugo/webkoku/series003_11.html
ついに絵文字登場

852 ：

国旗ひどす

853 ：

こんな仕様じゃ使えないわｗ

854 ：

西暦文字を新設して国旗文字の後に付け足すとかでもないと使えないな

855 ：

リンク先のPDFにも書いてあるけど、あれは国旗用じゃなくて国名コード用
それを実装によっては国旗として表示するかもね、というのが10646のスタンス
国旗用ってことにすると、そこに書いてあるような問題が発生するから

856 ：

だけど例えば、
南北朝鮮が統一したり、
統一後にまた分裂したりしたら、
ミャンマー国旗と同じ問題が発生しそう。

857 ：

いや、国旗絵文字はISO 3166に依存してるから、
問題が大きくなるも丸く収まるも3166でどう扱われるか次第。

858 ：

>>857
違うだろ
文字というのは意味と形の両方がともなってはじめて文字なのに、意味しか定義してないというのが問題の本質だろ。
ISOも所詮は意味の部分でしかない。

859 ：

意味しか定義されていない文字もどきなんてUnicode内にいくらでもあるじゃん。
何を今さら

860 ：

というか表示を定義しようとすると文字コード関係者で手に負える範囲じゃなくなるでしょ。
>>855のいう「実装によっては国旗として表示するかもね」、というのは
ややこしい問題から逃げてるのは間違いないけれど、
これよりいい実装方法が現実的な範囲に存在するとは思えない。
恨むなら、そもそもテキトーな実装をした携帯キャリアを恨め。

861 ：

国名二文字コードや三文字コードを�_の用に表す方法がある。

862 ：

>>859
今まで問題がなかったとでも？

863 ：

あまりにも遍在しすぎて問題として注目するに当たらない、ってことでしょう。

864 ：

>>863
なら問題はunicode側にあって、ISO3166は関係ないという主張の反論にはならんないんでは。

865 ：

>>864
・Unicodeでは類似例がありふれているので、たとえ悪い状況 (=複数の国旗デザインを区別できない) になっても大きな問題ではない。
・しかし、>>856の問題については悪い状況になるもならないも3166次第。
例えば今は韓国=KR、北朝鮮=KPだけど、
・統一朝鮮がKRを引き継いだ場合→Unicodeで韓国国旗と統一国旗の区別がつけられない (悪い状況)
・統一朝鮮がKPを引き継いだ場合→Unicodeで朝鮮国旗と統一国旗の区別がつけられない (悪い状況)
・統一朝鮮に新しいコード (例えばKO) を割り当て、KR/KPは3166-3に移動→コード重複がないので国旗問題が起きない。
つまり「そもそも問題が起きるか起きないかは3166次第だけど、起きたとしてもUnicodeでは別に珍しくないからいいよね。」ってこと。

866 ：

>別に珍しくはないからいいよね
いや、よくはないだろｗ
あと3166次第なのは確かだけど、3166に丸投げするような仕様がそもそも変っていう話もあるしね

867 ：

そして>>860に戻る。

868 ：

西暦年付加だと、同じ年にころころ変わった例に対応できないしなあ。ほんといい方法が思いつかない。

869 ：

ISOでも抱えきれないものを、Unicodeコンソーシアムに持ってきたら即死だろw

870 ：

領土問題にかかわると、ろくな事にならない

871 ：

IVSでなんとかしろ

872 ：

国旗のデザイン1枚ごとに1文字ずつ割り当てればこの問題は「一応」解決する。
あとは実装の問題なので、文字コードがどうこうできる話じゃない。

873 ：

日の丸は中心にある現行版と
微妙に旗竿寄りの明治版の2種類を収録してもらうお
多分日常的に使うptでは区別付かないだろうけど

874 ：

国旗化して表示するのは完全に実装依存だからUnicodeの知ったこっちゃないだろ。
ドメイン名から国旗表示するネットクライアントとかよくあるけど、この表示が
おかしいからってUnicodeに文句言われても困る。

875 ：

ISO3166は別の国への再割り当てが既に起きてるわけだしどうしようもないな

876 ：

いやしかし盛り上がるもんですな

877 ：

モルドヴァとかパラグアイの国旗には表面と裏面があるんだが
こういうのはどうするのだ

878 ：

何だそれｗいろいろあるんだな。

879 ：

>>877
当然表だろw

880 ：

>>877
アニメーションで両方描く

881 ：

>>873 の言っているように
かつては日本の国旗にも表裏があったのだよ

882 ：

それ竿に取り付ける分ずらしてただけだろ

883 ：

たんに表裏で鏡像になってるだけのものは>>877とは意味が違うでしょ。

884 ：

アラブの一部の国を除いて旗竿は左側が標準だということで。

885 ：

俺の竿も左側に傾いてる

886 ：

>>874
そもそも携帯絵文字の国旗をUNICODEに取り込むときにコードポイントけちるために
国名コードで表現する変な方法思いついただけちゃうんか？
それで実装依存だから関係ないとかありえんだろ。

887 ：

ケチとかじゃなくて最初から政治問題回避目的。
予備知識ゼロならまずこれを読め。
http://japan.cnet.com/sp/column_emojipandora/
国旗関係の経緯だけなら↓このあたり。
http://japan.cnet.com/sp/column_emojipandora/20394318/4/

888 ：

>>887
それ読んでも本質が見抜けない奴は黙ってろ。

889 ：

888ゲットおめ！
おめでたい記念にその本質をきっちり説明していってくれ。本人以外が理解できるようにな。

890 ：

ポエムとかかんべん

891 ：

>>888
本質はGoogleが日本のガラケー市場潰しのために絵文字を統一したと

892 ：

どんな薄手の参入障壁だよ

893 ：

ぶっつぶしてくれてむしろ大歓迎だわ

894 ：

横須賀通研のガラケー開発はプログラマの２０３高地だった。
毎日のように死人が出る文字通りのデスマーチ。
日本のソフトウェア業界の未来が縊死していった元凶だ。

895 ：

何でケータイってあんなにTRON系ばっかり使われてたんだろうな
Linuxはともかく、NetBSDそのまま使おうとか、そういう意見は出なかったんだろうか

896 ：

keyword
東大
御用学者
原発もTRON仕様にしとけば安全だったのに

897 ：

すんません、
ドル記号って確か本来縦棒が二本じゃないですか。なのに昨今のコンピュータ上の
では大抵一本しか線がない。でもこれに文句を付けている人はあまりみかけない。
ということはこれに関しては「こまけーことは気にするな」でいいということでしょうか。
実は仕事で中国系のフォントを扱っていたら円記号のデザインが横棒一本
なのがあって、この記号はおかしいというバグを処理する羽目になったのだけど、
これも「こまけーことは気にするな」でいいんでしょうか。

898 ：

U+1F4B2

899 ：

というか本来2本、ってのは事実なのか？

900 ：

ドル記号は縦棒一本と二本のグリフが存在する。
円記号は、日本円は常に横線二本、人民元は一本か二本。
ってWikipediaに載ってた。

901 ：

Yにスジ１本はやっぱりダメなのか

902 ：

ユーロ記号はわりときっちり形状が定義されていた気がする。
角度とか。

903 ：

そういやJISマークはどうなったんだろ。

904 ：

＞JISマーク
結局のところ、誰かが実用してるわけじゃないものは議論が深まらず結論も出ずに忘れ去られるという好例か

905 ：

本屋に行って裏表紙を眺めてみるといいよ。
横一本の円記号で値段が書いてあるものは少なくない。

906 ：

漢字に関してはうるさいくせに他の文字や記号類は適当だからなあ

907 ：

>>905
うわーほんとだ。言われるまで気が付かなかった（自分が持ってる本で確認）。
結構びっくり。

908 ：

JIS X9001を見ろよ

909 ：

おれが見るの？

910 ：

昔のタイプライターとかだと
Y打ってBSして-だっけ

911 ：

そういうのいいなあ

912 ：

>>905
『ユニコード戦記』は横線2本

913 ：

書体にOCR-Bが使われると横棒一本になる。

914 ：

>>913
ああそういうことか。
本の裏のバーコードやISBNに並んでる価格の￥が横一本なのが多いのは。

915 ：

同じ内容がバーコードで印刷されてるのに
そこまでOCR記号使うなって気もするけどな

916 ：

凝りまくったオールドスタイルの数字とかが並んでてもそれはそれでイヤだろ。
あくまで可読性重視、となるとOCRBは別に悪くない

917 ：

JAN規格で目視可能数字にOCR-Bのようなフォントを使うように指示されているらしい

918 ：

にゃらるほど

919 ：

>>910
そもそも0と1がなかったりしたな。

920 ：

lOllOllO

921 ：2012/11/01

マルイ？