最近GNU grepコマンドの最新バージョンがリリースされ、速度が10倍になったとのアナウンスがあった。それを聞いて、なんであんな枯れた技術に10倍もの高速化の余地があったのだろうと不思議に思った人も多いだろう。 ニュース記事:grepコマンド最新版、”-i”で10倍の高速化 本家のリリースノート:grep – News: grep-2.17 released [stable] 今回のリリースでは正確には、マルチバイトロケールで、-iオプション(–ignore-case、つまり大文字小文字を区別しないオプション)をオンにした時の速度が10倍くらいになったそうだ。 なぜそんなに速くなったのか?逆を言えば今までなぜそんなに遅かったのか? そもそも、多くの日本人にとって「大文字小文字の区別」というと英語のアルファベットか、せいぜいフランス語とかドイツ語とかのアクサン記号・ウムラウトがついたものく
日本がCJK統合漢字拡張F1/F2に提案している文字には、すでにUCSに入っている漢字と見分けがつかない例がいくつもある。これらは、提案書*1に「Similar and Variation」として既存の文字の符号位置が記載されているものの一部であり、つまり、似ている漢字の存在は百も承知で提案しているわけだ。 以下、そのような例を拾ってみた。左右に並べた文字のうち「UCS」欄に符号位置が入っているほうが、既存のもの。個々の文字について述べることはしないが、要するに「別字の衝突であれば、形が同じでも別の符号を与える」ということだろう。 だが、ちょっと待ってほしい。それって実はものすごく根本的な方針転換じゃないですか? 「機」の簡体字の「机」も「つくえ」の「机」も、形が同じである以上、同じ符号位置(U+673A)に包摂・統合するというのがCJK統合漢字の大原則であったはず*2。ここでいきなりそれ
iPhone間の新しい文字化けパターンが発見されたのでメモ*1。この少なくとも3つのダメな仕様が重なって発生する文字化けは、発見者によって「兄化け」と命名された*2。 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として
Python Programming Language 3日(オランダ時間)、Pythonの次世代バージョンにしてマイルストーンリリースとなるPython 3.0(final)が公開された。プロダクションとしての利用レベルに達したと評価されている。"Python 3000"や"Py3k"としても知られているが、この新バージョンPython 3.0は従来のPython 2系とは互換性がない。言語そのものはほとんど同じだが、ディクショナリや文字列の動作などの組み込みオブジェクトの動作が熟慮のうえで変更されており、これまで非推奨とされてきた機能は3.0からは削除されている。 Python 3.0における注目の新機能や主な変更は次のとおり。 Unicodeへの全面移行を実施。str型はUnicode文字列を表現し、それ以外のデータ/バイナリデータはbytes型で表現する。strとbytesの変換は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く