文字コード総合スレ 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/08(水) 02:09:19.94

余ってる場所を余計なことに使う奴が絶対出てきて、
それを根絶するのに凄い辛い思いをするからヤメレ。

**デフォルトの名無しさん** · 2018/08/08(水) 04:24:19.86

もうこれ人類的に根絶できないんだろうね
一生これなんだろうね

**デフォルトの名無しさん** · 2018/08/08(水) 04:37:42.38

>>615
utf8でいいよ

**デフォルトの名無しさん** · 2018/08/08(水) 08:35:31.20

そういえば、utf9というのもあったな。３６ビットコンピュータに最適だとか。

**デフォルトの名無しさん** · 2018/08/08(水) 14:09:08.17

UTF-7と言う変態も

**デフォルトの名無しさん** · 2018/08/08(水) 16:40:51.17

Base64

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

UTF-24を策定するべきだな。
全ての文字を24ビット(3バイト)で表す。
UTF-32の0x00で固定な最上位バイトを省くというので。
BMP外の文字だらけの文章には有利になるだろう。

**デフォルトの名無しさん** · 2018/08/08(水) 22:53:07.77

>>623
だな、固定長はUTF-24、可変長はUTF-8でいいだろう

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

UTF16はいらないとかUTF24がよいとか、変な書き込みする人、同一人物？
CPUのレジスタは32bitまたは64bitなので、1バイトをコピーするのも4バイトをコピーするのも時間コストは同じだよ。

**デフォルトの名無しさん** · 2018/08/08(水) 23:48:28.49

1バイトと4バイトとかミクロの性能比較なんか殆ど意味無い

**デフォルトの名無しさん** · 2018/08/08(水) 23:49:21.32

固定長だなんて幻想をまだ見てるの？

**デフォルトの名無しさん** · 2018/08/08(水) 23:50:49.11

固定長の方が高速で便利ですやん

**デフォルトの名無しさん** · 2018/08/08(水) 23:57:42.55

>>626
大ありですよ。

>>627
固定長の方が条件分岐が減るので処理速度が高く、プログラミングもしやすい。

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

>>626
ファイルサイズがでかくなればそれだけ処理をする回数が増えるからダイレクトに効いてくる。

**デフォルトの名無しさん** · 2018/08/09(木) 01:20:56.02

CPUひとつあたりの処理速度は10年前とあまり変わってないけど、搭載できるメモリの量は劇的に増えた。
内部実装がUTF32になって文字列リソースが2～4倍になったとしても利用できるメモリはそれ以上に激増しているのでまったく問題なし。
むしろUTF16やUTF32のほうが頭打ちのCPUにも優しい、ということがわかるはず。

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

16は全然優しくない
24もアライメントを考えると優しくない

**デフォルトの名無しさん** · 2018/08/09(木) 10:29:52.60

よし128だ。

**デフォルトの名無しさん** · 2018/08/09(木) 10:44:02.84

>>625
放っとけば居なくなるのに

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

>>633
合成やセレクタを撤廃できるのなら128でいいよ

**デフォルトの名無しさん** · 2018/08/09(木) 11:05:58.21

UNCODEv6

**デフォルトの名無しさん** · 2018/08/10(金) 22:27:21.22

UTF24とかメモリアクセス効率悪すぎるだろ。アライン考えろ。
情報交換用文字コードはエンディアンに依存しないUTF8。
内部用の文字コードはアクセス効率が良いUTF32。
貧乏人専用のUTF16。
それぞれ存在理由があるんだよ。

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

Windowsの場合、プログラムを何も改修することなくUTF16でサロゲートペアの絵文字を使えているでしょ。
もちろん、文字フォントを描画するAPI、つまりマイクロソフトの中の人が頑張っているからだが。

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

まぁ、Windowsプログラムで、動的に絵文字の肌色・髪色・性別などを変えようと思ったら、
UTF16のサロゲート処理を自分で行う必要があるけどね。

**デフォルトの名無しさん** · 2018/08/11(土) 00:03:26.88

