文字コード総合スレ Part11

**デフォルトの名無しさん** · 2018/01/22(月) 22:58:23.45

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/

**デフォルトの名無しさん** · 2018/08/16(木) 08:19:53.82

ファイルシステムに記録された物理的encodingに依存したコーディングができる方が良いという主張かねぇ。

**デフォルトの名無しさん** · 2018/08/16(木) 08:31:16.13

Windows標準のXmlLiteというXMLパーサーは、入力ファイルがどんな文字エンコードだろうと、
UTF16に適宜変換するようになっているので、プログラマに読み取り時の文字エンコード選択の余地はない。

**デフォルトの名無しさん** · 2018/08/16(木) 10:25:22.61

>>701
内部ネイティブ文字コードがcharになっているLinux/Unixでは
char非互換の文字コードに対応するのが大変だったという主張

>>702
Windowsは内部ネイティブ文字コードがUnicode（UTF-16）だから
別にそれでいいのでは？

それにしても結果論ではあるけど、wchar_tは失敗だったねぇ
16bitでは足りないことは最初からわかっていたけど、たとえ32bitであっても
異字体セレクタやらで意味的な1文字のbit数が固定ではなくなってしまった。
固定でないならば単純な実装で文字を扱うのは不可能。
whar_t使うメリットが無くなってしまった。

まあその怪我の功名で絵文字に色がつけられるようになり、肌色の違いも
対応も可能になったんだけど、これも良かったんだか悪かったんだが。
ここまで来たら絵文字以外の文字も全て色変化対応にしたらって思う
そうすりゃエスケープシーケンスなしで色を付けられるよ
もはや文字コードじゃないね

**デフォルトの名無しさん** · 2018/08/16(木) 10:57:13.81

Win10 1809のコンソールはUTF-8対応

Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY)
https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/

**デフォルトの名無しさん** · 2018/08/16(木) 11:03:08.50

アホが頑張るとろくなことにならない

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

wchar_t のこと何もわかっていないのに適当なこと言ってるな。
wchar_t は一つのプログラムで複数の文字コードを切り換えて使うための仕組みで、外部用の多バイトコードから内部文字コードに変換するのは当たり前。
char を wchar_t に書き換えるだけで済むとか誰も思っていない。そんなの言うだけ恥かしい。
大きさも規格では少なくとも 8bit で sizeof(wchar_t) >= 1 というだけ。なので 8bit でも 64 bit でも何でも良い。
windows で UTF16、linux の glibc で UTF32 を wchar_t にいれてるのは勝手にそうしてるだけで、そうしないといけないという決まりはないし、そうじゃないOSも普通にある。内部コードなので何を入れてるかはプログラマやユーザが気にする必要はない。
あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。ASCII が 7bit というのは常識レベルの知識。

**デフォルトの名無しさん** · 2018/08/16(木) 21:42:21.17

それで何が言いたいの？

**デフォルトの名無しさん** · 2018/08/16(木) 21:43:39.72

常識だし当たり前のことだから、
言ってることに間違いはないってことかな？

**デフォルトの名無しさん** · 2018/08/16(木) 21:50:57.04

ｵﾚですら電子ﾒｰﾙでは半角ｶﾅは使わないからな

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

今時のまともなMUAでいわゆる半角カナに対応できないものってあるかな？
fj全盛の20年前ならいざ知らず。

**デフォルトの名無しさん** · 2018/08/16(木) 22:16:46.79

C/C++

　The C and C++ standard libraries include a number of facilities for dealing with
　wide characters and strings composed of them. The wide characters are defined using
　datatype wchar_t, which in the original C90 standard was defined as

　　"an integral type whose range of values can represent distinct codes for all
　　 members of the largest extended character set specified among the supported
　　 locales" (ISO 9899:1990 §4.1.5)

　Both C and C++ introduced fixed-size character types char16_t and char32_t in the
　2011 revisions of their respective standards to provide unambiguous representation
　of 16-bit and 32-bit Unicode transformation formats, leaving wchar_t implementation-defined.
　The ISO/IEC 10646:2003 Unicode standard 4.0 says that:

　　"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently,
　　 programs that need to be portable across any C or C++ compiler should not use
　　 wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined
　　 wide characters, which may be Unicode characters in some compilers."

