zipパーサに関するメモ

仕事で zipファイルを展開せずバイナリのまま構造解析する可能性があったため, zipの仕様を調べていました. 仕様については Wikipedia(日本語版は今ひとつわからなかったところがあったので英語版をメインで見た方がよいと思います)等を参照してください. で, パース方法を調べると初めにファイル末尾にある End of central directory record(以下 EOCD)を探して, そこから Central directory file headerを探してごにょごにょするとあったのですが, EOCDには可変長なコメントフィールド(最大 0xffffバイト)があり, それを考慮した上で正しくパースするにはどうすればいいのだろうと思って, 各種言語の zipライブラリを調べてみました. これはそのメモです. 本記事は zip64の内容は含みません. ご注意ください

zip形式の仕様

Zip (file format) - Wikipedia

問題となると考えたケース

  • コメント部に別の zipを書き込んだ場合正しくパースできるのか
  • validなファイルを invalidと解釈しないか
  • 期待しないファイルを展開することはないか(今回未検証)

Go言語の archive/zip

zip.OpenReaderの大雑把な流れは以下のとおりです. 調べたのは Go 1.9の archive/zipになります.

  • EOCDを探す. 探すパターンが 2つあり, 末尾から 1024バイトの位置, 65 * 1024(=66560)バイトの位置から EOCDのマジックナンバを探す.
  • マジックナンバが見つかったら, マジックナンバを除いた位置から始まるバイト列で directoryEnd構造体(EOCDに対応)を初期化する
  • EOCDから Central directory file headerの先頭オフセットを取得し, 各ファイルの情報を zip.Fileに設定する
  • 各ファイルの情報を取得するとき, Central directory file headerのマジックナンバをチェックし, 不正だと zip.ErrFormatを返す

特にコメントを意識していないようです.

テスト zipの作成

test.zip(aaa.txtを保持)のコメント部に別の incomment.zip(test.txtを保持)を書き込みます. 期待としては, aaa.txtが展開/名前が取得されます. (zipに含まれる名前が適当すぎますが, それっぽい名前にしてしまうとバイト列が変わってしまうためはじめに作ったこスクリプトを利用しています)

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import zipfile

zip_file = 'test.zip'
incomment_file = 'incomment.zip'

for f in [zip_file, incomment_file]:
    if os.path.isfile(f):
        os.remove(f)

with open('test.txt', 'wb') as f:
    f.write(os.urandom(2048)) # 1024バイト以上の長さになるようにする.

incomment_zip = zipfile.ZipFile(incomment_file, mode='w')
incomment_zip.write('test.txt')
incomment_zip.close()

with open('aaa.txt', 'wb') as f:
    f.write(b'aaa')

zf = zipfile.ZipFile(zip_file, mode='w')
zf.write('aaa.txt')

with open(incomment_file, 'rb') as f:
    buf = f.read()

zf.comment = buf
zf.close()

作成した test.zipを archive/zipに与えてみる

以下のような zipに含まれるファイル一覧を表示する Goプログラムに test.zipを与えます.

package main

import (
    "archive/zip"
    "fmt"
)

func main() {
    r, err := zip.OpenReader("test.zip")
    if err != nil {
        fmt.Println(err)
        return
    }

    for _, f := range r.File {
        fmt.Println(f.Name)
    }
}

結果は以下のように validでないとエラーが返ります.

% go run main.go
zip: not a valid zip file

原因はコメント中の別 zipの Central directory file headerの offsetを元ファイルの先頭から調べたとき, Central directory file headerのマジックナンバではないためです. コメントに関する制約は特にないようなので上で作成した zipは validだと思うのですが, invalidな zipとして判断されてしまいました.

この問題を回避するためにコメント中の zipの Central directory file headerの offsetに元の zipのコメント位置の offsetを加算した値を書き込みます. 下記のカーソル位置から始まる 2byteが Central directory file headerの offsetなのでバイナリエディタ等を使って書き換えます. (上の例だと 0x0826を 0x0899に書き換えます)

f:id:syohex:20171004010648p:plain

