zip ファイル解凍時の文字化けに関する情報 - Cube Lilac
CubeICE の利用動機の一つとして Mac などで作成された zip ファイルを解凍する際に文字化けしない と言うものが挙げられます。この記事では、なぜ文字化けが発生するのかと言う基本的な情報から、Windows における主要な解凍ソフトの対応状況までを簡単に紹介していきます。 必ずしも UTF-8 の zip ファイル解凍時に文字化けする訳ではない Mac で作成された zip ファイルを Windows で解凍すると文字化けする原因は、Mac （Windows 以外） で採用されている文字コードが UTF-8 なので、日本語用 Windows で採用されている Shift_JIS (CP932) と異なるからと言われます。ただ、Windows 標準の解凍機能を用いた場合でも、必ずしも UTF-8 の zip ファイルで文字化けする訳ではありません。例えば、CubeICE には UT
TrueType フォント名を取得する - Cube Lilac
TrueType フォント名を取得する必要があったので作成してみました．今回必要だったのは，（ASCII での）フォント名とフォント・ファイル名（*.ttf）のマッピング，および日本語でのフォント名と ASCII でのフォント名のマッピングでした．尚，コードは FontForge の showttf.c と言うプログラムを参考に作成しました． 全体として注意する事は，*.ttf ファイルはビッグ・エンディアンで値が格納されている事です．ファイルを扱っているとエンディアン関係で悩まされる事は頻繁に遭遇するので，以下のような関数を定義しておく事にしました． template <class Ch, class Tr, class Type> inline bool get(std::basic_istream<Ch, Tr>& in, Type& dest, std::size_t which
既定ブラウザが Google Chrome だと Skype が暴走（CPU 使用率 100%）する - Cube Lilac
追記 この問題は、バージョン 6.13 でのアップデートで修正されたようです。詳細は、Skype の高負荷問題が修正された模様 - Life like a clown を参照下さい。(2014/01/23) 昨日、突然 PC がフリーズしてしまいまして、何事だろうと原因を探っているとどうやら Skype が暴走していたようです（フリーズ自体は、他にも CPU 使用率の高い何かがいたせいなのでしょうが）。 タスクマネージャ (Process Explorer) で確認すると、上図のように Skype の CPU 使用率が 25% 前後となっていました。現在使用している PC は 2 コア 4 スレッド CPU (Core i3 530) なので、1 コア（？ 1 スレッド？）分の CPU を Skype が使い切っているようです。 これはどうしたものかな……と Web 上を漁っていると、以下
大きなドシンとした古電子レンジ 〜昔の家電は丈夫で壊れにくい〜 - Cube Lilac
おじいさんの電子レンジ。40 年いつも動いている、ご自慢の電子レンジさ。 上記の画像は、私の実家にある電子レンジです。私の生まれるかなり前からあるそうなので、もう 40 年近くずっと稼働している事になります。40 年休まずにチンチンチンチン……この前、実家に帰って彼*1の近況を聞いたところ、動いてはいるんだけど内側のランプがついに点かなくなったとの事で、そろそろ危ないのかもなぁと心配しています。動かなくなってしまう日の事を考えると非常に寂しくなるくらい愛着の湧いてしまった、我が家の電子レンジです。 … いつか書こうと思っていた電子レンジの話を思い出したきっかけは、焦って新たな価値を足し続けてるからみんな路頭に迷ってる - kanackyの日記 と言う記事でした。全てがそうと言う訳ではありませんが、家電製品に関しては個人的にも「最近のものはいろいろな機能が付いているが脆くてすぐに壊れる。昔の
壊れかけの RAID0 - Cube Lilac
何も見えない 何も見せてくれない 僕の管理が昔より 適当になったからなのか ラックに置いていた 初めて買った黒い筐体 いくつものデータが いくつもの時代を作った 真夜中に日常から 修羅場に変わる 道を探していた 睡眠（おやすみ）もないままに 振り上げた行きばのない（拳） 押し寄せる後悔に 本当の幸せ教えてよ 壊れかけの RAID0 いつも聞こえてた いつも聞かせてくれてた（アクセス音） 画面ごしにログをみても かすかな勇気も生まれない RAID0 は知っていた 僕のメールに警告（アラート）した 絶望に破れそうな胸 やさしい手が肩をたたいた 華やいだ喧騒の後 静まる社内を背に 天井（てん）を眺めていた あてもないままに 遠ざかる自宅の帰路 帰れない残業に 本当の幸せ教えてよ 壊れかけの RAID0 キーを叩いていた 次のコマンドも判らずに 迷子になりそうな意識 素敵な同僚（とも）が起こした
Delayed ACK - Cube Lilac
これも研究関連で，遅延ACK（Delayed ACK）を無効にした状態でデータ通信をする必要がありまして． 今まではFreeBSDのPCで実験を行っていたのでsysctlで一発で無効にできたのですが，Linux系ではどうやらその方法では無理な模様． それで，JM projectで調べた所どうやらsetsockopt()を用いてquickackモードを有効にすれば良いらしいとの事なので，早速コードを修正して走らせて見たのですが・・・tcpdumpで見てる限り，思いっきり遅延ACKが動作してるぽいんですよね． 試行錯誤したところ，結局↓の説明が曲者だったようで・・・ TCP_QUICKACK 設定されていると quickack モードを有効にし、クリアされると無効にする。通常の TCP 動作では ack は必要に応じて遅延されるのに対し、 quickack モードでは ack はすぐに送信され
Facebook の「タグ付け機能」が怖い - Cube Lilac
Facebook には「タグ付け機能」と呼ばれるものが存在するそうです。これは、写真の一部分（例えば、顔の部分など）をクリックして、その箇所に表示されている部分に相当する人物の名前（任意の文字列）を設定できると言うものです。 この機能の怖いところは、「タグ付けされたユーザのタイムライン（ウォール）に該当の写真が表示されてしまう」と言う部分で、場合によっては自分にとって不都合な写真（第三者にはあまり知られたくないような会合に参加している写真など）や、みっともない写真（泥酔している写真など）を自分のタイムラインに掲載させられてしまうと言う危険性が存在します。 一部ネット界隈(たとえば某はてな界隈やTwitterなど)で、ソーシャルメディア上で他人の動向を暴露するのをやめて欲しいという感じのネタが盛り上がっています。 ソーシャルメディアでつぶやく前に注意したいこと・・・ | IDEA*IDEA
Hello, OpenSSL! - Cube Lilac
SSL 通信用のライブラリを追加しようと少し調べたところ，OpenSSL ライブラリを使うのがやはり王道っぽいので OpenSSL を使って実装してみました． gcc gcc を使う環境 (Linux, cygwin, ...) だと大抵の場合は最初からインストールされているようです．ない場合は，ソースコードをダウンロードして make するか，apt-get install とか適当なコマンドでインストールするとすんなり入るだろうと思います．コンパイル時には，crypto と ssl をリンクする必要があるようです． g++ -Wall -o test example_ssl.cpp -lcrypto -lssl VC++ Windows 版は，Shining Ligth Productions - Win32 OpenSSL からバイナリをダウンロードすることができるようです．Ligh
OpenSSLとselect - Cube Lilac
OpenSSL を使用しているときに複数のソケットの入力状況を管理する場合，通常の socket と同じように select や epoll を用いて制御を行うとうまくいかないときがあります． SSL のような暗号通信の場合、送信は「垂れ流し」では済まず、ハンドシェークを行なう必要があるからだが、この時、受信しようと思っていなかったデータ、つまり通信相手が送信したデータまで読み込んでしまう場合がある。 すると、SSL_write を呼んでいるのに、 OpenSSL の受信バッファに、意図せずデータが溜まってしまう。こうなってしまうと、select(2) や epoll(2) では検知できない。 select(2) や epoll(2) は、 I/O レベルでの受信データの有無を調べるシステムコールであり、それより上のレベルである OpenSSL ライブラリの受信バッファのことは関知しないか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
