文字コード総合スレ Part12

**デフォルトの名無しさん** · 2018/12/16(日) 12:38:15.61

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
　（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
　（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 https://mevius.5ch.net/test/read.cgi/tech/1516629503/

**デフォルトの名無しさん** · 2018/12/16(日) 23:11:32.43

ちょっと考えれば分かるようなことをなぜ聞くんだろう。

**デフォルトの名無しさん** · 2018/12/17(月) 20:40:27.55

ちょっと考えれば解るなんてすごい人だな。
ちょっと書いてみ

**デフォルトの名無しさん** · 2018/12/17(月) 21:18:18.25

あげ

**デフォルトの名無しさん** · 2018/12/18(火) 03:08:10.44

nkf - Network Kanji Filter Fork
https://ja.osdn.net/projects/nkf/scm/git/nkf/
v2.1.5
2018-12-15 18:19:02

**デフォルトの名無しさん** · 2018/12/18(火) 11:22:36.98

>やはり頭悪いのはunicodeと符号化を混同してる

ここは同意

>2つ以上のｵｸﾃｯﾄを使う符号単位で
>BOM入れないﾔﾂは池沼だからな

これは嘘

**デフォルトの名無しさん** · 2018/12/19(水) 00:20:13.76

低学歴知恵遅れには
ｴﾝﾃﾞｨｱﾝの概念がないのが
よおく分かったわ

**デフォルトの名無しさん** · 2018/12/19(水) 00:28:37.33

CPUの内部形式とデータには何の関係もない
現にネットワークデータはCPUとは無関係の並びになってる

**デフォルトの名無しさん** · 2018/12/19(水) 00:54:40.89

やっぱあれ書いたの半角さんだったんだｗ

**デフォルトの名無しさん** · 2018/12/19(水) 00:57:03.62

うわあ。。。
ﾏｼﾞでいってんの

こういうﾏｼﾞもんの低学歴がこの板で
はば利かせてるのがよく分かるわ

ﾏｼﾞで頭悪いことを
ﾊｼﾞもなくなんの躊躇もなくいうからな

ﾌﾟﾛｸﾞﾗﾑで
いちいｴﾝﾃﾞｨｱﾝ変換してんのすら
しらないらしいわ

当然Unicodeのｴﾝｺｰﾄﾞ方法にも
ﾋﾞｯｸﾞｴﾃﾞｨｱﾝとﾘﾄﾙｴﾝﾃﾞｨｱﾝがある

**デフォルトの名無しさん** · 2018/12/19(水) 00:58:18.75

もうね低学歴すぎてﾔﾊﾞｲって
ちなみﾈｯﾄﾜｰｸでﾃﾞｰﾀを交換するときは
暗黙で基本はﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝになってる

常識だからなｺﾚ

**デフォルトの名無しさん** · 2018/12/19(水) 01:00:17.18

低学歴知恵遅れって
なんでものすごい頭悪いことを
自信満々にいうわけ？

**デフォルトの名無しさん** · 2018/12/19(水) 01:12:57.34

ちなみipｱﾄﾞﾚｽの並びはﾋﾞｯｸｴﾝﾃﾞｨｱﾝになってる
ﾎﾟｰﾄ番号も当然ﾋﾞｯｸｴﾝﾃﾞｨｱﾝになってる

ｿｹｯﾄ通信のﾌﾟﾛｸﾞﾗﾑ組んだことあるなら
ﾎﾟｰﾄ番号設定するのにhtons（ｺﾚはｵｸﾃｯﾄ2つになる）という関数を使ったことあるﾊｽﾞだ

ちなみにこの関数はﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機なら
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝに変換された値がかえってくる

ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの計算機なら
そのままﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝの値がかえってくる

**デフォルトの名無しさん** · 2018/12/19(水) 01:39:07.45

半角カタカナはAAにしか見えない

**デフォルトの名無しさん** · 2018/12/19(水) 06:24:21.16

最近の子はバイトオーダーなんて意識しないからな
常識としては知っててほしいがけど
低レベルな処理書かなきゃ関係ないし触れることもないだろうから知らなくても困らんな
アラインメントとかパディングとかも同様

**デフォルトの名無しさん** · 2018/12/19(水) 12:49:47.13

