  |
はてなキーワード: 文字コードとは
プログラミングができるわけでもない一般人だが書かれている内容はだいたい分かった。
なぜ「数字」にこだわるのかも分からないし唐突に現れたサンプルプログラムも意図が分からない。
ドレミファソラシは「261、293、329、349、391、440、493」
可視光の波長
コンピュータのディスプレイは波長ではなくRGBで表現されるので分かりづらい。
そんなよく分からないLEDを使わずともフルカラーLEDがある。
たとえにマイナーな電子部品(？)が登場すると逆に分かりづらい。
それから縦30x横30のLEDから縦70x横70のLEDまでに内接する円の内部(x^2+y^2≦40)がすべて色001であれば、赤い円ができる。
このあたりはよく分からない。
(「点と円の当たり判定」を各座標ごとに実行)
めちゃくちゃ強い電気
なんかすごそう(小並感)。
ハイレベルとローレベルでなくアナログ値になるということなのだろうか？
それはたぶん現代人ならみんな知ってると思う。
どの文字コードのことを言っているのか分からないので集中できない。
(ためしにASCIIコードを調べてみたがAは65だった。また小文字にするとき足す値は32)
かなりシンプルになることが多い。
一般的には適当なrandomモジュールのようなものを利用するのではないか？
(ついでに実用的かを考えるなら曲数が60以上あったときのことが気になる)
今の仕事でも、既存のマクロでエラー出たときに原因箇所を調べたりするのは出来るけど、そこから何を直したら直るのかわかんない。
フローチャートを作れるのなら元増田に必要なのは「ポケットリファレンス」とか「逆引き～」とかいう類の本ではないだろうか？
(普通に考えればさすがに知っているだろうが念のため)
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
プロマネ「うーん、某社の社内システムをほぼ作り終えたはいいが、肝心のInternet Explorer 11でなんで文字化けするんや？」
通りすがりのワイ（別プロジェクト所属）「何か悩んでるんですか？」
プロマネ「かくかくしかじかなんだよ。文字コードUTF-8なんだけどさ？」
ワイ「あー、WindowsはSJISにしか対応していませんよ。もちろんIEも」
ワイ「クライアントにはゴメンナサイして、文字コード絡むところ修正しないとだめっすねえ。Unicodeの顔文字も受け付ける要件だったんですか？じゃあ要件定義からやり直しっすねえ」
最近ワイ「ん？Internet Explorerは特別にUTF-8に対応している？んん？」
これワイが悪いんか？
金融系SIerと一緒に仕事してるが、そこのエンジニアは原則ネット接続出来ない環境で開発している。
ホストシステムの開発なら別に構わないが、そんな環境でBtoCのインターネット公開サービスを開発しようとしてるのがタチが悪い
Android studioとか、インターネット接続下でないとインストールすら出来ない開発ツールがデフォルトなのに
そんなんだから生産性が上がらない。開発ツールのインストールだけで１ヶ月かかることもあるし、オフラインインストールが出来るかなり昔のツールを使わざるを得ないこともある
文字コードも今時shiftjisである。ホストと連動するからunicodeは使えないし第二水準までの文字しか使えない。
https://qiita.com/yumetodo/items/54e1a8230dbf513ea85b]
https://b.hatena.ne.jp/entry/s/qiita.com/yumetodo/items/54e1a8230dbf513ea85b]
https://togetter.com/li/1301253]
https://naruse.hateblo.jp/entry/2018/12/24/013446]
文字コードを多少かじった人間としては、また人類が文字コードで混乱している。と思っていて議論が深まるのかなと思ったりします。
ただ、この話、見ててもやもやする所が一つありまして、UTF-8の1コードポイント=uint8_t=unsigned charでええんかいな。という点です。
文字コードを少しでも知っている人はUTF-8は1つのコードポイントを可変長のバイト列で表します。
よく言われるようにASCIIは1バイト、大体のCJKV文字は3バイト以上で表します((久々にWikipediaのUTF-8見たら、UTF-8にサロゲートペアってあるんだねー。罪深いわOrale〜))。最大6バイトで1つのコードポイントを表します。
つまりですね、char16_tとかchar32_tとかがUTF-16やUTF-32にマッピングされるのは分かるんですよ。サロゲートペアは脇に置いておいて、コードポイントを表すのにはこの型(っつーか、データ長)を使うよってのが分かるので。
サロゲートペアを考えたときのUTF16も同じ考え方になるんですけど、UTF-8みたいな可変長のバイト長を取るエンコード方式は、結局、1「文字」を表す型(データ長)が定まらないんですよ。
char8_tをunsigned charの子クラスにしたとしてもそれって、UTF-8にとっては「1文字を表す型」ではないんですよ。「1文字を表すバイト列の単位の1つ」でしかないんですよ。(サロゲートペアを考慮したときのchar16_tも同様)。
意味論で言っちゃえばUTF-32に対してchar8_tを使っても意味は同じになるんですよ。UTF-32って8ビット×4で構成されるだけなんで。
なので、UTF-8で表される1文字を型で使いたかったらuint64_tの子クラス(本当は最大6バイトなので48でいいんだけど)にしなきゃダメなんじゃねぇの？もしくは最少8ビットで48ビットを保証する型。とC++界隈ではない自分は思うわけです。
最善の相で解釈するのであれば、ネットでフェミニズムを主張している人の中には本当に『男性にとっても女性にとっても共通する、性欲とは無関係な可愛いの概念』が存在すると信じている人がいるように思える。
なぜそう思うかを語ろうとすると男にとっての可愛いと性欲と恋愛感情を真面目に語ることになったので、性欲についてフェミニストに語らないお前らキモオタや男共は卑怯だへの返答も兼ねて書いてみようと思う。
男の性欲は割と即物的であり、結局のところ男にとって性的な行為で直接的に一番気持ちが良いのは『射精することそのもの』だ。それはセックスだろうがオナニーだろうが関係ない。（これ以外の副次的な部分、社会的な部分や支配欲的なところは存在するが、直接的には射精第一である。）
しばしば言われる『ブスとセックスするのは辛い』『結婚してから嫁が劣化（←この言葉は好きではないが）したので夜の相手が辛い』ということはつまるところ、
『勃起させ、射精するための労力＞射精による快楽』という構図になってしまったから言われるだけにすぎない。
女の性欲はもう少し複雑である、ということになっているはずだが、その点は深くは追及しない。
一般的な男にとっての”可愛い”は２種類しかない。『愛らしいという意味での可愛い』と『恋愛対象として高評価という意味での可愛い』だ。
（本筋から外れるが、女性の言う”可愛い”の意味はもっと多いことそのものは増田も理解している。ただ増田も含め、女性の言う”可愛い”の全体像を理解している男は滅多にいない。女性から”可愛い”と言われて戸惑ったりする男が多いが、これは『俺にとっては意味不明な尺度による”可愛い”かもしれないと思うと疑心暗鬼になる』ことによるものだ）
前者の代表例は『子犬可愛い』『子猫可愛い』であり、人間の女の子であっても、５歳の女の子が健気に頑張っている姿を可愛いと言っているならばこちらの意味だ。
後者の代表例は『新垣結衣可愛い』であり、ある程度成長した女性に使っているならばこちらの意味だ。
ただ、人間の女性に使っている場合、前者と後者はグラデーション気味になることがある。増田の場合、成人した女性であっても『金田朋子ちゃん可愛い』は前者の意味をある程度含んでいるし、逆に未成年でも『4年前の生田絵梨花（当時17歳）可愛い』は後者の意味を明確に含んでいる。デビューした当時のまいんちゃん（福原遥：当時10歳）可愛い』は100%前者である。岩本蓮加(14)なら…分からない。
そして男にとって ──女はどうなのか、というのはいまだに分からない── 恋愛感情の一部に性欲は必ず含まれていると言っても構わない。恋愛感情＝性欲ではなく、恋愛感情には性欲以外の部分もあるが、性欲を含まない恋愛感情は（おそらく）存在しない。つまり性欲⊂恋愛感情 である（←数学記号は文字コード的に大丈夫？）。生田絵梨花を可愛いと言っている男は、多かれ少なかれ『生田絵梨花とデートして、その後セックスしている自分』を想像している。ただ、そのことに自覚的であるかないか、それだけの違いでしか無い。
そして前述したように、三次元では幼い女の子がどこまで恋愛や性の対象になるかについてはある程度遠慮している部分もある。だが、二次元が相手だとその”遠慮”も無くなり、オタクの男が『木之本さくらちゃん可愛い』『高町なのはさん可愛い』と言っている時にはある程度は性的な意識もある場合が多い。同人誌を見れば明らかである。
…そんなわけなので、『エロと無関係な可愛い』は存在するかもしれないが、それは特に二次元の場合極めて限定的であると増田は思う。ただ一方で、『性的である』から『それ以外の部分を無視している』わけでもない、ということを主張しておきたい。
メール一回の容量ってどれくらいだろう。
添付ファイルつけた場合など考慮して多めなものが多いと見積もっても平均3MB程度だとして
（3MBだと文字コードにもよるんだけど、shift-jisだいたい150万文字くらい。あれ計算あってる？）
一人あたりの1日におけるメール総数自体は人によりそうだけど、
多くても100前後？（私は公務員のメールが想像つかないニートです）
3MB × 100通 × 60日 = 18,000MB = 18GB = 約20GB (一月10GB)
これでも少ない方なのかな。多いような少ないようなわからないけど、
年間120GBも使う？
たとえ120GB以上使ったとしても、
もう少し長い期間を貯めておくためのテクニックはあるような気がするんだけど。
そのシステムの1日のやり取りとかはどうなってるのよ。1日で120GBくらい超えるでしょ。
よくわかんないや。
効率性？確かに変換がなければタイプは速くなるが、アクセント記号書くのが効率的とは思えないな。どうやってタイプしたらいいのかわからんぞ。既存の機器で入力できなくてもいいわけか。もしや手書き入力か？文字コード直打ちか？
Mac nara eigo Kiibóodo de boínnji wo nagaoshi surú daké desu. iOS demo onaji desu. Windows nara, Alt Kíi ka nánika to no kumiawasé de dékita to omoimásu.
同音異義語ってそんなに嫌うような代物なのか？全ての単語に固有の文字をあてれば解決だな。もっともチャイナは簡体を進めたために衝突が増えたはずだが。ハングルの導入も然り。
Douonn igigo no kotó wo shinnpai shinái no de áreba, tánn ni kunnrei shiki de wakachigaki wo suréba íi daké na no desu ga, sou surú to, "douonn igigo ga..." to kanarazu iwaremásu.
Watashi ha douonn igigo ha sukoshi kúrai nara shikata ga nái to omoimásu ga, mattakú kúbetsu ga tsukánai no ha yóku nái to omoimásu.
学習コストって何のことかわからんが、日本人で日本語書けないやつには会ったことがない。外国人が苦労するとは想像するが、それなら発音と表記を揃えるべきだ。歴史的仮名遣いを取り込むとか、そうか、つまり趣味以上のものではないわけか。
Nihonnjinn ha nihonngo no kakikáta wo gakkou de nagái jikann wo kákete naraimásu. Sore ga Kósuto desu.
Gakushuu Kósuto wo sakugenn shité, onaji jikann de gakkou de hoka no kotó wo oshierarerú yóu ni náreba íi to omoimásu.
ローマ字書きのメリットとして機械に理解させたり、検索性の向上、合成音声への応用などあるわけだが、さういふ文脈は無視して趣味性の追求のために時代に逆行する信念には敬服しますた。これからもかんはつてくたさい！
Soréra ni tsúite taisetsu na no ha, hyóuki wo míte dóno tanngo ka ga wakáru kotó desu.
効率性？確かに変換がなければタイプは速くなるが、アクセント記号書くのが効率的とは思えないな。どうやってタイプしたらいいのかわからんぞ。既存の機器で入力できなくてもいいわけか。もしや手書き入力か？文字コード直打ちか？
同音異義語ってそんなに嫌うような代物なのか？全ての単語に固有の文字をあてれば解決だな。もっともチャイナは簡体を進めたために衝突が増えたはずだが。ハングルの導入も然り。
学習コストって何のことかわからんが、日本人で日本語書けないやつには会ったことがない。外国人が苦労するとは想像するが、それなら発音と表記を揃えるべきだ。歴史的仮名遣いを取り込むとか、そうか、つまり趣味以上のものではないわけか。
ローマ字書きのメリットとして機械に理解させたり、検索性の向上、合成音声への応用などあるわけだが、さういふ文脈は無視して趣味性の追求のために時代に逆行する信念には敬服しますた。これからもかんはつてくたさい！