ｶﾝﾍﾟｷな引用
やはりｵﾚのﾚｽはｶﾝﾍﾟｷ

**デフォルトの名無しさん** · 2018/08/16(木) 22:23:45.92

会社のﾒｰﾙは勝手にﾒｰﾙに含まれる半角を全角にかえやがる
※　必要で半角をいれてるからな

半角でﾌｫﾙﾀﾞ名つけるﾊﾞｶがいるせいで
その半角を含むﾊﾟｽに格納されてる資料のおいてあるﾊﾟｽを送ると
ﾒｰﾙ送ったあと一時期必ず文句がきてたからな

　その資料にｱｸｾｽできないと
　そんな場所ないと

うんざりしたから
この部分が半角ですと書いてやっても
ｱｸｾｽできないと返信が来る

何度か半角でﾌｫﾙﾀﾞ名つけたﾊﾞｶを探しだして
しばいたろかと思ったわ

**デフォルトの名無しさん** · 2018/08/16(木) 22:33:35.19

しばくんじゃなくてフォルダ名を変更すれば済むじゃん
あんたタイムゾーンスレでずっとそういう趣旨のこと言ってるよねｗ

**デフォルトの名無しさん** · 2018/08/16(木) 22:38:11.04

ﾌｫﾙﾀﾞ名は一回変更したわ

すると突然
半角以下にあるﾘﾝｸがすべてｱｸｾｽできなくって
みなが大騒ぎになったわ

そんなことやったのはだれだと
幸いｵﾚがやったとﾊﾞﾚずに済んだが

**デフォルトの名無しさん** · 2018/08/17(金) 00:58:59.23

掲示板に半角カナで書くバカもいる

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

メールで送らなければいい
会社のメールを変えればいい
会社を変えればいい

半角君の発想だとこんな感じ

**デフォルトの名無しさん** · 2018/08/17(金) 02:37:02.49

掲示板に半角ｶﾅ使うなとか原始人かよw

**デフォルトの名無しさん** · 2018/08/17(金) 05:01:13.36

>>706
今北産業

**デフォルトの名無しさん** · 2018/08/17(金) 05:32:43.08

>>718
そいつは勘違いしてるよ。

Linux/UnixはUTF-16などASCIIと互換性がない文字コードに
対応するのが大変だからUTF-8を作ったという話をしてるのにそれをわかってない
UTF-16に対応しようと思ったら、あちこちで使われてるcharをwchar_tに変えないといけない
printfですら使うことができない。まあ現実的に不可能だわな

最初からUnicode（UTF-16）対応として設計開発された
Windows NTとは違うわけだ

**デフォルトの名無しさん** · 2018/08/17(金) 06:41:03.91

>>719
詳しい解説サンクス
wchar_t 難し杉ない？

**デフォルトの名無しさん** · 2018/08/17(金) 07:06:48.04

外国人は鼻ほじりながら「おまいら大変だなー」と同情してるだろうな
charで全て賄える文字文化圏が羨ましい

**デフォルトの名無しさん** · 2018/08/17(金) 14:32:22.25

＞外国人は鼻ほじりながら「おまいら大変だなー」と同情してる

その手の輩も今はemojiに対応するために結局Unicodeと向き合わなくちゃならなくなってるけどな

**デフォルトの名無しさん** · 2018/08/17(金) 17:39:37.76

>>717
フォルダ名に半角カナ使うなとか原始人かよw

**デフォルトの名無しさん** · 2018/08/17(金) 17:52:36.10

>>723
？？

**デフォルトの名無しさん** · 2018/08/17(金) 17:57:13.67

バカ「半角カナを使うと文字化けするんだぞ！使うの禁止！」

それは昔メールでよく使われていたISO-2022-JPに半角カナがないのが
理由なのでSJISやEUC-JP、今の主流のUnicodeにはあてはまりません。
ISO-2022-JPでなければ半角カナ使って良いんですよ。

バカ「む、難しい言葉でごまかすな！」

**デフォルトの名無しさん** · 2018/08/17(金) 18:37:13.62

わざわざ使うようなものでもないけどな

**デフォルトの名無しさん** · 2018/08/17(金) 20:09:50.97

やっぱりバカどもは
なんにもわかってないわ。。。

電子メールでいうテキストというのは
７ｂｉｔだけで表現されたもんをテキストといってるワケ
つまり、伝統的にａｓｃｉｉ（７ｂｉｔ）だけで表現されてるデータをテキストと呼称してる

