LC_ALL環境変数とsortコマンド - sileのブログ
自分の環境では、sortコマンドを実行する時にLC_ALL環境変数に'C'をセットするかしないかで、処理終了までの時間が著しく変わる。 # 約40万行のデータ > wc -l words 392126 words # 入っているのはUTF-8の日本語(IPA辞書を利用) > head words やぼったい やぼったし やぼったから やぼったかろ やぼったかっ # 普通のソート > time sort words > /dev/null real 0m37.158s user 0m37.098s sys 0m0.056s # LC_ALL=Cでのソート > time LC_ALL=C sort words > /dev/null real 0m0.293s user 0m0.284s sys 0m0.008s ロケールを考慮してソートするかどうかの違いだと思うが(LC_ALL=Cの場合は、
Wanderlustと文字コード - 技術日記＠kiwanami
Wanderlustをもう5年以上使っているが、丸数字を含むメールで苦労していた。ローカルのファイルの読み書きは問題ないが、Wanderlust上では送信・受信でうまくいかない。 昔は Content-Type に charset=ISO-2022-JP って書いてありながら、iso-2022-jpの文字集合にない文字を使うようなメールは容赦なく切り捨てていた。添付ファイルの扱いも変だし、そんなうんこメー(ry 時は流れて、今や方眼紙Excelとメールに明け暮れるスーツな毎日。今時メールで丸数字や人名にハシゴ高が使えないメールソフトを使い続けるのは単に痛い人でしかない。というより、FromやToの欄にiso-2022-jp以外の文字集合の人（例えば(株)とか）がいるだけでアウトなので自分が辛い。 もう世間はGmailでUTF-8で本文を送っても問題が無くなり、しかも cp50220 という
#perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 : 404 Blog Not Found
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
MySQL 文字化け問題を本気で直す
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
Unicode の文字列をソースコードに埋め込む方法 - bkブログ
Unicode の文字列をソースコードに埋め込む方法 Unicode の文字列をソースコードに埋め込む場合、直接 UTF-8 などで文字列を書く方法と、\uXXXX などのようにエスケープして表記する方法があります。後者の方法についてまとめてみました。 \uXXXX 形式の場合 Java, JavaScript, Python, C++, C (C99から) などの多くの言語では \uXXXX という表記 (universal character names) でUnicode の文字を文字列の中に埋め込めます。たとえば、「あいう」は "\u3042\u3044\u3046" となります。 \uXXXX で埋め込んだ文字がどのように解釈されるかは言語や処理系によって異なります。 gcc/g++ の場合、 -fexec-charset オプションで、実際に使う文字セット・エンコーディングを指
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
Perl正規表現雑技
このページは Perl5.6 を対象としています． perl スクリプトは EUC-JP で書かれることを想定しています． このページは 正規表現メーリングリスト を参考に，私が独自にメモとしてまとめたものです． このページの正規表現やスクリプトについての詳しい説明， わかりやすい説明はおそらくできません． このページに書かれているスクリプトは， 個人の責任において実行してください． このページに書かれているスクリプトの 利用・改造は自由 です． その際はどこかにこのページの URI( http://www.din.or.jp/~ohzaki/regex.htm )を参考として記述していただければ幸いです(任意)． ご意見・ご感想・ご要望などは にお願いします．こう書いた方がいい， 動かん，わからん，バグってる，これ書け，などなどお待ちしています． このページへの リンクは自由 に張ってく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
azito.com