エンディアン嘘つかない

**デフォルトの名無しさん** · 2018/12/19(水) 16:46:27.07

>>23
バイトオーダーを意識する機会が減ったのは、xmlやjsonなどテキスト形式でデータ受け渡しすることが多くなったから。
テキスト形式ならバイトオーダーを意識せずに済むし、スクリプト言語で扱うのにも便利。

**デフォルトの名無しさん** · 2018/12/19(水) 20:30:33.10

いやいや、テキストでもUTF16とかUTF32ならめっちゃ意識するやん。

◆QZaw55cn4c · 2018/12/19(水) 20:51:34.30

>>24
豆知識、endian とは？
もともとは、卵を丸い方の端 (big end) から割る人々（Big Endians）と尖った方の端から割る人々 (Little Endians) との対立を表したものだった

**デフォルトの名無しさん** · 2018/12/20(木) 01:35:41.75

そういえばハンプティダンプティの絵文字がない

**デフォルトの名無しさん** · 2018/12/20(木) 03:36:13.08

バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。
C/C++で開発している時はコンパイラが自動的に配置・取得してくれるデータを、スクリプト言語では自力でオフセット調整して配置・取得しなければならない。
C/C++より簡単なことが長所だったはずのC#・Java・Perl・Python言語などで、低レベルなオフセット調節を自力で行う必要に迫られる皮肉な状況が起きる。

**デフォルトの名無しさん** · 2018/12/20(木) 04:20:27.30

> バイトオーダーやアラインメントは、C/C++以外の言語でバイナリデータを使おうとした時に強く意識することになる。
C/C++言語以外ではライブラリが処理してしまうんで意識しないかな
C/C++ライブラリを呼び出すライブラリを作るときは意識するだろうけど、
それって結局C/C++言語で書くんで、あれ？意識するのはC/C++かｗ

**デフォルトの名無しさん** · 2018/12/20(木) 06:53:32.14

>>30
例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。

**デフォルトの名無しさん** · 2018/12/20(木) 07:18:15.99

× 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、アセンブリ並みに低レベルなオフセット調節を自力で行う必要に迫られる。
○ 例えばWindows環境だと、C/C++以外の言語でWin32API関数を固有の構造体を入出力に使う場合、C/C++並みに低レベルなオフセット調節を自力で行う必要に迫られる。

◆QZaw55cn4c · 2018/12/20(木) 07:37:44.12

>>32
うーん、具体的な win32api 名（だけでいいです）を例示してください．

**デフォルトの名無しさん** · 2018/12/20(木) 07:43:09.20

>>31に聞いてください

**デフォルトの名無しさん** · 2018/12/20(木) 08:04:20.01

>>32
勝手に書き換えないでもらいたい。
C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが、他の言語だとそうはいかないので、アセンブリと同じようなオフセット調節が必要。
SendMessage(WM_COPYDATA)の送受信データの読み書きなど例はいくらでもある。

**デフォルトの名無しさん** · 2018/12/20(木) 10:08:25.12

>>35
>C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが

誰に騙された？

**デフォルトの名無しさん** · 2018/12/20(木) 13:46:21.36

実行メモリ上はともかく
ファイルやネットワークストリームでLEにするアホいるんか？

**デフォルトの名無しさん** · 2018/12/20(木) 16:58:53.93

エンディアンもさることながら32/64bit整数の幅調節が厄介。
使っている言語が32/64bitどちら向けでビルドされたものなのかによって構造体メンバのアラインメントを適切に処理する必要が出てくる。
言い換えれば、C/C++で作った構造体をバイト列で渡し、C/C++以外の言語でバイト列を構造体に復元する処理が厄介。
単に構造体の64bit整数メンバだけ気を付けるのではダメで、構造体の全メンバのアラインメントそのものが大きく変わりうることに注意する必要がある。

**デフォルトの名無しさん** · 2018/12/20(木) 18:26:27.50

いや、だからさ、その程度までは理解できてるのに、何故「C/C++だと構造体の各メンバ変数のアラインメントを意識しなくていいが」なんてことを言っちゃうの？
それとアラインメントの話とバイトオーダーの話を混同しないように気を付けた方がいいよ。

