文字コード総合スレ Part12
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。
■過去スレ
文字コード総合スレ part1 http://pc11.2ch.sc/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.sc/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.sc/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.sc/test/read.cgi/tech/1228052369/
（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.sc/test/read.cgi/tech/1177930957/
（隔離スレ）UnicodeとUTF-8の違いは？ その2 http://pc12.2ch.sc/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.sc/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.sc/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.sc/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.sc/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.sc/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.sc/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 https://mevius.2ch.sc/test/read.cgi/tech/1516629503/
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
IANA: Character Sets
http://www.iana.org/assignments/character-sets
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
JIS X 4061
日本語文字列照合順番
http://www.jisc.go.jp/
・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サニタイズが面倒になるのか
文字コード統一スレ 1文字目
http://pc8.2ch.sc/test/read.cgi/tech/1109171258/
隔離スレ:
UnicodeとUTF-8の違いは？
http://pc12.2ch.sc/test/read.cgi/tech/1177930957/
UnicodeとUTF-8の違いは？ その2
http://hibari.2ch.sc/test/read.cgi/tech/1274937437/
UnicodeとUTF-8の違いは？ その2
http://toro.2ch.sc/test/read.cgi/tech/1291075205/
UnicodeとUTF-8の違い4(インディアン隔離スレ)
http://toro.2ch.sc/test/read.cgi/tech/1342963035/
ICU - International Components for Unicode
http://site.icu-project.org/home
mlang
http://msdn.microsoft.com/ja-jp/library/aa767865(en-us).aspx
iconv
http://www.gnu.org/software/libiconv/
ICU
http://www.icu-project.org/
NKF32.DLL （非推奨）
http://www.vector.co.jp/soft/win95/util/se020949.html
・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とか。
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のフォントって、どのフォントがどのコード体系とか字体を使っている。
などを纏めているところってある？？
ちょっと書いてみ
https://ja.osdn.net/projects/nkf/scm/git/nkf/
v2.1.5
2018-12-15 18:19:02
ここは同意
>2つ以上のｵｸﾃｯﾄを使う符号単位で
>BOM入れないﾔﾂは池沼だからな
これは嘘
ｴﾝﾃﾞｨｱﾝの概念がないのが
よおく分かったわ
現にネットワークデータはCPUとは無関係の並びになってる
ﾏｼﾞでいってんの
こういうﾏｼﾞもんの低学歴がこの板で
はば利かせてるのがよく分かるわ
ﾏｼﾞで頭悪いことを
ﾊｼﾞもなくなんの躊躇もなくいうからな
ﾌﾟﾛｸﾞﾗﾑで
いちいｴﾝﾃﾞｨｱﾝ変換してんのすら
しらないらしいわ
当然Unicodeのｴﾝｺｰﾄﾞ方法にも
ﾋﾞｯｸﾞｴﾃﾞｨｱﾝとﾘﾄﾙｴﾝﾃﾞｨｱﾝがある
ちなみﾈｯﾄﾜｰｸでﾃﾞｰﾀを交換するときは
暗黙で基本はﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝになってる
常識だからなｺﾚ
なんでものすごい頭悪いことを
自信満々にいうわけ？
ﾎﾟｰﾄ番号も当然ﾋﾞｯｸｴﾝﾃﾞｨｱﾝになってる
ｿｹｯﾄ通信のﾌﾟﾛｸﾞﾗﾑ組んだことあるなら
ﾎﾟｰﾄ番号設定するのにhtons（ｺﾚはｵｸﾃｯﾄ2つになる）という関数を使ったことあるﾊｽﾞだ
ちなみにこの関数はﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機なら
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝに変換された値がかえってくる
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの計算機なら
そのままﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの値がかえってくる
常識としては知っててほしいがけど
低レベルな処理書かなきゃ関係ないし触れることもないだろうから知らなくても困らんな
アラインメントとかパディングとかも同様
バイトオーダーを意識する機会が減ったのは、xmlやjsonなどテキスト形式でデータ受け渡しすることが多くなったから。
テキスト形式ならバイトオーダーを意識せずに済むし、スクリプト言語で扱うのにも便利。
豆知識、endian とは？
もともとは、卵を丸い方の端 (big end) から割る人々（Big Endians）と尖った方の端から割る人々 (Little Endians) との対立を表したものだった
C/C++で開発している時はコンパイラが自動的に配置・取得してくれるデータを、スクリプト言語では自力でオフセット調整して配置・取得しなければならない。
C/C++より簡単なことが長所だったはずのC#・Java・Perl・Python言語などで、低レベルなオフセット調節を自力で行う必要に迫られる皮肉な状況が起きる。
C/C++言語以外ではライブラリが処理してしまうんで意識しないかな
C/C++ライブラリを呼び出すライブラリを作るときは意識するだろうけど、
それって結局C/C++言語で書くんで、あれ？意識するのはC/C++かｗ
例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。
○ 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、C/C++並みに低レベルなオフセット調節を自力で行う必要に迫られる。
うーん、具体的な win32api 名（だけでいいです）を例示してください．
勝手に書き換えないでもらいたい。
C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが、他の言語だとそうはいかないので、アセンブリと同じようなオフセット調節が必要。
SendMessage(WM_COPYDATA)の送受信データの読み書きなど例はいくらでもある。
>C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが
誰に騙された？
ファイルやネットワークストリームでLEにするアホいるんか？
使っている言語が32/64bitどちら向けでビルドされたものなのかによって構造体メンバのアラインメントを適切に処理する必要が出てくる。
言い換えれば、C/C++で作った構造体をバイト列で渡し、C/C++以外の言語でバイト列を構造体に復元する処理が厄介。
単に構造体の64bit整数メンバだけ気を付けるのではダメで、構造体の全メンバのアラインメントそのものが大きく変わりうることに注意する必要がある。
それとアラインメントの話とバイトオーダーの話を混同しないように気を付けた方がいいよ。
勝手に調整してくれるんじゃないの？想像しただけで
なんで Byte Order Mark(BOM) がﾌｧｲﾙの先頭に入ってるのか分かってない
Javaﾊﾞｲﾄｺｰﾄﾞのcafe babeみたいな飾りだと思ってんの
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機ばっかりがあるとこで
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝでﾌｧｲﾙを保存する理由なんかないからな
当然、そういったｺﾝﾃﾝﾂﾃﾞｰﾀがHTTPでも流れてくる
ｸﾙｸﾙﾊﾟｰしかいない
そしてそのｸﾙｸﾙﾊﾟｰの声だけがでかい
やっぱりな低学歴知恵遅れは
この板から排除する必要がある
板が正常に機能しない
32/64bitで整数サイズの違いでメンバオフセットが変わるってのはアライメントとは別の話。
ちゃんと32bitに詰まるように
ﾒﾝﾊﾞの順序かえる
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単位でｵｸﾃｯﾄ列の並びを逆転させる
ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機で
ﾘﾄﾙｴﾝﾃﾞｨｱﾝのﾌｧｲﾙ読み込むならｵｸﾃｯﾄ列の並びを逆転させる必要はない
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝならその逆になる
低学歴知恵遅れはこういった基本的な理解がない
C/C++の規格じゃ構造体のメンバは宣言された順にアドレスが増加するよう並べられることになっている。
仮に>>45のような最適化を行うことができる処理系が存在したとしても、一般的と言えるものではない。
手動で自分で並べ替える
他の言語でも一緒。ただし型が違うからバイト数を指定するだけの話
そんな経験するのは無理だよ
C++はむり
ﾚｽみればよく分かる
ﾚｽから頭の悪さがにじみ出てる
低学歴のﾚｽはすぐにわかるわ
残念なことに
しかし、Windows が VisualC++ でビルドされていて、VisualC++
もしくは互換のアラインメントができる言語でアプリを組めば、
気にしなくてもよい、ということだけだろう。
gcc も同じだよ。64bit版linux gccはwchar_tを16ビットにするか32ビットにするかを切り替えビルドできるからさらに厄介。
構造体を丸ごとダンプしたバイナリデータを同じOS上の別プロセスに渡すのは繊細な注意がいる。
16bitで格納されていようが32bitで格納されていようが
C/C++だったらアライメントを勝手に調整してくれるんだっけｗ
へー、勝手にねー、intで扱ってれば、勝手に調整してくれるんだーｗ
構造体が仕様として公開されている場合、どの言語であれアラインメントを意識した実装が必要になるが、C言語は実装コストが最も低くなる傾向はある。
スクリプト言語を使う人がアラインメントを意識せずにすんでいるのは、ライブラリ実装した人が頑張ってくれた・くれているおかげ。
先生。指定したオフセットから何バイト読み込むか指定する作業は、まさにアセンブラと同レベルの作業じゃありませんか。違いますか、先生。
違いますね。memcpy相当ですから
色んなところにいるよ
低学歴知恵遅れの自覚がないからな
Cでサンプル欲しいのですがどこかにありますか？
return htons(1) == 1;
}
UnicodeでのU+0080はxxxみたいに無名なのって理由ある？
というか削除されてる
http://www.ecma-international.org/publications/standards/Ecma-048.htm
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf
WikipediaソースによるとUnicode初期ドラフトにはU+0080も入っていたみたいなことも書かれてるね
https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set
エイプリルフールだって？
2019年は何が起きるかしらね
新元号『NEO平成』に決定みたいな
新元号の組字のためだけにAdobeJapan1を改訂するってのは馬鹿げてる
文字の中の何バイト目かを 1 バイトずつ遡って調べるということも
あったようだけど自分ではそういうコードを書いた記憶がない。
いや、もしかしたらあったのかもしれないけど。
EUC-JP の場合は ASCII なバイトかシングルシフトが現れた時点で
確定するようだけど。Unicode の時代になって良かったね。
まあ、そんなようなことを今更思った。あけましておめでとう。
ありがとう。
なにか事情があったんだろうけど、なんだろうね……。
>>79
大昔のことだけど、SJIS 文字列の末尾から検索するプログラム書いてた時は「SJIS、お前はマジでR」という気持ちで一杯でした。
もう二度とあんなことはやりたくない。
p=strchr( path,'\\'); /* おい *p 、お前は本当に '\\' なのか? 表とかじゃないのか? */
ライブラリが揃ってるからねー
一文字が1バイトだろうと3バイトだろうと
2文字で1文字を表していようが、簡単に一文字判定ができちゃう
先ずコードポイントの意味を理解してから質問した方が良い
最大4バイトじゃないよ
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/
Unicodeは複雑過ぎてライブラリを使わないと正しく扱うのはまず無理
もし自力で文字数をカウントしたいならこれとか読んで頑張れ
https://www.kthree.co.jp/kihelp/index.html?page=data/ivs&type=html
https://qiita.com/nonanona/items/b148c212ba7c24942e93#%E7%B5%B5%E6%96%87%E5%AD%97%E7%94%A8%E3%81%AE%E7%95%B0%E4%BD%93%E5%AD%97%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BFemoji-variation-selector%E3%81%A8%E3%81%AF
見た目上は1文字なのに例えば U+1F468 U+200D U+1F3A8 みたいに3文字になる。
酷いねー。見た目上は1文字なのにU+1F441 U+FE0F U+200D U+1F5E8 U+FE0F と5文字分使ってる
バイト数だと17バイトみたいね
http://tech.albert2005.co.jp/201/
https://qiita.com/nonanona/items/b148c212ba7c24942e93
https://n2p.co.jp/blog/column/counting-characters-on-twitter/
1文字に見えるやろ？でもこれは11文字なんや
全く意味がわからないｗ
11文字ってのは今現在存在する最大が11文字ってだけで青天井？
もうライブラリ使ってないと無理だね
という意義には賛同していたんですけれども、（主に経済的理由により）絵文字が入った時点で失望してしまいました…
仕切りなおしたほうがいいんじゃないですか？
というかもはや絵文字は世界中のスマホ/SNSユーザーに愛用されています。
ここまでくるともはや後戻りはできないのです。
Unicode12も来年・・・じゃないやもう今年リリースされる予定のはずだし
文字扱いするのは当然
世界には文盲がわんさか居るから結局象形文字が必要ってことか
そんなもんをコード化したら破綻するに決まってるんだよなぁ……
絵文字と象形文字の間には確固たる断絶があります、おっしゃるような連続的なものではないと考えています
例えば、ある象形文字と別の象形文字との違いははっきりしていますが、ある絵文字と別の絵文字との違いを示す具体的な指標はないのでは？
それとも、これは私の知らなかったことですが、もしかして絵文字の内容はピクセル単位、あるいはベクターイメージですでに定義されているのですか？
https://togetter.com/li/1305754
うっかりつなぎそうになった
巻きうんち/一本糞/ビチグソ
一応https://www.unicode.org/charts/PDF/UFFF0.pdf←ここを読んでみたんだが
U+FFFCが「Unicodeの範囲で異常」、U+FFFDが「Unicodeですらない」
ことを示す文字なのかな？
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.
sorry Japanese only please
なんで卑屈なの？
https://www.sankei.com/premium/news/190117/prm1901170009-n1.html
https://www.appps.jp/wp-content/uploads/2017/01/20170131-tell-icon-news-008.jpg
↑
の方が合ってると思うけど
現実は
↓
下載
これ使われてるの？
んーつまり基本的にはU+FFFDを使っとけばいいのかな。
マジで英語が読めんので当てずっぽうだがw
FFFD は文字用。変換のときに他の文字コードでは表現できる文字がユニコードでは表現できなかった場合用。
なるほど「オブジェクト」ってそういう意味か！
ありがとう。
つまり基本的に（Unicode環境で）「文字化け」した場合は
U+FFFCを目にすることはない訳だ。
（Webブラウザなら画像は別の形で表示されるし
端末なら8bitキャラクタの集合としてU+FFFDが使われるし）
アプリケーションが内部で使ってよい領域という意味と受け取ったわ。
よろしくお願いいたします。
https://pc.watch.impress.co.jp/docs/column/config/1158344.html
＞文字データをシフトJISではなく、Unicodeで保存するとどんないいことがあるのか。
＞たとえばUnicodeならあらゆる言語の文字を混在させることができる。
＞Wordでしか文書を書かないエンドユーザーにはそんなこと当たり前じゃないかと言われそうだが、
これって本当ですか？
私見では日本語の漢字と中国語の漢字を同一文書にて同時に表示できないし混在もできない、と思っていたんですが…。
CJK 漢字統合の影響はもう過去の話になってしまったんでしょうか？
現に存在するUTF-32/UTF-8 という文字コードの集合を使用した場合に日本語と中国語の漢字を
①：同一文書に含ませることは可能でしょうか？②：①が可能であったとして、PC の画面にて同時に表示することは可能でしょうか？
<span lang="zh">
みたいに指定してやると全く同じコードポイントでも違う字形になる。
こいつはプログラマじゃないからな
かなり適当な理解で記事描くな
Unicodeは全世界の文字に対応した文字コード
混在して使えるのは当たり前
より正確に言えば、
保存するときにローカルの文字コードに変換してるソフトかもしれないのでそのソフトの仕様による
例えば英文フォントしかないPCだと漢字は表示できないだろうから表示できるかどうかは環境による
だろう
>>131
あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ
私?では日本?の?字と中国?の?字を同一文?にて同?に表示できるし混在もできるが。
> あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ
縄文時代の日本語が文字コードで表せるならばUnicodeで表せる
文字がないのに文字コード化できるの？
俺に言うな。>>138に家
縄文時代の日本語を混在できないとしたら、
それは例えば「文字がない」ことなのに、
Unicodeだから無理みたいな言い方してるんだから
被害妄想にとりつかれた朝鮮人みたいだな。
じゃ、この発言で言いたかったことは何だって言うの？
「私（>>138）は馬鹿です。」以外に何も思いつかないんだが
>じゃ、この発言で言いたかったことは何だって言うの？
（unicodeならすべての言語を混在できるという話しを受けて）
あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理
だろ。他に何があるってんだ？
それを>>138がしょっぱなから「あらゆる言語を文字で混在させる」に読み違えてるように思える。
UNICODEじゃ全然足りないのは明らか
縄文時代の日本語ってなに？
参考リンク教えて
だから文字のない言語は無理だろ？
という話だけなのに、なんでひねくれてるの？
朝鮮人メンタル
とあるオンラインゲームをやってまして
そこで名前のソートの規則から、そのゲームが採用している文字コードの符号化方式を知りたいのですが
各コードにおいての文字の並びと、実際のゲーム内での文字のならびに違いがあったので素人の私にはお手上げ状態です
素人なりに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
ほとんど初心者なので知りませんでした こういう関数があるんですね
専門用語とかだけでも出してもらえて嬉しいです
何も知らないのでぐぐる事もできなかったので助かります
単語さえわかればあとはこちらで調べますので
他にも関連した情報がありましたら用語だけでも教えてもらえると嬉しいです
記号類がアルファベットの前に来るってのはそれっぽいような
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種類の順番が存在する
https://blog.emojipedia.org/230-new-emojis-in-final-list-for-2019/
ただの絵
ブリックパックの右二つがなんだかわからない
南アの飲み物マテと牡蠣じゃねーの
SSIDって英数字だけじゃないの？
ほとんどのルーターで禁止されているけど、ルーターのWebUIでSSIDを設定する時に
JavaScriptの文字列チェックを外して強引にUTF-8で設定させるのが一部で流行っているらしい。
うんこ
🍭
あめ
あめ
☔
雨
見えているのに到達できない場所みたいだな
どこかわかります。できれば、日本語だけでなく全文字が欲しい。
↓こんなやつがずらっと。
0x878D U+337E # SQUARE ERA NAME MEIZI [2000]
ここは知っています。
一つ上がってみよう
俺は見たこと無くて何とも言えないのだけど、実際に接続できたのだろうか？
Nobody knows the trouble i've seen, nobody knows but Jesus!
↑ここにアクセスしても空白のページが表示されるだけなんだけど
みなさんもそう？
前までは確かに存在したページの筈……。
あのページはすごい便利に使わしてもらってたのに、利用できないとは残念
http://cldr.unicode.org/
そのページから個々の文字に関する情報って見れなくね？
unicode、すっかりグダグダたな。なんだよ絵文字って。
http://blog.unicode.org/2019/03/announcing-unicode-standard-version-120.html
「ゑ」の小さい字もできるんだ、
「ぇ」みたいに。
https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b
> それに、今みたいなポリコレ棒が猛威を振るう時代だったら、CJK統合は行われなかったでしょうね。
> 部外者が他文化の文字に対してもの申す事は、文化への攻撃・侵害・侵略として糾弾されたでしょうから。
> 日本人や中国人側からではなく、米国や欧州の国々の方から強い反対が出たでしょう。
<https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b#comment-ba92e82cf5ff8a829c10>
↑これはなるほどと思った。政治的正当性についてとやかく言うつもりはないが
CJK統合はマジでそのCJK文化圏にいる利用者からは扱いずらすぎるからな……。
「意味や字形が似ている文字なら同じ符号を割り当てていい」のなら，
フラクツゥールを態々用意せずに，lang=de-x-Frakみたいな指定があったときに
文字「A」を「𝔄」という字形で表示すればいいのに，そうしてない。
小さいヲンは実は典拠が微妙
同じワ行音ってことで何となく入っちゃった
私は「ティム・アップル」 トランプ氏言い間違えに本人が便乗
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
(deleted an unsolicited ad)
https://twitter.com/muota_here/status/657111322656555008
(deleted an unsolicited ad)
>CJK文化圏にいる利用者からは扱いずらすぎる
わざとそれを狙って毒撒いたんじゃね？
ぁたιゎゆるさﾅょぃ
http://www.unicode.org/cldr/utility/character.jsp?a=9AD9
使えるように直ったっぽいよ。
「あたしわゆる」の後なんて書いてあるの？
さない
「あたしわ ゆるさない」 だろ
長すぎてどこまで読んだか判らない
>>217
ありがとー
>>192は俺な訳だがなぜ無関係なあなたが返事をしているんだw
http://www.unicode.org/reports/tr29/tr29-35.html#Modifications
Unicode 12.0.0 では新しく U+FF10..U+FF19 の全角数字を数字扱いするようになったのね。
UAX #14 では Ideographic のままだし何で今頃変えたのかよく分からないけど。
属性定義するのはいいけど定義をコロコロ変えてんじゃねぇよ
まじかよ
互換性がとも思うけど，寧ろ便利なのかな。
鈴木一郎が全部漢字だから一気に選択できたのに一が数字だからってんで
鈴木/一/郎なんて分けられたらやっかいだ
うわあ
FF10..FF19は確かに漏れだな
http://www.unicode.org/Public/11.0.0/ucd/auxiliary/WordBreakProperty.txt
grepの-Pオプションはpcreを使うのだけど、境界判定\bが-Eオプションと違う動きになる。PCRE_UCPオプションを使ってビルドいないからだろうと思う。
誰か知らないですか。
確かに2ちゃんねるの文字コード関連のレスで
「---っていうライブラリが便利だよ」みたいな文章だったと思うんですけど。。。
なぜかそのとき ライブラリのWebページをブクマし忘れてて そのライブラリの名前を失念してしまったんです
utf8procじゃねーの？
https://twitter.com/yabuki/status/1112565487995518979
(deleted an unsolicited ad)
何らかの揉め事になって面白い事になるかも。
汎用電子あたりにぶち込んでいいぞ
そんな大事な話でFA98とF9A8間違うとか絶対わざとやってるだろ
消して投稿しなおせよ
そもそも字が下手過ぎて習字の基本すら出来てないやろ
和にしても
ノ木口
なのに
ノ丶木口
って描かれてる
https://togetter.com/li/1333809
https://japan.cnet.com/article/35135080/
この手の合字をもっと増やしてもいいと思う。絵文字をボコボコ増やすよりも有意義だ。
㌀、㍇は既にある。ゲートウェイの合字があると面白い。
山手線の新駅の名前に使える。
AJ1ならワンチャンあるかも
誰でも読み書き出来る字を選ぶという配慮であろう。
令は小学4年、和は3年で習う字だ。
今時のキラキラネーム(DQNネーム)とは違う。
2010年追加の常用漢字の中には第２水準以下だったりJIS2004で字形変更されて
2点しんにょうや古い食へんの字があるよな。
教育漢字にはならなくて小学校では習わない字のままだったけど。
やり直せ
令の字に関してなぜかU+F9A8なんて話が流れてきた。韓国KSコード由来の互換漢字。
これは『改訂新版 プログラマのための文字コード技術入門』p.110に書いたような理由で入ったものだけども、扱うことはまずないのでは。
それ言うんならU+2F24の「⼤」を使った「⼤正」は今までチェックしてたのかい?
これはUnicodeになぜか別立てで入っている康熙部首の符号位置。
(deleted an unsolicited ad)
電子化された契約文書に大正の年号が使われることがないから影響もなかった。
でも令和は現状自由変換状態で、この状況はみんなのスマホやPCが“令和対応”のものに更新されるまで当面続く。
そこに「こっちの令が正しい形」説が追い打ちをかけてきてるのが困ったところ。
あるいは単に問題を取り違えてる素人かもしれん。
令和
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台あれば誰でもアクセス
できるので、ぜひ一度サイトを訪問してほしい。古文書の解読の楽しさはもちろん、自分が住んでいる地域で過去に起こった地震の歴史を学ぶこともできる。
https://honkoku.org/
不正コードでおかしくなるシステムもある
https://tech.nikkeibp.co.jp/it/article/COLUMN/20090223/325337/
https://www.jpcert.or.jp/sc-rules/c-msc10-c.html
https://www.slideshare.net/ockeghem/ss-5620584
https://www.asahi.com/articles/ASM4D61ZPM4DUTQP029.html
2019年4月13日11時08分
https://www.meti.go.jp/policy/it_policy/kaigen/20190405_kaigen_code.pdf
なぎはどの字が正解？
Unicodeに収録されている「パーツ」と「ほか」が追加されるとUnicode仮名合字が揃うから最優先
これ使えって言われそうだ
🇬🇼
GW？
ソ連の旗に書いてあるやつ？
見ているとゲシュタポ崩壊してくる
https://togetter.com/li/1341711
https://support.microsoft.com/ja-jp/help/4493453/windows-7-update-kb4493453
いつでも来やがれ
これ
↓
㋿
らしい
https://hayabusa9.2ch.sc/test/read.cgi/news/1556695686/
新しく増やす余地があるのなら慶応以前のもないと気持ち悪いなあ
保元とか平治とかちょうだいよ
http://abs.twimg.com/hashflags/Reiwa_NewEra_2019/Reiwa_NewEra_2019.png
将来にわたる日本の改元時儀式が爆誕した瞬間である
なんで今さらシフトJIS時代の遺物の仲間みたいなものを増やすんだか
それで使えなくてもかまわないんだろ
http://unicode.org/consortium/adopted-characters.html
IT技術者なら使わないけど、変換候補に出でくるものを使うのがなぜいけないのかと思うのが世の中の大半。
面白いお小遣い稼ぎだなと思ったが、
これ名前に主義主張とか入れて来る人がいたらややこしいことになりそうやな。
別に使っても良いと思うけど
それなら慶應より前のが全部入れろと
たかだか有限個なんだし楽勝だろ
入れるのを望む人が少ないから入らないんだろ
㍾㍽㍼㍻㋿
https://support.microsoft.com/ja-jp/help/4495667/windows-10-update-kb4495667
https://osdn.net/projects/kancollesniffer/news/26014
MS UI Gothicは等幅フォントだったのか
ワロヌ
自分の設計ミスじゃねーかｗ
https://twitter.com/u_1mu/status/1122083801662803968
(deleted an unsolicited ad)
「?」を使って無くても不具合起きるってことか
Windows Form 使ってるところはヤバいんじゃないか
問題が出るのがWinFormsだけとは限らない（少なくともExcelは確実に再現する）らしいから
ＧＷ明けには大問題になりそうな気がするんだけど、いまのところ全然そんな話になってないのがちょっと怖い
まさか「令和」の合字を付け足すだけのWindowsUpdateで
フォント幅の定義が勝手に変更されるなんて思わないよな・・・・
不幸中の幸いは「Microsoftがやらかしたことなんで開発側も被害者です」と言い張れることか
大半はそうでもないんでない？スマホアプリほど表示サイズにシビアでもないだろうし。
Excel書類とかメッチャシビアじゃん
業務アプリ系もヤバいと思うよ
ただまぁ、印刷用フォントにUI Gothic使ってたりしたらそれ自体バグと言っていいかもしれない。
ユーザー側が最新に合わせて調整し終えたところで修正が入って再阿鼻叫喚ありそう
切れて見えなくなる部分で影響が有ると嫌だな
自分は余裕を持たせる事が多いけど
やたらピッタリにしろ
っていう圧力が強いんだよなぁ
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ｷﾀｰ
去年L2に文書が出てた。
http://www.unicode.org/L2/L2018/18011-info-kps9566-2011.pdf
外に向けて公式発表とかはしてないのか
まだこれを含むフォントがインストールされてなく表示出来ない事がある環境依存文字だから使うなとか
そもそも互換文字だから使うな、「令」(U+4EE4)と「和」(U+548C)を並べて書けとか言われるんやろ
変な文字は使わず、90年までの規格で止めとくほうが正解かもね。
JISX0213には入れるのだろうか?
JIX X 0213だけじゃなくてJIS X 0301とかも。
年号の合字も無限に増やすのは無理だから
常に二文字表記で文字幅で調整すれば良い
天皇陛下万歳
千代に八千代に
https://japanese.engadget.com/2019/05/09/android-q-64-53/
専用の文字コードが必要なのかと
偏旁に配置した新字を創字したいのかなと思ってしまう
> 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]ト
これで
キジアパ
マ ート
マキ
ジ
│ア
トパ
をつくりたい
ジョイナーでは？ｗ
茄子
のの
も
へじ
そういうのは「文字」じゃなくてCSSとかで実装すればいいじゃん
……って思っちゃうなw
先行規格がない生まれながらの互換文字ってかわいそうじゃない？
数百年先を見通せない政策
実際女子しか生まれていない皇家も有るし
何らかの対策をしないと途絶える可能性は有るよ
継続させたいなら
本気で対策しないと拙いよ実際
今日の定例アップデートで修正入ったみたい
結婚してから外で子供を作るのは嫁の人権上まずいけど
若気の至りなら仕方が無いだろう
現実ではともかく
ネットの「不敬罪」はほぼネタだと思ったほうがいい
>>378御愁傷様
https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0212.TXT
X0212補助漢字とUnicodeの変換テーブルは↑で良いのでしょうか?
補助漢字には詳しくなくobsolete下にあるのでこれでよいのかよくわかりません。
これはやめた方がいいんじゃないかな…
後はまあ
全角チルダ問題ですか？
ユニコードNGの環境で初めて気づくことも多いんだよね
https://idle.srad.jp/story/19/05/30/0450219/
チーズの位置は許せない
絵文字増やすことが目的になってるだろもう
「今年の新絵文字発表」化してから急に世界中の注目を浴びる一大イベントになったんだもん
そら浮かれるよ
JIS X 0213ではそれぞれ1文字としてコードが割り当てられたのに、Unicodeでは
半濁点なしの仮名と半濁点の2文字で表さなければいけない。Unicodeにも1文字として
収録してもらいたい。
辞書に使われる記号 [名]、[形]、(単)、(複) など ([ ]は角丸正方形、( )は丸囲み文字) も
欲しい。
鼻濁音はUnicodeにちゃんと提案したら通りそう。
辞書で使われる記号は外字や私的領域に配置するしかないんじゃないかな。
テレビ番組表で使われる記号[字]、[ニ]、[多]、[声]、[吹]、[演]など ([ ]は正方形囲み文字) は
Enclosed Ideographic Supplement (U+1F2xx) として収録されたから、同じブロックの
空き領域に辞書用の記号も追加してもらいたい。
合成文字ではいけない理由って今時ある？
https://twitter.com/rikakoikee/status/1135127518258667520
ポップコーンが美味しかった。
美味しいチャーハン食べたい。
チーズドックもマックのポテトも食べたい…🍟
美味しいお寿司🍣アボカド🥑
と、からみチキン
食べたいものと行きたいとこが多すぎる🐭🏰
(deleted an unsolicited ad)
他の、スマホ系やネット文化系の板で絵文字スレを立てるのはそっちの文脈での必要に応じてやればいいが。
それを言ったら、漢字も合字で構わなくないか? 1文字ずつコードを割り当てずに、
パーツ(部首など)に分解し、パーツと配置方法をコードで指定するIDS方式にする。
ハングルも音素に分解する。そうすれば、CJKが占めていた膨大なコード領域が
明け渡され、Unicodeを16ビットに戻せる。非CJK圏の人々はそれを望んでいそう。
漢字は情報伝達効率がとても良くて、字 2バイトで character 18バイトと同等の
情報を伝達できる。IDS上下, ウ冠, 子 の6バイトで表しても、18バイトの3分の1しか
まだない。
糞
そうか？
画数で無駄だなぁって思っちゃった
それを言ったら、がよくわからんが
現状で漢字は個別、>>399の仮名は合成で表現する仕組みになってるもんをそれぞれわざわざややこしくするメリットある？
あと今更ひっくり返して形だけ16bitとか言語圏関係なく望んでないと思う
例えば[名]はU+540D U+20DE、(単)はU+5358 U20DDで表せる。
俺もそういうのがいいとは思うけど
同じ手偏でも幅が微妙に違ったりするじゃん。
そういうのって計算というより正直 美的感覚に基づくものだから，
結局 一字一字に「手偏の幅」とかいったパラメータを与える必要が出てきそう。
字形まで自動合成する必要はないだろ。字形は1字ずつデザインするが、それを呼び出すのに
IDSコードを使うだけ。
418だがそれはいいね。
それってソフトウェアやライブラリとして提供されてたりする？
もしよければ教えてほしい
これ。
結局調整が必要になるっぽいけど
IDSの組合せをそれが表現する漢字と対応させるんかと思ってた。
マ
「⿰山⿱上下」という並びが「峠」を意味するのか「山𠧗」を意味するのか区別できなくね？
あれは人間が読むことを前提にした文中で説明を簡素にするために使う記号であって
合成とか機械処理とかをやることははなから考えてないと思う。
⿰⿱山上下 → 峠
>>430 が正しい
⿰山⿱上下 → 峠 (正しい)
⿰山⿱上下 → 山𠧗 (不正)
山⿱上下 → 山𠧗 (正しい)
⿰⿱山上下 → 峠 (知らんがな)
最後のは不正では。
⿰⿱山上下なら
↓こんな文字になっちゃう
http://o.8ch.net/1gwka.png
曖昧さの余地はない筈。
⿰⿱山上下なら⿰(⿱(山, 上), 下)みたいな関数表示になって↑>>434みたいな字形になる。
UTF-8みたいなやつ
⿰男⿰女男
と
⿰⿰男女男
右端は俺orz
嬲は「⿲男女男」じゃないの？
正規化で一つにっていうのは判る
鼻濁音付き仮名文字は日本NBから提案したけど蹴られて今の姿になった。
http://std.dkuug.dk/JTC1/SC2/WG2/docs/n2092.pdf
仮名文字に限らずシーケンスで表現可能な文字に単体の文字コードを割り振ってもらうのは
相当説得力のある理由が要る。
逆に辞書用の記号は提案書を出せば通る可能性ありそう。
いや、>>444も言っている通り嬲は「⿲男女男」以外で表わせないと思うよ。
登録してほしいと思うのだが。
Unicodeってそもそも将棋の駒 全部登録されてないんじゃ？
とか
禁→木木示
とか
哭→口口犬
とか
と
畿→糸糸田戈
は同じ表現？
まあ機械処理向けの言語じゃないから
人が「分解できる」と思うかどうかだよね
ちなみに「畿」の部首って「田」なんだな。すげー意外。
ないよ。黒塗り五角形と白ヌキ五角形だけ。
●●構えっていうと門しか思い出せないし
●●囲いっていうと口しか思い出せないけど
将棋の駒の白抜き五角形は囲いなんだろうか
そこ日本の会社
枠線の中に複数文字入れるのどうするとか
中に「と」みたいなのを表示したい場合それは本当に「と」で表現するのかとかいろいろややこしくなりそう
将棋みたいに中身が決まってるやつは一通り個別に並べてもらったほうがシンプルじゃないのかな…
逆さのまではなくてもいいと思うがなあ
黒と白で、先手と後手を表しているだけだよ。
「テ」だったか「〒EL」みたいな
意味不明な文字が書いてある駒セットを
観たことがあるけど
あれはなんだったんだろう
朝鮮語か？
三 みたいなやつ？
全ての「成金」の文字は「金」を崩した文字だよ。
「と金」も、本当は「と」と書いてあるわけではなく、
「金」を崩した結果、「と」みたいになっているだけだよ。
その内 崩し字も登録されそう…とか思ったw
太字のaとかがなぜか「文字」として登録されてるんだから金の崩し字が登録されてもおかしくない
「と」と極めて似た文字になったという説がある
ニ
ヘ
なんでこれで金になるのかさっぱり判らん
https://blogimg.goo.ne.jp/user_image/50/8a/03ddf56cb868756327fb330bdd9e5231.jpg
あと
|
とか
レ
とか
謎のが多すぎ
どうなったか調べてみた。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されたらしい。
チェストーはインラインで使ったりするもんなんだろうか
漢字以外は興味持たないだろうって見透かされてるんだろうな
あきらかに文化的な偏りはあると思う。
この間もモンゴル文字かなんかを文字の結合方式とかをほとんど考慮しないで登録してしまった
という旨でUnicode共同体を批判してるブログ見掛けたし。
モンゴル文字のことはよくわからんが、ここに書いてあることによると、
> モンゴル文字は、語の中のどの位置にくるかによって、また母音調和等によって形が変化する。
> 中国・モンゴル国の両国ともに現状と地続きの音声アプローチの方を支持しているようであるが、
> 最終的にどの方式が選ばれるにしろ、相互運用性が確保されることは期待できそうである。
ということだから、現状の規格は、中国・モンゴル国が希望したものであって
欧米人が悪いというわけではないと思う。
f,i,j,l が続く場合は、文字を合字（リガチャ）にする場合が多い。
しかし、MSword も TeX も、「合字にせよ」という指定を入れなくても、
勝手に合字にしてくれるわけで、モンゴル文字も（よく解らんけど）
同じようにできないのかな、とは思う。
筆で金とうい字を1000回くらい書くとわかるようになるよ。ようは手抜き。
と
でいいのに
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRN0np1ZmeG8ZgXTV8K1Vjx-yF9KCNZgu3AKkiOYyYxdnnl-wk7
わらったw
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.2ch.sc/test/read.cgi/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。
釣られて そのスレ見に行ったけど
寧ろそのa4っていう小手の人が被害に遭ってるように思えたけどな
入力されたUTF-8文字列が何文字かを判定したりするのに都合の良いスクリプト。
その手の文字が登録されたことはあるのかな
LunaticとかAdobe的にいいのか
良いアイデアだと思う。
これ以上貴重な符号位置を占有しないで欲しい。
これとか。素晴しい発想だと思いませんこと？（お嬢様風）
実はそれを意図しているんだな、これが。
Webフォントが使えなかった場合に，意味不明な私的領域のコードポイントではなくその絵文字の「意味」の単語になるっていうフェールセーフ。
この発想はアクセシビリティの面からしてすごいと思う。
今までも↑こういうことを実現する手段はあったが（aria-*とか::beforeとかを活用する），
いささかハックじみた手法だったのに対して，この方法はほとんど何のひねりもないし，かつ
高いアクセシビリティを誇る。
素晴らしさを伝える記事とかないの？
全然意図してないと思うぞ。＞使った側の人が意図しなかった単語に化ける現象
これがアクセシビリティ向上になるのは入力者が単語と絵文字の対応を把握している場合だけで、
把握してない場合は入力者が知らない結果が出力される謎フォールバックになる。
入力者が絵文字パレットから選ぶ仕組みなら単語を把握してない可能性が高まるし、
個別に校正かけるなら元々あるimg altとかではなくWebフォントを使う強みは何？ってなるし
リッチテキスト使えるなら画像でいい
This is a penpen.や[Download Download Now!]は変やろ。あとThat is a ��guin.の誤爆避けも必要になる。
とか？ >>499
Webフォントを使う強みはページ読み込み速度の向上だと思うよ。
あ、それと色とか大きさとかをCSSでより柔軟に調整できる。
サブセット化もこれから足してくコンテンツ考えるとあんまりいいソリューションとは…
>>508
絵文字リガチャフォントだと高々100個くらいだから
日本語Webフォントの常識は当て嵌らんぞ
あえてこれ使いたいと思うならもちろん自由に使えばいいと思うが、
正直これを選ぶメリットがある局面はすごく限られてる気しかしない。
https://www.iso.org/standard/73773.html
いつの間にか完成していた。
BCってなに？
何これ？
>>97じゃないから確かなことは言えないけど
「better choice」じゃないかな？
つまり絵文字を「入れざるを得ない」ってことね。
FC: 前方互換性
BC: 後方互換性
UC: 上位互換性
LC: 下位互換性
ちい覚えた
correctはともかく左右は確実にねーだろw
わろたw
↑Unicodeの基本多言語面を使ったエンコード方法w
それbaseXXの本来の意味を成してないw
文字コードの本元の一つがこんな体たらくでいいのだろうか…w
https://www.w3.org/People/mimasa/xmldev.html.ja.sjis
あ、そういうことか。と思ったけどChromiumだとどうしようもねぇわ。
最近のブラウザって文字コードを修正する機能みたいなのって消えてるね。
Firefox68には文字コード指定が残ってる
通常は無効になってるけど>>531のリンク先を表示したときは有効になって
ISO-2022-JPを指定すると文字化けなしで読めた
XMLが使う符号化文字集合にUnicodeを推奨してるくらいじゃない？
これはひどいω
ファイル名まで .sjis つけてるくせになんで iso-2022-jp で保存してるのかイミフ
同じようなレスをした記憶が…と思ったら前スレにあった。
記憶障害じゃなくてよかったw
https://mevius.2ch.sc/test/read.cgi/tech/1516629503/821-843
どこの文化なんだろうか？
Windowsはsjisだからありえないし
Linuxも昔の普通はEUC-JPだろ？
iso-2022-jpはメールにしか使われてなかったはずだが
イシカワ マサヤスというのは誰だろうね。
どちらもICT業界から去ったのかな。
sjisやeuc-jpが整う前は、HTMLをiso-2022-jpにするのも選択肢の一つだったらしい
ttp://www.tohoho-web.com/lng/199801/98011002.htm
http://の先頭のhを取っても付けても同じですよ。
http://web.archive.org/web/19980116120529/http://www.pro.or.jp/~fuji/horrible/horrible.kanji.html
えぇ……。
そのリンク先に書いてあるけど、iso-2022-jp が使われてるのはMSが発端なのか？
> name="GENERATOR" content="Microsoft FrontPage 2.0"
> というのが各HTMLファイルの先頭にあることから、Microsoft の FrontPage が 漢字コードがシフトJISのファイルであるにもか かわらず、iso-2022-jp の指定するからではないかと思われます。
流れは似てるが今回は指摘されてるURLが問題なんだろ
よりによってアイツがってやつさ
HTMLの内容がiso-2022-jpというのはまた別問題か
sjis以外あるかな？ってやってみたら他のエンコーディングも見つかったし
>>531は単なる文字コード変換ミスかな？
https://www.w3.org/People/mimasa/xmldev.html.ja.aaaaa
俺の記憶にはないのだけども……。
中身がiso-2022-jpなんだってば
iso-2022-jpが使えるテキストエディタで書いたか
sjisに変換すべきところをiso-2022-jpに変換してしまったということ
昔のWindowsで書いたならsjisになるだろうから変換ミスかなって話
HTTPヘッダのcharsetが食い違ってるだけで
サーバー引越のときに設定間違えた可能性はあり得る
拡張子はjisじゃなくてsjisな
だからドキュメントの文字コードが明らかに間違ってるんだよ
ドキュメントからの文字コード判定の方を重視していた。
なぜならセキュリティというかサーバー運営者がよくわかっておらず
設定変更の必要性を理解できていなかったので設定されてなかった
たとえ設定変更ができるサーバーでもユーザーが理解していなかった
そんな時代だからブラウザで表示できれば良し程度のレベルが普通で
今からするとチェックが甘かった。その当時の間違った文字コードのページが今も残っている。
たぶんこんなところ
お前のレスの >>556 には jis って書いてあるだろω
お前が原因
単なる書き間違えじゃね？
リンク先見ればわかるでしょ
こういうおっちょこちょいが >>531 みたいなミス連発するんだろうな
固定ビット幅が実現できる唯一の規格であるUTF-32は希少では。
だからもしかすると文字コードでさえ適材適所なのかと考え始めている
ファイル読み書きのときはutf-8で勝利
あとはcps932が滅ぶのを待つだけ
UTF-32だとASCIIに比べて単純計算で四倍弱の容量を食ってしまうのが難点。
でもOSの本体くらいならそもそもテキストとして表現されてるファイルも少ないし案外肥大化は防げるのかも。
UTF-32でも一文字が32bitで収まるとは限らないからUTF-8でも大差ない
つまりx64版Linux用gccはstd::wstringがUTF-32。誰も使っていないように見えてそうでもない。
https://togetter.com/li/1396827
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/
本来UTF-32だけで必要十分だったのにどんどん複雑にしていって、
UTF-32でも不便になったからUTF-8でいいでしょ？
どうせ単純には扱えずライブラリ使うしか無いんだから。
という必要十分な文字コードを捨てたというのが現実
たったの32bitで足りるわけがない。
ではどうぞ御説明をどうぞw
codecvtは糞だ
だった
まあどっちでもいいけど
UTF-16を16ビットで1文字を表すと思い込んでいる人間がいるが、16ビット単位でデータ扱うだけで、1文字が32ビットのこともある。
それぐらいみんな知ってる
それぐらいみんな知ってる
貼れるんかこれ
https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b
スレの流れみた？UTF-32の話をしてんだぞ？
そのまえ
日本人ならＵＴＦ１６を掲げるＪａｖａを支持すべきだ
それは理由が書いてないから、読む価値ある？
ネットウヨの類は米英には尻の穴まで晒すようだし困ったものだ
じゃあ >>586 はスレの流れを遮って，古い話題を煽り文句で蒸し返した挙句，
碌な知識も持ってないことを晒してしまったヤベー奴ってことになるけどいいの？
もしくはiconv使う。
Ruby にも、NKF モジュールがある
文字コードに合った文字だけ使えば解決
煩雑な延命策を取らず、UTF32に完全移行すべきだった。
UTF16を残したせいでUTF32にも皺寄せが来ている。UTF32ではU+FFFFFFFFまで
対応できるはずなのに、UTF16のサロゲートペアで表せるU+10FFFFまでに符号空間が
制約されてしまった。つまり、実質的に32ビットではなく21ビットコードになってしまった。
UTF16を全廃しUTF32を本来の32ビットまで拡張すれば、異字体を異字体セレクタなしで
収録できるから、すべての文字を32ビットで表せて単純明快になる。
いろいろ間違ってるなｗ
まずUTF-16という仕様にはサロゲートペアが最初から含まれてる
UTF32に完全移行って何を移行するっていうんだ？互換性がないんだから
既に使われてるものを簡単に変えられるわけがない。
UTF32が21bitコードになってしまったのはUTF-8のせいだ
21bitあれば209万7152文字を表現できるんだから異字体セレクタなしで十分収録できる
異体字なんて数が限られているし、それ以上に役に立たない絵文字をバンバン追加している状況だし。
CP932とSJISとUTF16が生き残ってるのもだいたいこいつのせいだ
おまいもかなり可笑しいなω
>まず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で字体が違う
滅茶苦茶な欠陥規格だから、さっさと廃止した方が良い。
> UTF8は可変長だから、32ビットでも表そう思えば表せる。
無理。UTF-8は「自由に可変にできる文字コード」ではない。
ビットパターンが決まっていて最大21bitまでしか表現できない
原理的にはUTF8は「自由に可変にできる文字コード」で32ビットも表せる。
UTF16の制約で符号空間が21ビットのU+10FFFFまでと定められたから、
UTF8もそれを超えるコードを規格外とみなすようにしただけ。
エンコードと文字コードを混ぜんな
おまえみたいな奴がいるから混乱するんだよ
少しは馬鹿を自覚して黙ってろ
JavaやJavaScriptの内部エンコーディングもUTF-16だが
MSがSJISやめたら、世の中の既存の文書が
UTF8にでも変わると思ってんの？
魔法ですか？ｗｗｗ
どこからの？
セブンイレブンとか？
MSが企業に圧力を掛けたりして広めてきた歴史を言ってるんじゃなかろうか。
念の為言っておくとOOXML←OpenDocument、XPS←PDFね。
所でLinuxもデスクトップ環境も
一つに統一したほうが良いのではないか？ん？
それにPDFの競合規格はXPS以外にもたくさんある
https://ja.wikipedia.org/wiki/Portable_Document_Format#PDF%E3%81%AE%E7%AB%B6%E5%90%88%E8%A6%8F%E6%A0%BC
英語版Windowsも含めて日本語文字コードが内部で使われている
って思ってるやつは本当にいる
LinuxはWindowsとは思想がほぼ真逆だからね。
多様性を重んじる。俺はそっちのほうが好きかな。
でもそれを至高とするあまり，古いカーネルや別の派生版との互換性が，Windowsのそれらに比べてない。
当時PDFは国際標準にこそなってなかったが，
オープンフォーマットだったし，様々な場面で使われてた。
ただ描画ソフトがクソ重たいのしかなかった記憶がw
だから多様性を重んじるっていうのは
競合するフォーマットが複数できるってことで
（例えば画像フォーマットや圧縮フォーマット）
Microsoftが独自フォーマットを作るのと同じ思想なんだよ
> オープンフォーマットだったし
PDFはオープンではありませんでした。
プロプライエタリだって言ってるだろ
いつの知識なのかw
Windowsは表面的にはSJISで、内部ではUTF-16だ。
ほらな、SJISじゃないって言ってんのにSJISだっていう
潜在意識レベルでそう思い込んでるから治しようがないｗ
他言語の状況は知らんけど日本語以外でも似たようなものだろうな
「UTF-8以外R」みたいに言う奴多いよな。
影響範囲が大きすぎて、LinuxはUTF-16とかUTF-32には事実上対応できないんだよね
>多様性を重んじる。俺はそっちのほうが好きかな。
ところでホモにつきまとわれたらどうする？
ホモであることは否定しないが、ホモは嫌いという俺の感情も尊重していただきたい
これが多様性だ!
ホモにつきまとわれて困ると友人にこぼしたら、
性癖を暴露されたとか言われて更に嫌がらせで自殺された事件？
ああいうの見てると、ホモの権利拡大とかしちゃいかんよなって思うよなあ
Windowsが作るシステムファイルもSJISですよ？
そういうネタはいらんから
延々と嘘を書くのはやめてもらえませんか？
符号化方式がUTF-16やUTF-8など
どの符号化方式であってもUnicodeといえる
>>655
さて、何か言い返したい言葉は有るかね？
待ってても時間の無駄なので先に言っておくと
何も言わない or 捨て台詞はくだけ なら俺に喧嘩売らなければいいのにｗ
NTカーネル以外のものは他者だろ
まあ他人の人生だから干渉するつもりはないが，そういう生き方は苦労すると思うぞ？
https://en.wikipedia.org/wiki/FEFF
https://w.wiki/8Ew
https://w.wiki/8Hy
そのうち4文字になるんかな
違う
君の理屈だと中国はチベットの一部ということになる
UTF-16/32は端から過去互換性を捨ててるっていう理解OK？
ちゃんと仕様読め
意味がわからない
OK
>>682
ちゃんと仕様読め
685デフォルトの名無しさん2019/09/22(日) 02:18:18.82ID:tTe+mIIa
>>682
意味がわからない
686デフォルトの名無しさん2019/09/22(日) 11:35:45.78ID:LQCFANDg
>>682
OK
----
どういうことなの…
質問。皆さんが普段使っている文字コード変換ライブラリでおススメはなんですか。
それで満足しなきゃ自分で作るしかない
いまどきのまともな言語環境なら変換元のエンコーディングさえ分かってれば標準機能で出来るだろうに
それとも全角⇔半角の変換みたいなのをやりたいってこと？
https://ja.cppreference.com/w/cpp/string/multibyte/wcstombs
https://ja.cppreference.com/w/cpp/string/multibyte/mbstowcs
これ使え
https://docs.microsoft.com/ja-jp/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=vs-2019
https://docs.microsoft.com/ja-jp/cpp/c-runtime-library/reference/wcstombs-s-wcstombs-s-l?view=vs-2019
確かに便利でありがたかったです
https://mevius.2ch.sc/test/read.cgi/tech/1434079972/53
バグった挙句によけいな1byte追加しちゃったりした思い出。
https://www.vector.co.jp/soft/dl/winnt/net/se472641.html
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)
みたいなのでも良いです
そもそもありえない？
エージェントが読み込んだときに確実にShift JISだって判定できるんだっけか。
あるexeファイルをコマンドウインドウで開く。ということをしなきゃならないんだけどシフト＋右クリックしてもコマンドウインドウで開くというのがありませんでした
調べたら、コマンドウインドウで開くを表示したい場合メモ帳で名前を付けて保存の時に文字コードをUnicodeにして保存し実行したらレジストリがどうたら書いてあったんでしようとしたら、文字コードにUnicodeがありませんでした。
どうしたら良いですか？
>どうしたら良いですか？
諦める
高望みするから人間は苦しむんだよ
ASCII以外ではたぶん無いんじゃないかな
cp932としてもutf-8としても正しいバイト列で
それぞれが別の単語になるケースを探したことがあるけど、
それでも両方が意味のある単語になる例は見つけられかった
どういう目的でそういう例を探してるの？
cmdにd&dかバッチファイル作れ
これ以上はスレチ
ブログラム内の文字列のデータじゃなくてブログラムの地の部分
まともなエディタなら読めて当然。
これやな。
なんか謎の意匠がw
数字やアルファベットは半角を使うのが普通だからASCIIコードにある文字はASCIIコードを使った方がいいんだろうか
とか思われてるよ
っていうか IME で半角優先にしてるのでそっちばっかりになる
IME ON の状態であってもスペースももちろん半角だ
これらは単に全角と半角の関係ではないんじゃないかという気がする。
! や ? は書いてるのが日本語漢字仮名交じり文なら全角にするかも
2019 11 18
https://www.sankei.com/life/news/191118/lif1911180006-n1.html
感性で判断するんじゃなくて，論理的根拠をもって「，」か「、」かを決めるべきよね。
点があるのにコンマのような後ろにスペースを要する記号を使うのはおかしいと思う。
丸の代わりにピリオドを使うのも同じ。
それにしても、公文書の混ぜこぜの用法はどっちつかずだよな。
もともと、和文タイプライターで使われていた用法なのではないか？
これって、全角英数と同じで、日本語の体裁に合わせるためにわざわざ作られた文字だよねぇ。
フォント次第ながらも「，」は半角カンマ「,」と一目で見分けることができない。
一方「、」は全角しかない。よって誤植の起きにくい「、」で統一するべき。
半角の､だってあるだろ
AAとかでよく使われる
739は
囲う文字に合わせてる
欧米のカンマやピリオドの影響で明治後期くらいからだからな
縦書きでどの位置に「，」を打てばいいのよ？
なんで臨機応変に対応できないんだろう？
ウェブ上では横書き、本にしたら縦書きとかな
江戸時代のくずし字でかられた読み本は、句読点なし。読む人が判断することになっている。
活字慣れした現代人は太平洋戦争中の日記や戦場から送られてきた手紙さえ読めない。
よかったワープロが普及する前で
せいぜいサインする時に使うくらい
漢字や仮名は楷書でも筆の運びをちゃんと学んだ方が近道
多分、由来は漢文の補助点で句の切れ目に「、」を打って読みやすくしたもの。文末も句点だった模様。
一般に使われ出したのは明治でしょ
今年の漢字の季節ですね
災とかはこの前使ったよね
二年連続とかは知らん
３２ビット固定長の文字コードを使うようにしても
良いのじゃないだろうか？
ascii 的な世界（合衆国界隈とか）が発狂するので、utf-8 がつくられたのだと思います
まあコード内では utf-32 で統一するのがスマートですね
UTF16やUTF32では互換性を保てなかったのが理由
セレクタとか合成文字とか固定長に押し込むの非現実的でしょうに
具材がどうだとか細かなこと言ってて抽象化とは程遠いし、少なくとも色は与えるべきじゃなかった
ipaは都合約6万字ある
お前の一般が何かによる。
正式な正書法になったのは明治から。江戸時代の正書法は漢文の白文か武士の候文。
一方で庶民向けの版本や貸本では江戸期から句読点が使われてるので、本を読む層には馴染みがあった。
あと手習いの手本とかにも句読点があるので文字習う段階で知識として知ってるのでは。
ちんちんの絵文字は
剥けちんと包茎と勃起前とか勃起後とか色々バリエーション必要ですし
おもしろいと思っていってるの？
竹島はどこの国の領土ですか？
注意：「なぜその質問をしたいと思ったのですか」みたいな
質問を質問で返すようなクズな真似はしないこと
え？それ面白くないよ？面白いと思ってんの？プークスクス
という意味
違うと思う
QZは韓国人だから答えられないんでしょ
＞「なぜその質問をしたいと思ったのですか」
いやはや、私のパターンを熟知されているようでなにより、です、ちょっとうれしくなりました
なぜ韓国人だとおもったのですか？
https://medaka.2ch.sc/test/read.cgi/eco/1567773760/710
https://medaka.2ch.sc/test/read.cgi/eco/1567773760/712
https://medaka.2ch.sc/test/read.cgi/eco/1567773760/714
軍の統帥権が天皇と征夷大将軍(内閣総理大臣)のどちらにあるのか明確にしないと。
そのまえに格納方法をビッグエンディアンかリトルエンディアンで統一してくれ
竹島は日本の領土で、独島は韓国の領土だよ
なぜか韓国は竹島のことを独島だと言い張ってるけど
独島は別の島ですから、残念
おっとそれ以上言っちゃあいけない
https://special.sankei.com/a/life/article/20191130/0001.html
2019.11.30
2019年12月2日 19時21分
https://www3.nhk.or.jp/news/html/20191202/k10012198561000.html
「くずし字」解読は「文系」より「理系」向き！？
驚き！ ラーメン判別の技を応用
ＡＩの解読能力 高めるポイントは？
数億点もある難読資料 高まるＡＩへの期待
歴史資料の研究者からも期待の声
データのやりとりやファイルサイズが小さくなるのは理解できるけれども。
でもそれは圧縮機構を別途に設けたのではだめなのか？
https://ja.wikipedia.org/wiki/黒板太字
とかはかなりスタイル要素入ってると思うな。
てか数学用分野だけやけに優遇されてない？
でもそもそもを言い出したらYとVが元は同源だったりして、「純粋な文字」を綺麗に定義するのは無理よ
「優遇」っていうか，そういう文字を収録してた符号化文字集合と互換性を持たせるために導入したんでは。
例えば「(株)」っていう文字とかに代表される囲み文字はかなり日本語圏に偏向してるけど，
これだって日本を優遇してるんじゃなくて，日本で開発された符号化文字集合がそういう文字を含んでたから収録されている。
IMEってMS-IMEのこと？
それともかな漢字変換全般？
今年もこのスレの皆さんに多幸感がありますように！����������
ISO/IEC 10646の新版は今年中に出るかな～？
まぁ、文字コードの問題ではないんだが。
レスありがとう。どのOSにもそういう仕組みはないと思う。
よく上げられる例として、フォントの明示的な設定なしに\マークをバックスラッシュとして表示することはできない、というのもあるし。
一文字づつ判定して適切なフォントに変えて描画する処理を個々のアプリ自身が実装する必要があるはず。
https://gigazine.net/news/20200106-which-emoji-scissors-close/
面白い
https://bungu.plus.co.jp/product/cut/img/fcc_smart_03.jpg
localghost👻ってかわいくね？
→今まで危険そうで敬遠してたIDNに興味をもつ
→WikipediaとRFC3492を頼りにPunycodeのアルゴリズムを調べる
→エンコーダを自前で組んでみて、idn2コマンドやPythonの'idna'エンコーディングと比べてみる
→正規化する必要のある文字がどんどんふえる
→idn2とpythonのidnaってかなり違わくね？？ <-イマココ
idn2はギリシャ文字の「語尾のシグマ」ς(U+03C2)をσにしないし、あとチェロキー文字の大文字？を小文字？にしないし、けど小文字？はSupplementなのがなんかあやしいし、でidnaとどっちが正しいのか考えるのが面倒になって投げた
また国外から来にくそうな
http://blog.unicode.org/2020/01/unicode-emoji-130-now-final-for-2020.html
詰将棋用に上下逆の漢字を入れて欲しかった
国ごとに生活が違うから、結局何万種必要になる
手書きの分析しているソフトは本当に賢いと思うわ
まああれは面倒な文字はそもそも判定せず、
主要な文字から似たものを選んでいるだけではあるが・・・
> インラインテキスト中で使われている用例が示されていないのでrejectされたらしい。
ということらしいが、なら、タピオカミルクティーにインラインテキスト中で
使われている用例があるのか、と言いたい。だから納得できない。
取捨選択もなく全然洗練されないまま数だけ増えてる
政治的に正しい仏教徒とは何ですかね？
アホな創価学会員が言いそうな発言ですが。
☸️
↓
☸
専ブラでは絵文字として読めるがWebブラウザー(Chrome/旧Edge/IE11@Win10)で見ても◆◆状態でうまく表示されない…
全部あるぞ。お茶は「湯呑み」として。検索の仕方が足りない。
Unicode前提です
Unicode的にアジアンなんとかというドキュメントでそれに触れられているのを見つけましたが
結局のところ使用されているフォントで決まるような気がします
となるとCLIアプリが表示する前に判別する方法はないような
表示したあとならターミナルにカーソル位置問い合わせればわかりそうだと思いましたが
☸
うちのChromeはちゃんと出てる
ffでも問題なし
前にpythonで書いたときは
unicodedata.east_asian_width()
使ったと思う
Win32APIだと表示前に文字列全体の描画幅を求める方法があったと思う
・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で実装されているのでおかしくなる
詳しい解説サンクス
あざす
やっぱり混沌としてるのですね
とりあえず一度ターミナルの中を追ってみようかな
シフトJISの第2バイトがA0～FFでなく
40～FCにしたのは何でだろう
×A0～FF
〇80～FF
0x40開始で0x7Fを避けて2区分取ると0xFCになる
半角カナのせいで80～FFでは足りないから
JISコードの変換式もより簡単にでき
2バイト目もASCII領域を使わずにダメ文字も発生せず
補助漢字も全て入れられた
あのスペースの狭さでは、それは無理だったのでは？
どうするのがよかったのですか？具体的にいってみてよ
第１水準：[80-9F] [A1-FE]
第２水準：[E0-FF] [A1-FE]，[E0-EB] [80-9F]
補助漢字：[A0-DD] [A1-FE]，[A4-C1] [80-9F]
補助漢字は半角カナと排他利用
それは結局半角カナを潰しただけのことでは？
補助漢字6000字近くを使えるというメリットがあれば
半角カナをフェードアウトするには十分な機会になっただろう
補助漢字（JIS X 0212）が制定されたのは1990年だから
その翌年の1991年に発売されたMS-DOS 5.0あたりで
KANA ON／OFFコマンドを追加し、半角カナ／補助漢字の切り替えが出来れば
従来のテキストファイルの読み込みなども対応できる
文字コードのマップ切り替えはコンテンツ側で指示するべきことであって、OS/アプリ側で切り替えて対応するとか、発想が変だとおもいますね
合成文字はなくせない
コンテンツ側でなくユーザー側
イングランドの旗はUnicodeで7コードポイント必要なので64bitでは無理
128bitで
え、じゃあイギリスの旗はさらにそれにスコットランド分とアイルランド分が追加されるの
https://www.itmedia.co.jp/news/articles/2002/13/news068.html
まあGoogleじゃ無理か。
文字数：15000字超（非漢字：1700字超，漢字：13300字超）
区点域：0～127区，0～127点（最大16384字収納）
通 称：いちごJIS
修正の入った 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
(deleted an unsolicited ad)
色
女
子
言
周
https://srad.jp/story/20/03/06/1237211/
Windows と日本語のテキストについて - Windows Blog for Japan
https://blogs.windows.com/japan/2020/02/20/about-windows-and-japanese-text/
21以降も外字で作ってしまっていた事務所を思い出す
何度かPCを入れ替えるうちに使わなくなり、忘れ去られ、
久々に古い文書を引っ張り出して来たら謎の文字化けで外字の存在が発覚
外字が何故か?から始まってたり途中に別の字が挟まってたりしてもはや解読作業
Unicodeですら未だに無いんだよな．．．
それともなにか君は辞書から陰茎とか陰核という単語を削除せよというのか!
◎と字形が同じとかで一緒にされそう
あと将棋の駒(上下とか白黒)も欲しいとか言ってた人？
凸の下辺がないようなやつ
50まで作るんだったら、99まで作れば良かったのに。
できれば、100まで欲しかった。
⛫
Unicodeがまさにそんな感じだよ
符号位置なんて空いてりゃなんでも詰め込んでくる
囲み付き文字は合字でなんぼでも表示できるんじゃなかったのか？
黒字に白抜きはないか。
https://home.unicode.org/announcing-the-unicode-standard-version-13-0/
http://www.unicode.org/versions/Unicode13.0.0/
Components of Unicode 13.0.0
http://www.unicode.org/versions/components-13.0.0.html
Core Specification (PDF)
http://www.unicode.org/versions/Unicode13.0.0/UnicodeStandard-13.0.pdf
Code Charts (PDF・110 MB)
http://www.unicode.org/Public/13.0.0/charts/CodeCharts.pdf
改訂するのは確か毎年6月ねって決めたんじゃ……と思ったら去年から3月だった。
使ってるUnicodeは2015年に出た8.0のままなんだよな．．．
新しいフォント入れてもリンクが効かんという...
全部入りフォント作るにゃ16bitの壁
そんな罠が
それともISO/IECはまた別の判断か
https://www.iso.org/covid-19.html
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.
��トイレットペーパー
🦠
最近と細菌がかかってるというわけかい？
絵文字
🦠
意味
微生物
【類似･説明】細菌、ウイルス、アメーバなどを表す