再度コマンドを実行してみます. 思惑通りコメント中に書き込んだ zipの方を対象の zipとして認識してくれて text.txtが出力されました.

% go run main.go
test.txt

他の言語

中身までは見ていないですが, 試してみる. Goのような実装かもしれないので, 上の offset変更を適用した zipを喰わせます.

Python3(3.6.2)

import zipfile

zf = zipfile.ZipFile('test.zip', 'r')
print(zf.namelist())
% python3 test.py
['test.txt'] ## コメント中の zipを扱う

Perl(Archive::Zip 1.59)

use strict;
use warnings;

use Archive::Zip;

my $zip = Archive::Zip->new();
$zip->read('test.zip');
print $_, "\n" for $zip->memberNames();
% perl test.pl
test.txt ## コメント中の zipを扱う

unzipコマンド(6.00 Ubuntu版)

% unzip -l test.zip
Archive:  test.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     2048  2017-10-04 01:06   test.txt
---------                     -------
     2048                     1 file

Goのようにコメント中の zipが扱われてしまうものが多いようです. 手元で正しく動いたのは, macOSの Finder(Archive Utility)だけでした.

なおこれらのプログラムは zip中のファイル名だけでファイルの中身を誤って(??)取得させようとすると Central directory file headerの offsetもそれぞれ修正する必要があるかと思います. これは未検証なので, もしかするとうまくいかないかもしれません. 余裕があれば確認しようかと思います.

最後に

  • zipパーサにはコメントを考慮していないものがある.
  • そうなっていないのはやはり速度重視だから ?
    • ファイル末尾の min(コメントの最大長, ファイルサイズ)から状態(コメント中か否か等)を調べてマジックナンバを探索していけばよさそうなものだが..
  • 最初に探すべきデータブロックに可変長なフィールドがあるのはどうなのか.

Emacs実践入門 改訂新版を読みました.

gihyo.jp

tomoyaさんから献本頂きました. ありがとうございます. 紙で置いておきたいというのと若干申し訳ないというのもあり紙版も購入しました.

感想

「実践」とつくように実践な内容です. 操作, 設定, 拡張の 3つのパートから構成されていますが, どれもほどよい長さにまとまっていて読みやすいです. その上, Emacsにこんな謎の機能あるんだとかではなく, 実際によく使う機能のことが多く書かれていると思います. Emacs自体膨大な機能から成り立っており, 標準機能だけで一冊どころではない本にできますが, それを全部書いたら尋常じゃない量になるし, 人によっては使わない機能ばっかりになってしまいます. この本では標準の機能, 標準外の機能が読みやすい形でまとまっているなぁと思いました. たまに登場するコラムもいいアクセントというか参考になると思いました.

初心者や Emacsを使っているけど 3rdパーティ製のツールを使っていないという人という人には特にいいかなと思います. Emacsと付く本はだいたい読んでいますが, 実践という意味では一番よいと思います.

初版とくらべて

だいぶ前に読んで記憶が若干あやふやですが, 拡張の章が微妙に新しくないなぁと思ったような気がするのですが, 今回の改訂版は新しくなっていて今時だなというのを感じました.

若干気になったところ(順番は適当でページ順ではありません)

  • minor-modeの有効・無効が t, 0が使われている箇所がある. 公式的には有効は正の整数(通常 +1), 無効は負の整数(通常 -1)を推奨
  • add-hookに lambdaを使っている. 紙面上の問題というのもあるけど, lambdaで指定しまうとそれを名前で参照する方法がないので関数で指定した方がよい. 特定の状況で無効化したいとき, 名前で参照できれば, それだけ remove-hookすればよいので.
  • major-modeの決定で見つからなかったら text-modeとなっているけど, fundamental-modeではないだろうか.
  • (どちらでもいいが統一されていないような)lambdaに quoteがついているところがある
  • foo.elと foo.elcがあると常に foo.elcが読まれるとあるが, load-prefer-newerに依存する. デフォルトだと nilなので, elcの方が優先されるのは確かですが

最後に

私が作成したツールも紹介されているのですが, 最近 Emacsまともに使っていないので申し訳ないですね. これを契機に Emacs感を取り戻したいと思います.

