エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
UTF-8/UTF-16/UTF-32 を処理系の内部エンコーディングに使う場合のそれぞれのメリット - higepon blog
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
UTF-8/UTF-16/UTF-32 を処理系の内部エンコーディングに使う場合のそれぞれのメリット - higepon blog
ごく最近調べて実装したり、人に聞いたメモなので間違っていたらぜひ御指摘を。 UTF-8 ascii が 1byte ... ごく最近調べて実装したり、人に聞いたメモなので間違っていたらぜひ御指摘を。 UTF-8 ascii が 1byte で ascii に一致する。 これが大きい。 処理系が実装されている C のコードで、絶対に ascii だと分かっている変数にたいして、標準C関数を使いまくれるのがうれしい。 文字列リテラルも可搬性を維持したまま使える。 strcmp("hige-func", hoge) これが UTF-32 だったら、たとえ全てが ascii と分かっていても専用の関数(ブリッジ?)を作らないと行けない。 fopen とか。 あとはasciiばかりの場合には効率が良いとか。 UTF-16 2byteに収まる。 サロゲートペアの部分なんか気にしないぜと男気を見せれば、完全2byteの世界になること。 UTF-32 完全 4byte 固定なので処理がとても楽。*1 L"abあ" は、何文字?