>>637
24が駄目なら8はもっと駄目なんでないの？

**デフォルトの名無しさん** · 2018/08/11(土) 10:22:26.41

だからUTF8は内部利用じゃなくて情報交換用なんだろ。

**デフォルトの名無しさん** · 2018/08/11(土) 10:45:32.80

SJISと取り決めてあるテキストデータにUTF8をぶっこんできた取引先があって
翌朝からの日本社会に大混乱を引き起こしかねない危機に晒された経験がある
UTF8滅ぶべしと俺は本気で思っている

**デフォルトの名無しさん** · 2018/08/11(土) 10:58:00.76

エンコーディングは関係ないだろ。
決めごとを守れないその取引先と異常データを突っ込まれただけで混乱しちゃうプログラムの問題。

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

何年か前に、地域の緊急速報のテストメールか何かに
エンコーディングを混在させて文字化けを地域住民に送って混乱させたのあったな
メールテンプレートのエンコーディングと、流し込む本文で混在させちゃったみたいな

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

ないしほてし活復を語本日く書に左らか右どけい良もでき書横

**デフォルトの名無しさん** · 2018/08/11(土) 13:16:33.61

>>644
去年だぞ

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

546<<
ケォヴわいくにみ読

**デフォルトの名無しさん** · 2018/08/11(土) 15:47:35.74

中東の言語は確か右からだったよな
やろうと思えば簡単そう

**デフォルトの名無しさん** · 2018/08/11(土) 15:56:48.16

TeXって右から書くのにも対応してるっけ

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

sjisの～とcp932の～の違いって何？
～を入力して検索すると、sjisのほうはヒットしないんよね

**デフォルトの名無しさん** · 2018/08/11(土) 19:10:44.45

>>650
「入力して検索する」
どうやって入力して何を検索するのか他人に分かるように書いたらどうか
入力側がUNICODEで変換不能とかじゃない

**デフォルトの名無しさん** · 2018/08/12(日) 00:02:17.72

＞649

ArabTeX　を使えば出来ます

**デフォルトの名無しさん** · 2018/08/12(日) 14:13:27.50

Draft Emoji Candidates
http://unicode.org/emoji/future/emoji-candidates.html

**デフォルトの名無しさん** · 2018/08/12(日) 14:20:12.48

絵文字がんがん増えてるけど、ぱっと見で見分けが付かない微妙なの多いよなぁ

**デフォルトの名無しさん** · 2018/08/12(日) 14:26:24.04

馬鹿は同じ過ちを繰り返す

**デフォルトの名無しさん** · 2018/08/12(日) 14:35:29.88

そのうち洗練されて象形文字になって、やがて漢字に…あれ?

**デフォルトの名無しさん** · 2018/08/13(月) 14:33:07.24

この際1byteを32bitか64bitにしたらどうよ
1byteが8bitになったのはアルファベットや数字が固定長で表せて
2^nbitで処理しやすかったからなんだろうけど
1byteが32bitか64bitになればエンディアンの問題もなくなって分かりやすくなる

**デフォルトの名無しさん** · 2018/08/13(月) 14:58:06.25

そうなんか？
16新数で2桁でちょうどいいからだと思ってた

**デフォルトの名無しさん** · 2018/08/13(月) 14:59:26.97

あと 8bit を 1byte というけど
4bit のことをなんていうの？

**デフォルトの名無しさん** · 2018/08/13(月) 15:02:02.90

>>657
8bitや16bitのCPUはどうすんの？

**デフォルトの名無しさん** · 2018/08/13(月) 15:15:08.87

>>657

32bitでも、64bitでも、好きな長さを「word」と呼べばいい。
これで、エンディアンの問題もなくなって分かりやすくなるんだよな。

**デフォルトの名無しさん** · 2018/08/13(月) 15:19:57.39

>>659
ニブル - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%8B%E3%83%96%E3%83%AB

> ニブルは4ビットのことである。

**デフォルトの名無しさん** · 2018/08/13(月) 16:04:07.52