**デフォルトの名無しさん** · 2018/12/20(木) 19:07:05.38

C/C++しらないけど、魔法のようにアライメントを
勝手に調整してくれるんじゃないの？想像しただけで

**デフォルトの名無しさん** · 2018/12/20(木) 21:19:19.38

Unicodeは普通にﾘﾄﾙｴﾝﾃﾞｨｱﾝもありだ

なんで Byte Order Mark(BOM) がﾌｧｲﾙの先頭に入ってるのか分かってない
Javaﾊﾞｲﾄｺｰﾄﾞのcafe babeみたいな飾りだと思ってんの

ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機ばっかりがあるとこで
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝでﾌｧｲﾙを保存する理由なんかないからな

当然、そういったｺﾝﾃﾝﾂﾃﾞｰﾀがHTTPでも流れてくる

**デフォルトの名無しさん** · 2018/12/20(木) 21:20:17.21

やっぱりこの板には
ｸﾙｸﾙﾊﾟｰしかいない

そしてそのｸﾙｸﾙﾊﾟｰの声だけがでかい

やっぱりな低学歴知恵遅れは
この板から排除する必要がある
板が正常に機能しない

**デフォルトの名無しさん** · 2018/12/20(木) 21:26:52.62

アライメントはふつうコンパイラが適切に調整してくれるよね。
32/64bitで整数サイズの違いでメンバオフセットが変わるってのはアライメントとは別の話。

**デフォルトの名無しさん** · 2018/12/20(木) 21:31:46.95

32bitなら
ちゃんと32bitに詰まるように
ﾒﾝﾊﾞの順序かえる

**デフォルトの名無しさん** · 2018/12/20(木) 21:38:37.03

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でも考え方は同じ
強制ﾊﾟｯｷﾝｸﾞのｵﾌﾟｼｮﾝ使えるｺﾝﾊﾟｲﾗもある

**デフォルトの名無しさん** · 2018/12/20(木) 21:42:31.32

今問題としてるのはファイルの話だ。
32bitシステムで作られたファイルを64bitシステムに
持ってきたとしてもファイルの内容が変わるわけじゃない

つまりC/C++で32bitでint型で扱っていたからと言って
64bitでもint型で扱ってはいけないということだ

**デフォルトの名無しさん** · 2018/12/20(木) 21:44:56.46

ﾊﾞｶがよくやる誤りは
ﾒﾓﾘ境界をまたぐ位置で64bit値を参照したりして
ﾊﾞｽｴﾗｰを起こす

ｼﾘｱﾗｲｽﾞﾃﾞｰﾀを直に参照できると思ってるﾊﾞｶがあとをたたない
CISCの計算機しか使ったことないｻﾙ並の脳みそのﾔﾂがよくやる

**デフォルトの名無しさん** · 2018/12/20(木) 21:53:38.53

そんなﾌｧｲﾙ読み込むときに
普通にintなんか使わないからな
そんなことは低学歴知恵遅れしか発想できない

utf16なら16bit単位(uint16_t)
utf32なら32bit単位(uint16_t)
で読み込む

ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機で
ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝのUnicode読む場合は
16bit単位なら16bit単位でｵｸﾃｯﾄ列の並びを逆転させる
32bit単位なら32bit単位でｵｸﾃｯﾄ列の並びを逆転させる

ﾘﾄﾙｴﾝﾃﾞｨｱﾝの計算機で
ﾘﾄﾙｴﾝﾃﾞｨｱﾝのﾌｧｲﾙ読み込むならｵｸﾃｯﾄ列の並びを逆転させる必要はない

ﾋﾞｯｸﾞｴﾝﾃﾞｨｱﾝならその逆になる

低学歴知恵遅れはこういった基本的な理解がない

**デフォルトの名無しさん** · 2018/12/20(木) 21:59:01.65

>>45
C/C++の規格じゃ構造体のメンバは宣言された順にアドレスが増加するよう並べられることになっている。
仮に>>45のような最適化を行うことができる処理系が存在したとしても、一般的と言えるものではない。

**デフォルトの名無しさん** · 2018/12/20(木) 21:59:21.79

one little two little three little endians

**デフォルトの名無しさん** · 2018/12/20(木) 22:00:12.93