転職して 1年と 2ヶ月ほど経った

なかなか忙しい日々を過ごしています.

仕事内容

具体的なことを書いていいのかわからないので雑に書きますが…

  • サーバプログラム(APIサーバ)を Goで書いた
    • 初めての仕事でのサーバプログラムであったが, APIサーバで JSON返すだけなので, そこまで大きな苦労はせず. 仕事の進め方などは前職とはだいぶ変わったので戸惑うところはあったけど, 苦痛とかストレスが溜まるということは特になく楽しくできたと思う
  • サーバプログラムを 4-5ヶ月書いた後からはずっと C++書いている
  • IDEをメインにするようになった
    • Xcodeはあんまり印象よくないけど, Visual StudioC++コンパイラの質を除くとだいぶ良かったので
    • デバッグ周りがだいぶ便利.
    • JetBrains All Products Packを私的に購入
    • 最近少し JSも書いたが, WebStormを使っている

転職について

結果としては良かったと思う. 自分自身も新しい刺激を受けられたというのと, 自分の前職の知識をいくらか広めることができたということが, 特に. ずっと同じことをして何かをずっと伸ばしていくというのもキャリアとしてもちろんあることだと思うけど, 新しいことを学び, 自分の知識を別の場所で広げていくというのもいいなぁと思えました. 社会的にそういうのが広まっていけば, 魅力的な職場というのも増えていくだろうので. 絶対しろとはいいませんけど, 考えてみるのはいいことなのではないかと思います.

激遅回線の改善

東京へ引っ越してきてマンションでのネット契約方法がよくわからず不動産屋からいただいた資料にあった Sonetと契約(100Mbps)したがこれがどうにもこうにも激遅である. 人があんまりいない時間だと普通に使えるんだけど, 夜とか 10年前かってレベルの遅さだったので改善方法がないか調べて対策を行った. 結論としては IPoEをプロバイダに有効にしてもらい, ルータを DS-Lite対応のものすればよい. これでひどいとき 1Mbps出ていたかどうかのレベルだったものが 90Mbpsぐらい安定して出るようになった. インターネット関連のストレスはだいぶ減りました.

IPoEに申し込む

DMM光なんかだと申込時にできるっぽいんだけど, Sonetだと改めて電話して有効にしてもらう必要があった. 電話して一日ぐらいしたら有効になるのでルータ等の電源を一度落として再起動し, IPv6関連の設定を行う. Sonetのトップページにある IPの表示やら kame.netの亀が見れるかを確認して問題ないことを確認する.

DS-Lite対応ルータにする

世の中 IPv6が主流であれば IPoEだけでいいのだろうが, 全然そんなことないのでごく一部のサイトを除くと全然恩恵を受けられない. IPv4のコンテンツを IPv4向けの回線で見ても元の通り遅いままなので, DS-Liteを使う. 元々使っていた前職で開発に関わっていた某社のメーカのルータでは対応していなかったので以下のルータを購入した(無線が 2日に一回ぐらい切れるのであまりよい印象ではないがすぐに購入できるかつ安いというのがそれほどなかった). 設定メニューで該当のものがなくて驚いたが IPv6アドレスを振ってしばらくしたら出てきた.

www.iodata.jp

参考

techlog.iij.ad.jp

blog.amedama.jp

macOS Sierraにアップグレードした際のメモ

今更手持ちの macOSSierraにアップグレードした. karabinerで IMEのトグルとキーリピートだけ変えていたので使えなくなってしまったので自分が行った対応のメモ

キーリピートの変更

知らなかったけど, コマンドライン経由であれば System Preference以上の設定にできるようである. 以下のリンクのもので十分だったのでそのままにした.

% defaults write -g InitialKeyRepeat -int 10 # normal minimum is 15 (225 ms)
% defaults write -g KeyRepeat -int 1 # normal minimum is 2 (30 ms)

apple.stackexchange.com

IMEの切り替え