Thx!
DNCL

**デフォルトの名無しさん** · 2018/08/14(火) 02:11:13.81

無理。各コンピュータ内部なら好きなビッド数にすれば良いけど、インターネットのほぼ全ての規格はオクテットが基準になってる。
インターネット全部作り直すくらいやらないと今更変更できない。

**デフォルトの名無しさん** · 2018/08/14(火) 09:43:35.42

byteとoctetを区別すればいいだろ

**デフォルトの名無しさん** · 2018/08/14(火) 12:58:54.95

>>584
昔の ISO/IEC 10646 がそんな感じじゃなかったっけ？
UCS-4 が Four-Octet Canonical Form (4オクテット正規形) と呼ばれてて
UTF-8 や UTF-16 はあくまで Transformation Format だと。

**デフォルトの名無しさん** · 2018/08/14(火) 13:43:48.36

UTF-32に統一できないなら、UTF-8を残そうがUTF-16を残そうが
どちらも大して変わんないんだよね。
UTF-8 も UTF-16 も既存OSの互換性を保つためにあるのだから

UTF-8はANSI互換性というメリットがあるというけれど
なんてことはない、Unix/Linuxの改修が大変だったから、
文字コードのエンコーディング方式自体を作ったってだけの話
互換性のために作ったものだよ

16bitにすべての文字を収めるのは不可能だが、仮に収まったとしたら
UTF-16はサロゲートペアなどなく1文字16bitというシンプルなものになっていた。

もし最初から32bit必要だと認識していれば、UTF-32という1文字32bitに
統一された素晴らしい文字コードになっていただろう
そしてWindowsはそれを標準文字コードとして採用しただろう。
（WindowsがUTF-16なのは、その頃はUnicode = UTF-16の前身のUCS-2 だったから）

結局固定長でないなら、どちらも面倒なことに大差ないし
互換性を保つために面倒な方式を残すのであれば、
それがUTF-8でもUTF-16でも同じこと

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

UTF-8はエンディアンの問題が無いのが良い

**デフォルトの名無しさん** · 2018/08/14(火) 15:00:48.27

8も16も大して変わらないと言えばそうだけど、種類が少ないに越したことはないし
どっちかひとつ残すならやっぱり8なので、16には退場願いたいね

**デフォルトの名無しさん** · 2018/08/14(火) 15:32:16.19

>>669
Windowsという重要な役目があるので無理だってわかってるだろ？

**デフォルトの名無しさん** · 2018/08/14(火) 15:39:29.46

>>667
妄想は要らん
asciiとの互換性とosの改修は関係ない
16bitに収まったとしたらとか ifを言い出したらきりがない

**デフォルトの名無しさん** · 2018/08/14(火) 15:47:44.20

>>670
昔からMSは独自文字コードが大好きだからUNICODEからUTF-16が無くなっても問題ない

**デフォルトの名無しさん** · 2018/08/14(火) 16:47:25.95

>>671
> asciiとの互換性とosの改修は関係ない

大あり。C言語はASCII互換前提となっている。
具体的に言うと、文字列の終端文字が\0なので
UTF-16やUTF-32といった、1文字の中に\0が
含まれてる場合に対応できない

UTF-8でなければprintfなどの基本的でよく使われる関数
全てをUnicode対応に改修しなければならなかった。
もしくは捨て去さるかだ

**デフォルトの名無しさん** · 2018/08/14(火) 16:48:00.48

>>672
昔からUnicode対応なんですがーｗ

**デフォルトの名無しさん** · 2018/08/14(火) 16:54:07.60

UTF-16やUTF-32も1文字の中に\0が含まれているわけじゃないがな。

**デフォルトの名無しさん** · 2018/08/14(火) 17:16:53.37

含まれるやろ

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

L'\0' は含まれないが '\0' は含まれる

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

http://ash.jp/code/unitbl1.htm

41 41 41 41 0041 A
42 42 42 42 0042 B
43 43 43 43 0043 C
44 44 44 44 0044 D
45 45 45 45 0045 E