だからそう書いてる
手動で自分で並べ替える

**デフォルトの名無しさん** · 2018/12/20(木) 22:12:47.37

自分で並べ替えろって話か。それは勘違いした、すまん。

**デフォルトの名無しさん** · 2018/12/20(木) 22:23:36.55

結局C/C++でもアライメント意識して、自分で適切な型を選択しているってわけさ
他の言語でも一緒。ただし型が違うからバイト数を指定するだけの話

**デフォルトの名無しさん** · 2018/12/20(木) 23:02:54.77

PGならば、楽するためにJava/C#/Python/Perl/Rubyなどを使ってたはずなのに、C++よりめんどくさくなって心が折れそうになる経験を一度はしておいたほうがいい。

**デフォルトの名無しさん** · 2018/12/20(木) 23:23:21.93

いや、C++よりも面倒なことってないから
そんな経験するのは無理だよ

**デフォルトの名無しさん** · 2018/12/20(木) 23:49:16.62

やはり低学歴知恵遅れには
C++はむり

ﾚｽみればよく分かる
ﾚｽから頭の悪さがにじみ出てる

低学歴のﾚｽはすぐにわかるわ
残念なことに

**デフォルトの名無しさん** · 2018/12/21(金) 12:36:36.76

データのアラインメントはどんな言語を使うにしても気にする必要がある。
しかし、Windows が VisualC++ でビルドされていて、VisualC++
もしくは互換のアラインメントができる言語でアプリを組めば、
気にしなくてもよい、ということだけだろう。

**デフォルトの名無しさん** · 2018/12/21(金) 14:56:12.53

>>57
gcc も同じだよ。64bit版linux gccはwchar_tを16ビットにするか32ビットにするかを切り替えビルドできるからさらに厄介。
構造体を丸ごとダンプしたバイナリデータを同じOS上の別プロセスに渡すのは繊細な注意がいる。

**デフォルトの名無しさん** · 2018/12/21(金) 16:01:10.01

で、なんだっけ？バイナリファイルのデータが
16bitで格納されていようが32bitで格納されていようが
C/C++だったらアライメントを勝手に調整してくれるんだっけｗ
へー、勝手にねー、intで扱ってれば、勝手に調整してくれるんだーｗ

**デフォルトの名無しさん** · 2018/12/21(金) 16:43:13.79

intが16bitの組み込み向けプログラムであっても同じコンパイルオプションで作ったモジュール同士ならバイナリの復元はC言語の型キャストだけで可能。
構造体が仕様として公開されている場合、どの言語であれアラインメントを意識した実装が必要になるが、C言語は実装コストが最も低くなる傾向はある。
スクリプト言語を使う人がアラインメントを意識せずにすんでいるのは、ライブラリ実装した人が頑張ってくれた・くれているおかげ。

**デフォルトの名無しさん** · 2018/12/21(金) 17:01:59.77

一方他の言語では、指定したオフセットから何バイト読み込むか指定するだけなのであった

**デフォルトの名無しさん** · 2018/12/21(金) 17:02:51.29

C言語は、ヘッダファイル書いた人が頑張ってくれた・くれているおかげ

**デフォルトの名無しさん** · 2018/12/21(金) 17:23:19.85

>>61
先生。指定したオフセットから何バイト読み込むか指定する作業は、まさにアセンブラと同レベルの作業じゃありませんか。違いますか、先生。

**デフォルトの名無しさん** · 2018/12/21(金) 17:47:28.44

>>63
違いますね。memcpy相当ですから

**デフォルトの名無しさん** · 2018/12/21(金) 18:13:53.48

低学歴知恵遅れ先生はC/C++スレだけじゃなくてここにもくるようになったのか

**デフォルトの名無しさん** · 2018/12/21(金) 21:50:05.59

>>65
色んなところにいるよ

**デフォルトの名無しさん** · 2018/12/21(金) 22:02:28.52

相変わらず日本語の読解に問題がありそうな奴がいるなぁ。

**デフォルトの名無しさん** · 2018/12/21(金) 23:50:03.63

まず低学歴知恵遅れは
低学歴知恵遅れの自覚がないからな

**デフォルトの名無しさん** · 2018/12/22(土) 11:38:13.24

