■これまでに行われた議論
・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のフォントって、どのフォントがどのコード体系とか字体を使っている。
などを纏めているところってある？？
ちょっと考えれば分かるようなことをなぜ聞くんだろう。
ちょっと考えれば解るなんてすごい人だな。
ちょっと書いてみ
>やはり頭悪いのは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も来年・・・じゃないやもう今年リリースされる予定のはずだし
絵文字は象形文字の発展版なんだから
文字扱いするのは当然
現代の文字は自然発生するわけでも王朝が発布するわけでもなくユニコードコンソーシアムが追加するのだ
>>97
世界には文盲がわんさか居るから結局象形文字が必要ってことか 当の日本人にすら絵文字を扱いきれてなかったのに
そんなもんをコード化したら破綻するに決まってるんだよなぁ……
1964年の東京五輪での案内表示がきっかけでしょ絵文字の開花は。
>>99
絵文字と象形文字の間には確固たる断絶があります、おっしゃるような連続的なものではないと考えています
例えば、ある象形文字と別の象形文字との違いははっきりしていますが、ある絵文字と別の絵文字との違いを示す具体的な指標はないのでは？
それとも、これは私の知らなかったことですが、もしかして絵文字の内容はピクセル単位、あるいはベクターイメージですでに定義されているのですか？ 便器に◎とか〓とか描いてあっても何のことか判らんで悩むだけやぞ
カフェで野良WiFiのSSIDが絵文字になってたわ
うっかりつなぎそうになった
形状バリエーションも欲しい
巻きうんち/一本糞/ビチグソ
Unicodeですらないのに「U+～」という表記はこれ如何にｗ
Replacement Characters: U+FFFC–U+FFFD
U+FFFC. The U+FFFC object replacement character is used as an insertion point for objects located within a stream of text.
All other information about the object is kept outside the character data stream.
Internally it is a dummy character that acts as an anchor point for the object’s formatting information.
In addition to assuring correct placement of an object in a data stream, the object replacement character allows the use of general stream-based algorithms for any textual aspects of embedded objects.
U+FFFD. The U+FFFD replacement character is the general substitute character in the Unicode Standard.
It can be substituted for any “unknown” character in another encoding that cannot be mapped in terms of known Unicode characters.
It can also be used as one means of indicating a conversion error, when encountering an ill-formed sequence in a conversion between Unicode encoding forms.
See Section 3.9, Unicode Encoding Forms for detailed recommendations on the use of U+FFFD as replacement for ill-formed sequences. See also Section 5.3, Unknown and Missing Characters for related topics.
>>115
sorry Japanese only please 今はこうですよ
山
↑
の方が合ってると思うけど
現実は
↓
下載
>>115
んーつまり基本的にはU+FFFDを使っとけばいいのかな。
マジで英語が読めんので当てずっぽうだがw FFFC はオブジェクト用。変換のときに絵でも音楽でも写真でも、主に文字以外のものが埋め込まれていた場合用。
FFFD は文字用。変換のときに他の文字コードでは表現できる文字がユニコードでは表現できなかった場合用。
>>128
なるほど「オブジェクト」ってそういう意味か！
ありがとう。
つまり基本的に（Unicode環境で）「文字化け」した場合は
U+FFFCを目にすることはない訳だ。
（Webブラウザなら画像は別の形で表示されるし
端末なら8bitキャラクタの集合としてU+FFFDが使われるし） そもそも外部に公開するドキュメントにU+FFFC,U+FFFDが存在すべきでないということでは。
アプリケーションが内部で使ってよい領域という意味と受け取ったわ。
漢字コードのことでわからなくなりましたので質問いたします。
よろしくお願いいたします。
https://pc.watch.impress.co.jp/docs/column/config/1158344.html
＞文字データをシフトJISではなく、Unicodeで保存するとどんないいことがあるのか。
＞たとえばUnicodeならあらゆる言語の文字を混在させることができる。
＞Wordでしか文書を書かないエンドユーザーにはそんなこと当たり前じゃないかと言われそうだが、
これって本当ですか？
私見では日本語の漢字と中国語の漢字を同一文書にて同時に表示できないし混在もできない、と思っていたんですが…。
CJK 漢字統合の影響はもう過去の話になってしまったんでしょうか？ 字体とか書体を文字としてどう考えるか、で答えが変わるだろ
>>132
現に存在するUTF-32/UTF-8 という文字コードの集合を使用した場合に日本語と中国語の漢字を
①：同一文書に含ませることは可能でしょうか？②：①が可能であったとして、PC の画面にて同時に表示することは可能でしょうか？ 新しめのブラウザでUTF-8の文書を書いて、中国圏の自体にしたい文字を
<span lang="zh">
みたいに指定してやると全く同じコードポイントでも違う字形になる。
>>131
こいつはプログラマじゃないからな
かなり適当な理解で記事描くな >>131
Unicodeは全世界の文字に対応した文字コード
混在して使えるのは当たり前 >>133
より正確に言えば、
保存するときにローカルの文字コードに変換してるソフトかもしれないのでそのソフトの仕様による
例えば英文フォントしかないPCだと漢字は表示できないだろうから表示できるかどうかは環境による
だろう
>>131
あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ >131
私?では日本?の?字と中国?の?字を同一文?にて同?に表示できるし混在もできるが。
あちゃー。unicode文字が全部?になってしまった。
>>138
> あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ
縄文時代の日本語が文字コードで表せるならばUnicodeで表せる >>142
俺に言うな。>>138に家
縄文時代の日本語を混在できないとしたら、
それは例えば「文字がない」ことなのに、
Unicodeだから無理みたいな言い方してるんだから Unicodeだからできないなんて、誰も言ってないと思うのだが。
被害妄想にとりつかれた朝鮮人みたいだな。
> あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ
じゃ、この発言で言いたかったことは何だって言うの？
「私（>>138）は馬鹿です。」以外に何も思いつかないんだが >>147
>じゃ、この発言で言いたかったことは何だって言うの？
（unicodeならすべての言語を混在できるという話しを受けて）
あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理
だろ。他に何があるってんだ？ 横からすまんが元レスをたどると>>131「あらゆる言語の文字を混在させる」だぞ。
それを>>138がしょっぱなから「あらゆる言語を文字で混在させる」に読み違えてるように思える。 宇宙の惑星や生命体の多さから言って
UNICODEじゃ全然足りないのは明らか
>>148
縄文時代の日本語ってなに？
参考リンク教えて >>149
だから文字のない言語は無理だろ？
という話だけなのに、なんでひねくれてるの？ なぜ文字コードスレで文字の無い言語の話をしようと思ったのか
このサイトを参考に文字コード引っ張って来てみました
http://ash.jp/code/unitbl21.htm
区 点 JIS SJIS EUC UTF-8 UTF-16 字
01 86 2176 8196 A1F6 EFBC8A FF0A ＊
84 06 7426 EAA4 F4A6 E78699 7199 熙
17 77 316D 898D B1ED E78795 71D5 燕
44 80 4C70 96EE CCF0 E79FA2 77E2 矢
27 71 3B67 8E87 BBE7 E7B4AB 7D2B 紫
01 49 2151 8170 A1D1 EFBD9D FF5D ｝
ゲーム内では熙 燕 矢 紫の順にソートされており
引っ張ってきた文字コードを見ると、数字と文字のソート関係が昇順で一致していたのがUTF-8かUTF-16だったので
その2つかな？と思ったのですが、実際にそれらの符号化のサイトを見てみたら、ゲーム内のソートとはまた違う規則性のようでした
実験として、符号化の一番値の大きい文字である「FF5D ｝」を文字として使ってみたところ
先の4つの漢字の下にソートされたのでUTFあたりが近そうなのですが、それ以上は素人にはわからないので困ってしまっている状況です。
どうかご助言の方なにとぞよろしくお願いします。 区別しない文字があるんだから文字コード外のルールでソートされてるんだろ
特定の符号化を示唆する特徴が見られたとしてもそれは実際に採用されてる符号化と直接の関係がない
回答ありがとうございます
本当に助かります
>>161
あーそういう感じですか・・・
ってことは自分で調査しないとだめそうですね
返答ありがとうございました
>>162
ほとんど初心者なので知りませんでした こういう関数があるんですね
専門用語とかだけでも出してもらえて嬉しいです
何も知らないのでぐぐる事もできなかったので助かります
単語さえわかればあとはこちらで調べますので
他にも関連した情報がありましたら用語だけでも教えてもらえると嬉しいです 例えば韓国製のゲームなら韓国語での文字コード順になってるかもな
データベースにMySQLを使ってるかもしれないという前提だと
MySQLでのソート順序はCollationという
http://variable.jp/2009/07/14/mysql-collation/
> MySQL5.0では，126種類でMySQL5.1では，127種類のCollationが用意されている。
> 一つの文字コードに複数のCollationが用意されていて、文字データの場合，文字コードによって，
> 並びが変化する。
127種類のうちUTF8系だけで21種類の順番が存在する 中国製なら中文系かもな。「Big5」とか「CNS11643（EUC_TW）」とか、「GB2312（EUC_CN）」とか。
>>169
ブリックパックの右二つがなんだかわからない 真珠を絵に入れるなら pearl oyster にしとけばいいのに
>>176
ほとんどのルーターで禁止されているけど、ルーターのWebUIでSSIDを設定する時に
JavaScriptの文字列チェックを外して強引にUTF-8で設定させるのが一部で流行っているらしい。 内部では単なるヌル終端のバイト列として扱ってるだけなんだろう
>>180
見えているのに到達できない場所みたいだな ユニコードの文字の説明（#から右の部分）がのっているテキストファイルの置き場所って
どこかわかります。できれば、日本語だけでなく全文字が欲しい。
↓こんなやつがずらっと。
0x878D U+337E # SQUARE ERA NAME MEIZI [2000]
そこ知ってるならもう辿り着けたも同然なのに
一つ上がってみよう
一昔前に、大塩平八郎のLANや応仁のLANというSSIDが話題になったことがあるよね。
俺は見たこと無くて何とも言えないのだけど、実際に接続できたのだろうか？
境界判定するつもりが教会判定することになり異端審問にかけられた。
Nobody expects the Spanish Inquisition!
>>190
Nobody knows the trouble i've seen, nobody knows but Jesus! 確かに空白だな、と思ってソース見たらtofuが並んでた
Service Temporarily Unavailable
そうか…
あのページはすごい便利に使わしてもらってたのに、利用できないとは残念
>>197
そのページから個々の文字に関する情報って見れなくね？ >>199
unicode、すっかりグダグダたな。なんだよ絵文字って。 U+32ffにはplaceholderも入れてないのか
>>201
「ゑ」の小さい字もできるんだ、
「ぇ」みたいに。 その読みにくい文体、中学のマイコン部の先輩が部誌に書いてたコラムに似てるなと思った
内容はともかく
> それに、今みたいなポリコレ棒が猛威を振るう時代だったら、CJK統合は行われなかったでしょうね。
> 部外者が他文化の文字に対してもの申す事は、文化への攻撃・侵害・侵略として糾弾されたでしょうから。
> 日本人や中国人側からではなく、米国や欧州の国々の方から強い反対が出たでしょう。
<https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b#comment-ba92e82cf5ff8a829c10>
↑これはなるほどと思った。政治的正当性についてとやかく言うつもりはないが
CJK統合はマジでそのCJK文化圏にいる利用者からは扱いずらすぎるからな……。
「意味や字形が似ている文字なら同じ符号を割り当てていい」のなら，
フラクツゥールを態々用意せずに，lang=de-x-Frakみたいな指定があったときに
文字「A」を「𝔄」という字形で表示すればいいのに，そうしてない。 苦情が出た時のために拡張領域があるんだから許してあげてよ。
小さいゐゑヰヱは "used to write archaic Japanese" なんだけど
小さいヲンは実は典拠が微妙
同じワ行音ってことで何となく入っちゃった
リンゴロゴ(U+F8FF)を使った Tim が正しく表示される環境は限定的なのかな？
私は「ティム・アップル」 トランプ氏言い間違えに本人が便乗
https://www.afpbb.com/articles/-/3214744
【3月8日 AFP】米アップル（Apple）のティム・クック（Tim Cook）最高経営責任者（CEO）は7日、
ドナルド・トランプ（Donald Trump）米大統領に名前を呼び間違えられたことを受け、
公式ツイッター（Twitter）アカウントの名前を「ティム・アップル」に変更した。
トランプ氏は6日、ホワイトハウス（White House）で開かれた会合で、
アップルの国内投資と雇用創出について感謝の意を述べた際、クック氏を「ティム・アップル」と呼び、ツイッター上で話題を呼んだ。
するとクック氏は翌朝、これに便乗し、自身のツイッターの表示名を「ティム」の後にアップルのロゴをつけたものに変更。
ツイッターユーザーからは、米マイクロソフト（Microsoft）共同創業者のビル・ゲイツ（Bill Gates）氏を
「ビル・マイクロソフト」、米電気自動車（EV）大手テスラ（Tesla）のイーロン・マスク（Elon Musk）最高経営責任者（CEO）を
「イーロン・テスラ」、初代米大統領のジョージ・ワシントン（George Washington）を
「ジョージ・アメリカ」と呼んだらどうかといったトランプ氏への提案も飛び出した。
ヒラリー・クリントン（Hillary Clinton）元米国務長官を「Crooked Hillary（歪んだヒラリー）」と呼ぶなど、
ニックネームを生み出してきたことで知られるトランプ氏は、過去にも同じような言い間違えをしている。
昨年には、米航空防衛大手ロッキード・マーチン（Lockheed Martin）のマリリン・ヒューソン（Marillyn Hewson）CEOを「マリリン・ロッキード」と紹介した。
(c)AFP
ティム・クック氏のツイッター・アカウント
https://twitter.com/tim_cook
https://twitter.com/5chan_nel (5ch newer account) Private Use Area を公にさらす変態
Tim Appleと呼ばれたTim Cook、Tim Tofuを名乗る。
>>207
>CJK文化圏にいる利用者からは扱いずらすぎる
わざとそれを狙って毒撒いたんじゃね？ >>216
「あたしわゆる」の後なんて書いてあるの？ >>218
さない
「あたしわ ゆるさない」 だろ これから漢数字とか丸数字も数字扱いしだすゾォー^
属性定義するのはいいけど定義をコロコロ変えてんじゃねぇよ
>>223
まじかよ
互換性がとも思うけど，寧ろ便利なのかな。 ダブルクリックで文字列選択するような機能に影響でなければいいけどなあ
鈴木一郎が全部漢字だから一気に選択できたのに一が数字だからってんで
鈴木/一/郎なんて分けられたらやっかいだ
Unicodeじゃなくて個別のライブラリの仕様次第だと思うけど、近い将来影響が出てきそうだね。
そういえば(今もそうかは知らないが)Firefoxは「々」がそういう選択のされ方だった。あれはなんでなんだろう。
正規表現ライブラリpcreは境界判定\bや英数字判定\wの判定方法をフラグPCRE_UCPで切り替えられるようになっている。
grepの-Pオプションはpcreを使うのだけど、境界判定\bが-Eオプションと違う動きになる。PCRE_UCPオプションを使ってビルドいないからだろうと思う。
このスレかどっかでC99で作られたUnicodeライブラリの紹介を見掛けた気がするんだけど
誰か知らないですか。
確かに5ちゃんねるの文字コード関連のレスで
「---っていうライブラリが便利だよ」みたいな文章だったと思うんですけど。。。
なぜかそのとき ライブラリのWebページをブクマし忘れてて そのライブラリの名前を失念してしまったんです
ICUは有名なのですぐ見付かるだろうしなによりC99じゃない。
utf8procじゃねーの？
新元号発表の時の墨書、楷書体だけど「令」の字形はU+F9A8に似ていた。
何らかの揉め事になって面白い事になるかも。
てか「人一卩」と「人丶マ」は異体字セレクタにあるけど、官房長官が掲げた「人丶卩」が無いな
Gengo-Oshuujiコレクションを申請するときがきたか
あのお習字も公文書扱いらしいな
汎用電子あたりにぶち込んでいいぞ
個人的には新元号に2004年のJISで例示字形変更された字や第2水準以下の字が使われなくて良かったと思ってる。
>>245
そんな大事な話でFA98とF9A8間違うとか絶対わざとやってるだろ
消して投稿しなおせよ >>247
そもそも字が下手過ぎて習字の基本すら出来てないやろ
和にしても
ノ木口
なのに
ノ丶木口
って描かれてる 集合住宅名にありがちシリーズだと㌞・㌪はあるがヒルズとかテラスとかがないな
Unicodeに入れるのはむりぽ
AJ1ならワンチャンあるかも
>>250
誰でも読み書き出来る字を選ぶという配慮であろう。
令は小学4年、和は3年で習う字だ。
今時のキラキラネーム(DQNネーム)とは違う。 常用漢字から選ぶとは最初に告知されてたが、
2010年追加の常用漢字の中には第２水準以下だったりJIS2004で字形変更されて
2点しんにょうや古い食へんの字があるよな。
教育漢字にはならなくて小学校では習わない字のままだったけど。
あの「令和」っていう習字の画像って公文書として入手できないのかな。
どのメーカーの半紙と墨汁を使ったか公開すればバカ売れだな
>>264
電子化された契約文書に大正の年号が使われることがないから影響もなかった。 大正時代に生まれた人なんかいくらでも電子管理の対象になりうるだろ
大正はIME類に成語として登録されてるからよっぽどでもないかぎり他の大は出てこんわね。
でも令和は現状自由変換状態で、この状況はみんなのスマホやPCが“令和対応”のものに更新されるまで当面続く。
そこに「こっちの令が正しい形」説が追い打ちをかけてきてるのが困ったところ。
じゃあ令和もIME登録したらいい，って思っちゃうのは素人考えなんですかね。
他人のIMEに一括登録できるなら何かのプロだな。
あるいは単に問題を取り違えてる素人かもしれん。
江戸時代の地震記録した古文書495点 市民参加して解読完了！「くずし字学んだ」 2019年04月07日 06時00分 @ハザードラボ
https://www.hazardlab.jp/know/topics/detail/2/8/28696.html
江戸時代の古文書に記録された災害の歴史。くずし字を現代文字に直しながら読んでいくプロジェクトだ（京都大）
京都大学は、地震研究所図書室が所蔵する江戸時代の地震を記録した古文書495点の解読を終了したと発表した。
2017年1月にスタートした解読作業は、4600人を超える一般市民が参加してくずし字で書かれている古文書を、一字ずつ現代文字に活字化するという
プロジェクトで、過去の災害の歴史を学ぶきっかけにつながるという。
古代から地震が多かった日本では、『日本書紀』に残る416年の「允恭（いんぎょう）地震」を最古として、数多くの史料が残されている。しかし、解読されたのは
そのうちのほんの一部で、有益な情報のほとんどが手付かずの状態だ。 くずし字学習アプリを使ってゲーム感覚で学ぶ
翻刻が終わった『地震年代記』（国立民族博物館）
京都大学大学院の「古地震研究会」は2017年1月、東大地震研究所の図書室が所蔵する古文書495点をインターネット上に公開し、Wikipediaのように閲覧者が
現代文字に書き換えるプロジェクトを開始。これまでに4626人が登録し、このうち347人が実際に文字の入力作業に参加した結果、新書30?35冊分の文字数に
あたる465万文字が入力されたという。
「みんなで翻刻」というこのサイトには、数多くのくずし字のパターンや、江戸時代の本から収集した3000種類近い熟語が収録されており、
くずし字学習支援アプリと連携することで、初心者でもくずし字を学ぶことができる機能が備わっている。（翻刻＝文字起こし）
過去の災害の歴史を学ぶきっかけに
学習アプリを使って、ゲーム感覚でくずし字を学ぶ
スタート当初は、地震研究所二代目所長をつとめた地震学者の石本巳四雄（みしお）氏がコレクションした114点の災害史料の翻刻を目標としていたが、
開始から5カ月後には完了。その後、資料を追加することで495点すべての作業が終わった。
今後は、ほかの資料館が所蔵する史料も登録を進め、翻刻を続ける計画なので、興味がある人は今からでも遅くない。パソコン1台あれば誰でもアクセス
できるので、ぜひ一度サイトを訪問してほしい。古文書の解読の楽しさはもちろん、自分が住んでいる地域で過去に起こった地震の歴史を学ぶこともできる。 UTF-8って、制御コード含まれることはないんだっけか
だぶりのコードもあるし
不正コードでおかしくなるシステムもある
>>254
Unicodeに収録されている「パーツ」と「ほか」が追加されるとUnicode仮名合字が揃うから最優先 >>254
これ使えって言われそうだ
🇬🇼 これ結果的に包摂への理解が世間に広がれるきっかけになればいいなあ
元号合字はBCだと思ってたのに
新しく増やす余地があるのなら慶応以前のもないと気持ち悪いなあ
保元とか平治とかちょうだいよ
ツイッターのオリジナル令和絵文字
官房長官が額縁を掲げたという先例をそのまま踏襲したことにより、
将来にわたる日本の改元時儀式が爆誕した瞬間である
㍾ ㍽ ㍼ ㍻みたいなのってNECの外字由来じゃなかったっけ
なんで今さらシフトJIS時代の遺物の仲間みたいなものを増やすんだか
「シフトJIS時代の遺物」に依存している人が少なからずいて、その人たちが令和のも作られるのを望んだんだろ
つってもシフトJIS時代の遺物アプリケーションでは使えないんだぞ。なんだそれ。
世の中の大部分のワープロソフトはunicode対応済みだからSJIS縛りはない。
>>319
IT技術者なら使わないけど、変換候補に出でくるものを使うのがなぜいけないのかと思うのが世の中の大半。 >>324
面白いお小遣い稼ぎだなと思ったが、
これ名前に主義主張とか入れて来る人がいたらややこしいことになりそうやな。 >>325
別に使っても良いと思うけど
それなら慶應より前のが全部入れろと
たかだか有限個なんだし楽勝だろ >>327
入れるのを望む人が少ないから入らないんだろ >>330
MS UI Gothicは等幅フォントだったのか 仮に慶応以前も入れるとしたらさすがにBMP外だろうな。
まあDLLバージョン非互換地獄みたいなのと根は同じと考えれば大変だなと思う
おそらく今世紀半ば頃になるだろう令和の次以降も組み文字入れるつもりなのだろうか?
不思議なもんで平成31年がはるか昔のように感じられる。
>>335
「?」を使って無くても不具合起きるってことか
Windows Form 使ってるところはヤバいんじゃないか >>339
問題が出るのがWinFormsだけとは限らない（少なくともExcelは確実に再現する）らしいから
ＧＷ明けには大問題になりそうな気がするんだけど、いまのところ全然そんな話になってないのがちょっと怖い
まさか「令和」の合字を付け足すだけのWindowsUpdateで
フォント幅の定義が勝手に変更されるなんて思わないよな・・・・
不幸中の幸いは「Microsoftがやらかしたことなんで開発側も被害者です」と言い張れることか 勝手に見た目が変わってしまうのは迷惑と言えば迷惑だけど、それが問題かというと
大半はそうでもないんでない？スマホアプリほど表示サイズにシビアでもないだろうし。
>>341
Excel書類とかメッチャシビアじゃん
業務アプリ系もヤバいと思うよ 印刷フォームのレイアウトが崩れたりとかはあるかな。
ただまぁ、印刷用フォントにUI Gothic使ってたりしたらそれ自体バグと言っていいかもしれない。
Excelの罫線で帳票造って印刷してるところは阿鼻叫喚だなω
なんだかな感がありつつもさすがに影響でかいから修正すると思うけど、
ユーザー側が最新に合わせて調整し終えたところで修正が入って再阿鼻叫喚ありそう
そもそもExcelの印刷機能はプリンタが変わっただけで文字切れする
レイアウトが崩れても見なくなる部分がなければ最悪なんとかなるけど
切れて見えなくなる部分で影響が有ると嫌だな
自分は余裕を持たせる事が多いけど
やたらピッタリにしろ
っていう圧力が強いんだよなぁ
知らないんだけどExcelってフォント埋め込みできないの？
令和は入れて金正恩は入れないのはダブスタじゃないんですか
そちらの事情詳しくないんだけど最新版ではじょんうんもコード振られてるの？
いきなり?で草
外に向けて公式発表とかはしてないのか
令和の合字(U+32FF)は結局シフトJIS環境では使えないし、
まだこれを含むフォントがインストールされてなく表示出来ない事がある環境依存文字だから使うなとか
そもそも互換文字だから使うな、「令」(U+4EE4)と「和」(U+548C)を並べて書けとか言われるんやろ
どうせ、利用するフォントによって、どの文字まで表示できるか？決まるんだから
変な文字は使わず、90年までの規格で止めとくほうが正解かもね。
令和組み文字はCP932には入れないようだが、
JISX0213には入れるのだろうか?
つーかそろそろ日本工業規格も令和に対応すべきだと思うのだが。
JIX X 0213だけじゃなくてJIS X 0301とかも。
CP932に追加は無いだろうけど最近の過去互換の軽視ぷりからするとやらかす可能性が完全0じゃないのが怖い
半角カタカナも滅べば良いし
年号の合字も無限に増やすのは無理だから
常に二文字表記で文字幅で調整すれば良い
天皇陛下万歳
千代に八千代に
絵文字とかと同じ 令[ZWJ]和 でいいのにな
専用の文字コードが必要なのかと
漢字のジョイントって意図が不明瞭にならないか？
偏旁に配置した新字を創字したいのかなと思ってしまう
ほとんど見掛けないけど漢字位置記述文字みたいなの使えば？
あれは人間への説明用であって合成して表示させるものじゃないから違うような
> the reader can then create a mental picture of the ideographs from the description.
> In particular, support for the characters in the Ideographic Description block does not require the rendering engine to recreate the graphic appearance of the described character.
あ，そうなのか。
あれを適切に設定すれば，対応したビューアで自由に漢字が表現できるもんだとばかり……。
教えてくれてありがとう。
あれだと縦書きと横書きで並び変えられないしね
欲しいのは組み文字ジョインター
キ[KMJ]ジ[KMJ]マア[KMJ]パ[KMJ]ー[KMJ]ト
これで
キジアパ
マ ート
マキ
ジ
│ア
トパ
をつくりたい
>>369
そういうのは「文字」じゃなくてCSSとかで実装すればいいじゃん
……って思っちゃうなw でも令和合字入れちゃったからなあ
先行規格がない生まれながらの互換文字ってかわいそうじゃない？
同じ失敗を繰り返すタイプ
数百年先を見通せない政策
理論上は文字コードを無限に増やせる仕様じゃないとダメでしょ。
不敬罪ではないでしょうw
実際女子しか生まれていない皇家も有るし
何らかの対策をしないと途絶える可能性は有るよ
継続させたいなら
本気で対策しないと拙いよ実際
>>345
今日の定例アップデートで修正入ったみたい だから今のうちに隠し子を作っておけと
結婚してから外で子供を作るのは嫁の人権上まずいけど
若気の至りなら仕方が無いだろう
>>381
現実ではともかく
ネットの「不敬罪」はほぼネタだと思ったほうがいい ほとんど報道されないけどたまに逮捕されてるよな
>>378御愁傷様 地球外知的生命体との遭遇を前提に、拡張性を確保しとかないとね。
Consortiumが提供しているのはそれくらいかと
0x2237 0x007E # TILDE
これはやめた方がいいんじゃないかな…
後はまあ
チルダは主要フォントは同じ字形になっちゃったから、
ユニコードNGの環境で初めて気づくことも多いんだよね
つうか誰が何の目的で入れたんだよ
絵文字増やすことが目的になってるだろもう
だってこれまで一般人からは存在も意識されてなかった文字コードの改訂が
「今年の新絵文字発表」化してから急に世界中の注目を浴びる一大イベントになったんだもん
そら浮かれるよ
鼻濁音を表す仮名か゜、き゜、く゜、け゜、こ゜、カ゜、キ゜、ク゜、ケ゜、コ゜は
JIS X 0213ではそれぞれ1文字としてコードが割り当てられたのに、Unicodeでは
半濁点なしの仮名と半濁点の2文字で表さなければいけない。Unicodeにも1文字として
収録してもらいたい。
辞書に使われる記号 [名]、[形]、(単)、(複) など ([ ]は角丸正方形、( )は丸囲み文字) も
欲しい。
>>399
鼻濁音はUnicodeにちゃんと提案したら通りそう。
辞書で使われる記号は外字や私的領域に配置するしかないんじゃないかな。 NHKの情報番組によると、最近スマホに移行した役者の役所広司さんはガラケーの絵文字が好きでスマホの絵文字が不満らしい。
>>400
テレビ番組表で使われる記号[字]、[ニ]、[多]、[声]、[吹]、[演]など ([ ]は正方形囲み文字) は
Enclosed Ideographic Supplement (U+1F2xx) として収録されたから、同じブロックの
空き領域に辞書用の記号も追加してもらいたい。 よくわからん
合成文字ではいけない理由って今時ある？
この板に絵文字スレを別に作るのはいい案だとは思えない。一緒に扱ったほうがいい。
他の、スマホ系やネット文化系の板で絵文字スレを立てるのはそっちの文脈での必要に応じてやればいいが。
>>403
それを言ったら、漢字も合字で構わなくないか? 1文字ずつコードを割り当てずに、
パーツ(部首など)に分解し、パーツと配置方法をコードで指定するIDS方式にする。
ハングルも音素に分解する。そうすれば、CJKが占めていた膨大なコード領域が
明け渡され、Unicodeを16ビットに戻せる。非CJK圏の人々はそれを望んでいそう。
漢字は情報伝達効率がとても良くて、字 2バイトで character 18バイトと同等の
情報を伝達できる。IDS上下, ウ冠, 子 の6バイトで表しても、18バイトの3分の1しか
まだない。 バイトでいうならそうか…
画数で無駄だなぁって思っちゃった
>>413
それを言ったら、がよくわからんが
現状で漢字は個別、>>399の仮名は合成で表現する仕組みになってるもんをそれぞれわざわざややこしくするメリットある？
あと今更ひっくり返して形だけ16bitとか言語圏関係なく望んでないと思う >>399で書かれてる辞書で使われるような丸囲みとか四角囲みはU+20DDやU+20DEと組み合わせて表せばいい。
例えば[名]はU+540D U+20DE、(単)はU+5358 U20DDで表せる。 >>413
俺もそういうのがいいとは思うけど
同じ手偏でも幅が微妙に違ったりするじゃん。
そういうのって計算というより正直 美的感覚に基づくものだから，
結局 一字一字に「手偏の幅」とかいったパラメータを与える必要が出てきそう。 >>413
字形まで自動合成する必要はないだろ。字形は1字ずつデザインするが、それを呼び出すのに
IDSコードを使うだけ。 正直IPAmjにだけ入ってるクラスの漢字見てるとこれIDSでどうすんのって思うよ。今更どうしようもないと思う。
台湾に漢字の部首を組み合わせてフォントを合成する技術があるらしい。
>>422
それってソフトウェアやライブラリとして提供されてたりする？
もしよければ教えてほしい 技術も何もメイリオあたりもそういうのじゃなかったっけ
結局調整が必要になるっぽいけど
なんか思ってた技術と違うわ。
IDSの組合せをそれが表現する漢字と対応させるんかと思ってた。
漢字構成記述文字列って複数の記述文字の組み合わせとそもそもの複数の文字とをどうやって区別するんだろう。
「⿰山⿱上下」という並びが「峠」を意味するのか「山𠧗」を意味するのか区別できなくね？
1文字になる以外の解釈が可能な定義にはなってないように見えるが
というかもともとそういうもんじゃない？
あれは人間が読むことを前提にした文中で説明を簡素にするために使う記号であって
合成とか機械処理とかをやることははなから考えてないと思う。
違うな
>>430 が正しい
⿰山⿱上下 → 峠 (正しい)
⿰山⿱上下 → 山𠧗 (不正)
山⿱上下 → 山𠧗 (正しい)
⿰⿱山上下 → 峠 (知らんがな) >>433
最後のは不正では。
⿰⿱山上下なら
↓こんな文字になっちゃう
カッコなしで誤解釈の余地なくやるにはRPNにすればよいのでは？
括弧なしでも漢字構成記述文字列は一意に定まるぞ。
曖昧さの余地はない筈。
ていうかそもそも漢字構成記述文字列自体がポーランド記法っぽい性格を持ってる。
⿰⿱山上下なら⿰(⿱(山, 上), 下)みたいな関数表示になって↑>>434みたいな字形になる。 同じ文字を二通り以上の表現方法があるのはセキュリティ上やばいと爺さんが言ってた
UTF-8みたいなやつ
全然関係ないが男女男男女女男女男女を思い出した。おっさんだな、俺。
だから複数あるっていう意味で書いたんだが
正規化で一つにっていうのは判る
表現意図としては比が2:1:1と1:1:2と1:1:1で違いがあるような
将棋好きのおいらとしては、ひっくり返った「玉」「飛」「歩」とかも
登録してほしいと思うのだが。
>>448
Unicodeってそもそも将棋の駒 全部登録されてないんじゃ？ 笑→ケケ夭
とか
禁→木木示
とか
哭→口口犬
とか
と
畿→糸糸田戈
は同じ表現？
>>450
まあ機械処理向けの言語じゃないから
人が「分解できる」と思うかどうかだよね
ちなみに「畿」の部首って「田」なんだな。すげー意外。 >>449
ないよ。黒塗り五角形と白ヌキ五角形だけ。 文字表現ってことで
●●構えっていうと門しか思い出せないし
●●囲いっていうと口しか思い出せないけど
将棋の駒の白抜き五角形は囲いなんだろうか
いっそのことCombining Diacritical Marks for Symbolsあたりに将棋の駒の枠線を登録してもらえればいい
>>454
枠線の中に複数文字入れるのどうするとか
中に「と」みたいなのを表示したい場合それは本当に「と」で表現するのかとかいろいろややこしくなりそう
将棋みたいに中身が決まってるやつは一通り個別に並べてもらったほうがシンプルじゃないのかな… >>453
黒と白で、先手と後手を表しているだけだよ。 文章中に書くなら白黒五角形で十分だと思うが、なんで盤面まで表現したがるかな。
歩の裏の「と」があるべき位置に
「テ」だったか「〒EL」みたいな
意味不明な文字が書いてある駒セットを
観たことがあるけど
あれはなんだったんだろう
朝鮮語か？
Ｔ
三 みたいなやつ？
全ての「成金」の文字は「金」を崩した文字だよ。
「と金」も、本当は「と」と書いてあるわけではなく、
「金」を崩した結果、「と」みたいになっているだけだよ。
どうでもいいけどそのレスを見て
その内 崩し字も登録されそう…とか思ったw
太字のaとかがなぜか「文字」として登録されてるんだから金の崩し字が登録されてもおかしくない
歩兵の裏は金と同じ読みの今（きん）の崩し字をあてたので
「と」と極めて似た文字になったという説がある
T
ニ
ヘ
なんでこれで金になるのかさっぱり判らん
あと
|
とか
レ
とか
謎のが多すぎ >>457
どうなったか調べてみた。L2/18-170は2018年8月開催のUTC #156で議論され、
議事録には提案者にfeedbackを返したとだけ記録されている。
http://www.unicode.org/L2/L2018/18183.htm のe.5
で、この文書番号で検索すると同じ提案者の出したL2/18-342が引っかかって
そこにこう書いてある。
> Shogi proposal. The proposal I am talking about is (L2/18-170), the committee's
> rationale for rejection was that: “the symbols in question were not attested in
> lines of text”.
インラインテキスト中で使われている用例が示されていないのでrejectされたらしい。 なるほどなあ。
チェストーはインラインで使ったりするもんなんだろうか
日本NBが後押しすれば10646に入りそうな気がするけどね
漢字以外は興味持たないだろうって見透かされてるんだろうな
まあ言いたかないけど 欧米が制定した企画だからね……。
あきらかに文化的な偏りはあると思う。
この間もモンゴル文字かなんかを文字の結合方式とかをほとんど考慮しないで登録してしまった
という旨でUnicode共同体を批判してるブログ見掛けたし。
https://nixeneko.hatenablog.com/entry/2018/03/04/140000
モンゴル文字のことはよくわからんが、ここに書いてあることによると、
> モンゴル文字は、語の中のどの位置にくるかによって、また母音調和等によって形が変化する。
> 中国・モンゴル国の両国ともに現状と地続きの音声アプローチの方を支持しているようであるが、
> 最終的にどの方式が選ばれるにしろ、相互運用性が確保されることは期待できそうである。
ということだから、現状の規格は、中国・モンゴル国が希望したものであって
欧米人が悪いというわけではないと思う。 ただ、似たようなものは英文にもあるわけで、fish や office のように、
f,i,j,l が続く場合は、文字を合字（リガチャ）にする場合が多い。
しかし、MSword も TeX も、「合字にせよ」という指定を入れなくても、
勝手に合字にしてくれるわけで、モンゴル文字も（よく解らんけど）
同じようにできないのかな、とは思う。
ごめん。誤り。MSwordは指定しない限り、合字にはならなかった。
>>466
筆で金とうい字を1000回くらい書くとわかるようになるよ。ようは手抜き。 プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
http://2chb.net/r/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 >>482
釣られて そのスレ見に行ったけど
寧ろそのa4っていう小手の人が被害に遭ってるように思えたけどな Unicode協会が配布してるプログラムでシェルスクリプトでUTF-8文字列を扱えるデータってないかな。
入力されたUTF-8文字列が何文字かを判定したりするのに都合の良いスクリプト。
CLDR for shellみたいなのがないかなと。
Unicode協会って書かれると、アグネスがやってるパチモンに見えてくる
使えないよ
その手の文字が登録されたことはあるのかな
最近Kenのツイートが酷い
LunaticとかAdobe的にいいのか
絵文字をリガチャとして実装するという話を聞いたことがあるが
良いアイデアだと思う。
これ以上貴重な符号位置を占有しないで欲しい。
見る側の環境によって、絵文字を使った側の人が意図しなかった単語に化ける現象が発生してしまう
>>497
実はそれを意図しているんだな、これが。
Webフォントが使えなかった場合に，意味不明な私的領域のコードポイントではなくその絵文字の「意味」の単語になるっていうフェールセーフ。
この発想はアクセシビリティの面からしてすごいと思う。
今までも↑こういうことを実現する手段はあったが（aria-*とか::beforeとかを活用する），
いささかハックじみた手法だったのに対して，この方法はほとんど何のひねりもないし，かつ
高いアクセシビリティを誇る。 なんか公式ページの説明が簡素すぎてよく分からん。
素晴らしさを伝える記事とかないの？
>>498
全然意図してないと思うぞ。＞使った側の人が意図しなかった単語に化ける現象
これがアクセシビリティ向上になるのは入力者が単語と絵文字の対応を把握している場合だけで、
把握してない場合は入力者が知らない結果が出力される謎フォールバックになる。
入力者が絵文字パレットから選ぶ仕組みなら単語を把握してない可能性が高まるし、
個別に校正かけるなら元々あるimg altとかではなくWebフォントを使う強みは何？ってなるし どのフォントでどこからどこまでリガチャっていう指定を含めないといけないからプレーンテキストで利用できない
リッチテキスト使えるなら画像でいい
This is a pen��.とか[�� Download Now!]みたいにもともと並べて使うことも多いしな。
This is a penpen.や[Download Download Now!]は変やろ。あとThat is a ��guin.の誤爆避けも必要になる。
>>500
Webフォントを使う強みはページ読み込み速度の向上だと思うよ。 >>500
あ、それと色とか大きさとかをCSSでより柔軟に調整できる。 WebフォントってDL待ちでむしろ遅いイメージしかないな…
日本語だとどうしても…
サブセット化もこれから足してくコンテンツ考えるとあんまりいいソリューションとは…
>>507
>>508
絵文字リガチャフォントだと高々100個くらいだから
日本語Webフォントの常識は当て嵌らんぞ 推すなあ。
あえてこれ使いたいと思うならもちろん自由に使えばいいと思うが、
正直これを選ぶメリットがある局面はすごく限られてる気しかしない。
>>513
>>97じゃないから確かなことは言えないけど
「better choice」じゃないかな？
つまり絵文字を「入れざるを得ない」ってことね。 BA-90使いたいのに斑の黄顔になるのはなんだかなー
IC: 相互互換性
FC: 前方互換性
BC: 後方互換性
UC: 上位互換性
LC: 下位互換性
ちい覚えた
LeftとかRightとかCorrectは無いんか
>>524
correctはともかく左右は確実にねーだろw 共産とりっけんと社民社と国民主と令和革命はLC互換
高度に発達したエンコードはMojibakeと見分けがつかない
基本多言語面って制御文字含んでるよね。
それbaseXXの本来の意味を成してないw
ISO-2022-JP のくせに content-type: text/html; charset=shift_jis で送ってきてるからなあ
>>533
あ、そういうことか。と思ったけどChromiumだとどうしようもねぇわ。
最近のブラウザって文字コードを修正する機能みたいなのって消えてるね。 >>535
Firefox68には文字コード指定が残ってる
通常は無効になってるけど>>531のリンク先を表示したときは有効になって
ISO-2022-JPを指定すると文字化けなしで読めた ところでW3Cって文字コードの制定とかに関わってたっけ？
XMLが使う符号化文字集合にUnicodeを推奨してるくらいじゃない？
>>533
ファイル名まで .sjis つけてるくせになんで iso-2022-jp で保存してるのかイミフ HTMLをiso-2022-jpにするのって
どこの文化なんだろうか？
Windowsはsjisだからありえないし
Linuxも昔の普通はEUC-JPだろ？
iso-2022-jpはメールにしか使われてなかったはずだが
>>531
イシカワ マサヤスというのは誰だろうね。 石川雅康と石川哲志は親族だろうか？
どちらもICT業界から去ったのかな。
XHTMLが終わってしまって、そのまま放置の石川さん。
1998年当時のWebブラウザはキャラクタセットの判定すら怪しかった。
>>549
そのリンク先に書いてあるけど、iso-2022-jp が使われてるのはMSが発端なのか？
> name="GENERATOR" content="Microsoft FrontPage 2.0"
> というのが各HTMLファイルの先頭にあることから、Microsoft の FrontPage が 漢字コードがシフトJISのファイルであるにもか かわらず、iso-2022-jp の指定するからではないかと思われます。 >>540
流れは似てるが今回は指摘されてるURLが問題なんだろ
よりによってアイツがってやつさ ブラウザって一時だけでも拡張子によって文字コードを判断してた時期があったの？
俺の記憶にはないのだけども……。
だからこれはjisという拡張子でHTTPヘッダのcharsetもshift_jisなのに
中身がiso-2022-jpなんだってば
iso-2022-jpが使えるテキストエディタで書いたか
sjisに変換すべきところをiso-2022-jpに変換してしまったということ
昔のWindowsで書いたならsjisになるだろうから変換ミスかなって話
jisって拡張子ならiso-2022-jp(JISコード)なのは意図通りだろ
HTTPヘッダのcharsetが食い違ってるだけで
鯖の仕様が変わってcharsetのデフォが変わったからな
サーバー引越のときに設定間違えた可能性はあり得る
>>557
拡張子はjisじゃなくてsjisな
だからドキュメントの文字コードが明らかに間違ってるんだよ 昔のブラウザはHTTPヘッダのcharsetよりも
ドキュメントからの文字コード判定の方を重視していた。
なぜならセキュリティというかサーバー運営者がよくわかっておらず
設定変更の必要性を理解できていなかったので設定されてなかった
たとえ設定変更ができるサーバーでもユーザーが理解していなかった
そんな時代だからブラウザで表示できれば良し程度のレベルが普通で
今からするとチェックが甘かった。その当時の間違った文字コードのページが今も残っている。
たぶんこんなところ
>>561
単なる書き間違えじゃね？
リンク先見ればわかるでしょ >だからこれはjisという拡張子でHTTPヘッダのcharsetもshift_jis
こういうおっちょこちょいが >>531 みたいなミス連発するんだろうな なんでUTF8以外違法になった今そんな話してんだか・・・
サクラエディタがとうの昔にUTF32対応していた事実をいまごろ知った。
でもUTF-16の「どんな文字でも固定ビット幅」という利点が失われてしまった今，
固定ビット幅が実現できる唯一の規格であるUTF-32は希少では。
読むぶんにはナイーブな実装で足りるからいいけど実際使うとなったら00が無駄に思えてきて敬遠しがち
だからもしかすると文字コードでさえ適材適所なのかと考え始めている
内部表現は32bit単位で固定長の方が楽
ファイル読み書きのときはutf-8で勝利
あとはcps932が滅ぶのを待つだけ
OSのインターフェースはUTF-8，内部表現はUTF-32が一番いいのかもね。
UTF-32だとASCIIに比べて単純計算で四倍弱の容量を食ってしまうのが難点。
でもOSの本体くらいならそもそもテキストとして表現されてるファイルも少ないし案外肥大化は防げるのかも。
複数のコードポイントのシーケンスで一文字を表現するUNICODEだから
UTF-32でも一文字が32bitで収まるとは限らないからUTF-8でも大差ない
プログラミング言語C++に関していうと、x64版Linux用gccは既定でwchar_tのサイズが4バイト。
つまりx64版Linux用gccはstd::wstringがUTF-32。誰も使っていないように見えてそうでもない。
UTF-8だけで必要十分という結論に到達せざるをえない現実
逆なんだよな。
本来UTF-32だけで必要十分だったのにどんどん複雑にしていって、
UTF-32でも不便になったからUTF-8でいいでしょ？
どうせ単純には扱えずライブラリ使うしか無いんだから。
という必要十分な文字コードを捨てたというのが現実
宇宙に存在するすべての知的生命体が用いている文字すべてを網羅するのがUnicodeの理念。
たったの32bitで足りるわけがない。
文字コードのスレッドなのにUnicodeがわかっていないやつらばかりw
UTF-32じゃなくてUCS4じゃないの？内部コードに便利なのは
>>588
UTF-16を16ビットで1文字を表すと思い込んでいる人間がいるが、16ビット単位でデータ扱うだけで、1文字が32ビットのこともある。 ビットサイズ固定でどうにかなると思っていた時期が俺にもありました。
>>591
スレの流れみた？UTF-32の話をしてんだぞ？ 6 仕様書無しさん sage 2019/08/31(土) 11:36:13.12
日本人ならＵＴＦ１６を掲げるＪａｖａを支持すべきだ
>>598
それは理由が書いてないから、読む価値ある？ なんで毛唐の決めたコードを支持するのか、意味が分からん
ネットウヨの類は米英には尻の穴まで晒すようだし困ったものだ
>>597
じゃあ >>586 はスレの流れを遮って，古い話題を煽り文句で蒸し返した挙句，
碌な知識も持ってないことを晒してしまったヤベー奴ってことになるけどいいの？ re2のようにUTF-8にしか正式対応していない正規表現ライブラリもある。
寧ろre2がUTF-32に対応すべきでは。
もしくはiconv使う。
NKF(Network Kanji code conversion Filter)を使えば？
Ruby にも、NKF モジュールがある
どこぞの皇帝や中国王朝みたいに文字の方を変えて宇宙統一してしまえば良い
文字コードに合った文字だけ使えば解決
収録文字数が2の16乗を超えた時点でUTF16は破綻したんだから、サロゲートペアなんて
煩雑な延命策を取らず、UTF32に完全移行すべきだった。
UTF16を残したせいでUTF32にも皺寄せが来ている。UTF32ではU+FFFFFFFFまで
対応できるはずなのに、UTF16のサロゲートペアで表せるU+10FFFFまでに符号空間が
制約されてしまった。つまり、実質的に32ビットではなく21ビットコードになってしまった。
UTF16を全廃しUTF32を本来の32ビットまで拡張すれば、異字体を異字体セレクタなしで
収録できるから、すべての文字を32ビットで表せて単純明快になる。
>>611
いろいろ間違ってるなｗ
まずUTF-16という仕様にはサロゲートペアが最初から含まれてる
UTF32に完全移行って何を移行するっていうんだ？互換性がないんだから
既に使われてるものを簡単に変えられるわけがない。
UTF32が21bitコードになってしまったのはUTF-8のせいだ
21bitあれば209万7152文字を表現できるんだから異字体セレクタなしで十分収録できる 異体字セレクタが導入されたのは別にコードポイントが足りないからじゃないだろ。
異体字なんて数が限られているし、それ以上に役に立たない絵文字をバンバン追加している状況だし。
MSがUTF-16を採用したせいで廃止しようにもできないだろ
CP932とSJISとUTF16が生き残ってるのもだいたいこいつのせいだ
>>612
>まずUTF-16という仕様にはサロゲートペアが最初から含まれてる
あれ、そうだった? だとしたら、UTF16は最初から破綻していたってことだな。
変なものを作らずにUTF32を導入すべきだった。
>UTF32に完全移行って何を移行するっていうんだ？互換性がないんだから
>既に使われてるものを簡単に変えられるわけがない。
シフトJISからUnicodeへも互換性がないのに移行が進んだだろ。
>UTF32が21bitコードになってしまったのはUTF-8のせいだ
UTF8は可変長だから、32ビットでも表そう思えば表せる。
21ビットになったのはUTF16のせい。
>21bitあれば209万7152文字を表現できるんだから異字体セレクタなしで十分収録できる
収録した記号は他にも色々あるし、U+F0000～U+10FFFFは外字領域だし、
21ビットだけでは心許ない。
>>613
異字体セレクタは同じコードでもAdobe-Japan1とMoji_Johoで字体が違う
滅茶苦茶な欠陥規格だから、さっさと廃止した方が良い。 >>616
> UTF8は可変長だから、32ビットでも表そう思えば表せる。
無理。UTF-8は「自由に可変にできる文字コード」ではない。
ビットパターンが決まっていて最大21bitまでしか表現できない >>618
原理的にはUTF8は「自由に可変にできる文字コード」で32ビットも表せる。
UTF16の制約で符号空間が21ビットのU+10FFFFまでと定められたから、
UTF8もそれを超えるコードを規格外とみなすようにしただけ。 >>619
エンコードと文字コードを混ぜんな
おまえみたいな奴がいるから混乱するんだよ
少しは馬鹿を自覚して黙ってろ >>614
JavaやJavaScriptの内部エンコーディングもUTF-16だが >>614
MSがSJISやめたら、世の中の既存の文書が
UTF8にでも変わると思ってんの？
魔法ですか？ｗｗｗ マジレスするとOOXMLとかXPSとか「ある程度便利だけど既存の規格で十分じゃない？」というMS独自規格を、
MSが企業に圧力を掛けたりして広めてきた歴史を言ってるんじゃなかろうか。
念の為言っておくとOOXML←OpenDocument、XPS←PDFね。
>>625
所でLinuxもデスクトップ環境も
一つに統一したほうが良いのではないか？ん？ PDFはアドビのプロプラフォーマットってイメージが抜けないｗ
そのうち「MSはUnicodeを潰すためにCP932を作った」とか言い出す奴が出てくる
Windowsの内部でCP932に依存している。
英語版Windowsも含めて日本語文字コードが内部で使われている
って思ってるやつは本当にいる
>>627
LinuxはWindowsとは思想がほぼ真逆だからね。
多様性を重んじる。俺はそっちのほうが好きかな。
でもそれを至高とするあまり，古いカーネルや別の派生版との互換性が，Windowsのそれらに比べてない。 >>628
当時PDFは国際標準にこそなってなかったが，
オープンフォーマットだったし，様々な場面で使われてた。
ただ描画ソフトがクソ重たいのしかなかった記憶がw >>634
だから多様性を重んじるっていうのは
競合するフォーマットが複数できるってことで
（例えば画像フォーマットや圧縮フォーマット）
Microsoftが独自フォーマットを作るのと同じ思想なんだよ >>635
> オープンフォーマットだったし
PDFはオープンではありませんでした。
プロプライエタリだって言ってるだろ >>633
いつの知識なのかw
Windowsは表面的にはSJISで、内部ではUTF-16だ。 > Windowsは表面的にはSJISで
ほらな、SJISじゃないって言ってんのにSJISだっていう
潜在意識レベルでそう思い込んでるから治しようがないｗ
WindowsというよりWindowsアプリが特定のOEMコードページやANSIコードページに決め打ちして作られてる物があるということだろ
他言語の状況は知らんけど日本語以外でも似たようなものだろうな
Linuxの思想自体は多様性を重んじるのかもしれんが、ユーザーはそれに反して
「UTF-8以外死ね」みたいに言う奴多いよな。
そうはいってもLinuxはASCIIと互換性がない文字コード（例 UTF-32）は死ねだからｗ
影響範囲が大きすぎて、LinuxはUTF-16とかUTF-32には事実上対応できないんだよね
文字集合を符号化するのは、文字の区切れが判断できないからって解釈してんだけどあってる？
>>634
>多様性を重んじる。俺はそっちのほうが好きかな。
ところでホモにつきまとわれたらどうする？ >>644
ホモであることは否定しないが、ホモは嫌いという俺の感情も尊重していただきたい
これが多様性だ! >>645
ホモにつきまとわれて困ると友人にこぼしたら、
性癖を暴露されたとか言われて更に嫌がらせで自殺された事件？
ああいうの見てると、ホモの権利拡大とかしちゃいかんよなって思うよなあ >>639
Windowsが作るシステムファイルもSJISですよ？ >>649
延々と嘘を書くのはやめてもらえませんか？ まあWindowsはNTカーネルとは限らないからな
>>653はNTカーネルに限ると完全Unicode対応って意味やで ここでUnicodeといっちゃうあたりの頭の弱さよ
補足すると、Unicodeは文字列集合で
符号化方式がUTF-16やUTF-8など
どの符号化方式であってもUnicodeといえる
>>655
さて、何か言い返したい言葉は有るかね？ どうせ言い返す言葉は無いだろうから
待ってても時間の無駄なので先に言っておくと
何も言わない or 捨て台詞はくだけ なら俺に喧嘩売らなければいいのにｗ
完全Unicode対応ならどの符号化方式も対応してなきゃダメだろ
※ LinuxはUTF-16、UTF-32に対応していません
※ MacもUTF-16、UTF-32に対応していません
他者を貶めたところで>>654が真実になることはない じゃあNTカーネルに限ってはUnicodeっていうのは正しいってこと？
どーしても我流を貫きたいんだなw
まあ他人の人生だから干渉するつもりはないが，そういう生き方は苦労すると思うぞ？
本当に短縮したいところは日本語ページのパーセントエンコードされたところだがうまくいかないもんだな
日本語のページも短縮URLにできるんだけど，そうじゃなくて？
文字通り文字コードのエンコードを間違えてるんだろう
[%E5は無効なエンコードです。メインページに戻る。]
これ使われた順に生成されていくの？
そのうち4文字になるんかな
絵文字などサロゲートペアが必要な領域をUTF-7で表現するとUTF-32よりもバイトサイズが大きくなる。まめな。
utf-7が使われてる環境とかデータとか出会ったことが無い
>>678
違う
君の理屈だと中国はチベットの一部ということになる UTF-8もUTF-7も「ASCII互換にしようと思えばできる」文字符号化方式で
UTF-16/32は端から過去互換性を捨ててるっていう理解OK？
684デフォルトの名無しさん2019/09/21(土) 17:13:19.94ID:AMltcnvP
>>682
ちゃんと仕様読め
685デフォルトの名無しさん2019/09/22(日) 02:18:18.82ID:tTe+mIIa
>>682
意味がわからない
686デフォルトの名無しさん2019/09/22(日) 11:35:45.78ID:LQCFANDg
>>682
OK
----
どういうことなの… 揚げ足取り終了。
質問。皆さんが普段使っている文字コード変換ライブラリでおススメはなんですか。
お勧めもなにもiconvかICUで大体用は足りる
それで満足しなきゃ自分で作るしかない
文字コードの変換だけ？
いまどきのまともな言語環境なら変換元のエンコーディングさえ分かってれば標準機能で出来るだろうに
それとも全角⇔半角の変換みたいなのをやりたいってこと？
Windows SDK付属のデバッグ用ソースを見たところmbstowcs_sの文字コード変換は、Win32APIであるMultiByteToWideCharを使っているようですね。
MultiByteToWideChar / WideCharToMultiByte 最強
null-terminatedとそうでない場合の仕様の違いをちゃんと理解してなくて
バグった挙句によけいな1byte追加しちゃったりした思い出。
python3でlogging使ってsyslogに出力すると
ASCIIで出力してもなぜか最後に\0が付いてログが残る
鯖側のsyslogdの方で付いてるのかと思ったが
そうじゃなくてpython3が勝手に付けてるみたい
python3のstringがunicode化したときにバグ入ったんかな
python2のときはそんなこと無かった気がする
深い闇を垣間見た気がする
handler.log_format_string = '<%d>%s'
だと no attribute
handler.setFormatter(logging.Formatter('%(message)s'))
だと結局 \0 付いたままでした
コンストラクタ呼ぶ前に
logging.handlers.SysLogHandler.append_nul = False
で解決しました
thx!
エンコードされた文字のバイト並びが
utf-8 と cp832 で同じ(にみえる)ものってどんなのがあります？
そもそも 3bytes と 2bytes なのは仕方ないのですが
utf-8 だと (xx yy zz)
みたいなのが
cp932 だと (xx yy) 00
逆に
cp932 だと (uu vv) (ww xx) (yy zz)
みたいなのが
utf-8 だと (uu vv ww) (xx yy zz)
みたいなのでも良いです
そもそもありえない？
cp932 ってことはいわゆる半角カナも入れて良いのカナ
出来れば「美乳」みたいなクオリティ高いのが良いです
美乳ってどういう特長を持ってたんだっけ？
エージェントが読み込んだときに確実にShift JISだって判定できるんだっけか。
PC初心者です。
あるexeファイルをコマンドウインドウで開く。ということをしなきゃならないんだけどシフト＋右クリックしてもコマンドウインドウで開くというのがありませんでした
調べたら、コマンドウインドウで開くを表示したい場合メモ帳で名前を付けて保存の時に文字コードをUnicodeにして保存し実行したらレジストリがどうたら書いてあったんでしようとしたら、文字コードにUnicodeがありませんでした。
どうしたら良いですか？
>>708
>どうしたら良いですか？
諦める
高望みするから人間は苦しむんだよ >>704
ASCII以外ではたぶん無いんじゃないかな
cp932としてもutf-8としても正しいバイト列で
それぞれが別の単語になるケースを探したことがあるけど、
それでも両方が意味のある単語になる例は見つけられかった
どういう目的でそういう例を探してるの？ >>708
cmdにd&dかバッチファイル作れ
これ以上はスレチ ブログラムソースをUTF16やUTF32で書いてる人いるの？
ブログラム内の文字列のデータじゃなくてブログラムの地の部分
まるでUTF-16文書は読むのに向かないかのような発言やな
まともなエディタなら読めて当然。
青っぽいデザイン変更で入口が使いにくくなってる辺り?
