文字コード総合スレ 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/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が絵文字になってたわ
うっかりつなぎそうになった

**デフォルトの名無しさん** · 2019/01/10(木) 14:02:26.62

形状バリエーションも欲しい
巻きうんち/一本糞/ビチグソ

**デフォルトの名無しさん** · 2019/01/10(木) 18:35:20.73

POO WITH TURBANとかもほしい

**デフォルトの名無しさん** · 2019/01/14(月) 01:16:50.95

U+FFFCとU+FFFDの違いってなんだろう。
一応https://www.unicode.org/charts/PDF/UFFF0.pdf←ここを読んでみたんだが
U+FFFCが「Unicodeの範囲で異常」、U+FFFDが「Unicodeですらない」
ことを示す文字なのかな？

**デフォルトの名無しさん** · 2019/01/14(月) 11:40:16.54

Unicodeですらないのに「U+～」という表記はこれ如何にｗ

**デフォルトの名無しさん** · 2019/01/15(火) 16:00:55.99

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.

**デフォルトの名無しさん** · 2019/01/15(火) 18:43:18.89

>>115
sorry Japanese only please

**デフォルトの名無しさん** · 2019/01/15(火) 20:15:36.54

>>116
なんで卑屈なの？

**デフォルトの名無しさん** · 2019/01/16(水) 11:07:49.88

朝鮮人クオリティ

**デフォルトの名無しさん** · 2019/01/17(木) 14:01:24.86

消えゆく「黒電話」マーク…時代とともに変化
https://www.sankei.com/premium/news/190117/prm1901170009-n1.html

**デフォルトの名無しさん** · 2019/01/17(木) 14:27:36.24

一方、保存ボタンには相変わらずフロッピー��

**デフォルトの名無しさん** · 2019/01/17(木) 21:08:16.21

今はこうですよ
https://www.appps.jp/wp-content/uploads/2017/01/20170131-tell-icon-news-008.jpg

**デフォルトの名無しさん** · 2019/01/17(木) 21:10:53.89

ダウンロードかな

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

山

↑
の方が合ってると思うけど
現実は
↓

下載

**デフォルトの名無しさん** · 2019/01/18(金) 15:39:10.11

直訳かよ

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

>>115
これ使われてるの？

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

使われてるよ

**デフォルトの名無しさん** · 2019/01/20(日) 06:25:45.86

>>115
んーつまり基本的にはU+FFFDを使っとけばいいのかな。
マジで英語が読めんので当てずっぽうだがw

**デフォルトの名無しさん** · 2019/01/20(日) 19:36:07.54

FFFC はオブジェクト用。変換のときに絵でも音楽でも写真でも、主に文字以外のものが埋め込まれていた場合用。
FFFD は文字用。変換のときに他の文字コードでは表現できる文字がユニコードでは表現できなかった場合用。

**127** · 2019/01/21(月) 07:51:07.97

>>128
なるほど「オブジェクト」ってそういう意味か！
ありがとう。
つまり基本的に（Unicode環境で）「文字化け」した場合は
U+FFFCを目にすることはない訳だ。
（Webブラウザなら画像は別の形で表示されるし
端末なら8bitキャラクタの集合としてU+FFFDが使われるし）

**デフォルトの名無しさん** · 2019/01/21(月) 10:29:40.20

そもそも外部に公開するドキュメントにU+FFFC,U+FFFDが存在すべきでないということでは。
アプリケーションが内部で使ってよい領域という意味と受け取ったわ。

◆QZaw55cn4c · 2019/01/22(火) 01:05:00.00

漢字コードのことでわからなくなりましたので質問いたします。
よろしくお願いいたします。

https://pc.watch.impress.co.jp/docs/column/config/1158344.html
＞文字データをシフトJISではなく、Unicodeで保存するとどんないいことがあるのか。
＞たとえばUnicodeならあらゆる言語の文字を混在させることができる。
＞Wordでしか文書を書かないエンドユーザーにはそんなこと当たり前じゃないかと言われそうだが、

これって本当ですか？

私見では日本語の漢字と中国語の漢字を同一文書にて同時に表示できないし混在もできない、と思っていたんですが…。
CJK 漢字統合の影響はもう過去の話になってしまったんでしょうか？

**デフォルトの名無しさん** · 2019/01/22(火) 02:31:06.16

字体とか書体を文字としてどう考えるか、で答えが変わるだろ

◆QZaw55cn4c · 2019/01/22(火) 02:34:15.81

>>132
現に存在するUTF-32/UTF-8 という文字コードの集合を使用した場合に日本語と中国語の漢字を
①：同一文書に含ませることは可能でしょうか？②：①が可能であったとして、PC の画面にて同時に表示することは可能でしょうか？

**デフォルトの名無しさん** · 2019/01/22(火) 02:59:07.23

どっちも可能

**デフォルトの名無しさん** · 2019/01/22(火) 07:59:46.55

新しめのブラウザでUTF-8の文書を書いて、中国圏の自体にしたい文字を
<span lang="zh">
みたいに指定してやると全く同じコードポイントでも違う字形になる。

**デフォルトの名無しさん** · 2019/01/22(火) 13:07:54.27

>>131
こいつはプログラマじゃないからな
かなり適当な理解で記事描くな

**デフォルトの名無しさん** · 2019/01/22(火) 14:56:00.21

>>131
Unicodeは全世界の文字に対応した文字コード
混在して使えるのは当たり前

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

>>133
より正確に言えば、
保存するときにローカルの文字コードに変換してるソフトかもしれないのでそのソフトの仕様による
例えば英文フォントしかないPCだと漢字は表示できないだろうから表示できるかどうかは環境による
だろう

>>131
あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ

**デフォルトの名無しさん** · 2019/01/23(水) 08:37:00.98

>131
私?では日本?の?字と中国?の?字を同一文?にて同?に表示できるし混在もできるが。

**デフォルトの名無しさん** · 2019/01/23(水) 08:38:04.03

あちゃー。unicode文字が全部?になってしまった。

**デフォルトの名無しさん** · 2019/01/23(水) 12:18:22.13

>>138
> あらゆる言語とは言うけど、縄文時代の日本語を混在させるのは無理だと思うがなあ
縄文時代の日本語が文字コードで表せるならばUnicodeで表せる

**デフォルトの名無しさん** · 2019/01/23(水) 20:08:35.75

>>141
文字がないのに文字コード化できるの？

**デフォルトの名無しさん** · 2019/01/23(水) 23:59:31.81

漂流する論点

**デフォルトの名無しさん** · 2019/01/24(木) 10:44:11.21

論点ずらしは朝鮮人のはじまり

**デフォルトの名無しさん** · 2019/01/24(木) 14:09:11.07

>>142
俺に言うな。>>138に家
縄文時代の日本語を混在できないとしたら、
それは例えば「文字がない」ことなのに、
Unicodeだから無理みたいな言い方してるんだから