文字コード総合スレ Part12
■ このスレッドは過去ログ倉庫に格納されています
■これまでに行われた議論
・Windows 10のコマンドプロンプトでUTF-8を使用する場合chcp 65001で切替可能。日本語入力等も可
・Shift JIS や EUC-JP や Big5 や GB なんかをUnicode に変換してしまうと、ラウンドトリップは保証されるか
・単一情報をソースの文字コード(or 言語)情報なしに元に戻したい （統計的に文字の出現確率なんかを調べる）
・0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、逆変換時に結果が変わるの問題
・丸付き数字は機種依存文字か？。Unicodeでは機種依存文字ではない。
・Safari文字コード変換のバグは
・Microsoft文字コード変換のバグは
・U+31F0..U+31FF（アイヌ語表記用小書きカタカナ）が入ってない件
・文字化けに強いishフォーマットでエロ画像を交換する場合、ssより、s7のほうが化けにくい
・SJISとUNICODEの判別はどのようにすればいいですか？BOM。無ければ、統計判断。 ライブラリを使うが吉
・ところでケータイのUnicode対応度って実際どうよ？ → 対応済み
・TwitterのWebインターフェイスからだと、サロゲートペアは2文字としてカウント。140字打てない 。
・Unicode 5.2で追加されたUnicodeSMP(第1面)、Unicode 5.1で未定義だったSMPのコードポイントや第15、第16面が
Windows7では表示されない。 → 和田研細丸ゴシック2004ARIBはARIB外字を含んでいる。
・元号を安置する場所はJIS第三で確保済み。ウニコードでブロックを確保は政治力次第。
・元号は個人名ではない。特定の時間軸基準に数える年号を漢字で指す文字。
陛下の崩御後必ずしも元号が追号になるわけではない。むしろ違う場合が多い。昭和54年法律43号の元号法参照。
・文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコード。 → ヌル1バイトが貴重な時代からの負の遺産。
・Windows7出荷時に未定義だったコードポイントはフォント入れても豆腐になる。Unicode5.2は表示しない。欝だ。
・Unicode6ドラフトでPILE_OF_POO文字確定。ウニコードがもはやイミフ。SerifとSans-Serifで幅に違いは出る？
・Unicodeのzipが文字化けする。→Windows 7は公式パッチで対応可能。8以降は標準対応 ・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(U+6076)」に統一。口偏＋恶(U+6076)は普通に使われているがUnicodeにはない
・日本人のニーズが満たせないのも確かなので原規格分離（中国では「曾→曽」は簡体字と繁体字の違いとはみなされていないとか）
・UNICODEを扱うプログラムはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろって→YES
・UnicodeとUTF-8の違いは？
・日本のCJK Ext.D Submissionに{魚針}が含まれてる件
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。
中国ではってレベルじゃねーぞ。
・Unicodeは言語情報を直接扱わない。 多言語の混在表現は（unicodeでは）できないか
・Unicode文字列リストを各国言語を考慮してソートしたいんですが → ムリです。
・Unicodeサニタイズが面倒になるのか ■単語一覧
・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とか。 oo|o|o|||o|o|o|o|||ooo|oo|o|ooooo||o||o|oooo|||o||||o|oo|o|||o|o|o|o|o|oo
ooo||o|o|||||||o|o||oo|ooo||ooo|o||oooo|oo|o||oo|||ooo||||oo||ooooo||oo||
oo||ooo|o||o||ooooo|oo|oo|o|o|||o|||||o|o|oo||oo|ooo||o||||o|o||o||o|oooo
ooo|||||o|oo|||ooo|o|oo|||||ooooooooooo|||ooo|||o||||oo|oo|||ooo|o||oo|||
ooooo|ooo||o|oo|||oooo|oo|||||ooooo||o|||oo|||o|o|o|o||||o|||||oo|oo|oo|o
||o|oo||oooooo||o|oo||o|||ooo||oo||oo||ooo|o|o|oo|||||o|o|o|||oooooo|o|||
||o||||o|oo|||o||oo||ooo|ooo|oo|||oo|o|||o|||oo|oo|oo|o|||||oooo||ooooooo
oo|oo|||||oo|||||o|oo|o||oo|||o|ooo||o|oo|||o||ooooooooo|ooooo|o|||o||o||
o|oo|o||o|oo|oo|oo|o|o|o|oo|o||||oo|oo||ooo|ooooo||||o|oo|oo|||o|||oo||||
|o||||o|||oo|o||o||oo||oooo|oo|o||oooo|oo|||||||oo|o|o|ooo|oooo||||ooo|oo
ooooo|||oo||oo|o||o|ooooooo||||||o|o||o|o|ooo||oo||o||oooo||oo|oo|||o||||
|o|||oo||o||o|o|||o||oooo|oo|||o||oo|ooooo|o|||o|||oo|ooo|ooo|||oo||oo|oo
||ooo|||ooo|||o|ooooo||||oo|||||oo||ooo|o||o||ooo|oo||oo|oo|||o|o|o|oooo|
|||oo|o||o||o|ooooooooo|o|o|||||oo|o||ooo|o||o|oo||||oo|o||o||o|ooo|||ooo
oooo|||ooooo||o||oo|ooo|||||o|oo|||o||o||ooo|ooo||oo||oo||o||o|oo|o|oo|||
oooooo||||oo|o||oo|||o|ooooo||ooo||||||oooo|||||oo||||ooo|||o|o|o|o||oooo
o|o|o|oo|o|oooo|o|ooo||oo|oo||||||||ooo|o||o||oo||o|||ooo|o||oo||oo||oo|o
oo||||oooooo|o||o|o|oooo||o|||oo|ooo|o|o|o|ooo||o|o|oo|o|||o|o|o|||o||o||
oo|oooo|oo|o|oo||||oo|||o||o|o||o||o|oooo|o||||o|o||o|ooooo||ooo||||||ooo
oo||o|oo||||oo|||||||||ooo|oo|||oo||oooo||o|o|o||||ooooooooo|oo|||oo|oo|o
o|o|||||o|o|||oo|oo|o|||o|o|||oo|oo||ooo|oo|oo||oooo||||o||||ooooooo||ooo
o|||||oo|o|||oo|ooooo|ooooo||o||oo||ooo||||oo|oooo||||oo|oooo||oo|o||||||
|oo|oo|||||oooooo||||ooo|||||ooo|oo|o|||oo|o|o|||o||ooo||ooo|o|oo|||o|ooo
ooooo|o|oo||o||||oo||oo|o|ooo||o|o|o|||ooo||||||o||oo|ooo||o|o||oo|o||ooo
|oo|ooooo||o||o|o|oo|oo|||ooo||||o|oo|oo|o||||o|oo|||o||o|||||ooooo|o|ooo
|o||ooooooo|||oo|ooo|ooo||||ooo||oo||ooo|||||||ooo|o|ooooo|||||o|o|o|||o| こんなスレあったんだ
Windowsのフォントって、どのフォントがどのコード体系とか字体を使っている。
などを纏めているところってある？？ ちょっと考えれば分かるようなことをなぜ聞くんだろう。 ちょっと考えれば解るなんてすごい人だな。
ちょっと書いてみ nkf - Network Kanji Filter Fork
https://ja.osdn.net/projects/nkf/scm/git/nkf/
v2.1.5
2018-12-15 18:19:02 >やはり頭悪いのはunicodeと符号化を混同してる
ここは同意
>2つ以上のｵｸﾃｯﾄを使う符号単位で
>BOM入れないﾔﾂは池沼だからな
これは嘘 低学歴知恵遅れには
ｴﾝﾃﾞｨｱﾝの概念がないのが
よおく分かったわ CPUの内部形式とデータには何の関係もない
現にネットワークデータはCPUとは無関係の並びになってる うわあ。。。
ﾏｼﾞでいってんの
こういうﾏｼﾞもんの低学歴がこの板で
はば利かせてるのがよく分かるわ
ﾏｼﾞで頭悪いことを
ﾊｼﾞもなくなんの躊躇もなくいうからな
ﾌﾟﾛｸﾞﾗﾑで
いちいｴﾝﾃﾞｨｱﾝ変換してんのすら
しらないらしいわ
当然Unicodeのｴﾝｺｰﾄﾞ方法にも
ﾋﾞｯｸﾞｴﾃﾞｨｱﾝとﾘﾄﾙｴﾝﾃﾞｨｱﾝがある もうね低学歴すぎてﾔﾊﾞｲって
ちなみﾈｯﾄﾜｰｸでﾃﾞｰﾀを交換するときは
暗黙で基本はﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝになってる
常識だからなｺﾚ 低学歴知恵遅れって
なんでものすごい頭悪いことを
自信満々にいうわけ？ ちなみipｱﾄﾞﾚｽの並びはﾋﾞｯｸｴﾝﾃﾞｨｱﾝになってる
ﾎﾟｰﾄ番号も当然ﾋﾞｯｸｴﾝﾃﾞｨｱﾝになってる
ｿｹｯﾄ通信のﾌﾟﾛｸﾞﾗﾑ組んだことあるなら
ﾎﾟｰﾄ番号設定するのにhtons（ｺﾚはｵｸﾃｯﾄ2つになる）という関数を使ったことあるﾊｽﾞだ
ちなみにこの関数はﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機なら
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝに変換された値がかえってくる
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの計算機なら
そのままﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの値がかえってくる 最近の子はバイトオーダーなんて意識しないからな
常識としては知っててほしいがけど
低レベルな処理書かなきゃ関係ないし触れることもないだろうから知らなくても困らんな
アラインメントとかパディングとかも同様 >>23
バイトオーダーを意識する機会が減ったのは、xmlやjsonなどテキスト形式でデータ受け渡しすることが多くなったから。
テキスト形式ならバイトオーダーを意識せずに済むし、スクリプト言語で扱うのにも便利。 いやいや、テキストでもUTF16とかUTF32ならめっちゃ意識するやん。 >>24
豆知識、endian とは？
もともとは、卵を丸い方の端 (big end) から割る人々（Big Endians）と尖った方の端から割る人々 (Little Endians) との対立を表したものだった バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。
C/C++で開発している時はコンパイラが自動的に配置・取得してくれるデータを、スクリプト言語では自力でオフセット調整して配置・取得しなければならない。
C/C++より簡単なことが長所だったはずのC#・Java・Perl・Python言語などで、低レベルなオフセット調節を自力で行う必要に迫られる皮肉な状況が起きる。 > バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。
C/C++言語以外ではライブラリが処理してしまうんで意識しないかな
C/C++ライブラリを呼び出すライブラリを作るときは意識するだろうけど、
それって結局C/C++言語で書くんで、あれ？意識するのはC/C++かｗ >>30
例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。 × 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。
○ 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、C/C++並みに低レベルなオフセット調節を自力で行う必要に迫られる。 >>32
うーん、具体的な win32api 名（だけでいいです）を例示してください． >>32
勝手に書き換えないでもらいたい。
C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが、他の言語だとそうはいかないので、アセンブリと同じようなオフセット調節が必要。
SendMessage(WM_COPYDATA)の送受信データの読み書きなど例はいくらでもある。 >>35
>C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが
誰に騙された？ 実行メモリ上はともかく
ファイルやネットワークストリームでLEにするアホいるんか？ エンディアンもさることながら32/64bit整数の幅調節が厄介。
使っている言語が32/64bitどちら向けでビルドされたものなのかによって構造体メンバのアラインメントを適切に処理する必要が出てくる。
言い換えれば、C/C++で作った構造体をバイト列で渡し、C/C++以外の言語でバイト列を構造体に復元する処理が厄介。
単に構造体の64bit整数メンバだけ気を付けるのではダメで、構造体の全メンバのアラインメントそのものが大きく変わりうることに注意する必要がある。 いや、だからさ、その程度までは理解できてるのに、何故「C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが」なんてことを言っちゃうの？
それとアラインメントの話とバイトオーダーの話を混同しないように気を付けた方がいいよ。 C/C++しらないけど、魔法のようにアライメントを
勝手に調整してくれるんじゃないの？想像しただけで Unicodeは普通にﾘﾄﾙｴﾝﾃﾞｨｱﾝもありだ
なんで Byte Order Mark(BOM) がﾌｧｲﾙの先頭に入ってるのか分かってない
Javaﾊﾞｲﾄｺｰﾄﾞのcafe babeみたいな飾りだと思ってんの
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機ばっかりがあるとこで
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝでﾌｧｲﾙを保存する理由なんかないからな
当然、そういったｺﾝﾃﾝﾂﾃﾞｰﾀがHTTPでも流れてくる やっぱりこの板には
ｸﾙｸﾙﾊﾟｰしかいない
そしてそのｸﾙｸﾙﾊﾟｰの声だけがでかい
やっぱりな低学歴知恵遅れは
この板から排除する必要がある
板が正常に機能しない アライメントはふつうコンパイラが適切に調整してくれるよね。
32/64bitで整数サイズの違いでメンバオフセットが変わるってのはアライメントとは別の話。 32bitなら
ちゃんと32bitに詰まるように
ﾒﾝﾊﾞの順序かえる char unko
char foo
int aho
short poi
char baka
int manuke
short boo
char woo
↓
int manuke
----
int aho
----
short poi
short boo
----
char unko
char foo
char baka
char woo
64bitでも考え方は同じ
強制ﾊﾟｯｷﾝｸﾞのｵﾌﾟｼｮﾝ使えるｺﾝﾊﾟｲﾗもある 今問題としてるのはファイルの話だ。
32bitシステムで作られたファイルを64bitシステムに
持ってきたとしてもファイルの内容が変わるわけじゃない
つまりC/C++で32bitでint型で扱っていたからと言って
64bitでもint型で扱ってはいけないということだ ﾊﾞｶがよくやる誤りは
ﾒﾓﾘ境界をまたぐ位置で64bit値を参照したりして
ﾊﾞｽｴﾗｰを起こす
ｼﾘｱﾗｲｽﾞﾃﾞｰﾀを直に参照できると思ってるﾊﾞｶがあとをたたない
CISCの計算機しか使ったことないｻﾙ並の脳みそのﾔﾂがよくやる そんなﾌｧｲﾙ読み込むときに
普通にintなんか使わないからな
そんなことは低学歴知恵遅れしか発想できない
utf16なら16bit単位(uint16_t)
utf32なら32bit単位(uint16_t)
で読み込む
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機で
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝのUnicode読む場合は
16bit単位なら16bit単位でｵｸﾃｯﾄ列の並びを逆転させる
32bit単位なら32bit単位でｵｸﾃｯﾄ列の並びを逆転させる
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機で
ﾘﾄﾙｴﾝﾃﾞｨｱﾝのﾌｧｲﾙ読み込むならｵｸﾃｯﾄ列の並びを逆転させる必要はない
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝならその逆になる
低学歴知恵遅れはこういった基本的な理解がない >>45
C/C++の規格じゃ構造体のメンバは宣言された順にアドレスが増加するよう並べられることになっている。
仮に>>45のような最適化を行うことができる処理系が存在したとしても、一般的と言えるものではない。 one little two little three little endians 自分で並べ替えろって話か。それは勘違いした、すまん。 結局C/C++でもアライメント意識して、自分で適切な型を選択しているってわけさ
他の言語でも一緒。ただし型が違うからバイト数を指定するだけの話 PGならば、楽するためにJava/C#/Python/Perl/Rubyなどを使ってたはずなのに、C++よりめんどくさくなって心が折れそうになる経験を一度はしておいたほうがいい。 いや、C++よりも面倒なことってないから
そんな経験するのは無理だよ やはり低学歴知恵遅れには
C++はむり
ﾚｽみればよく分かる
ﾚｽから頭の悪さがにじみ出てる
低学歴のﾚｽはすぐにわかるわ
残念なことに データのアラインメントはどんな言語を使うにしても気にする必要がある。
しかし、Windows が VisualC++ でビルドされていて、VisualC++
もしくは互換のアラインメントができる言語でアプリを組めば、
気にしなくてもよい、ということだけだろう。 >>57
gcc も同じだよ。64bit版linux gccはwchar_tを16ビットにするか32ビットにするかを切り替えビルドできるからさらに厄介。
構造体を丸ごとダンプしたバイナリデータを同じOS上の別プロセスに渡すのは繊細な注意がいる。 で、なんだっけ？バイナリファイルのデータが
16bitで格納されていようが32bitで格納されていようが
C/C++だったらアライメントを勝手に調整してくれるんだっけｗ
へー、勝手にねー、intで扱ってれば、勝手に調整してくれるんだーｗ intが16bitの組み込み向けプログラムであっても同じコンパイルオプションで作ったモジュール同士ならバイナリの復元はC言語の型キャストだけで可能。
構造体が仕様として公開されている場合、どの言語であれアラインメントを意識した実装が必要になるが、C言語は実装コストが最も低くなる傾向はある。
スクリプト言語を使う人がアラインメントを意識せずにすんでいるのは、ライブラリ実装した人が頑張ってくれた・くれているおかげ。 一方他の言語では、指定したオフセットから何バイト読み込むか指定するだけなのであった C言語は、ヘッダファイル書いた人が頑張ってくれた・くれているおかげ >>61
先生。指定したオフセットから何バイト読み込むか指定する作業は、まさにアセンブラと同レベルの作業じゃありませんか。違いますか、先生。 低学歴知恵遅れ先生はC/C++スレだけじゃなくてここにもくるようになったのか 相変わらず日本語の読解に問題がありそうな奴がいるなぁ。 まず低学歴知恵遅れは
低学歴知恵遅れの自覚がないからな 実行時に使用中のCPUがLEかBEかを判定するプログラムを
Cでサンプル欲しいのですがどこかにありますか？ bool is_bigendian() {
return htons(1) == 1;
} C1制御文字の<128>って多くの文字コードで「PAD」と名付けられているのに
UnicodeでのU+0080はxxxみたいに無名なのって理由ある？ あけましておめでとうございます
2019年は何が起きるかしらね エイプリルフールはまだだけど元号ネタとかあるだろうな
新元号『NEO平成』に決定みたいな 新元号が分からなくてグリフが間に合わないからUnicode 12.1を出すってのは仕方ないけど
新元号の組字のためだけにAdobeJapan1を改訂するってのは馬鹿げてる MS-DOS でのプログラミングではメモリ内の特定のバイトについて
文字の中の何バイト目かを 1 バイトずつ遡って調べるということも
あったようだけど自分ではそういうコードを書いた記憶がない。
いや、もしかしたらあったのかもしれないけど。
EUC-JP の場合は ASCII なバイトかシングルシフトが現れた時点で
確定するようだけど。Unicode の時代になって良かったね。
まあ、そんなようなことを今更思った。あけましておめでとう。 >>72
ありがとう。
なにか事情があったんだろうけど、なんだろうね……。 あけおめ
>>79
大昔のことだけど、SJIS 文字列の末尾から検索するプログラム書いてた時は「SJIS、お前はマジで殺す」という気持ちで一杯でした。
もう二度とあんなことはやりたくない。 ありがとう、まさにそういうことです。
p=strchr( path,'\\'); /* おい *p 、お前は本当に '\\' なのか? 表とかじゃないのか? */ Windows環境ならそこは _mbschr() でしょ。 UnicodeはSJISよりも扱いが複雑だけど
ライブラリが揃ってるからねー
一文字が1バイトだろうと3バイトだろうと
2文字で1文字を表していようが、簡単に一文字判定ができちゃう 複数コードポイントで1文字を表すのって上限って決まってないの？青天井？ UTF-8なら、最大四バイトだけど、そういうことじゃなくて？ >>86
先ずコードポイントの意味を理解してから質問した方が良い Unicodeは1文字の概念も破綻しちゃったね
1文字に見えるやろ？でもこれは11文字なんや
全く意味がわからないｗ 見た目上の1文字は最大4バイト×11文字で44バイトなのかな？ｗ
11文字ってのは今現在存在する最大が11文字ってだけで青天井？
もうライブラリ使ってないと無理だね 世の中にあるすべての文字をコード化してやる！
という意義には賛同していたんですけれども、（主に経済的理由により）絵文字が入った時点で失望してしまいました…
仕切りなおしたほうがいいんじゃないですか？ 仕切りなおしてもBCで絵文字は入ります。
というかもはや絵文字は世界中のスマホ/SNSユーザーに愛用されています。
ここまでくるともはや後戻りはできないのです。 仕切りなおすどころかUnicodeの規格がさらに拡張されて状況悪化するんだろうなあ
Unicode12も来年・・・じゃないやもう今年リリースされる予定のはずだし 絵文字は象形文字の発展版なんだから
文字扱いするのは当然 現代の文字は自然発生するわけでも王朝が発布するわけでもなくユニコードコンソーシアムが追加するのだ ■ このスレッドは過去ログ倉庫に格納されています