右から二番目がUTF16の文字コード
見ての通り基本のアルファベットの中に0x00が含まれてる

つまり ABCは、00 41 00 42 00 43 もしくは 41 00 42 00 43 00 という並びとなり
これをprintf等にわたすとASCII文字として1文字8bitと解釈し、
00を\0とみなすので途中で切れるか全く表示されなくなる

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

説明足らずな>>675が揚げ足取りだと思われると可愛そうなので（笑）
補足してあげると、UTF-16やUTF-32の1文字はそれぞれ16bit or 32bit で
16bitで\0、32bitで\0 は含まれてないと言いたいのだ

だが今は、printfなど1文字8bitと解釈する関数の話をしているので
8bitずつ見ていくと文字の途中に\0が含まれるのだ

**デフォルトの名無しさん** · 2018/08/14(火) 17:37:04.18

まあWindowsみたいにcharはロケール依存のままでwchar_tだけUnicodeという構成もあるので
UnixのUnicode対応にUTF-8が必須だったかというとわからんけどなー

**デフォルトの名無しさん** · 2018/08/14(火) 19:46:09.12

>>680
え？ Unixもwchar_tはUnicodeだけど？

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

正確には、既存のコードの多くは wchar_t が使われて無くて、
その対応が大変だっていう話

WindowsはOSすべてを自分たちで作ってるからどうにかなったが、
オープンソースで他人が作ったものの寄せ集めだと対応が大変だろうね

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

gcc は、 wchar_t を16bitと32bitでコンパイル時に選択できるようになっているので、のちのちWindows以上に厄介なことになるでしょう。

**デフォルトの名無しさん** · 2018/08/14(火) 22:54:07.34

>>681
Linuxではそうだけど、Unix一般の話でいうとwchar_tはcharの多バイト文字をひとつの値で表せられるならなんでもいいし
実際BSDはcharがSJISならwchar_tはJISコード

**デフォルトの名無しさん** · 2018/08/15(水) 01:31:39.17

OSの中とかプログラム言語とかどうでもいい。
インターネットとかの通信プロトコルでオクテット(8bit)単位で交信、終端は0x0A 0x0Dとかの特定のオクテットコード列を使用とかになってるのが多数ある。
内部では好きなビット数で処理すれば良いけど、通信には8bit単位の処理系も必須。
ユニコード使うかどうか以前の問題。

**デフォルトの名無しさん** · 2018/08/15(水) 01:44:12.43

ケチケチ言わずIPV6くらいドカンと拡張しようぜ

**デフォルトの名無しさん** · 2018/08/15(水) 02:10:10.66

wcharは、内部の符号化に依存しちゃいけないし、幅が 16bitか32bitかに依存するのもよくない
使うのがなかなか難しいね

但し、char と混在させるのは単なる誤り。printf に使うと途中で切れるとかいうのは使う側のミス

**デフォルトの名無しさん** · 2018/08/15(水) 05:49:51.06

wchar_tやったときない

**デフォルトの名無しさん** · 2018/08/15(水) 11:55:41.55

>>687
printfで途切れる云々は仮にLANG=C.UTF-16みたいなロケールがあったとしての話だろ？
isdigit等も実装できないし、規格上できないようになってるとは思うけど

**デフォルトの名無しさん** · 2018/08/15(水) 13:30:59.38

>>687
printfはchar（のポインタ）を受け取るんだから、wchar_tは使えないでしょ？
というかcharで表示できない文字だから、wchar_tが作られたというのが正しい

そうなると、printfだけでなく多くの文字列用関数に対して
charバージョンとwchar_tバージョンが必要になって、変更しなければいけなくなるよね
それが大変だからUnix/LinuxはUTF-16には対応するのは現実的に不可能
対応が簡単なUTF-8を作りました。という流れ。

>>689
> LANG=C.UTF-16みたいなロケールがあったとしての話だろ

Unix/LinuxはUTF-16に対応するの大変だから、
そんなロケールは実現できないだろうね