昔は、７ｂｉｔのデータしかやりとりできなかったネットワークもあったからな
ｕｔｆ－８とかｓｈｉｆｔ－ｊｉｓとかな、メールでは意味不明なバイナリーなわけ

分かる？

そんなテキストもどきでも
いまでもプロトコルの規定どおり７ｂｉｔのデータ以外を発信してはいけないのは当然

　
　Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ：　７ｂｉｔ　←　コレは絶対だからな

ｕｔｆ－８やｓｈｉｆｔ－ｊｉｓのテキストもどきならｂａｓｅ６４エンコードするとかしないといけない
そのままがいいならｕｎｉｃｏｄｅのエンコード形式でｕｔｆ－７という選択肢もある

**デフォルトの名無しさん** · 2018/08/17(金) 20:12:42.50

お、書けた
ﾙｰﾀ再起動でも書けなかったのに
>>727のﾚｽをｻｸﾗで半角全角変換するだけで書けた
どの部分がよくなかったのかよくわからん
ｻｰﾊﾞｰが>>727のﾚｽをｾｷｭﾘﾃｨﾌﾞﾛｯｸではじいてるみたいだったからな

まあいいか

**デフォルトの名無しさん** · 2018/08/17(金) 20:12:47.89

今北産業

**デフォルトの名無しさん** · 2018/08/17(金) 20:14:07.81

日本のすべてのｼｽﾃﾑではずっとな
ﾒｰﾙのﾃｷｽﾄ表示まで保証されてるのはiso-2022-jpにﾏｯﾋﾟﾝｸﾞできる文字だけだからな
iso-2022-jpにﾏｯﾋﾟﾝｸﾞできない文字はそもそも保証されてない

※ JISにﾏｯﾋﾟﾝｸﾞできないUnicodeやShift半角ｶﾅなんか保証してない
※ 最低でもiso-2022-jpのﾌｫﾝﾄなら日本のどのｼｽﾃﾑにも用意できてるﾊｽﾞだからな
※ そうでないとﾃｷｽﾄすら表示できない

保証されなくてもいいなら、そのままばっちいままのﾃｷｽﾄもどきをｴﾝｺｰﾄﾞして発信すればいいﾜｹ
別にUTF-8、Shift_JISで送ってはいけないということはない
※ UTF-8なんかもともとｴﾝｺｰﾄﾞされてるｵｸﾃｯﾄをさらに7bitにｴﾝｺｰﾄﾞしてから発信することになる

わかった？

**デフォルトの名無しさん** · 2018/08/17(金) 20:17:14.05

結論をいえば
受信されるｼｽﾃﾑで最終的にそのｼｽﾃﾑ用にﾃﾞｺｰﾄﾞまでできて
表示まできるのなら問題ない
それだったら受信したﾔﾂも腹もたたない

表示できないﾒｰﾙもらったら腹立つだろ
ﾃﾞｺｰﾄﾞ未対応だったり未対応形式だったりするｴﾛ動画をしらずにﾀﾞｳｿしてな、
そのｴﾛ動画が再生できないのと同じぐらいの強いｲﾗﾀﾞﾁを感じるﾊｽﾞだからな

**デフォルトの名無しさん** · 2018/08/17(金) 20:18:53.90

ﾎﾝﾄなこの板は低学歴底辺知恵遅れのｺﾞﾐｸｽﾞしかいないのがよく分かるわ

　> あと「8bit のASCII」とか寝惚けたこと言ってるけどそんなこと言うやつは文字コードの話する資格ない。
　> ASCII が 7bit というのは常識レベルの知識。

ID:HgLxU9xgやｵﾚみたいにきわめて常識的なこといってるﾔﾂが叩かれて
しったかﾃｷﾄｰなこといってる低学歴底辺知恵遅れが幅をきかせてるのがこの板だからな。。。

**デフォルトの名無しさん** · 2018/08/17(金) 20:29:28.96

>Ｃｏｎｔｅｎｔ－Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ：　７ｂｉｔ　←　コレは絶対だからな

前世紀の遺物かよｗ
つかオマエ、mohtaみたいでキモいんだが。

**デフォルトの名無しさん** · 2018/08/17(金) 20:32:13.67

　MIME-Version: 1.0

