1 名前:デフォルトの名無しさん mailto:sage [2018/12/16(日) 12:38:15.61 ID:VlX3xGEw.net] Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。 プログラマーなら一度は煩わされたことのある文字コードについてのスレ。 UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、 合成文字、ソート、TRON、外字コード、その他について語り合いましょう。 各言語での文字列の扱いについての質問もOKです。 基本マッターリ、ささ、茶でもどうぞ。 ■過去スレ 文字コード総合スレ part1 pc11.2ch.net/test/read.cgi/tech/1031028205/ 文字コード総合スレ part2 pc11.2ch.net/test/read.cgi/tech/1143375639/ 文字コード総合スレ part3 pc11.2ch.net/test/read.cgi/tech/1180250376/ 文字コード総合スレ part4 pc11.2ch.net/test/read.cgi/tech/1228052369/ (スレ再利用)UnicodeとUTF-8の違いは? pc12.2ch.net/test/read.cgi/tech/1177930957/ (隔離スレ)UnicodeとUTF-8の違いは? その2 pc12.2ch.net/test/read.cgi/tech/1274937437/ 文字コード総合スレ part5 pc12.2ch.net/test/read.cgi/tech/1236529563/ 文字コード総合スレ part6 hibari.2ch.net/test/read.cgi/tech/1278923059/ 文字コード総合スレ part7 toro.2ch.net/test/read.cgi/tech/1306595564/ 文字コード総合スレ part8 peace.2ch.net/test/read.cgi/tech/1354248962/ 文字コード総合スレ part9 peace.2ch.net/test/read.cgi/tech/1401301779/ 文字コード総合スレ Part10 mevius.2ch.net/test/read.cgi/tech/1444822140/ 文字コード総合スレ Part11 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
30 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 03:36:13.08 ID:Epiz8Tj2.net] バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。 C/C++で開発している時はコンパイラが自動的に配置・取得してくれるデータを、スクリプト言語では自力でオフセット調整して配置・取得しなければならない。 C/C++より簡単なことが長所だったはずのC#・Java・Perl・Python言語などで、低レベルなオフセット調節を自力で行う必要に迫られる皮肉な状況が起きる。
31 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 04:20:27.30 ID:ojhJ7lIE.net] > バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。 C/C++言語以外ではライブラリが処理してしまうんで意識しないかな C/C++ライブラリを呼び出すライブラリを作るときは意識するだろうけど、 それって結局C/C++言語で書くんで、あれ?意識するのはC/C++かw
32 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 06:53:32.14 ID:Epiz8Tj2.net] >>30 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。
33 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 07:18:15.99 ID:ojhJ7lIE.net] × 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。 ○ 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、C/C++並みに低レベルなオフセット調節を自力で行う必要に迫られる。
34 名前: mailto:sage [2018/12/20(木) 07:37:44.12 ID:W1ypdRwu.net] >>32 うーん、具体的な win32api 名(だけでいいです)を例示してください.
35 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 07:43:09.20 ID:ojhJ7lIE.net] >>31 に聞いてください
36 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 08:04:20.01 ID:Epiz8Tj2.net] >>32 勝手に書き換えないでもらいたい。 C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが、他の言語だとそうはいかないので、アセンブリと同じようなオフセット調節が必要。 SendMessage(WM_COPYDATA)の送受信データの読み書きなど例はいくらでもある。
37 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 10:08:25.12 ID:48mnxvPx.net] >>35 >C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが 誰に騙された?
38 名前:デフォルトの名無しさん [2018/12/20(木) 13:46:21.36 ID:P4Rv6f7s.net] 実行メモリ上はともかく ファイルやネットワークストリームでLEにするアホいるんか?
39 名前:デフォルトの名無しさん [2018/12/20(木) 16:58:53.93 ID:Epiz8Tj2.net] エンディアンもさることながら32/64bit整数の幅調節が厄介。 使っている言語が32/64bitどちら向けでビルドされたものなのかによって構造体メンバのアラインメントを適切に処理する必要が出てくる。 言い換えれば、C/C++で作った構造体をバイト列で渡し、C/C++以外の言語でバイト列を構造体に復元する処理が厄介。 単に構造体の64bit整数メンバだけ気を付けるのではダメで、構造体の全メンバのアラインメントそのものが大きく変わりうることに注意する必要がある。
40 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 18:26:27.50 ID:6OEKrw3R.net] いや、だからさ、その程度までは理解できてるのに、何故「C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが」なんてことを言っちゃうの? それとアラインメントの話とバイトオーダーの話を混同しないように気を付けた方がいいよ。
41 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 19:07:05.38 ID:oZOw2Nhk.net] C/C++しらないけど、魔法のようにアライメントを 勝手に調整してくれるんじゃないの?想像しただけで
42 名前:デフォルトの名無しさん [2018/12/20(木) 21:19:19.38 ID:/Up9dRku.net] Unicodeは普通にリトルエンディアンもありだ なんで Byte Order Mark(BOM) がファイルの先頭に入ってるのか分かってない Javaバイトコードのcafe babeみたいな飾りだと思ってんの リトルエンディアンの計算機ばっかりがあるとこで ビッグエンディアンでファイルを保存する理由なんかないからな 当然、そういったコンテンツデータがHTTPでも流れてくる
43 名前:デフォルトの名無しさん [2018/12/20(木) 21:20:17.21 ID:/Up9dRku.net] やっぱりこの板には クルクルパーしかいない そしてそのクルクルパーの声だけがでかい やっぱりな低学歴知恵遅れは この板から排除する必要がある 板が正常に機能しない
44 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 21:26:52.62 ID:gpCj1726.net] アライメントはふつうコンパイラが適切に調整してくれるよね。 32/64bitで整数サイズの違いでメンバオフセットが変わるってのはアライメントとは別の話。
45 名前:デフォルトの名無しさん [2018/12/20(木) 21:31:46.95 ID:/Up9dRku.net] 32bitなら ちゃんと32bitに詰まるように メンバの順序かえる
46 名前:デフォルトの名無しさん [2018/12/20(木) 21:38:37.03 ID:/Up9dRku.net] 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でも考え方は同じ 強制パッキングのオプション使えるコンパイラもある
47 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 21:42:31.32 ID:oZOw2Nhk.net] 今問題としてるのはファイルの話だ。 32bitシステムで作られたファイルを64bitシステムに 持ってきたとしてもファイルの内容が変わるわけじゃない つまりC/C++で32bitでint型で扱っていたからと言って 64bitでもint型で扱ってはいけないということだ
48 名前:デフォルトの名無しさん [2018/12/20(木) 21:44:56.46 ID:/Up9dRku.net] バカがよくやる誤りは メモリ境界をまたぐ位置で64bit値を参照したりして バスエラーを起こす シリアライズデータを直に参照できると思ってるバカがあとをたたない CISCの計算機しか使ったことないサル並の脳みそのヤツがよくやる
49 名前:デフォルトの名無しさん [2018/12/20(木) 21:53:38.53 ID:/Up9dRku.net] そんなファイル読み込むときに 普通にintなんか使わないからな そんなことは低学歴知恵遅れしか発想できない utf16なら16bit単位(uint16_t) utf32なら32bit単位(uint16_t) で読み込む リトルエンディアンの計算機で ビッグエンディアンのUnicode読む場合は 16bit単位なら16bit単位でオクテット列の並びを逆転させる 32bit単位なら32bit単位でオクテット列の並びを逆転させる リトルエンディアンの計算機で リトルエンディアンのファイル読み込むならオクテット列の並びを逆転させる必要はない ビッグエンディアンならその逆になる 低学歴知恵遅れはこういった基本的な理解がない
50 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 21:59:01.65 ID:gpCj1726.net] >>45 C/C++の規格じゃ構造体のメンバは宣言された順にアドレスが増加するよう並べられることになっている。 仮に>>45 のような最適化を行うことができる処理系が存在したとしても、一般的と言えるものではない。
51 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 21:59:21.79 ID:KozHiIkR.net] one little two little three little endians
52 名前:デフォルトの名無しさん [2018/12/20(木) 22:00:12.93 ID:/Up9dRku.net] だからそう書いてる 手動で自分で並べ替える
53 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 22:12:47.37 ID:gpCj1726.net] 自分で並べ替えろって話か。それは勘違いした、すまん。
54 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 22:23:36.55 ID:tzmwAGAt.net] 結局C/C++でもアライメント意識して、自分で適切な型を選択しているってわけさ 他の言語でも一緒。ただし型が違うからバイト数を指定するだけの話
55 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 23:02:54.77 ID:Epiz8Tj2.net] PGならば、楽するためにJava/C#/Python/Perl/Rubyなどを使ってたはずなのに、C++よりめんどくさくなって心が折れそうになる経験を一度はしておいたほうがいい。
56 名前:デフォルトの名無しさん mailto:sage [2018/12/20(木) 23:23:21.93 ID:tzmwAGAt.net] いや、C++よりも面倒なことってないから そんな経験するのは無理だよ
57 名前:デフォルトの名無しさん [2018/12/20(木) 23:49:16.62 ID:/Up9dRku.net] やはり低学歴知恵遅れには C++はむり レスみればよく分かる レスから頭の悪さがにじみ出てる 低学歴のレスはすぐにわかるわ 残念なことに
58 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 12:36:36.76 ID:C7PBMVlX.net] データのアラインメントはどんな言語を使うにしても気にする必要がある。 しかし、Windows が VisualC++ でビルドされていて、VisualC++ もしくは互換のアラインメントができる言語でアプリを組めば、 気にしなくてもよい、ということだけだろう。
59 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 14:56:12.53 ID:wVAQd9sY.net] >>57 gcc も同じだよ。64bit版linux gccはwchar_tを16ビットにするか32ビットにするかを切り替えビルドできるからさらに厄介。 構造体を丸ごとダンプしたバイナリデータを同じOS上の別プロセスに渡すのは繊細な注意がいる。
60 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 16:01:10.01 ID:2iFVCAc3.net] で、なんだっけ?バイナリファイルのデータが 16bitで格納されていようが32bitで格納されていようが C/C++だったらアライメントを勝手に調整してくれるんだっけw へー、勝手にねー、intで扱ってれば、勝手に調整してくれるんだーw
61 名前:デフォルトの名無しさん [2018/12/21(金) 16:43:13.79 ID:wVAQd9sY.net] intが16bitの組み込み向けプログラムであっても同じコンパイルオプションで作ったモジュール同士ならバイナリの復元はC言語の型キャストだけで可能。 構造体が仕様として公開されている場合、どの言語であれアラインメントを意識した実装が必要になるが、C言語は実装コストが最も低くなる傾向はある。 スクリプト言語を使う人がアラインメントを意識せずにすんでいるのは、ライブラリ実装した人が頑張ってくれた・くれているおかげ。
62 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 17:01:59.77 ID:2iFVCAc3.net] 一方他の言語では、指定したオフセットから何バイト読み込むか指定するだけなのであった
63 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 17:02:51.29 ID:2iFVCAc3.net] C言語は、ヘッダファイル書いた人が頑張ってくれた・くれているおかげ
64 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 17:23:19.85 ID:wVAQd9sY.net] >>61 先生。指定したオフセットから何バイト読み込むか指定する作業は、まさにアセンブラと同レベルの作業じゃありませんか。違いますか、先生。
65 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 17:47:28.44 ID:2iFVCAc3.net] >>63 違いますね。memcpy相当ですから
66 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 18:13:53.48 ID:ORTv1gtC.net] 低学歴知恵遅れ先生はC/C++スレだけじゃなくてここにもくるようになったのか
67 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 21:50:05.59 ID:0muy2Btq.net] >>65 色んなところにいるよ
68 名前:デフォルトの名無しさん mailto:sage [2018/12/21(金) 22:02:28.52 ID:SVNbSsFy.net] 相変わらず日本語の読解に問題がありそうな奴がいるなぁ。
69 名前:デフォルトの名無しさん [2018/12/21(金) 23:50:03.63 ID:j37Ohb1y.net] まず低学歴知恵遅れは 低学歴知恵遅れの自覚がないからな
70 名前:デフォルトの名無しさん [2018/12/22(土) 11:38:13.24 ID:boWDflNh.net] 実行時に使用中のCPUがLEかBEかを判定するプログラムを Cでサンプル欲しいのですがどこかにありますか?
71 名前:デフォルトの名無しさん mailto:sage [2018/12/22(土) 13:36:46.26 ID:aa5NQG9N.net] bool is_bigendian() { return htons(1) == 1; }
72 名前:デフォルトの名無しさん mailto:sage [2018/12/31(月) 08:52:03.67 ID:Tj5kujd4.net] C1制御文字の<128>って多くの文字コードで「PAD」と名付けられているのに UnicodeでのU+0080はxxxみたいに無名なのって理由ある?
73 名前:デフォルトの名無しさん mailto:sage [2018/12/31(月) 13:29:33.60 ID:8Z6ezMyM.net] U+0080,U+0081,U+0084,U+0099は、ISO6429/ECMA-48で制御文字に含まれていない というか削除されてる www.ecma-international.org/publications/standards/Ecma-048.htm 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
74 名前:デフォルトの名無しさん mailto:sage [2019/01/01(火) 01:45:48.02 ID:kXQfWbAp.net] なんてこった エイプリルフールだって?
75 名前:デフォルトの名無しさん mailto:sage [2019/01/01(火) 23:58:04.80 ID:j16q/z48.net] あけましておめでとうございます 2019年は何が起きるかしらね
76 名前:デフォルトの名無しさん mailto:sage [2019/01/02(水) 00:20:17.09 ID:R6tFufwf.net] エイプリルフールはまだだけど元号ネタとかあるだろうな 新元号『NEO平成』に決定みたいな
77 名前:デフォルトの名無しさん mailto:sage [2019/01/02(水) 11:30:40.86 ID:6YX6jwF2.net] 新元号『』
78 名前:デフォルトの名無しさん mailto:sage [2019/01/02(水) 22:33:06.92 ID:Fz1uszjs.net] 新元号が分からなくてグリフが間に合わないからUnicode 12.1を出すってのは仕方ないけど 新元号の組字のためだけにAdobeJapan1を改訂するってのは馬鹿げてる
79 名前:デフォルトの名無しさん mailto:sage [2019/01/03(木) 00:28:36.38 ID:agNiXwq6.net] 元号は安晋に内定してるだろ
80 名前:デフォルトの名無しさん mailto:sage [2019/01/03(木) 09:15:51.35 ID:IESB6EpY.net] MS-DOS でのプログラミングではメモリ内の特定のバイトについて 文字の中の何バイト目かを 1 バイトずつ遡って調べるということも あったようだけど自分ではそういうコードを書いた記憶がない。 いや、もしかしたらあったのかもしれないけど。 EUC-JP の場合は ASCII なバイトかシングルシフトが現れた時点で 確定するようだけど。Unicode の時代になって良かったね。 まあ、そんなようなことを今更思った。あけましておめでとう。
81 名前:デフォルトの名無しさん mailto:sage [2019/01/03(木) 21:04:56.87 ID:ejflNGhp.net] >>72 ありがとう。 なにか事情があったんだろうけど、なんだろうね……。
82 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 13:59:50.88 ID:8DNHKlb4.net] あけおめ >>79 大昔のことだけど、SJIS 文字列の末尾から検索するプログラム書いてた時は「SJIS、お前はマジで殺す」という気持ちで一杯でした。 もう二度とあんなことはやりたくない。
83 名前:79 mailto:sage [2019/01/04(金) 17:36:17.24 ID:opswFKCW.net] ありがとう、まさにそういうことです。 p=strchr( path,'\\'); /* おい *p 、お前は本当に '\\' なのか? 表とかじゃないのか? */
84 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 18:54:02.55 ID:3Gm4cMvD.net] Windows環境ならそこは _mbschr() でしょ。
85 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 19:30:16.38 ID:EMYjNY+E.net] UnicodeはSJISよりも扱いが複雑だけど ライブラリが揃ってるからねー 一文字が1バイトだろうと3バイトだろうと 2文字で1文字を表していようが、簡単に一文字判定ができちゃう
86 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 21:30:36.38 ID:atCGQoq2.net] 複数コードポイントで1文字を表すのって上限って決まってないの?青天井?
87 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 22:02:58.14 ID:rG/yv5Zr.net] UTF-8なら、最大四バイトだけど、そういうことじゃなくて?
88 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 22:11:30.43 ID:FtJLKwOD.net] >>86 先ずコードポイントの意味を理解してから質問した方が良い
89 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 22:27:33.32 ID:atCGQoq2.net] なんかごめん
90 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 23:45:49.70 ID:EMYjNY+E.net] >>86 最大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
91 名前:デフォルトの名無しさん mailto:sage [2019/01/04(金) 23:54:23.74 ID:EMYjNY+E.net] ZWJシーケンス というのもあるね 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文字になる。
92 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:00:08.40 ID:41KVD0qa.net] https://unicode.org/emoji/charts/emoji-zwj-sequences.html#1f441_fe0f_200d_1f5e8_fe0f 酷いねー。見た目上は1文字なのにU+1F441 U+FE0F U+200D U+1F5E8 U+FE0F と5文字分使ってる バイト数だと17バイトみたいね
93 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:03:32.79 ID:fLBZxFEd.net] 合成文字・絵文字とかが絡むともっと地獄になるけどな tech.albert2005.co.jp/201/ https://qiita.com/nonanona/items/b148c212ba7c24942e93
94 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:03:39.55 ID:41KVD0qa.net] ZWJを使うと最大11文字だって。 https://n2p.co.jp/blog/column/counting-characters-on-twitter/
95 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:07:24.29 ID:41KVD0qa.net] Unicodeは1文字の概念も破綻しちゃったね 1文字に見えるやろ?でもこれは11文字なんや 全く意味がわからないw
96 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:11:16.35 ID:41KVD0qa.net] 見た目上の1文字は最大4バイト×11文字で44バイトなのかな?w 11文字ってのは今現在存在する最大が11文字ってだけで青天井? もうライブラリ使ってないと無理だね
97 名前: mailto:sage [2019/01/05(土) 00:12:47.39 ID:F8+3E8Pf.net] 世の中にあるすべての文字をコード化してやる! という意義には賛同していたんですけれども、(主に経済的理由により)絵文字が入った時点で失望してしまいました… 仕切りなおしたほうがいいんじゃないですか?
98 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:38:07.30 ID:198zQJKz.net] 仕切りなおしてもBCで絵文字は入ります。 というかもはや絵文字は世界中のスマホ/SNSユーザーに愛用されています。 ここまでくるともはや後戻りはできないのです。
99 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 00:46:41.68 ID:fLBZxFEd.net] 仕切りなおすどころかUnicodeの規格がさらに拡張されて状況悪化するんだろうなあ Unicode12も来年・・・じゃないやもう今年リリースされる予定のはずだし
100 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 01:28:42.81 ID:41KVD0qa.net] 絵文字は象形文字の発展版なんだから 文字扱いするのは当然
101 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 12:51:39.06 ID:l3tIMYns.net] 現代の文字は自然発生するわけでも王朝が発布するわけでもなくユニコードコンソーシアムが追加するのだ
102 名前:デフォルトの名無しさん [2019/01/05(土) 13:09:21.22 ID:Lsf8iZgV.net] >>97 世界には文盲がわんさか居るから結局象形文字が必要ってことか
103 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 15:08:59.93 ID:WAT5i9L3.net] 世界が認めたニッポンのスゴーイ文化やぞ
104 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 15:19:11.13 ID:dE0KuiGH.net] 当の日本人にすら絵文字を扱いきれてなかったのに そんなもんをコード化したら破綻するに決まってるんだよなぁ……
105 名前:デフォルトの名無しさん [2019/01/05(土) 16:29:31.32 ID:XzO5Y/Fl.net] 1964年の東京五輪での案内表示がきっかけでしょ絵文字の開花は。
106 名前: mailto:sage [2019/01/05(土) 17:03:40.22 ID:F8+3E8Pf.net] >>99 絵文字と象形文字の間には確固たる断絶があります、おっしゃるような連続的なものではないと考えています 例えば、ある象形文字と別の象形文字との違いははっきりしていますが、ある絵文字と別の絵文字との違いを示す具体的な指標はないのでは? それとも、これは私の知らなかったことですが、もしかして絵文字の内容はピクセル単位、あるいはベクターイメージですでに定義されているのですか?
107 名前:デフォルトの名無しさん mailto:sage [2019/01/05(土) 17:24:42.05 ID:41KVD0qa.net] はい
108 名前:デフォルトの名無しさん [2019/01/05(土) 19:28:07.65 ID:2yRzjNJO.net] 便器に◎とか〓とか描いてあっても何のことか判らんで悩むだけやぞ
109 名前:デフォルトの名無しさん mailto:sage [2019/01/06(日) 10:52:08.85 ID:6OQPByjN.net] 田穣崇さん『ドコモの絵文字にうんちを入れたかったのですが、社内で大反対されまして…』 うんちの絵文字がUnicodeに登録されるまでの裏話 https://togetter.com/li/1305754
110 名前:デフォルトの名無しさん mailto:sage [2019/01/09(水) 21:32:33.71 ID:Duz5lH4D.net] うんちにも色バリエーションつけたいなあ
111 名前:デフォルトの名無しさん [2019/01/10(木) 11:56:03.90 ID:+qf2Eno1.net] カフェで野良WiFiのSSIDが絵文字になってたわ うっかりつなぎそうになった
112 名前:デフォルトの名無しさん mailto:sage [2019/01/10(木) 14:02:26.62 ID:LOQSfV+x.net] 形状バリエーションも欲しい 巻きうんち/一本糞/ビチグソ
113 名前:デフォルトの名無しさん mailto:sage [2019/01/10(木) 18:35:20.73 ID:1lL5sq44.net] POO WITH TURBANとかもほしい
114 名前:デフォルトの名無しさん mailto:sage [2019/01/14(月) 01:16:50.95 ID:s6eFaywu.net] U+FFFCとU+FFFDの違いってなんだろう。 一応https://www.unicode.org/charts/PDF/UFFF0.pdf←ここを読んでみたんだが U+FFFCが「Unicodeの範囲で異常」、U+FFFDが「Unicodeですらない」 ことを示す文字なのかな?
115 名前:デフォルトの名無しさん mailto:sage [2019/01/14(月) 11:40:16.54 ID:tN6VIVTj.net] Unicodeですらないのに「
116 名前:U+〜」という表記はこれ如何にw [] [ここ壊れてます]
117 名前:デフォルトの名無しさん mailto:sage [2019/01/15(火) 16:00:55.99 ID:exaSay/9.net] 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.
118 名前:デフォルトの名無しさん mailto:sage [2019/01/15(火) 18:43:18.89 ID:cLBK0jiu.net] >>115 sorry Japanese only please
119 名前:デフォルトの名無しさん mailto:sage [2019/01/15(火) 20:15:36.54 ID:XDACXjEE.net] >>116 なんで卑屈なの?
120 名前:デフォルトの名無しさん [2019/01/16(水) 11:07:49.88 ID:vTKVQdGX.net] 朝鮮人クオリティ
121 名前:デフォルトの名無しさん mailto:sage [2019/01/17(木) 14:01:24.86 ID:yxSqAYIN.net] 消えゆく「黒電話」マーク…時代とともに変化 https://www.sankei.com/premium/news/190117/prm1901170009-n1.html
122 名前:デフォルトの名無しさん mailto:sage [2019/01/17(木) 14:27:36.24 ID:fAu7Qwle.net] 一方、保存ボタンには相変わらずフロッピー
123 名前:デフォルトの名無しさん [2019/01/17(木) 21:08:16.21 ID:rro3H2AR.net] 今はこうですよ https://www.appps.jp/wp-content/uploads/2017/01/20170131-tell-icon-news-008.jpg
124 名前:デフォルトの名無しさん mailto:sage [2019/01/17(木) 21:10:53.89 ID:1NGaj4L3.net] ダウンロードかな
125 名前:デフォルトの名無しさん [2019/01/18(金) 04:13:25.86 ID:6U5tZjv3.net] 山 ↑ の方が合ってると思うけど 現実は ↓ 下載
126 名前:デフォルトの名無しさん mailto:sage [2019/01/18(金) 15:39:10.11 ID:XYduBDiM.net] 直訳かよ
127 名前:デフォルトの名無しさん mailto:sage [2019/01/19(土) 00:58:09.98 ID:cLBGydY8.net] >>115 これ使われてるの?
128 名前:デフォルトの名無しさん mailto:sage [2019/01/19(土) 01:02:48.22 ID:TqFwYkHH.net] 使われてるよ
129 名前:デフォルトの名無しさん mailto:sage [2019/01/20(日) 06:25:45.86 ID:kFywruI2.net] >>115 んーつまり基本的にはU+FFFDを使っとけばいいのかな。 マジで英語が読めんので当てずっぽうだがw
130 名前:デフォルトの名無しさん mailto:sage [2019/01/20(日) 19:36:07.54 ID:GM/wkhUD.net] FFFC はオブジェクト用。変換のときに絵でも音楽でも写真でも、主に文字以外のものが埋め込まれていた場合用。 FFFD は文字用。変換のときに他の文字コードでは表現できる文字がユニコードでは表現できなかった場合用。