実行時に使用中のCPUがLEかBEかを判定するプログラムを
Cでサンプル欲しいのですがどこかにありますか？

**デフォルトの名無しさん** · 2018/12/22(土) 13:36:46.26

bool is_bigendian() {
　return htons(1) == 1;
}

**デフォルトの名無しさん** · 2018/12/31(月) 08:52:03.67

C1制御文字の<128>って多くの文字コードで「PAD」と名付けられているのに
UnicodeでのU+0080はxxxみたいに無名なのって理由ある？

**デフォルトの名無しさん** · 2018/12/31(月) 13:29:33.60

U+0080,U+0081,U+0084,U+0099は、ISO6429/ECMA-48で制御文字に含まれていない
というか削除されてる
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/01/01(火) 01:45:48.02

なんてこった
エイプリルフールだって？

**デフォルトの名無しさん** · 2019/01/01(火) 23:58:04.80

あけましておめでとうございます
2019年は何が起きるかしらね

**デフォルトの名無しさん** · 2019/01/02(水) 00:20:17.09

エイプリルフールはまだだけど元号ネタとかあるだろうな
新元号『NEO平成』に決定みたいな

**デフォルトの名無しさん** · 2019/01/02(水) 11:30:40.86

新元号『��』

**デフォルトの名無しさん** · 2019/01/02(水) 22:33:06.92

新元号が分からなくてグリフが間に合わないからUnicode 12.1を出すってのは仕方ないけど
新元号の組字のためだけにAdobeJapan1を改訂するってのは馬鹿げてる

**デフォルトの名無しさん** · 2019/01/03(木) 00:28:36.38

元号は安晋に内定してるだろ

**デフォルトの名無しさん** · 2019/01/03(木) 09:15:51.35

MS-DOS でのプログラミングではメモリ内の特定のバイトについて
文字の中の何バイト目かを 1 バイトずつ遡って調べるということも
あったようだけど自分ではそういうコードを書いた記憶がない。
いや、もしかしたらあったのかもしれないけど。
EUC-JP の場合は ASCII なバイトかシングルシフトが現れた時点で
確定するようだけど。Unicode の時代になって良かったね。
まあ、そんなようなことを今更思った。あけましておめでとう。

**デフォルトの名無しさん** · 2019/01/03(木) 21:04:56.87

>>72
ありがとう。
なにか事情があったんだろうけど、なんだろうね……。

**デフォルトの名無しさん** · 2019/01/04(金) 13:59:50.88

あけおめ

>>79
大昔のことだけど、SJIS 文字列の末尾から検索するプログラム書いてた時は「SJIS、お前はマジで殺す」という気持ちで一杯でした。
もう二度とあんなことはやりたくない。

79 · 2019/01/04(金) 17:36:17.24

ありがとう、まさにそういうことです。
p=strchr( path,'\\'); /* おい *p 、お前は本当に '\\' なのか? 表とかじゃないのか? */

**デフォルトの名無しさん** · 2019/01/04(金) 18:54:02.55

Windows環境ならそこは _mbschr() でしょ。

**デフォルトの名無しさん** · 2019/01/04(金) 19:30:16.38

UnicodeはSJISよりも扱いが複雑だけど
ライブラリが揃ってるからねー
一文字が1バイトだろうと3バイトだろうと
2文字で1文字を表していようが、簡単に一文字判定ができちゃう

**デフォルトの名無しさん** · 2019/01/04(金) 21:30:36.38

複数コードポイントで1文字を表すのって上限って決まってないの？青天井？

**デフォルトの名無しさん** · 2019/01/04(金) 22:02:58.14

UTF-8なら、最大四バイトだけど、そういうことじゃなくて？

**デフォルトの名無しさん** · 2019/01/04(金) 22:11:30.43

>>86
先ずコードポイントの意味を理解してから質問した方が良い

**デフォルトの名無しさん** · 2019/01/04(金) 22:27:33.32

なんかごめん

**デフォルトの名無しさん** · 2019/01/04(金) 23:45:49.70

>>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

**デフォルトの名無しさん** · 2019/01/04(金) 23:54:23.74

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文字になる。

**デフォルトの名無しさん** · 2019/01/05(土) 00:00:08.40

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バイトみたいね

