比較:(日本語 (Mac) - x-mac-japanese) (日本語 (シフト JIS) - CP932) - 文字コード表「比較:(日本語 (Mac) - x-mac-japanese) (日本語 (シフト JIS) - CP932) - 文字コード表」の文字コード表です
【図解】【3分解説】UnicodeとUTF-8の違い！【今さら聞けない】 - Qiita
UTF-16のことをUnicodeと記しているソフトウェア(Windowsのメモ帳など)もありますのでUnicodeとあったらそれはUTF-16を使って変換したものなのだな、というふうに理解してください。 そうなってしまっている理由はこちらで解説されていました。 これでUnicodeとUTF-8の違いはバッチリですね！おわり。 読んで分かりやすかったり少しでも何か学べたと思えたら いいね や コメント をもらえるとこれからの励みになります！ もう少し時間がある方へ 手計算で文字をUTF-8での符号まで計算してみましょう。 理解が一気に深まります。手順は以下。 1. 文字のコードポイントをUnicodeから見つけてくる。 2. コードポイントをUTF-8の方式で変換してみる。 Omiitaの「お」をUTF-8による符号まで変換してみます。 文字「お」のコードポイントをUnicodeから見つけ
「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita
物語の始まり 事の発端は納品後。 先方からメッセージが届きました。 クライアント様「このファイルの文字コードがShift_JISになっておりますので、UTF-8で再納品をお願いいたします。」 拙者（あれ…UTF-8にしてたと思うんだけどな） 拙者「確認いたします。」 文字コードを確認する 本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。 そして、ご指摘いただいたのは、今回の更新案件で中身はいじらなかったJavaScriptファイル。 本来ならば納品するファイルではないのですが、文字コード変換という要件があったため、納品ファイルとして加えられたものでした。 一括で文字コードを変えたので作業漏れかなぁと思っていました。 ファイルの中身は記事用にかなり適当につくったものですが、まあだいたいこんな感じです。
MySQLのsjisとcp932の違い - tmtms のメモ
今さらですけど、自分でもちゃんと把握してなかったので調べてみました。 MySQLのCharsetのうちシフトJIS系のものはsjisとcp932の二つあります。 どちらもコードの範囲は次のように同じです。 1バイト文字 0x00-0x7F, 0xA1-0xDF 2バイト文字の1バイト目 0x81-0x9F, 0xE0-0xFC 2バイト文字の2バイト目 0x40-0x7E, 0x80-0xFC 違いは文字集合です。1バイト文字はどちらも同じ(ASCII + JIS X 0201 カナ)ですが、2バイト文字はsjisはJIS X 0208 で、cp932はWindows-31Jです。 sjisに含まれていない文字 cp932はsjisよりも文字が多く、丸囲み数字(「①」「②」「③」等)、ローマ数字(「Ⅰ」「Ⅱ」「Ⅲ」等)、組文字（「㍉」「㌍」「㍻」等）、その他「彅」「髙」等の JIS X 0
Redmine構築後のDBの文字コードをutf8mb4に変換して絵文字に対応する - Dig that groovy!
動機 Redmine上で絵文字を記入し保存しようとすると… ゴール 文字コードがutf8で初期化されたDBをutf8mb4に変換し、Redmineで絵文字（4バイト文字）が書き込めるようにする 参考リンク MySQLでテーブルとカラムの文字コードを一括変更する - Be an Idealistic Realist ActiveRecordをutf8mb4で動かす - Qiita MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる 前提 これの続き Redmine を LXC on Ubuntu 14.04で動かす - Dig that groovy! といってもあまりコンテナうんぬんは関係ない MySQL 5.5.43-0ubuntu0
UTF-8からSJISに文字化けすると糸偏の漢字がよく出てくる - Qiita
はじめに Twitterで、文字化けネタを幾つかつぶやきました。 サッちゃんはね サチコっていうんだ ほんとはね だけど ちっちゃいから 自分のこと SJISで 保存するんだよ おかしいな 繧ｵ繝ちゃん — ロボ太 (@kaityo256) 2017年10月10日 「私 魔女のキキです。こっちはSJISの繧ｸ繧ｸ」 — ロボ太 (@kaityo256) 2018年1月6日 UTF-8「もしかして…」 SJIS「私達…」 「「入れ替わ縺縺ｦ繧九≦縲懶ｼ†」」 — ロボ太 (@kaityo256) 2018年2月13日 どれもUTF-8で保存された文字をSJISとして解釈したための文字化けを表現したものですが、パッと見で「糸偏の漢字が多いな」ということがわかるかと思います。なぜそうなるかを簡単に説明してみようと思います。 なお、文字コードはいろいろ面倒なので、ここではざっくりとしたことしか言い
MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
Rubyのエンコーディングその2 - tmtms のメモ
この前「Rubyのエンコーディング」という記事を書いたのですが、それをネタに 8/25 の NSEG で発表しました。 Rubyのエンコーディング from Masahiro Tomita この中で、エンコーディングが原因で予期しないところで落ちてしまうことが結構あるという話もしたんですが、今回はプログラムが落ちないようにするにはどうすればいいかを考えてみます。 エンコーディングが原因で落ちてしまうのは大体次のパターンのようです。 文字列や正規表現のエンコーディングが異なる 文字列中に不正な文字が含まれている 文字列や正規表現のエンコーディングが異なる 正規表現をリテラルで生成していれば、エンコーディングは敢えて指定しない限りは普通はスクリプトエンコーディングになってると思うので、問題は文字列の方です。 特にファイルから読み込んだ文字列のエンコーディングが何になっているかに注意しましょう。
UTF-8にもいろいろある - ザリガニが見ていた...。
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
欢迎光临-HB