プログラミング初心者を惑わす存在にchar型がいる。
キャラ型、キャー型、シャー型などと呼び名も一定しておらず（intはイントと皆呼ぶだろう）、あたかもその名前からキャラクターを扱うもののように思われている。
C言語は古い言語なので設計思想は完全に時代遅れなのだが、コンピュータ言語は互換性の観点から容易に修正ができず（関数名に明らかなスペルミスがあるがもはや修正できない）、拡張という名の増改築の繰り返しで、C++など魔境と呼ばれ、完全に仕様を理解している人間はいないとまで言われている（違法増築のようなこともあるし）。
だから、大規模リセットがなされ、C#やKotlnなどが登場してくるのだ。なぜ新しい言語がつくられるのか。それが最大の理由だ。
というのも、プログラミング記法と実際のコードの性能にはあまり関係がない（バグ生成率という意味ではおおいに関係があるから、PGのスキルにコード性能が左右されないという意味なら相関性はある）から、Cだってコンパイラを改善すればいいし、VM用のコードを生成するためにC言語の記法を採用してもいい（.NETフレームワークを使うのにCでもいいわけだ）。
もっとも、いまあげたC#もまあ、20年経っているので、それなりに時代遅れ（C言語のswitch構文をそのまま模倣したのはクソ仕様のひとつだろう）だが。
C言語は今後も使われていくだろうが、ここがコンピュータ言語の厄介なところだ。
いわば、古典の使用を強制されているようなものだといえる。
考えてみてくれ。C言語の初出は50年前だ。
日常的に50年前の車に乗るか？ 50年前のTVを使うか？ 50年前のファッションをするか？
そうだ。C言語は拡張されているとはいえ、古臭い思想のもとに設計することを私たちPGは強制されているのだ！
電気回路の方がずっと進歩している。
いまどきリレーで設計することがあるだろうか？ 複数のトランジスタを組み合わせて演算回路をつくることがあるだろうか？
ほとんどないと断言できる。
しかし、Cは普通に生きていて、そこらじゅうの機械の中のソフトウェアのコーディングに使用されているのだ！！
そして、COBOLと違い、今も絶賛利用され中のCはいつまでのその古くさいレガシーを引きずり続け、初学者を惑わし続ける。
その代表格がchar型だ。
こいつをキャラクター型などと呼ぶことこそ50年前の思想だ。
ASCIIコードのような１バイト文字しかなかった時代の産物なのだ！
Unicodeで４バイトも食うこの時代に１バイト長のデータをキャラクター型などと呼ぶナンセンス、度し難いのだ。
先走った。憎いからだ。char型が。
そう。つまり、char型というのはキャラクター型のことではない。
String型と似ているような気がしてしまうのは名前のせいであって、本質的に別もの（C#では容易にStringと変換できるが本来そのようなものではない）だ。
つまりだ。
byte型=char型と思ってもらっていい。
char型は１バイト長さの数値データだ。２バイトならint型だ。
これはのちに拡張されたuint8_tが内部的にはunsigned charだってことが何よりの証拠。8ビット長データなのだ。
まとめよう。
byte、char、uint8_t １バイト（８ビット）
short、int16、uint16_t ２バイト（１６ビット）
int32、long、uint32_t ４バイト（３２ビット）
こういうことだ。
キャラクター型という名前に惑わされるな。
さらに言えば、ASCIIコードはUnicodeとは似ていない。
char型がString型ではなく、明らかにint型に近いことが分かったと思うが、ASCIIコードも0x00～0xFFの範囲を取る１バイトの数値データと考えても支障がない（もっともASCIIは0x7Fまでだが）。
１バイトなのでエンディアンを気にする必要もない。
ASCIIコードは数値に混ぜて使うと区別がつかない。フォーマットをお互い揃えておかないと何のことかさっぱりなのだ。
初学者向けの教本では、わかりやすさのためかすぐにchar型を使って文字の説明を始める。charの話もでてきて、ますます混乱するだろう。
なにせ配列というのは単純にポインタにすぎないので、ますます混乱を深めるのだ（int xのxとはポインタアドレスの数値にすぎず、xとは&x[0]のことだ。）。
だから私は言いたい。
初心者向け教科書にchar型を出すな。
すべてuint8_tで済ませろ。
0x00～0xFFの範囲でも計算もASCIIも扱えるんだからずっとわかりやすいだろう？
配列の話も、初学者にchar型配列と文字列(string型)の区別は意味不明だ。
どっちも列といっていて、複数のデータ（文字）がいはいっていて、同じに見える。
Stringとcharに何の違いある？ 混乱を招くだけだ。
なので、すべてuint8_tとして扱えばいい。
ASCIIコードもさぼらず最初に説明しておく。
数字が取り決めで文字として扱えることになっている（だからコード表だ）ことを教えるのだ。
なので、数値0x00は0だが、ASCII文字'0'はコード表に則り0x30である、と。
もっとも、ASCIIがなぜ0x00(0)～0x7E(127)までしかないのか。
これ、signed char型の値のプラスの範囲のみであるのだ。-128～127だ。これは一般的なchar型と同じだが、char型自体に正負の定義はないらしいのだ。
マジクソだな！
つまりだ、char型は0x00～0xFFを取るが、その示す範囲は-128～127(signed char)もしくは0～255(unsigned char)なのである。
どっちにせよASCIIコードは使えるようになっている。
だからって定義しなくていいわけねえだろ。ボケが。こんな小さい計算をするわけでもないし、bool値でも問題にならないのわかるが……。
とにかく、char型には問題が多い。こんなもんを教科書で教えることに問題がある。
