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
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; +--------
MySQLのタイムゾーン - tmtms のメモ
YAPC::Asia 2015 のセッションで、MySQL のタイムゾーンの話が出ていましたが、以前タイムゾーン周りで少しはまったことがあったのを思い出したので書いてみます。 MySQLのデフォルトのタイムゾーンは mysqld 起動時のシステム設定です。TZ 環境変数の値か、変数が設定されていなければ /etc/localtime(Ubuntu の場合) です。 # TZ=Japan /usr/sbin/mysqld mysql> SHOW VARIABLES LIKE '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +---------
Ruby, MySQL のうるう秒の扱い - @tmtms のメモ
2015/7/1 にうるう秒が挿入されるということで、うるう秒の話題が盛り上がってるようなので自分も書いてみます。 Linux 上のプログラムが時刻で60秒を刻むには、うるう秒対応のタイムゾーンを使う必要があります。 通常はうるう秒を考慮していないタイムゾーンが使用されているので、60秒を含む時刻になることはありません。 60秒を含む時刻を扱うには、right/Japan のように right/ を前につけたタイムゾーンを指定します。 前回のうるう秒は 2012/7/1 08:59:60 (JST) だったので、これで試してみます。 % TZ=Japan date --date='2012-07-01 08:59:60' date: `2012-07-01 08:59:60' は無効な日付です % TZ=right/Japan date --date='2012-07-01 08:59:6
Sequel について (その1) - tmtms のメモ
最近 Sequel というライブラリを触ってるので簡単にまとめてみます。 Sequel Sequel は Ruby の構文で SQL クエリを記述するためのライブラリです。 SQL の文法が嫌いな自分には持って来いです。 RDB 毎の差異も吸収してくれます。 自分は MySQL しか知らないので、以下は MySQL での例です。 インストール % gem install sequel % gem install ruby-mysql 接続 DB = Sequel.connect('mysql://user:password@hostname:port/dbname') # または DB = Sequel.mysql('dbname', :host=>'hostname', :user=>'user', :password=>'password', :port=>'port') 上の例では定
Rubyのエンコーディングその2 - tmtms のメモ
この前「Rubyのエンコーディング」という記事を書いたのですが、それをネタに 8/25 の NSEG で発表しました。 Rubyのエンコーディング from Masahiro Tomita この中で、エンコーディングが原因で予期しないところで落ちてしまうことが結構あるという話もしたんですが、今回はプログラムが落ちないようにするにはどうすればいいかを考えてみます。 エンコーディングが原因で落ちてしまうのは大体次のパターンのようです。 文字列や正規表現のエンコーディングが異なる 文字列中に不正な文字が含まれている 文字列や正規表現のエンコーディングが異なる 正規表現をリテラルで生成していれば、エンコーディングは敢えて指定しない限りは普通はスクリプトエンコーディングになってると思うので、問題は文字列の方です。 特にファイルから読み込んだ文字列のエンコーディングが何になっているかに注意しましょう。
Rubyのエンコーディング - tmtms のメモ
Ruby 1.9 から文字列や正規表現オブジェクトはそれぞれエンコーディング(いわゆる文字コード)を保持するようになりました。 たとえば 0xB1 0xB2 という２バイトは EUC-JP エンコーディングでは「渦」、SHIFT_JIS エンコーディングでは「ｱｲ」という文字になります。つまり同じバイト列でもエンコーディングが異なれば異なる文字として解釈されます。 1.8 では文字列はただのバイト列でした。なので、それがどのような文字を表しているのか、つまりエンコーディングが何なのかはプログラムが知っている必要がありました。 1.9 では文字列オブジェクト自身が自分が何のエンコーディングかを知っています。同じ 0xB1 0xB2 というバイト列でも、それが EUC-JP の「渦」なのか SHIFT_JIS の「ｱｲ」なのかは、文字列自身が知っています。 スクリプトエンコーディング スクリプ
デブサミ2010 2日目のスライド - tmtms のメモ
デブサミ2010 2日目のスライドです。見つけたら都度追加していきます。 【19-B-1】ここまで来た！製造、金融でのアジャイル基幹システム開発〜ユーザー主導が成功の鍵！〜／浜津和弘,森川哲史,漆原茂 【19-B-2】Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス／玉川憲 【19-B-3】三周遅れのXP -僕とドワンゴのXP-／庄司嘉織 【19-B-4】開発品質向上のための、ASQ/ALMソリューション 〜品質向上策・活用していないのは何故ですか？〜／藤原祐之 【19-B-5】パネルディスカッション 出張！ DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜／和田卓人,角田直行,和智右桂,佐藤匡剛,渡邉健太郎 【19-B-6】実践Cucumber 〜ユーザの視点でシステムの振る舞いをテストしよう／諸橋恭介 【19-B-7】次世代Web
Developers Summit 2010 1日目のスライド - tmtms のメモ
デブサミ2010 1日目のスライドです。まだあまり公開されてないのか単に見つけられてないのか…。新しく見つけたら都度リンクします。 【18-B-1】 クラウドがもたらすパラダイムシフトとデベロッパーへのインパクト／栗原潔 【18-B-2】 ”クラウド”をビジネスにしませんか？ 〜Force.comのテクノロジーとビジネスモデル〜／岡本充洋 【18-B-3】 Google的分散コンピューティング／Gregor Hohpe 【18-B-4】 現場から見たエンタープライズ／山口幹一朗 【18-B-5】 クラウドの構築事例／並河祐貴 【18-B-6】 オラクルのエバンジェリスト2人が考えるクラウド・プラットフォーム／中島一樹,佐藤直生 【18-B-7】 アーキテクチャに憧れろ−『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション／鈴木雄介,伊藤直也,小野和俊,江島健太郎 (ロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