似たような理由EUC-JPは対応できたけど、SJISは対応できなかった

と思ったけど以下のような警告出るけど使えるのかｗ
> # localedef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS
> キャラクタマップ `SHIFT_JIS' は ASCII 互換ではありません, ロケールは ISO C に従っていません

こんなのまで見つけた
http://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
ダメ文字（文字の一部に\が含まれる場合）にさえ、あたらなければ大丈夫ってことなんかな
UTF-16と違って確率的には低いだろうけど

**デフォルトの名無しさん** · 2018/08/15(水) 15:55:17.05

>>662
シュメール文明の神アヌンナキたちの故郷の惑星のことかと思った

**デフォルトの名無しさん** · 2018/08/15(水) 16:15:54.08

乳首の甘噛み

**デフォルトの名無しさん** · 2018/08/15(水) 16:25:48.18

>>690
> 似たような理由EUC-JPは対応できたけど、SJISは対応できなかった

kwsk

**デフォルトの名無しさん** · 2018/08/15(水) 16:43:22.85

>>693
だからダメ文字だって

http://ash.jp/code/code.htm
>　また、2バイト文字の中に"\"(0x5C)を含むデータが存在するため、文字列がメタ処理されてしまい、文字化けする可能性があります。

LinuxやUnixに限った話ではないけど、
文字を1バイトずつ処理するようなもの（つまりcharポインタ）は
ASCIIと互換性がないと不具合の原因になる

だからSJISやUTF-16やUTF-32はLinuxやUnixで
ネイティブに処理するのは苦手なんだ

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

中途半端な多encoding対応で不具合が出たという話。要はバグ。

**デフォルトの名無しさん** · 2018/08/15(水) 22:23:06.07

アホか、アホしか居ないか？
それともわざとボケてんのか？
なんで wchar_t の話と printf の話を一緒に語ってるんだ？

wprintf 🤔

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

>>696
だからprintfで実装されているものをwprintfに修正するのが大変だって話
またwopenfなどワイド文字対応の関数が存在しない場合も存在する。

それに単純に置き換えてしまうと、今度はASCII環境で動かなくなってしまう
なぜならwchar_tは16bit または 32bitという固定サイズなので
8bitのASCIIは扱えない（当然可変長バイトのUTF-8もwchar_tでは扱えない）

だからwchart_tというものが作られたけど、Linux/Unixはそれを使用して
ワイド文字列対応にするのは現実的に不可能と判断し、
printfで扱えるASCII互換のUTF-8を使うことにした

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

ダウト
wchar_t で普通に ASCII も使える。当たり前。i18n でプログラム組んだことないだろ？
UNIX 系で utf8 が好まれる最大の理由は内部コードとかじゃなくて、ファイル名。
ファイル名に直接 0x00 が入れられないので。あとはネットワークまわり。

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

そりゃ16bit（つまりUTF-16）として書くか変換すりゃASCIIの範囲の文字列は
扱えるだろうさ、そうじゃなくて8bitのASCII文字が扱えないって話

charは1文字8bitとして定義されたものだが、UTF-8を扱う場合は可変長としても考えられる
wchar_tは16bit （または環境によっては32bit）であるがUTF-16を扱う場合は16bit単位の可変長、
つまりサロゲートペアを扱える。しかしwchar_tは所詮16bit（または32bit）単位なので8bitは扱えない

そのためUTF-8のファイルを読み込むときには、wchar_tに変換して読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-8に変換するとかしてだ。

このようにASCII互換のデータを扱うためには単純にchar型をwchar_t型に置換しただけでは
だめで変換処理が必要になる。それに対してUTF-8であれば、char型を可変長char型と
みなすことでそのまま扱うことができる。文字列の長さをカウントするときとか
1文字単位で処理しなければいけないところだけ、UTF-8を扱えるライブラリを使えば良い

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

訂正

そのためUTF-8のファイルを読み込むときには、wchar_tに変換しながら読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-16に変換するとかしてだ。

**デフォルトの名無しさん** · 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