MIME-Versionは1.0しかない
ﾎﾝﾄな知恵遅れがいってることは
いつも意味が分からない

**デフォルトの名無しさん** · 2018/08/17(金) 20:34:01.29

低学歴底辺知恵遅れの世界にﾌﾟﾛﾄｺﾙなんかないからな

低学歴底辺知恵遅れﾄﾞｶﾀは
ﾈｯﾄﾜｰｸのﾌﾟﾛｸﾞﾗﾑなんかやらないから関係ない

**デフォルトの名無しさん** · 2018/08/17(金) 20:37:37.32

低学歴底辺知恵遅れと
まともな人間の間では
そもそも意思疎通は不可能

ﾌﾟﾛﾄｺﾙがまったく違う
低学歴底辺知恵遅れ特有のﾌﾟﾛﾄｺﾙがあるらしいが
ｵﾚはそのﾌﾟﾛﾄｺﾙがまったく分からない

**デフォルトの名無しさん** · 2018/08/17(金) 22:48:02.68

氏名における「髙」や「𠮷」や「乭」 | yasuokaの日記 | スラド
https://srad.jp/~yasuoka/journal/623209/

読売の元の記事貼ろうと思ったらネット上には無かった……。
JIS X 0213ベースなのか？
戸籍統一文字と住基ネット文字コードの擦り合わせしたデータベースはどうするんだあれ

**デフォルトの名無しさん** · 2018/08/18(土) 12:04:57.41

UNICODEで恥ずかしい書き込みしてた人が
大量レスでスレ流ししてるようにしか見えない

**デフォルトの名無しさん** · 2018/08/18(土) 12:25:36.64

ID:yTcXDgUV
連投してID赤くしてたら誰もレス読まないぞ

**デフォルトの名無しさん** · 2018/08/18(土) 12:27:24.39

>>739
＞ID赤くしてたら
皆が皆、専用ブラウザを使っているとは限らないのでは？

**デフォルトの名無しさん** · 2018/08/18(土) 12:33:47.22

unicode の議論と wchar_t の議論を混ぜるやつは素人。
unicode が普及するすっと前から wchar_t は普通に使われてる。

**デフォルトの名無しさん** · 2018/08/18(土) 14:13:23.54

そりゃ使われてるかどうかで言えば使われてるだろうけど。

そんなことよりも技術的な所気にならない？

問1 16bitのwchar_tで1バイトまたは 3バイトのEUC-JPを
扱う場合メモリイメージはどのようになるでしょうか？

問2 32bitのwchar_tで1バイトのEUC-JPを扱う場合
メモリイメージはどのようになるでしょうか？

答えわかる？意外すぎてびっくりするよ。

**デフォルトの名無しさん** · 2018/08/18(土) 14:15:44.35

16bitのwchar_tや32bitのwchar_tの使い方（エンコーディング）によるとしか

**デフォルトの名無しさん** · 2018/08/18(土) 14:18:12.19

>>743
そういう答えの場合は、知ってる実装を一つだけでもいいので答えてくれればいいよ

**デフォルトの名無しさん** · 2018/08/18(土) 14:33:57.87

>>744
コンパイラとか libc を設計する奴以外は内部実装関係ないやろ。内部実装に依存したら移植性が無くなる。
知りたかったらlibcのソース嫁。最近の linux の glibc ならUCS4に統一。昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。

**デフォルトの名無しさん** · 2018/08/18(土) 14:42:51.01

> 昔のunixだと EUCコードそのまま16ビットでフラグ付きで入れてた。
それはwchar_tが32bitってことかな？
16bitでは不可能だよね？

**デフォルトの名無しさん** · 2018/08/18(土) 14:48:48.76

wchar_t自体はcharset/encoding独立だとしても、実際にEUC-JPを格納する実装が
存在していたとは知らなかったな。

**デフォルトの名無しさん** · 2018/08/18(土) 14:55:58.85

>>746
知らないなら、変な知ったかぶりせずに黙ってるべき。
実装によって色々差があるけど最上位ビットとかをフラグに使用して16ビットに詰め込んでたんだよ。
うろ覚えだけど、例えば
0021-007e に ascii
00a1-00fe に jis kana
2121-7e7e に 0208
a1a1-fefe に 0212
とか、そんな感じ。