**デフォルトの名無しさん** · 2019/01/05(土) 00:03:32.79

合成文字・絵文字とかが絡むともっと地獄になるけどな
http://tech.albert2005.co.jp/201/
https://qiita.com/nonanona/items/b148c212ba7c24942e93

**デフォルトの名無しさん** · 2019/01/05(土) 00:03:39.55

ZWJを使うと最大11文字だって。
https://n2p.co.jp/blog/column/counting-characters-on-twitter/

**デフォルトの名無しさん** · 2019/01/05(土) 00:07:24.29

Unicodeは1文字の概念も破綻しちゃったね
1文字に見えるやろ？でもこれは11文字なんや
全く意味がわからないｗ

**デフォルトの名無しさん** · 2019/01/05(土) 00:11:16.35

見た目上の1文字は最大4バイト×11文字で44バイトなのかな？ｗ
11文字ってのは今現在存在する最大が11文字ってだけで青天井？
もうライブラリ使ってないと無理だね

◆QZaw55cn4c · 2019/01/05(土) 00:12:47.39

世の中にあるすべての文字をコード化してやる！
という意義には賛同していたんですけれども、（主に経済的理由により）絵文字が入った時点で失望してしまいました…

仕切りなおしたほうがいいんじゃないですか？

**デフォルトの名無しさん** · 2019/01/05(土) 00:38:07.30

仕切りなおしてもBCで絵文字は入ります。
というかもはや絵文字は世界中のスマホ/SNSユーザーに愛用されています。
ここまでくるともはや後戻りはできないのです。

**デフォルトの名無しさん** · 2019/01/05(土) 00:46:41.68

仕切りなおすどころかUnicodeの規格がさらに拡張されて状況悪化するんだろうなあ
Unicode12も来年・・・じゃないやもう今年リリースされる予定のはずだし

**デフォルトの名無しさん** · 2019/01/05(土) 01:28:42.81

絵文字は象形文字の発展版なんだから
文字扱いするのは当然

**デフォルトの名無しさん** · 2019/01/05(土) 12:51:39.06

現代の文字は自然発生するわけでも王朝が発布するわけでもなくユニコードコンソーシアムが追加するのだ

**デフォルトの名無しさん** · 2019/01/05(土) 13:09:21.22

>>97
世界には文盲がわんさか居るから結局象形文字が必要ってことか

**デフォルトの名無しさん** · 2019/01/05(土) 15:08:59.93

世界が認めたニッポンのスゴーイ文化やぞ

**デフォルトの名無しさん** · 2019/01/05(土) 15:19:11.13

当の日本人にすら絵文字を扱いきれてなかったのに
そんなもんをコード化したら破綻するに決まってるんだよなぁ……

**デフォルトの名無しさん** · 2019/01/05(土) 16:29:31.32

1964年の東京五輪での案内表示がきっかけでしょ絵文字の開花は。

◆QZaw55cn4c · 2019/01/05(土) 17:03:40.22

>>99
絵文字と象形文字の間には確固たる断絶があります、おっしゃるような連続的なものではないと考えています
例えば、ある象形文字と別の象形文字との違いははっきりしていますが、ある絵文字と別の絵文字との違いを示す具体的な指標はないのでは？
それとも、これは私の知らなかったことですが、もしかして絵文字の内容はピクセル単位、あるいはベクターイメージですでに定義されているのですか？

**デフォルトの名無しさん** · 2019/01/05(土) 17:24:42.05

はい

**デフォルトの名無しさん** · 2019/01/05(土) 19:28:07.65

便器に◎とか〓とか描いてあっても何のことか判らんで悩むだけやぞ

**デフォルトの名無しさん** · 2019/01/06(日) 10:52:08.85

田穣崇さん『ドコモの絵文字にうんちを入れたかったのですが、社内で大反対されまして…』うんちの絵文字がUnicodeに登録されるまでの裏話
https://togetter.com/li/1305754

**デフォルトの名無しさん** · 2019/01/09(水) 21:32:33.71

うんちにも色バリエーションつけたいなあ

**デフォルトの名無しさん** · 2019/01/10(木) 11:56:03.90

カフェで野良WiFiのSSIDが絵文字になってたわ
うっかりつなぎそうになった