Unicodeと、C#での文字列の扱い
進化の過程で煩雑な文字コード体系になっているUnicodeは、プログラミングでの取り扱いが面倒だ。C#とUnicodeの関係はどうなっているのか？ C#が抱える課題とその解決策について見てみよう。 ← 前回 連載 INDEX 前編では、文字コード、そしてUnicodeがこれまでにどのような進化の道程を歩んできたかを見た。そこで説明したように、文字コード自体が結構な複雑さになっている。当然、プログラミング言語における文字列の扱いにも面倒が付きまとう。 後編である今回は、C#のstring型がどういう実装になっているかや、現状抱えている課題、それに対して検討している解決策などについて説明していく（以下、文字コードは全て16進数で表記する）。 文字列型 まずは、プログラミング言語内部での文字列の扱いについて話そう。Unicodeの歴史で話した通り、もともと、Unicodeは2Bytes固定長の文
プログラミング言語における文字コードの話
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
『NieR：Automata』のサブクエストはキャラを掘り下げる内容に。開発のPGプランナーチームを直撃！
『NieR：Automata』のサブクエストはキャラを掘り下げる内容に。開発のPGプランナーチームを直撃！ 『ドラッグ オン ドラグーン』シリーズなどを手がけたヨコオタロウ氏がディレクションを、『ベヨネッタ』シリーズなどを生み出したプラチナゲームズが開発を手がける、スクウェア・エニックスのアクションRPG『NieR：Automata（ニーア オートマタ）』。世界中のファン待望の一作が、ついに発売されました。 そこで今回は、プラチナゲームズの開発現場に潜入！ プランナーチームのメンバー6人にお時間をいただき、それぞれが手がけた仕事からこだわりのポイント、開発中のおもしろエピソードまでを根掘り葉掘りとお聞きしてきました！ ちなみに、致命的なネタバレなどは極力除外した内容になっていますので、まだゲームをプレイしていないという方も、安心してお読みいただけます。 サブクエストにも独自のこだわりが満載
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