**デフォルトの名無しさん** · 2018/08/18(土) 15:23:20.80

やけに wchar_t にこだわる（かみつく）奴がいるけど理由がわからん
内部がどういうエンコーディングかはプログラマは意識する必要ないのに

**デフォルトの名無しさん** · 2018/08/18(土) 15:32:18.21

>>747
16ビットでなくて 32ビットで良いなら、今でも FreeBSD は EUC-JP をそのまま wchar_t に入れてる。
32bit なのでフラグ操作とかもなくて生のまま 0x008fa2be とか 0x00008ea0 とか。

**デフォルトの名無しさん** · 2018/08/18(土) 16:04:03.91

低学歴低知能のｸｸｿﾆｰﾄどもや底辺ﾄﾞｶﾀどもは
自分がどんだけ知恵遅れなこと書いてるのか
なかったことにししてる

ｻﾏｰﾀｲﾑｽﾚでも同じだからな
ｺｲﾂﾗ

**デフォルトの名無しさん** · 2018/08/18(土) 19:02:32.17

>>742
漏れの知ってる答えは
１も２もそういうコード書く奴はクビ

**デフォルトの名無しさん** · 2018/08/21(火) 10:01:44.15

RFC 8369 - Internationalizing IPv6 Using 128-Bit Unicode
https://tools.ietf.org/html/rfc8369

**デフォルトの名無しさん** · 2018/08/21(火) 14:20:52.24

あれだろうなと確認したらやはりあれだった

**デフォルトの名無しさん** · 2018/08/21(火) 14:31:10.12

ああ、アレだな

**デフォルトの名無しさん** · 2018/08/21(火) 15:54:58.52

あれだよねあれ。あれ安くて美味しいよね

**デフォルトの名無しさん** · 2018/08/21(火) 15:56:11.80

え？ハトが？

**デフォルトの名無しさん** · 2018/08/24(金) 18:18:47.09

すいません文字コードについて教えてほしいことがありますマジものの初心者なんですがどうかおねがいします

Unicodeの一種（？）で65280文字ある種類のものを、なんと呼ぶのでしょうか。
（最初の方は透明に見えるフォントで始まり、最後の方は全角英数などが割り当てられています
http://www.m-hoz.com/jsp/unicode.jsp?Bgn=0&;End=65536
このページと想定しているものはまったく同じです）
WikipediaなどでUnicodeの記事を読んだのですが、バージョンや面やサブセットなどたくさんの種類があり
私が利用したいと思っている65280文字を含むUnicodeの一集合のことをなんと呼べばいいのか分かりませんでした。
というか正直、Unicodeというのは65280文字（0xFFFF番目ですから）までしかないものと思っていましたが
なんかそれを遥かに凌ぐ量の文字が収録されていると書いてあり余計に混乱してしまいました
文字コードに関する知識がほとんどなくおかしい文章になってしまいすいませんよろしくおねがいします。

**デフォルトの名無しさん** · 2018/08/24(金) 18:42:02.68

65536-256

**デフォルトの名無しさん** · 2018/08/24(金) 18:46:30.51

>>758
正直なところ何を言いたいのか理解できないのだが、Unicode で定義されている文字なら公式サイトで全部見られるよ。

Code Charts
http://unicode.org/charts/

**デフォルトの名無しさん** · 2018/08/24(金) 19:19:57.24

>>758
基本多言語面
https://ja.wikipedia.org/wiki/%E9%9D%A2_(%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89)#%E5%9F%BA%E6%9C%AC%E5%A4%9A%E8%A8%80%E8%AA%9E%E9%9D%A2

Unicodeは似てる文字を一つにまとめて約6万5000文字（16bit）に収めるぞーって
言っていたのが、案の定無理だと破綻し（だから言っただろうがバカメリケンが）、
21bitを使い最大で約111万文字収録可能になってる
最新のUnicode 11.0 では13万7439文字が収録されてる

**デフォルトの名無しさん** · 2018/08/24(金) 19:24:24.02

Unicodeはもはや文字コードじゃない
文字シーケンスというべきだろう
複数の文字を使って1文字を表している

**デフォルトの名無しさん** · 2018/08/24(金) 20:11:02.68

>>761
「基本多言語面」
ありがとうございます！すみません。言い方がボケナスで余計な労力をお掛けしました。
この言葉が知りたかったのです。