今までは右 Commandを toggleキーとして使っていたがデフォルトの機能ではだいたいできなかった. 最近は仕事で Windowsを使うことが多々あり Windowsだと Alt + backtick(US配列のキーボード利用のため)で IME切り替えだったのでそれに近い形にした. System Preference -> Keyboard -> Shortcuts -> Input Sourcesの Select next input sourceCommand + backtickを割り当てることとした. 若干面倒くさいがそこまで日本語を打ちまくるわけでもないので十分だと思う.

おわりに

できれば macOS自身にもっとカスタマイズ機能をつけて欲しいところである

Visual Studio(C++)セットアップ

Visual StudioC++を書く際の設定メモ

メニュー等を英語にする

使い方を調べるときなど, Stackoverflow等を見るわけですが, 日本語だと圧倒的に情報が少ないので英語にする. やり方は英語の言語パッケージをインストールして使用言語を英語にすればよい. あと可能であるならば Windowsのシステム言語も英語系にした方がよいと思う. Visual Studio C++コンパイラの仕様でデフォルトのエンコーディングとしてシステム言語が使われるということがあり, CP932だとコンパイルできないソース(Chromiumソースコードとか)が極めて稀だがあった. まあ /utf-8フラグをつけることで対策はできるのでそこまで深刻ではないが…

エクステンション

Qiitaとかいろいろ見て試してみたけどほとんどしっくりこなかった. 最終的に入れたのは VsVimと後述の Reshaper C++のみ. キーバインドEmacsVimに慣れすぎてしまっているので, 十字キーだけでは辛くて, 何かしらの補助がないと欲しい. Vimバインドにしたのは干渉が少ないから. Emacs系だとどうしても IDEが元々提供するものとかぶってしまいうまくいかないから. VsVimは生粋の Vim使いの人はどう思うかわからないけど, かなりよくできている. Visual Studioの各種コマンドといい感じで強調して使えるのがよい. リファクタリング時等に自動でインサートモードに切り替えてくれるなどストレスがあまりない(IdeaVim等設定があるのかもしれないが, 変数の名前一括変換のときなど, nomalモードのままでいらいらすることが多々ある).

Reshaper C++

Visual StudioC++書く人は全員入れた方がいいと思った. 特に仕事でコード書く人は. 無料ではないが余裕でペイできると思う. 提供する機能(Search Everywhere)とかめちゃくちゃ便利なんだけど一番いいのは静的コード検査機能. まあこれは Reshaper C++がいいというのはもちろんなんだけど, Visual Studioが提供するものがしょぼすぎるというのが大きい. Visual Studioが提供する静的検査はめちゃくちゃ遅い上に精度も微妙. 全く使い物にならないってことはないけど, Xcodeの clangの静的解析に比べると質も速さも断然落ちる. あと意味不明な警告もいろいろ出る. 同じループなのになぜか一方だけメモリリークを指摘されるとか(実際はしていないのに). リアルタイムで指摘してくれる警告もデフォルトより大幅に増えるので, コードの質を高めるなら必須だと思います.

company-cmakeで大文字, 小文字を考慮した補完をする

company-cmake(標準)でディレクティブ(関数, キーワード等)を補完すると全部小文字になる. カーソル前の文字列(prefix)が大文字だろうと小文字に変換されてしまう. プロジェクトによっては大文字でディレクティブが書かれていることがあり, 補完後わざわざ upcaseとかしていたけどめんどいので prefixが大文字の場合は大文字に補完されるようにしてみた. コードは以下の通り. 本質的に直そうかと PRを書こうとしたが治す箇所が多いし, 今のところはこれで我慢する.

(defvar my/company-cmake-prefix nil)
(defun my/company-completion-started (unused)
  (let ((prefix (company-grab-symbol)))
    (setq my/company-cmake-prefix (and (not (string-empty-p prefix)) (string= prefix (upcase prefix))))))

(defun my/company-completion-finished (result)
  (when my/company-cmake-prefix
    (delete-char (- (length result)))
    (insert (upcase result))))

(defun my/cmake-mode-hook ()
  (add-hook 'company-completion-started-hook #'my/company-completion-started nil t)
  (add-hook 'company-completion-finished-hook #'my/company-completion-finished nil t))
(add-hook 'cmake-mode-hook #'my/cmake-mode-hook)