自動的に移動しない場合はをクリックしてください。
● [エッグ][Ruby] throw 失踪事件 (前編) そんなことより1よ、聞いてくれ。最近 emacs (ruby-mode) の highlight がおかしいんすよ、highlight。行頭に変な色がついちゃってるの。 まぁ、構文解析でなく正規表現で頑張るタイプなので、emacs にはよくあることなんだけど。"とか`の後も結構おかしくなるよね>ruby-mode。つーか、osx 上なので、そもそも iTerm の問題なのかもしれないし。でさ、そんなことよりも、さっき突然、開発中の Merb アプリが動かなくなったんすよ。これは色どころじゃない話。致命的!しかもエラー内容が謎で いやいやいやいや。違う違う違う違う!(浜崎あゆみ)。もちつけ matz ruby。1.9ならいざ知らず(失礼)。お前には throw を扱う能力が絶対にあるから。冷静になってくれ!みたいな感じで、お送りして
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
JIS X 0213の第3・4水準漢字の一部が4バイトとなる。マイナーな文字ですね。 例えば、第1・2水準漢字だけ対応していればよい案件などでは考慮しなくてよいでしょう。 MySQLではこのUTF-8で4バイトになる文字を扱えないのだとか(MySQL6なら対応したそうだ)。 数値文字参照で全部書いてみた。 (パッチのあたっていないWindowsXPなどでは表示されないです。) 𠀋 𡈽 𡌛 𡑮 𡢽 𠮟 𡚴 𡸴 𣇄 𣗄 𣜿 𣝣 𣳾 𤟱 𥒎 𥔎 𥝱 𥧄 𥶡 𦫿 𦹀 𧃴 𧚄 𨉷 𨏍 𪆐 𠂉 𠂢 𠂤 𠆢 𠈓 𠌫 𠎁 𠍱 𠏹 𠑊 𠔉 𠗖 𠘨 𠝏 𠠇 𠠺 𠢹 𠥼 𠦝 𠫓 𠬝 𠵅 𠷡 𠺕 𠹭 𠹤 𠽟 𡈁 𡉕 𡉻 𡉴 𡋤 𡋗 𡋽 𡌶 𡍄 𡏄 𡑭 𡗗 𦰩 𡙇 𡜆 𡝂 𡧃
@檸檬の家 ブログ更新を停止しています 自己紹介 連絡先: 小川 創生 (motoyuki@bc4.so-net.ne.jp) このブログは個人的な「書きたいこと雑記帳」であり、現在または過去の所属の公式見解等を示すものではありません。 (2009年12月15日追記: MySQL 6.0 は5月に開発凍結となっており、この記事で述べている新機能の行方は不透明な状況です。「MySQLの改定常用漢字表対応が危うい件」もお読みください。) だいぶこの話題を書くのが遅くなってしまったが、新しい常用漢字表の議論がそろそろ佳境なので、このタイミングで書き記しておく。 オープンソースのデータベース管理システム「MySQL」は、特に Web システムを中心に、すでに国内外で多数の主要企業が導入している。しかし、マルチバイト文字については、たとえば商用の Oracle や、別のオープンソースの Pos
Don't use DBIx::Class::UTF8Columns - JPerl Advent Calendar 2009 Perl に関するちょっとした Tips をのっけてみるよ。ちゃんと続くかな? 自分のつくったもジュールを紹介するハッカートラックということで、僕は DBIx::Class に同封されている DBIx::Class::UTF8Columns について書きます。 まず最初に、このモジュールをつかわないでください。 DBIx::Class::UTF8Columns は DBIx::Class のコアモジュールになってから、utf8 を扱う場合はこのモジュールを使うといいよという記述をいろいろなところで目にします。しかしこのモジュールがしていることを理解せずに使用すると予期せぬ不具合に悩まされるかもしれません。今日はこのモジュールを使わない方が良い理由と、その代替案を示
2009年09月13日13:00 カテゴリLightweight Languages #perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 駄目です。 [を] Perl の utf8 まわりのおまじない 最近良く使うおまじない、というかイディオム。 utf8::decode($text) unless utf8::is_utf8($text); こういう場合は、Encode::decode_utf8()でないと。 以下をごらんください。 #!/usr/bin/perl use strict; use warnings; use Encode; use Devel::Peek; for my $bytes ( "\x2F", "\xC0\xAF", "\xE0\x80\xAF", "\xF0\x80\x80\xAF" ) { my $u
Perl の utf8 まわりのおまじない 2009-09-12-4 [Programming] 自分用メモ。 最近良く使うおまじない、というかイディオム。 utf8::decode($text) unless utf8::is_utf8($text); (追記:より良いおまじない。詳細は後述。 $text = Encode::decode_utf8($text) unless utf8::is_utf8($text); ) Perl の CGI モジュールでクエリから得られるデータの文字列のutf8フラグの有無が環境によって違うことがあってイライラ。 でもこのおまじないでなんとかなった。 こんな文脈で使う: use utf8; use CGI; ... my $text = $q->param('text') || ""; utf8::decode($text) unless utf8:
HTML::FillInForm::Liteの使いどころという記事で,HTML::FillInForm::Liteが遅いということが取り上げられていた。 試しに記事内のベンチマークを行ったところ,確かに遅い。 # HTML::FillInForm 1.06 Benchmark: HTML::FillInForm vs. HTML::FillInForm::Lite Rate fillinall_lite fillinall fillinpart_lite fillinpart fillinall_lite 570/s -- -52% -76% -78% fillinall 1199/s 110% -- -49% -54% fillinpart_lite 2349/s 312% 96% -- -9% fillinpart 2595/s 355% 116% 10% --ところで,このベンチマー
@ARGVには、普通UTF8フラグはつきません。どうやってフラグをつけるのか調べてみました。 その後、ブックマークコメントを見て、モジュール探したら見つけましたんで、追加しました。 -C か環境変数でやる こちらで見つけました. 起動オプション-Cか環境変数PERL_UNICODEにAを与えてやります。 perl -CA -e 'print utf8::is_utf8($ARGV[0]);' あああ PERL_UNICODE=A perl -e 'print utf8::is_utf8($ARGV[0]);' あああ -CやPERL_UNICODEが取れる値は、perldoc perlrun にあります。以下、抜粋。 -C [number/list] The "-C" flag controls some Unicode of the Perl Unicode features. As o
ちょっと最近Buzzurlに自作スクリプトか何かで、大量の二重エンコード文字列を含むブックマークが投稿されたので対策のために調べてみたことのまとめ。<追記>id:miyagawaさんのブクマで Encode::DoubleEncodedUTF8 というモジュールを教えてもらいました。調べたら作者もid:miyagawaさん。二重エンコード是正にはこちらを使うようにしましょう。 でもこれ"二重エンコード perl utf8"とかでぐぐったけど見つからなかった…。id:miyagawaさんのブログとかもっと検索に引っかかるべきだと思うのだが。 PerlでUTF8文字列を使うときの原則 PerlでUTF8文字列を扱うならば、Encodeの神であるところのid:dankogaiが何度も何度も口をすっぱくして言っている次の原則に従わなければならない。そうしないとすごく不愉快な目にあう。 入り口で d
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、(2/3)SQLインジェクションを根絶!セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題:ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『¥』は?」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
最近unicodeに対応したソフトが増加してくるにつれ、用語の混乱も一部には見られるようになってきました。そこで特に触れることの多い、UTF-7,UTF-8,UTF-16 についてここで少し取り上げておきたいと思います。 UnicodeとUCS UnicodeはThe Unicode Consortiumが定めた文字コードの規格である。UCSはISOとIECが共同で制定したもので、ISO/IEC 10646 の規格番号が付いている。両者は大雑把にいえば同じものと考えてもよいのだが、違う機関が定めたものである故に、微妙に(?)差があるのも事実である。 ■Unicode側の改訂経緯 Unicode1.0(1991) アメリカの技術者を中心に作られ、漢字コードは極めてデタラメ Unicode1.1(1993) 中国の技術者が加わり、少しはまともになる。日本が猛反発。 Unicode2.0(199
2009年06月15日07:00 カテゴリLightweight Languages perl - use utf8; #って何だ? id:otsuneに建設予定フラグがたてられていたので。 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech Perl の utf8 関係が未だ全く理解できない。わからないことがわからないので整理 use utf8はいつフラグをたてるか use utf8 しててもフラグたたないことがある…… これは、以下の実例を見ていただくのが一番よいだろう。 #!/usr/bin/perl use strict; use warnings; use utf8 (); sub check_flag{ my $str = shift; print qq("$str" ), utf8::is_utf8($str) ? 'is' : 'IS NOT',
2009年06月08日14:30 カテゴリLightweight Languages perl - use encoding; #は黒歴史 ぎゃあぁぁ length関数で文字列の長さを求める - perl初心者BLOG - Hatena::Group::Perl 日本語の文字数を正確に求めたい場合、use encodingを指定する use encoding;は、jperlなど、かつて存在したL10Nされたperl用に書かれたレガシースクリプトを、モダンperlで動かすときのためのおまじないです。こういう目的で利用すべきではありません。 このあたりのことは、以前 404 Blog Not Found:perl - no encoding; # whenever possible でも書いたのですが、大事なことなのでまた書きます。 スクリプトはUTF-8で書き、use utf8;する のがモ
文字エンコーディングの変換を行うと、異なる2文字が同じ文字に変換されることがあります。このような文字を重複文字と呼ぶことにします。UTF-8→Shift_JISおよびUTF-8→EUC-JPについて、重複文字を自分用の資料としてまとめてみました。 MacOSX上のPHP5.2.9での実験結果ですが、プログラミング言語や環境によらず気をつけるべき文字一覧ということになると思います。 色のついている部分が重複している部分です。「-」となっているのは変換できなかった文字です。また、ヘッダのカッコ数字ごとに文字エンコーディング変換に利用した関数が異なります。詳細は下記の通りです。 (1) mb_convert_encoding($char, "Shift_JIS", "UTF-8") (2) mb_convert_encoding($char, "SJIS-win", "UTF-8") (3) i
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
以前までは、データベース MySQL を利用したアプリケーションを作るときは、文字コードとして EUC-JP を利用していました。最近は、国際化との兼ね合いなどから UTF-8 を利用するようにしています。 MySQL で UTF-8 を扱う場合、照会順序として utf8_bin を使用していました(何も考えずに)。 utf8_bin の場合、部分一致探索 LIKE などの使用時に英字の大文字小文字が区別されてしまう。大文字小文字を区別されないようにするためには、照会順序として utf8_general_ci を使用すればよいのですが、他にも utf8_unicode_ci があることに気がつきました。 utf8_general_ci と utf8_unicode_ci では、どこが違うのだろう? utf8_general_ci also is satisfactory for both
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く