ちなみに極めてどうでもいいことですが
マインクラフトというゲームのフォントを変えたいと思っており
その為のフォントおよび文字コードの勉強していこうとしていたところでした。

**デフォルトの名無しさん** · 2018/08/25(土) 06:50:31.16

HTML のフォント指定は、こういう感じ。
「html フォント指定」で検索！

HTMLの文字コードは、UTF-8

フォントを変更します

これは明朝体を指定

それとも、マインクラフトはHTMLじゃないのか？

**デフォルトの名無しさん** · 2018/08/25(土) 07:11:24.89

>>762
合字はそうすることが自然だからそうなってるんだと思ってるんだけど、全部個別に文字コードを割り当てたほうがいいってこと？

**デフォルトの名無しさん** · 2018/08/25(土) 09:10:13.50

>>764
マインクラフトのフォントは
./assets/minecraft/textures/font
というディレクトリに16ドットフォントが16列16行配置されたPNG形式の画像が0xFF枚格納されてる
というような仕様になってますね
HTMLはあんまり関係ないです。

**デフォルトの名無しさん** · 2018/09/07(金) 14:01:42.05

&hearts;

**デフォルトの名無しさん** · 2018/09/10(月) 17:53:51.80

Unicodeの公式サイト（http://unicode.org/）で，Unicodeの最新安定バージョンがなにかを調べるにはどこを見ればいいんですかね。
今11.0だそうですが，他サイトの情報なので，なるべく本家本元の情報が欲しいんです。

**デフォルトの名無しさん** · 2018/09/10(月) 19:07:05.53

>>768
ちゃんとメニューを見よう。

サイトの左側のメニューから The Unicode Standard プルダウンの中にある Latest Version を選べばよい。
というわけで、現時点では 11.0 が最新という認識で正解です。

**デフォルトの名無しさん** · 2018/09/11(火) 03:10:58.81

>>769
あざす。
http://www.unicode.org/versions/latest/
ここにアクセスしたら自動的に最新版に繋がりますね。

**デフォルトの名無しさん** · 2018/09/12(水) 15:59:00.59

Unicodeって，なんで初めに多バイト文字のことを考えなかったんだろう。
そもそも多バイト文字を統一するために設立したようなもんなんだから，
2^16では済まないことくらい予測できた筈なのにね

**デフォルトの名無しさん** · 2018/09/12(水) 16:00:08.88

The Unicode Blog: New Japanese Era
http://blog.unicode.org/2018/09/new-japanese-era.html

Unicodeの方でも記事になってたのか。

**デフォルトの名無しさん** · 2018/09/12(水) 16:39:35.87

>>771
アルファベット二十数文字しか使ってない奴らが
六万文字もあれば世界中全部の文字カバーできるよな
って雑に考えたから

**デフォルトの名無しさん** · 2018/09/12(水) 17:33:44.29

>>773
ちょっと漢字の知識があっても漢字が５万字くらいだろ？
漢字で5万使って残り1万5千だな、余裕だろって感じだったんだろうな

**デフォルトの名無しさん** · 2018/09/12(水) 22:23:14.60

>>774
まあ正直，日本人でも特段勉強してなかったらそういう感覚やろうしな

**デフォルトの名無しさん** · 2018/09/12(水) 22:25:38.00

で、ﾊﾞｶは5ﾏﾝの漢字全部読めるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部書けるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使えるの？
で、ﾊﾞｶは5ﾏﾝの漢字全部使ってるの？

**デフォルトの名無しさん** · 2018/09/12(水) 22:30:26.22

卜部の卜
トﾅｶｲの卜
見た目でも違いなんかまったくわからない

**デフォルトの名無しさん** · 2018/09/13(木) 02:31:52.28

でもコンピュータに合わせて世界を
作り変えることができるなら、
65535文字に抑えるだろうな

サマータイムもない世の中
文字も16進数が基本かな
電気の流れもマイナスからプラスへだ

**デフォルトの名無しさん** · 2018/09/13(木) 08:51:11.89

君が代によれば、天皇の世は八千代続くので、
元号の合字も８０００個必要になる。
Unicodeのどこかの面にまとめて確保できないものだろうか。

**デフォルトの名無しさん** · 2018/09/13(木) 09:03:45.21

>>778
おおむね賛同するが
電流の流れが電子の流れと逆なのは電算機登場以前の話だぞ

