文字コード総合スレ Part12
レス数が1000を超えています。これ以上書き込みはできません。
■これまでに行われた議論
・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も来年・・・じゃないやもう今年リリースされる予定のはずだし 絵文字は象形文字の発展版なんだから
文字扱いするのは当然 現代の文字は自然発生するわけでも王朝が発布するわけでもなくユニコードコンソーシアムが追加するのだ >>97
世界には文盲がわんさか居るから結局象形文字が必要ってことか 当の日本人にすら絵文字を扱いきれてなかったのに
そんなもんをコード化したら破綻するに決まってるんだよなぁ…… 1964年の東京五輪での案内表示がきっかけでしょ絵文字の開花は。 >>99
絵文字と象形文字の間には確固たる断絶があります、おっしゃるような連続的なものではないと考えています
例えば、ある象形文字と別の象形文字との違いははっきりしていますが、ある絵文字と別の絵文字との違いを示す具体的な指標はないのでは？
それとも、これは私の知らなかったことですが、もしかして絵文字の内容はピクセル単位、あるいはベクターイメージですでに定義されているのですか？ 便器に◎とか〓とか描いてあっても何のことか判らんで悩むだけやぞ 田穣崇さん『ドコモの絵文字にうんちを入れたかったのですが、社内で大反対されまして…』 うんちの絵文字がUnicodeに登録されるまでの裏話
https://togetter.com/li/1305754 カフェで野良WiFiのSSIDが絵文字になってたわ
うっかりつなぎそうになった 形状バリエーションも欲しい
巻きうんち/一本糞/ビチグソ U+FFFCとU+FFFDの違いってなんだろう。
一応https://www.unicode.org/charts/PDF/UFFF0.pdf←ここを読んでみたんだが
U+FFFCが「Unicodeの範囲で異常」、U+FFFDが「Unicodeですらない」
ことを示す文字なのかな？ 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
だから文字のない言語は無理だろ？
という話だけなのに、なんでひねくれてるの？ なぜ文字コードスレで文字の無い言語の話をしようと思ったのか いきなりですが質問失礼します
とあるオンラインゲームをやってまして
そこで名前のソートの規則から、そのゲームが採用している文字コードの符号化方式を知りたいのですが
各コードにおいての文字の並びと、実際のゲーム内での文字のならびに違いがあったので素人の私にはお手上げ状態です
素人なりに6時間ほどぐぐってみたりしたのですが、それらしい符号化方式は特定できませんでした
スプレッドシートに、ゲーム内で実際にソートされていた文字を順番も合わせてまとめました
文字コードや符号化のスペシャリストのみなさんにこれを見てもらって、一番近い符号化方式をお教えいただけたらうれしいです
文字ソートまとめ、上から下に向かって昇順になっています
https://docs.google.com/spreadsheets/d/1QbN1zHY8BLnUampdKYVIRzK34SrTdq2gkMBgct03Fu8/edit?usp=sharing
それではよろしくお願いします このサイトを参考に文字コード引っ張って来てみました
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
ほとんど初心者なので知りませんでした こういう関数があるんですね
専門用語とかだけでも出してもらえて嬉しいです
何も知らないのでぐぐる事もできなかったので助かります
単語さえわかればあとはこちらで調べますので
他にも関連した情報がありましたら用語だけでも教えてもらえると嬉しいです Unicode(UTF-8, UTF-16)はコードポイント順とは別にソート順のデータが定義されてるんだけど
記号類がアルファベットの前に来るってのはそれっぽいような
http://www.unicode.org/Public/UCA/latest/allkeys.txt
でも〆の位置は明らかに違うなぁ 例えば韓国製のゲームなら韓国語での文字コード順になってるかもな
データベースに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! https://unicode.org/cldr/utility/character.jsp?a=1D00
↑ここにアクセスしても空白のページが表示されるだけなんだけど
みなさんもそう？
前までは確かに存在したページの筈……。 確かに空白だな、と思ってソース見たら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
さない
「あたしわ ゆるさない」 だろ >>207
長すぎてどこまで読んだか判らない
>>217
ありがとー >>220
>>192は俺な訳だがなぜ無関係なあなたが返事をしているんだw UAX #29: Unicode Text Segmentation
http://www.unicode.org/reports/tr29/tr29-35.html#Modifications
Unicode 12.0.0 では新しく U+FF10..U+FF19 の全角数字を数字扱いするようになったのね。
UAX #14 では Ideographic のままだし何で今頃変えたのかよく分からないけど。 これから漢数字とか丸数字も数字扱いしだすゾォー^
属性定義するのはいいけど定義をコロコロ変えてんじゃねぇよ >>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
そもそも字が下手過ぎて習字の基本すら出来てないやろ
和にしても
ノ木口
なのに
ノ丶木口
って描かれてる アドビのフォントが新元号「令和」に対応--2パターンの合字を追加
https://japan.cnet.com/article/35135080/
この手の合字をもっと増やしてもいいと思う。絵文字をボコボコ増やすよりも有意義だ。
㌀、㍇は既にある。ゲートウェイの合字があると面白い。
山手線の新駅の名前に使える。 集合住宅名にありがちシリーズだと㌞・㌪はあるがヒルズとかテラスとかがないな Unicodeに入れるのはむりぽ
AJ1ならワンチャンあるかも >>250
誰でも読み書き出来る字を選ぶという配慮であろう。
令は小学4年、和は3年で習う字だ。
今時のキラキラネーム(DQNネーム)とは違う。 常用漢字から選ぶとは最初に告知されてたが、
2010年追加の常用漢字の中には第２水準以下だったりJIS2004で字形変更されて
2点しんにょうや古い食へんの字があるよな。
教育漢字にはならなくて小学校では習わない字のままだったけど。 あの「令和」っていう習字の画像って公文書として入手できないのかな。 どのメーカーの半紙と墨汁を使ったか公開すればバカ売れだな https://twitter.com/yanok/status/1113052042254143489
令の字に関してなぜかU+F9A8なんて話が流れてきた。韓国KSコード由来の互換漢字。
これは『改訂新版 プログラマのための文字コード技術入門』p.110に書いたような理由で入ったものだけども、扱うことはまずないのでは。
それ言うんならU+2F24の「⼤」を使った「⼤正」は今までチェックしてたのかい?
これはUnicodeになぜか別立てで入っている康熙部首の符号位置。
https://twitter.com/5chan_nel (5ch newer account) >>264
電子化された契約文書に大正の年号が使われることがないから影響もなかった。 大正時代に生まれた人なんかいくらでも電子管理の対象になりうるだろ 大正はIME類に成語として登録されてるからよっぽどでもないかぎり他の大は出てこんわね。
でも令和は現状自由変換状態で、この状況はみんなのスマホやPCが“令和対応”のものに更新されるまで当面続く。
そこに「こっちの令が正しい形」説が追い打ちをかけてきてるのが困ったところ。 じゃあ令和もIME登録したらいい，って思っちゃうのは素人考えなんですかね。 他人のIMEに一括登録できるなら何かのプロだな。
あるいは単に問題を取り違えてる素人かもしれん。 江戸時代の地震記録した古文書495点 市民参加して解読完了！「くずし字学んだ」 2019年04月07日 06時00分 @ハザードラボ
https://www.hazardlab.jp/know/topics/detail/2/8/28696.html
https://www.hazardlab.jp/contents/post_info/2/8/6/28696/09_01.png
江戸時代の古文書に記録された災害の歴史。くずし字を現代文字に直しながら読んでいくプロジェクトだ（京都大）
京都大学は、地震研究所図書室が所蔵する江戸時代の地震を記録した古文書495点の解読を終了したと発表した。
2017年1月にスタートした解読作業は、4600人を超える一般市民が参加してくずし字で書かれている古文書を、一字ずつ現代文字に活字化するという
プロジェクトで、過去の災害の歴史を学ぶきっかけにつながるという。
古代から地震が多かった日本では、『日本書紀』に残る416年の「允恭（いんぎょう）地震」を最古として、数多くの史料が残されている。しかし、解読されたのは
そのうちのほんの一部で、有益な情報のほとんどが手付かずの状態だ。 くずし字学習アプリを使ってゲーム感覚で学ぶ
https://www.hazardlab.jp/contents/post_info/2/8/6/28696/cover.jpg
翻刻が終わった『地震年代記』（国立民族博物館）
京都大学大学院の「古地震研究会」は2017年1月、東大地震研究所の図書室が所蔵する古文書495点をインターネット上に公開し、Wikipediaのように閲覧者が
現代文字に書き換えるプロジェクトを開始。これまでに4626人が登録し、このうち347人が実際に文字の入力作業に参加した結果、新書30?35冊分の文字数に
あたる465万文字が入力されたという。
「みんなで翻刻」というこのサイトには、数多くのくずし字のパターンや、江戸時代の本から収集した3000種類近い熟語が収録されており、
くずし字学習支援アプリと連携することで、初心者でもくずし字を学ぶことができる機能が備わっている。（翻刻＝文字起こし）
過去の災害の歴史を学ぶきっかけに
https://www.hazardlab.jp/contents/post_info/2/8/6/28696/apri.png
学習アプリを使って、ゲーム感覚でくずし字を学ぶ
スタート当初は、地震研究所二代目所長をつとめた地震学者の石本巳四雄（みしお）氏がコレクションした114点の災害史料の翻刻を目標としていたが、
開始から5カ月後には完了。その後、資料を追加することで495点すべての作業が終わった。
今後は、ほかの資料館が所蔵する史料も登録を進め、翻刻を続ける計画なので、興味がある人は今からでも遅くない。パソコン1台あれば誰でもアクセス
できるので、ぜひ一度サイトを訪問してほしい。古文書の解読の楽しさはもちろん、自分が住んでいる地域で過去に起こった地震の歴史を学ぶこともできる。 UTF-8って、制御コード含まれることはないんだっけか だぶりのコードもあるし
不正コードでおかしくなるシステムもある >>254
Unicodeに収録されている「パーツ」と「ほか」が追加されるとUnicode仮名合字が揃うから最優先 >>254
これ使えって言われそうだ
🇬🇼 役所から『楷書体の“令和”の“令”の“マ”を明朝体のように縦棒に直せ』と指示がきた「どっちでもいいはずでは」
https://togetter.com/li/1341711 これ結果的に包摂への理解が世間に広がれるきっかけになればいいなあ 元号合字は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ってフォント埋め込みできないの？ The Unicode Blog: Unicode Version 12.1 released in support of the Reiwa Era
http://blog.unicode.org/2019/05/unicode-12-1-en.html
The Unicode Blog: Unicode コンソーシアムは「令和」をサポートする Unicode 12.1 を正式リリースしました
http://blog.unicode.org/2019/05/unicode-12-1-jp.html
Unicode 12.1.0
http://www.unicode.org/versions/Unicode12.1.0/
Unicode 12.1.0ｷﾀｰ 令和は入れて金正恩は入れないのはダブスタじゃないんですか そちらの事情詳しくないんだけど最新版ではじょんうんもコード振られてるの？ いきなり?で草
外に向けて公式発表とかはしてないのか 令和の合字(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御愁傷様 地球外知的生命体との遭遇を前提に、拡張性を確保しとかないとね。 質問
https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0212.TXT
X0212補助漢字とUnicodeの変換テーブルは↑で良いのでしょうか?
補助漢字には詳しくなくobsolete下にあるのでこれでよいのかよくわかりません。 Consortiumが提供しているのはそれくらいかと 0x2237 0x007E # TILDE
これはやめた方がいいんじゃないかな…
後はまあ チルダは主要フォントは同じ字形になっちゃったから、
ユニコードNGの環境で初めて気づくことも多いんだよね つうか誰が何の目的で入れたんだよ
絵文字増やすことが目的になってるだろもう だってこれまで一般人からは存在も意識されてなかった文字コードの改訂が
「今年の新絵文字発表」化してから急に世界中の注目を浴びる一大イベントになったんだもん
そら浮かれるよ 鼻濁音を表す仮名か゜、き゜、く゜、け゜、こ゜、カ゜、キ゜、ク゜、ケ゜、コ゜は
JIS X 0213ではそれぞれ1文字としてコードが割り当てられたのに、Unicodeでは
半濁点なしの仮名と半濁点の2文字で表さなければいけない。Unicodeにも1文字として
収録してもらいたい。
辞書に使われる記号 [名]、[形]、(単)、(複) など ([ ]は角丸正方形、( )は丸囲み文字) も
欲しい。 >>399
鼻濁音はUnicodeにちゃんと提案したら通りそう。
辞書で使われる記号は外字や私的領域に配置するしかないんじゃないかな。 NHKの情報番組によると、最近スマホに移行した役者の役所広司さんはガラケーの絵文字が好きでスマホの絵文字が不満らしい。 >>400
テレビ番組表で使われる記号[字]、[ニ]、[多]、[声]、[吹]、[演]など ([ ]は正方形囲み文字) は
Enclosed Ideographic Supplement (U+1F2xx) として収録されたから、同じブロックの
空き領域に辞書用の記号も追加してもらいたい。 よくわからん
合成文字ではいけない理由って今時ある？ 池江 璃花子さんのツイート
https://twitter.com/rikakoikee/status/1135127518258667520
ポップコーンが美味しかった。
美味しいチャーハン食べたい。
チーズドックもマックのポテトも食べたい…🍟
美味しいお寿司🍣アボカド🥑
と、からみチキン
食べたいものと行きたいとこが多すぎる🐭🏰
https://twitter.com/5chan_nel (5ch newer account) この板に絵文字スレを別に作るのはいい案だとは思えない。一緒に扱ったほうがいい。
他の、スマホ系やネット文化系の板で絵文字スレを立てるのはそっちの文脈での必要に応じてやればいいが。 >>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で違いがあるような >>399-400
鼻濁音付き仮名文字は日本NBから提案したけど蹴られて今の姿になった。
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n2092.pdf
仮名文字に限らずシーケンスで表現可能な文字に単体の文字コードを割り振ってもらうのは
相当説得力のある理由が要る。
逆に辞書用の記号は提案書を出せば通る可能性ありそう。 >>443
いや、>>444も言っている通り嬲は「⿲男女男」以外で表わせないと思うよ。 将棋好きのおいらとしては、ひっくり返った「玉」「飛」「歩」とかも
登録してほしいと思うのだが。 >>448
Unicodeってそもそも将棋の駒 全部登録されてないんじゃ？ 笑→ケケ夭
とか
禁→木木示
とか
哭→口口犬
とか
と
畿→糸糸田戈
は同じ表現？ >>450
まあ機械処理向けの言語じゃないから
人が「分解できる」と思うかどうかだよね
ちなみに「畿」の部首って「田」なんだな。すげー意外。 >>449
ないよ。黒塗り五角形と白ヌキ五角形だけ。 文字表現ってことで
●●構えっていうと門しか思い出せないし
●●囲いっていうと口しか思い出せないけど
将棋の駒の白抜き五角形は囲いなんだろうか いっそのことCombining Diacritical Marks for Symbolsあたりに将棋の駒の枠線を登録してもらえればいい >>454
枠線の中に複数文字入れるのどうするとか
中に「と」みたいなのを表示したい場合それは本当に「と」で表現するのかとかいろいろややこしくなりそう
将棋みたいに中身が決まってるやつは一通り個別に並べてもらったほうがシンプルじゃないのかな… >>453
黒と白で、先手と後手を表しているだけだよ。 文章中に書くなら白黒五角形で十分だと思うが、なんで盤面まで表現したがるかな。 歩の裏の「と」があるべき位置に
「テ」だったか「〒EL」みたいな
意味不明な文字が書いてある駒セットを
観たことがあるけど
あれはなんだったんだろう
朝鮮語か？ Ｔ
三 みたいなやつ？
全ての「成金」の文字は「金」を崩した文字だよ。
「と金」も、本当は「と」と書いてあるわけではなく、
「金」を崩した結果、「と」みたいになっているだけだよ。 どうでもいいけどそのレスを見て
その内 崩し字も登録されそう…とか思ったw
太字のaとかがなぜか「文字」として登録されてるんだから金の崩し字が登録されてもおかしくない 歩兵の裏は金と同じ読みの今（きん）の崩し字をあてたので
「と」と極めて似た文字になったという説がある >>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に一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/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的にいいのか 絵文字をリガチャとして実装するという話を聞いたことがあるが
良いアイデアだと思う。
これ以上貴重な符号位置を占有しないで欲しい。 https://symbolset.com/
これとか。素晴しい発想だと思いませんこと？（お嬢様風） 見る側の環境によって、絵文字を使った側の人が意図しなかった単語に化ける現象が発生してしまう >>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フォントの常識は当て嵌らんぞ 推すなあ。
あえてこれ使いたいと思うならもちろん自由に使えばいいと思うが、
正直これを選ぶメリットがある局面はすごく限られてる気しかしない。 ISO/IEC 10646:2017/Amd 2:2019 - Nandinagari, Georgian extension, and other characters
https://www.iso.org/standard/73773.html
いつの間にか完成していた。 >>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 で保存してるのかイミフ なんか同じような原因で文字化けしてるページに対して
同じようなレスをした記憶が…と思ったら前スレにあった。
記憶障害じゃなくてよかったw
https://mevius.5ch.net/test/read.cgi/tech/1516629503/821-843 HTMLをiso-2022-jpにするのって
どこの文化なんだろうか？
Windowsはsjisだからありえないし
Linuxも昔の普通はEUC-JPだろ？
iso-2022-jpはメールにしか使われてなかったはずだが >>531
イシカワ マサヤスというのは誰だろうね。 石川雅康と石川哲志は親族だろうか？
どちらもICT業界から去ったのかな。 XHTMLが終わってしまって、そのまま放置の石川さん。 >>541
sjisやeuc-jpが整う前は、HTMLをiso-2022-jpにするのも選択肢の一つだったらしい
ttp://www.tohoho-web.com/lng/199801/98011002.htm >>547
http://の先頭のhを取っても付けても同じですよ。 > どこかの雑誌で、「charset=iso-2022-jp は自動判別の指定」と堂々と紹介された
http://web.archive.org/web/19980116120529/http://www.pro.or.jp/~fuji/horrible/horrible.kanji.html
えぇ……。 1998年当時のWebブラウザはキャラクタセットの判定すら怪しかった。 >>549
そのリンク先に書いてあるけど、iso-2022-jp が使われてるのはMSが発端なのか？
> name="GENERATOR" content="Microsoft FrontPage 2.0"
> というのが各HTMLファイルの先頭にあることから、Microsoft の FrontPage が 漢字コードがシフトJISのファイルであるにもか かわらず、iso-2022-jp の指定するからではないかと思われます。 >>540
流れは似てるが今回は指摘されてるURLが問題なんだろ
よりによってアイツがってやつさ あ、違ったわ。MSのはMicrosoft FrontPage 2.0がmetaタグの指定を間違ってるって話で
HTMLの内容がiso-2022-jpというのはまた別問題か
sjis以外あるかな？ってやってみたら他のエンコーディングも見つかったし
>>531は単なる文字コード変換ミスかな？
https://www.w3.org/People/mimasa/xmldev.html.ja.aaaaa ブラウザって一時だけでも拡張子によって文字コードを判断してた時期があったの？
俺の記憶にはないのだけども……。 だからこれは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よりも
ドキュメントからの文字コード判定の方を重視していた。
なぜならセキュリティというかサーバー運営者がよくわかっておらず
設定変更の必要性を理解できていなかったので設定されてなかった
たとえ設定変更ができるサーバーでもユーザーが理解していなかった
そんな時代だからブラウザで表示できれば良し程度のレベルが普通で
今からするとチェックが甘かった。その当時の間違った文字コードのページが今も残っている。
たぶんこんなところ >>559
お前のレスの >>556 には jis って書いてあるだろω
お前が原因 >>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。誰も使っていないように見えてそうでもない。 【名案】0～9の代わりにUnicode全文字を使えば「65536進法」になり，なんでも1桁で表現できるから2桁の計算が不要！ ・・・ためしに「65021－65018＝3」ってどう書くの？
https://togetter.com/li/1396827 UTF-16でも8バイト必要なのに、32bit（4バイト）に収まるわけ無いだろうｗ
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/ 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
まあ他人の人生だから干渉するつもりはないが，そういう生き方は苦労すると思うぞ？ 全然関係ないけどWPへのリンクはMWの短縮URLが使える。
https://w.wiki/8Ew 本当に短縮したいところは日本語ページのパーセントエンコードされたところだがうまくいかないもんだな 日本語のページも短縮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のときはそんなこと無かった気がする ttps://bugs.python.org/issue12168 深い闇を垣間見た気がする
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文書は読むのに向かないかのような発言やな
まともなエディタなら読めて当然。 青っぽいデザイン変更で入口が使いにくくなってる辺り? 文を書くときに？や（）などの半角にも全角にもある文字はどっちを使うべきなのか迷う。
数字やアルファベットは半角を使うのが普通だからASCIIコードにある文字はASCIIコードを使った方がいいんだろうか JIS X 0208 を 0201 のスーパーセットにしなかったのが諸悪の根源 そもそも世界中の文字を一つの体系で包括できると考えたりしたのが…ﾌﾞﾂﾌﾞﾂ サル共がコンピュータを使わなければ面倒がないのに
とか思われてるよ ASCII に含まれてる記号は半角で入力してる
っていうか IME で半角優先にしてるのでそっちばっかりになる
IME ON の状態であってもスペースももちろん半角だ チルダとかハイフンマイナス、引用符あたりは迷う。
これらは単に全角と半角の関係ではないんじゃないかという気がする。 0-9A-Za-z は半角だけどその他はちょっと迷うかな
! や ? は書いてるのが日本語漢字仮名交じり文なら全角にするかも 俺は「，」のほうが寧ろ収まりがいいように見えるけどな。
感性で判断するんじゃなくて，論理的根拠をもって「，」か「、」かを決めるべきよね。 日本語の文章は分かち書きをするわけではないから、
点があるのにコンマのような後ろにスペースを要する記号を使うのはおかしいと思う。
丸の代わりにピリオドを使うのも同じ。
それにしても、公文書の混ぜこぜの用法はどっちつかずだよな。
もともと、和文タイプライターで使われていた用法なのではないか？ 使ったこと無いからわからなかったが、全角コンマなんてのがあるんだな。
これって、全角英数と同じで、日本語の体裁に合わせるためにわざわざ作られた文字だよねぇ。 >>733
フォント次第ながらも「，」は半角カンマ「,」と一目で見分けることができない。
一方「、」は全角しかない。よって誤植の起きにくい「、」で統一するべき。 >>736
半角の､だってあるだろ
AAとかでよく使われる 見分けられないで言い切られたらコーヒー噴くしかない 文字コードスレなのにいまだに「全角」とか言う奴いるんだな ここまで無知だと辛いどころか辛さも感じないほどにアホなんだろうな
739は カッコは半角と全角でベースラインが違うフォントも少なくないんで
囲う文字に合わせてる そもそも日本語は句読点は使っていなくて使われ始めたのが
欧米のカンマやピリオドの影響で明治後期くらいからだからな FULLWIDTHとか出てくるのを全角以外にどう呼べと 句点の代わりに「候(そうろう)」を使ってたんでしょ、昔の人は。 日本はもともと縦書きで「，」なんて使ってなかっただろ？
縦書きでどの位置に「，」を打てばいいのよ？ 縦書きは、を使って横書きは，を使えばいいじゃん
なんで臨機応変に対応できないんだろう？ 臨機応変に縦書きと横書きを変換するからだよ
ウェブ上では横書き、本にしたら縦書きとかな 漢文で書かれた本の中には、句点は、文字の横に○をつけていたものがる。
江戸時代のくずし字でかられた読み本は、句読点なし。読む人が判断することになっている。 教科書フォントに慣れ切って高卒レベルの古典教養しかない現代人は「くずし字」の原書をほとんど読めない問題。 中学高校の古典の授業で、原書を写真印刷した文書を読ませる機会を与えるべきだろう。
活字慣れした現代人は太平洋戦争中の日記や戦場から送られてきた手紙さえ読めない。 厨二満載の文集が他人に読まれなくなる日も近いんだな
よかったワープロが普及する前で アメリカでも筆記体が廃れつつあるんじゃなかったか
せいぜいサインする時に使うくらい ラテン文字は筆を選ばないでも問題無いが
漢字や仮名は楷書でも筆の運びをちゃんと学んだ方が近道 ん? 江戸時代から句読点はあったよ。
多分、由来は漢文の補助点で句の切れ目に「、」を打って読みやすくしたもの。文末も句点だった模様。 金とか何回か選ばれてるのはあるな
二年連続とかは知らん もうそろそろコンピュータの世界では
３２ビット固定長の文字コードを使うようにしても
良いのじゃないだろうか？ >>762
ascii 的な世界（合衆国界隈とか）が発狂するので、utf-8 がつくられたのだと思います
まあコード内では utf-32 で統一するのがスマートですね C言語がASCII前提としていたので、
UTF16やUTF32では互換性を保てなかったのが理由 じゃけん戸籍に登録されてる異字体全部収録しましょうね〜（鬼畜） 固定長好きな人が定期的に出てくるのはなんでなの？
セレクタとか合成文字とか固定長に押し込むの非現実的でしょうに 21bitもの空間与えたら要らん文字まで突っ込みまくってごみ溜めみたいになってしまったじゃないか。 絵文字は特に漢字に馴染みが無い連中が嬉しがってるけど、象形文字の発明前に戻ったようだよ
具材がどうだとか細かなこと言ってて抽象化とは程遠いし、少なくとも色は与えるべきじゃなかった 16bit固定なら世界中の文字が記述できるとして始まったのがそもそものUnicodeだからな >>757
お前の一般が何かによる。
正式な正書法になったのは明治から。江戸時代の正書法は漢文の白文か武士の候文。
一方で庶民向けの版本や貸本では江戸期から句読点が使われてるので、本を読む層には馴染みがあった。
あと手習いの手本とかにも句読点があるので文字習う段階で知識として知ってるのでは。 >>772
ちんちんの絵文字は
剥けちんと包茎と勃起前とか勃起後とか色々バリエーション必要ですし >>777
竹島はどこの国の領土ですか？
注意：「なぜその質問をしたいと思ったのですか」みたいな
質問を質問で返すようなクズな真似はしないこと 質問じゃなくて、馬鹿にしてるんだろ
え？それ面白くないよ？面白いと思ってんの？プークスクス
という意味 >>780
違うと思う
QZは韓国人だから答えられないんでしょ >>779
＞「なぜその質問をしたいと思ったのですか」
いやはや、私のパターンを熟知されているようでなにより、です、ちょっとうれしくなりました 憲法9条を改正するだけじゃダメなのよ。
軍の統帥権が天皇と征夷大将軍(内閣総理大臣)のどちらにあるのか明確にしないと。 >>762
そのまえに格納方法をビッグエンディアンかリトルエンディアンで統一してくれ >>779
竹島は日本の領土で、独島は韓国の領土だよ
なぜか韓国は竹島のことを独島だと言い張ってるけど
独島は別の島ですから、残念 「くずし字」ＡＩが解読 ラーメン判別法も応用！ | NHKニュース
2019年12月2日 19時21分
https://www3.nhk.or.jp/news/html/20191202/k10012198561000.html
「くずし字」解読は「文系」より「理系」向き！？
驚き！ ラーメン判別の技を応用
ＡＩの解読能力 高めるポイントは？
数億点もある難読資料 高まるＡＩへの期待
歴史資料の研究者からも期待の声 可変長の文字コードは、CPUのパイプライン処理とは相性が悪いはず。大量の文字
データのやりとりやファイルサイズが小さくなるのは理解できるけれども。
でもそれは圧縮機構を別途に設けたのではだめなのか？ 異体字セレクタとして色だけじゃなく斜体、下線、太字などのHTML的な要素も入れてみたらどうか HTMLががんばってCSSに追い出したスタイル要素を文字コードが取り込んだらかわいそうｗ Unicodeは文字コードじゃなくて文字シーケンスと名前を変えるべき 黒板太字 - Wikipedia
https://ja.wikipedia.org/wiki/黒板太字
とかはかなりスタイル要素入ってると思うな。
てか数学用分野だけやけに優遇されてない？ 発音記号なんかはただの小文字aの異体字で意味が違ったりするからなあ
でもそもそもを言い出したらYとVが元は同源だったりして、「純粋な文字」を綺麗に定義するのは無理よ >>801
「優遇」っていうか，そういう文字を収録してた符号化文字集合と互換性を持たせるために導入したんでは。
例えば「(株)」っていう文字とかに代表される囲み文字はかなり日本語圏に偏向してるけど，
これだって日本を優遇してるんじゃなくて，日本で開発された符号化文字集合がそういう文字を含んでたから収録されている。 IMEの辞書とかは数学とか物理とか理系用語にめちゃくちゃ弱いイメージ >>805
IMEってMS-IMEのこと？
それともかな漢字変換全般？ SKKは既定の辞書はすごく弱いけど語句登録がほぼ一瞬でできるのが利点よね。 あけましておめでとう！
今年もこのスレの皆さんに多幸感がありますように！���������� あけましておめでとうございます
ISO/IEC 10646の新版は今年中に出るかな～？ Consolasは良いフォントだとは思うのだけど、全角中黒「・」(U+30FB)が半角中黒(U+FF65)と判別しにくいところが気になる。
まぁ、文字コードの問題ではないんだが。 特定のフォントの特定の文字だけ任意に入れ替えるパッチとかフックとか無いんだっけ >>813
レスありがとう。どのOSにもそういう仕組みはないと思う。
よく上げられる例として、フォントの明示的な設定なしに\マークをバックスラッシュとして表示することはできない、というのもあるし。
一文字づつ判定して適切なフォントに変えて描画する処理を個々のアプリ自身が実装する必要があるはず。 ぷにコードに関するチラ裏
localghost👻ってかわいくね？
→今まで危険そうで敬遠してたIDNに興味をもつ
→WikipediaとRFC3492を頼りにPunycodeのアルゴリズムを調べる
→エンコーダを自前で組んでみて、idn2コマンドやPythonの'idna'エンコーディングと比べてみる
→正規化する必要のある文字がどんどんふえる
→idn2とpythonのidnaってかなり違わくね？？ <-イマココ
idn2はギリシャ文字の「語尾のシグマ」ς(U+03C2)をσにしないし、あとチェロキー文字の大文字？を小文字？にしないし、けど小文字？はSupplementなのがなんかあやしいし、でidnaとどっちが正しいのか考えるのが面倒になって投げた 6月のWG2は高松になったのか
また国外から来にくそうな Unicodeは完全にコンソーシアムのおもちゃになってんな タピオカミルクティーがあるのに、将棋の駒がフルセット揃っていないのは納得できない。 >>825
詰将棋用に上下逆の漢字を入れて欲しかった 要するに新種の漢字なんだな
国ごとに生活が違うから、結局何万種必要になる 漢字の扱いは本当に難しい
手書きの分析しているソフトは本当に賢いと思うわ
まああれは面倒な文字はそもそも判定せず、
主要な文字から似たものを選んでいるだけではあるが・・・ 825だが、将棋の駒がダメな理由は、>>469 にある通り、
> インラインテキスト中で使われている用例が示されていないのでrejectされたらしい。
ということらしいが、なら、タピオカミルクティーにインラインテキスト中で
使われている用例があるのか、と言いたい。だから納得できない。 架空の文字は登録しないというポリシーもあったと思ったが、emojiに関してはやりたい放題だな。 漢字以前の象形文字モドキの再発明だからなぁ
取捨選択もなく全然洗練されないまま数だけ増えてる 政治的に正しい仏教徒としては、墓石のバリエーションの少なさには納得いかんぞ >>841
政治的に正しい仏教徒とは何ですかね？
アホな創価学会員が言いそうな発言ですが。 絵文字ってここにどう書き込めばいいんです？
☸️
↓
☸
専ブラでは絵文字として読めるがWebブラウザー(Chrome/旧Edge/IE11@Win10)で見ても◆◆状態でうまく表示されない… >>842
全部あるぞ。お茶は「湯呑み」として。検索の仕方が足りない。 固定フォントのターミナルのような環境である文字のフォントの幅が全幅か半幅か判別する確実な方法ってありますか？
Unicode前提です
Unicode的にアジアンなんとかというドキュメントでそれに触れられているのを見つけましたが
結局のところ使用されているフォントで決まるような気がします
となるとCLIアプリが表示する前に判別する方法はないような
表示したあとならターミナルにカーソル位置問い合わせればわかりそうだと思いましたが >>844
うちのChromeはちゃんと出てる
ffでも問題なし >>847
前にpythonで書いたときは
unicodedata.east_asian_width()
使ったと思う
Win32APIだと表示前に文字列全体の描画幅を求める方法があったと思う >>847
・Unicodeでは文字幅は 0(結合文字)、1(いわゆる半角)、2(いわゆる全角)、1か2(曖昧幅) のいずれかに決まっている
・1か2になるのはαや☆などであり、東アジアの環境で2、それ以外で1
・wcwidthで調べるとその値を返すが、曖昧幅への対応がどうなっているかは分からない
・linuxのglibcは、データを自分で修正しない限り曖昧幅は1扱い(LANG=ja_JP.eucJPすれば2にはなる)
・CLIでのカーソル位置はカーネルのttyドライバが担当しており、そもそもフォン卜の情報を持っていない
・linuxカーネルでは全ての文字が(全角も)幅1扱い
・行編集もtty担当なので、catをそのまま実行して全角文字を入力後backspaceするとカーソルがずれる
・多くのシェルはwcwidthで入力/削除された文字やプロンプトに表示する文字の幅を調べ、必要に応じてカーソルを移動させる
・ターミナルはwcwidthまたは同等の独自関数(曖昧幅の設定ができることが多い)で文字幅を調べて、実際に表示させる
・等幅フォントでも曖昧幅の文字がどちらで実装されているかそれぞれ異なる上、ターミナルはフォントの文字幅情報を使わないことが多い(プロポーショナルでないことのみ確認)
・↑により、文字が重なったり変な隙間ができたりすることがある
・一部のターミナルはwcwidthの結果に従うように文字を潰したり引きのばしたりして表示する(minttyとか)
・アプリ(シェルとか)、ライブラリ(ncursesとか)、端末マルチプレクサ(tmuxとか)、端末エミュレータ、カーネル(tty)、フォント全てで想定する幅がそろっていないとうまく動かない
・日本語フォントの多くは曖昧幅2なので、linuxのCLIではαや☆がおかしくなることが多い(wcwidthが1を返すせい)
・Unicodeを作った西洋人は馬鹿だから、罫線素片の幅も曖昧で、ncursesがバグる
・絵文字は文字幅1だが、フォン卜の多くは2で実装されているのでおかしくなる >>853
あざす
やっぱり混沌としてるのですね
とりあえず一度ターミナルの中を追ってみようかな Unicodeの時代に今更だけど、
シフトJISの第2バイトがA0～FFでなく
40～FCにしたのは何でだろう JISの区点は1区あたり94点
0x40開始で0x7Fを避けて2区分取ると0xFCになる >>858
半角カナのせいで80～FFでは足りないから シフトJISはもう少し工夫すれば
JISコードの変換式もより簡単にでき
2バイト目もASCII領域を使わずにダメ文字も発生せず
補助漢字も全て入れられた EUCだと半角カナも補助漢字もバイト数が増えるからな．．． >>863
あのスペースの狭さでは、それは無理だったのでは？
どうするのがよかったのですか？具体的にいってみてよ 非漢字＿：[81-98] [80-9F]
第１水準：[80-9F] [A1-FE]
第２水準：[E0-FF] [A1-FE]，[E0-EB] [80-9F]
補助漢字：[A0-DD] [A1-FE]，[A4-C1] [80-9F]
補助漢字は半角カナと排他利用 >>868
それは結局半角カナを潰しただけのことでは？ >>869
補助漢字6000字近くを使えるというメリットがあれば
半角カナをフェードアウトするには十分な機会になっただろう
補助漢字（JIS X 0212）が制定されたのは1990年だから
その翌年の1991年に発売されたMS-DOS 5.0あたりで
KANA ON／OFFコマンドを追加し、半角カナ／補助漢字の切り替えが出来れば
従来のテキストファイルの読み込みなども対応できる >>870
文字コードのマップ切り替えはコンテンツ側で指示するべきことであって、OS/アプリ側で切り替えて対応するとか、発想が変だとおもいますね いっその事1byte=32bitにすればサロゲートペアもBOMも要らなくなるし多バイト文字という概念もなくなる >>875
イングランドの旗はUnicodeで7コードポイント必要なので64bitでは無理
128bitで 👽 全宇宙の未知なる知的生命体の使用言語を網羅しなきゃならないのだから可変長は必須 >>876
え、じゃあイギリスの旗はさらにそれにスコットランド分とアイルランド分が追加されるの グーグルってしょっちゅう意味のわからんことするよな 実行ファイルがテキストとデータで構成されるように、絵文字表現もテキストとデータを組み合わせた文法が出てきそう。 顔文字より正規表現のためのメタ文字とかあったほうが良いのにね。
まあGoogleじゃ無理か。 そのメタ文字にマッチしたい正規表現を書く日が来るぞ 規格名：JIS X 0215
文字数：15000字超（非漢字：1700字超，漢字：13300字超）
区点域：0～127区，0～127点（最大16384字収納）
通 称：いちごJIS https://twitter.com/akinomyoga/status/1230127240806985728
修正の入った Cygwin 3.1.4 のリリースノートが来て、見てみたら @cjksingle という不穏な locale が発明されてる。
何かと思ったら「CJK文字も全て半角にすれば文字幅問題解決じゃん」という欧米人(東欧系?)の思いつきで、これは新しい悪夢なのでは…。mintty は仕事が早すぎ
https://gitlab.freedesktop.org/terminal-wg/specifications/issues/9#note_406682
因みにこの東欧人を追うともっと面白い(?)ものが。。漢字や絵文字が行末に収まらない時は左半分はその行に右半分は次の行に表示するのが合理的だと Windows Terminal に赴いて主張してる。
曰く、殆どの漢字は偏(へん)と旁(つくり)から成るので分断しても意味を失わないとか…
https://github.com/microsoft/terminal/issues/4345#issuecomment-578434025
https://twitter.com/5chan_nel (5ch newer account) 半角と全角の区別付かなくなると困るから元の半角文字はさらに半分で表示したらどうかな 外字というと丸囲みの数字が①～⑳以外にもほしくて
21以降も外字で作ってしまっていた事務所を思い出す
何度かPCを入れ替えるうちに使わなくなり、忘れ去られ、
久々に古い文書を引っ張り出して来たら謎の文字化けで外字の存在が発覚
外字が何故か⑳から始まってたり途中に別の字が挟まってたりしてもはや解読作業 (0)とか黒丸の小文字英字とか白丸のンとか黒丸の仮名とかは
Unicodeですら未だに無いんだよな．．． わいせつだって文字情報じゃないか!
それともなにか君は辞書から陰茎とか陰核という単語を削除せよというのか! >>903
◎と字形が同じとかで一緒にされそう
あと将棋の駒(上下とか白黒)も欲しいとか言ってた人？ >>902
50まで作るんだったら、99まで作れば良かったのに。
できれば、100まで欲しかった。 >>900
Unicodeがまさにそんな感じだよ
符号位置なんて空いてりゃなんでも詰め込んでくる アレはUNICODEが16ビットだったときの産物だからなー
囲み付き文字は合字でなんぼでも表示できるんじゃなかったのか？
黒字に白抜きはないか。 あれ、もうUnicode 13.0.0出たの？
改訂するのは確か毎年6月ねって決めたんじゃ……と思ったら去年から3月だった。 Win10は頻繁にバージョンアップしてるけど、
使ってるUnicodeは2015年に出た8.0のままなんだよな．．． そーそー
新しいフォント入れてもリンクが効かんという...
全部入りフォント作るにゃ16bitの壁 高松もキャンセルなのかな
それともISO/IECはまた別の判断か
https://www.iso.org/covid-19.html Unicode 14.0 Delayed for 6 Months
http://blog.unicode.org/2020/04/unicode-140-delayed-for-6-months.html
Due to COVID-19, the Unicode Consortium has decided to postpone the release of version 14.0 of the Unicode Standard by 6 months, from March to September of 2021.
This delay will also impact related specifications and data, such as new emoji characters.
This announcement does not affect the new emoji included in Unicode Standard version 13.0 announced on March 10, 2020. せっかくだから細菌��とは別にウイルスの絵文字つくってくれ 外人が絵文字大好きなのは勝手だけど、既存コードの部分もちゃんとして欲しい なるほど、最近と細菌がかかってる、とこういうわけですな するってえと何かい？
最近と細菌がかかってるというわけかい？ >>891
超遅レスだが、全角半角問題の亡霊が絵文字とかで再燃してる感じ?
そっか絵文字ってサロゲートの領域のやつ以外にVSを使ってるのもあるのか。面倒だな。
>>897
Unicodeには公式定義があるでしょ
話は違うが、外人は絵文字をEmotional Iconかなんかの略だと思ってる感があって
そこはどうなんだという。 ひらがなの'あ'よりも'W'のほうが幅広だったり、
★マークが半角幅だったりするフォントが溢れてるのに、
半角全角区別しても仕方ないだろ まあだからそこはターミナルとか限られた環境の話で。
フォントもそれ用のを選ぶし。
そろそろ全角半角なんてのをやめて、文字のカラム位置を揃えたいならフォントの
メトリックスの方で調整すればいいだけ、かもしれないけど。 >>946
Unicodeに収録された文字には文字幅のプロパティがある、という意味で。 >>947
かみ合ってないやん
>>894からの流れなんだから >>894 ? 知らんがなw
そもそも「全部」ってどういう意味だ? 全部の文字? 全部のターミナルに関わるソフトの挙動? 既存定義とは違う新しい定義の話題に
「既存定義があるぞ」は全然かみ合ってないし
知らんがなと笑われてもそれこそ知らんがな >>951
というかどういうレベルの話をしているのか掴みかねてね。
「絵文字にはUnicodeで文字幅が定義されている」これは大雑把に正しいぞ。
リンク先の元ネタをフォローしてみようか? U+2764 U+FE0F はどうするか、という話。
ここでは誰もフォローしてなかったのでこのレベルの話はしてないと理解した。
でもフォローしてみよう。 というか、既存の定義とは何かもはっきりしてなかったのに新しい定義?
なので既存の定義（の一つ）を示してみたのだが。
全角半角というのは、SJISとかEUCとか使ってた頃の化石の概念だが、ターミナルでの
文字表示にナニゲに悪くはないので、むやみに廃止せず、Unicodeの種類が増殖していく中
如何にサポートできるか? それとも廃止した方がいいのか? あるいはターミナル自体が化石w?
みたいな問題意識を共有? できるならば話はできるかもw んだからUnicodeは全角半角を再定義してるんだよ
https://ja.wikipedia.org/wiki/東アジアの文字幅 >>959
なんだそれを「再」定義というのか。だったらその前の「定義」って何? どれのこと?
SJISやEUCで、文字のバイト数＝幅という「慣習」はあったと思うが。大昔に。
で、U+2764 U+FE0Fはその再定義では駄目なので再々定義しないといけないw
個人的な意見ではU+2764 U+FE0Fは半角でいい（せざるを得ない）と判断する。
その根拠は... 省略w
ただ、ターミナルの特殊性 vs フォントのデザイン vs 文字コードで幅を決定 等、
いろいろと無理がある中で妥協点を見つけるとすると、そうなるかな、という感じ。 曖昧な定義は定義じゃないというならべつに「再」は削ってもいいが？ %s の文字数とかで文字列の幅調整出来ないんだよな しかし絵文字の力はすごい。
これを使いたいがために外人共もUnicodeを以前よりはるかに意識するようになってきてる。
VSとか、漢字の字形の微妙な差とかの用途より、もはや絵文字がメインユーザー。
同様なことが「文字幅」にも起きつつあるようだ。もはや東アジアだけの問題ではないのかもw そして線がごちゃごちゃしてる漢字はいらなくね？って話になって排除されるんでしょう？
白人のやることはいつもそうだ >>964
それはグレートチャイナ様が抵抗してくださるのでは？ 彼らも漢字から線減らしてるじゃん
そのうち中共の悪事を次世代に隠すために漢字を扱えるのは中共の上の方だけになりかねない気もする
そのとき中国の一般人民が使ってるのが絵文字だよ >>966
それは失策だったという評判です、実際、現行である第一次案は通りましたが、第二次漢字簡化方案は失敗しました 斎と斉と齊と齋は一緒だから一つにしろとかな
渡辺渡邊渡邉もどうせ一緒だろうとか ひどいよな
一と二や三などたかが横線の一本二本すら妥協できないのに、
異体字はひとつにまとめようとするひどい話だ。 >>969
これは一緒にしろよと思うことはある
文献で必要だから分けて欲しいが、明治の戸籍作成時の書き間違いまで
大事に引き継ぐ必要はないだろ そして再委託で中国人アルバイトに丸投げして
年金記録問題になるとな でもそれ用途があってのことだから規格側の仕事じゃないのよね
統合したいのなら運用のほうを変えないことにはね
いずれにしてももう入れちゃったから永久保存だね はしご高とくち高は無理やり統合されちゃって有耶無耶らしいのですが… >>970
マジレスすると「異体字」という言葉は正しく使って欲しい気が。 >>969
> 斎と斉と齊と齋は一緒だから一つにしろとかな
しっかり区別できない限り、乃木坂ファンにはなれない。 イタイ痔でイタイ字
ミミズ腫れでミミズ字
老眼でヨタヨタ字震え字
ギャル文字マルモジオタ字ハングル文字
° ° ° °
± ± ± ±
² ² ² ²
³ ³ ³ ³ >>977
メンバーの斉の字どころか、なんとか坂っグループ自体も区別できてないので何ら問題ないなw >>963
あと絵文字と言えば、今流行りの、肌の色がどうたらってやつな。このせいで複雑化した。
でも、他にも目の色とか髪の色とかもあるが、独立には選べないぞ?
ここら辺はいいのか? 大騒ぎしてる奴ら。
なんてことを書いてるとそのうちそれぞれのトーンセレクタが入ってさらに複雑化したりして。
あとは目がツリ目で気に入らないorその逆とかでそういうセレクタとか。
唇が分厚いorその逆のセレクタとか。
おっと誰か来たようだ 表意文字を使ってない奴らに絵文字を語らせるのは1000年早いわ。 なるほど、絵文字への文句というのは、文字の抽象を理解できない奴らからのしょうもない
文句かも、確かに。 >>982
5chの文字コードスレで数値参照か?
男は黙ってShift_JISだろ。
Shift_JISとは何かを考えるいいきっかけにもなる（ならなくていいかw） 参照ならむしろSJIS範囲内だ
各自環境でどう表示されてるかは関知しない 俺の名前は明朝体だと口高で、楷書体だとはしご高なので、はしご高と口高は統合されてないと逆に困る。
はしご高問題とか伝統的な漢字の書体のことを全く知らないド素人が単なるフォントの違いを勝手に別の漢字扱いしただけだろ。 つまり単なるフォントの違いにこだわるド素人の名前ってこと・・・？ 「包摂」の概念を知らないといけないな。
「包摂 文字コード」で検索すると出てくるが、「そ」や「り」は一画で
書く場合と、二画で書く場合があるが、それは「同一の文字であって
字体が異なるだけ」とみなすのが「包摂」ということ。
「高」と「髙」は別の文字と考えられ、「包摂」されていない。
すなわち文字コードも分けられている。これは、unicodeで規定された
以上、もう変えることはできない。 >>989
(1) 日本(JIS)では包摂されてた
(2) 台湾では包摂されてなかった -> Unicode で採用
(参考) CP932では包摂されてない -> 5chは実際にはCP932、ということでいいのかな?
Unicodeで別になってて嬉しい人は台湾に感謝しないとw >>989
＞「高」と「髙」
CP932 では区別されているのですか？ >>992
区別されてるよ。
「マイクロソフト標準キャラクタセット」で検索すると、
詳しい情報が出てくるよ。 いや、本来の漢字の伝統だと JIS の包摂基準の方が正しくて Unicode のは間違っている素人基準だって話。
そのせいで、手書きの文字が印刷した書類と違っているというバカな注文つけてくる役人がいて困る。
口高でもはしご高でもない草書や行書の高はどうするつもりなんだw 私の場合はそのせいだよ。
WEB申請(UTF16)と手書きが違うのでちょっと役場まで来いやゴラって言われたので。 自分はずっとだいざきで書いてて住民票やパスポートもそれで申請してた。
が、いつからかたちざきで書くよう求められるようになった。
なんか基準が変わったのか？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 565日 1時間 34分 59秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