**デフォルトの名無しさん** · 2018/09/13(木) 09:54:19.07

>>774
宇宙人と交信する予定は無かったのか

**デフォルトの名無しさん** · 2018/09/13(木) 09:56:12.02

>電気の流れもマイナスからプラスへだ

これいつかやっても良いと思うけど
どこにどんな影響が出るんやろね
数学の外積の定義とかも変えたくなりそう

**デフォルトの名無しさん** · 2018/09/13(木) 16:01:34.38

>>782
電子がマイナスからプラスへと流れると電流がプラスからマイナスへ流れるという理解で問題ない

**デフォルトの名無しさん** · 2018/09/13(木) 17:09:43.69

数字が連続してない符号化文字集合ってあるのかな。
EBCDICとかは英語が連続してないことで有名だけど。

**デフォルトの名無しさん** · 2018/09/13(木) 19:23:35.05

C言語の規格で'0'から'9'は連続していることになってたと思うから
そうじゃない文字コードがあったとしてもとっくに淘汰されてるのでは

**デフォルトの名無しさん** · 2018/09/13(木) 19:34:24.00

どうせ文字集合じゃねーって言われるけど
漢数字

**デフォルトの名無しさん** · 2018/09/13(木) 19:47:56.84

0～9は世界共通文字
どの国でも同じ文字が使える

**デフォルトの名無しさん** · 2018/09/13(木) 20:25:28.42

世界共通になる前に6と9のどちらかを変更しておいて欲しかった

**デフォルトの名無しさん** · 2018/09/13(木) 21:10:29.13

>>786
毎日のように使うのに、普通に気が付いてなかった。
おもしろい。
けど文字集合ではないなw

>>788
あと1と7

**デフォルトの名無しさん** · 2018/09/13(木) 21:35:44.08

漢数字がそれが表わす数字順に並ばないって結構有名だったのか……恥かしい

**デフォルトの名無しさん** · 2018/09/14(金) 06:35:40.18

>>788
9って手で書くときはqみたいな形じゃない？
なんでコンピュータのフォントだと丸まるんだろう。

**デフォルトの名無しさん** · 2018/09/14(金) 07:22:37.60

>>791
ビリヤードの玉なんかわざわざ区別のつかないような字形にした上で
区別が付くように線を引いてるんだぜ

**デフォルトの名無しさん** · 2018/09/14(金) 12:40:21.98

>>788
ＲとЯ

**デフォルトの名無しさん** · 2018/09/14(金) 15:58:06.01

1960年代1970年代では、
コーディングシート上で「O(オー）」」と「０（ゼロ９）とを
区別するために

Fortranは「「O（オー）」の上に傍線を書いたし、
COBOLでは、「０（ゼロ）」に斜線を引いて区別
してたような気がする。

「I（あい）」と「１（いち）」の場合は、「Ｉ（アイ）」を
小文字の「i」を使っていたような気がする。

なにぶん、古い話なので、間違っているかもしれないが
一応参考までに

**デフォルトの名無しさん** · 2018/09/14(金) 16:10:40.01

斜線入りの0
VS使ってU+0030 U+FE00で表せるように
なってたんだな。

**デフォルトの名無しさん** · 2018/09/14(金) 16:32:11.43

>>795
本当だ！
って、なぜVS？重ね書きでいいのだから合成では、って探したらU+0338 U+0030でもいいらしい……
二重収録……

**デフォルトの名無しさん** · 2018/09/14(金) 18:22:58.68

まーーた「異字体」という概念を欧米のやつらがめちゃめちゃにしやがったな

**デフォルトの名無しさん** · 2018/09/14(金) 19:03:02.27

>>794
Dも横線入れたり、Uは必ず小文字のヒゲ書いたな
今でも手書きアルファベットでついやっちまうｗ

**デフォルトの名無しさん** · 2018/09/14(金) 19:03:15.35

Unicodeをめちゃくちゃにしてるのは大昔の馬鹿な中国人

**デフォルトの名無しさん** · 2018/09/14(金) 21:49:17.28

斜線入りゼロの全角版もU+FF10 U+FE00で規定しようとしてるな。
もうアホかと。

**デフォルトの名無しさん** · 2018/09/14(金) 22:09:46.77

あーあもうめちゃくちゃだよ…