Unicodeファイル名の読み込みに対応しました。 差分 読み書きの動作確認が出来たところで、Hamigaki.Charsetで実装したコードページの変換処理も組み込みました。 差分 UNLHA32.DLLのドキュメントを見ると、レベル1ヘッダはUnicodeとコードページに対応して…

LHAのファイル名出力をHamigaki.Charsetを使って書き直しました。 差分 まだコードページはCP_ACPのままで、ヘッダに入っている値は使ってません。要修正。 UTF-16出力部分がsizeof(wchar_t)==4の環境でバグっていた(というかUCS-2を想定していた)ので別途作…

Unicodeファイル名の出力がバグってたので修正しました。 差分 動作確認用にUnicode版の簡易アーカイバも作りました。 wlha.cpp LHMeltで確認した限り、うまくいっているようです。 とりあえずWindowsでは動いてますが、それ以外では問題ありです。 Windows…

Unicodeファイル名の書き出しを実装してみました。 差分 古いテスト(ナロー版)は通っていますが、ワイド版はまだコンパイル通しただけです。 ヘッダの構造体はlha::basic_header<Path>に変わっていて、headerとwheaderのtypedefを追加しています。 あと、ワイド版</path>…

Unicode ファイル名ヘッダ(0x44)を使う場合も、ファイル名ヘッダ(0x01)は必須 UNLHA32.DLLは変換できない文字はアンダーバーに置換する 結果、ファイル名が重複することがあり、Unicodeヘッダ未対応のアーカイバだと上書きされることがある

今日からHamigaki.Archiversのwpath対応に移ります。 まずはUnicodeに対応しているのが分かっているLHAから考えます。 UNLHA32.DLLのドキュメントを読む限り、Unicodeファイル名を出力する方法は次の３つのようです。 マルチバイト文字列で表現できない場合…

ZIPに続き、LZHも4GB超ファイルに対応しました。 raw_lzh_file_sink_impl.hppの差分 実際には随分前に4GB対応したつもりだったのですが、ディスク容量の都合でテストできず、バグったままになっていました。 試してみると、ヘッダの内容が同じであるにも関わ…

LZHヘッダの処理を手直ししていてバグを見つけました。 raw_lzh_file_sink_impl.hppの差分 raw_lzh_file_source_impl.hppの差分 LZHファイルは終端に1バイトのヌル文字(エンドマーク)を使います。 逆に言えば、ヘッダの1バイト目はヌル文字であってはいけま…

LZHファイルの追記サンプルを作成しました。 append_lha.cpp lhaサンプルとほぼ同じですが、初期化の部分だけ違います。 io_ex::file_sink file; try { // 読み書き(truncなし)でオープンを試みる file.open(argv[1], std::ios_base::binary|std::ios_base::…

Level1ヘッダの出力も実装しました。 raw_lzh_file_sink_impl.hppの差分 圧縮/解凍のサンプルも移行完了でバッチリ、と思ったんですが、Cygwinでコンパイルエラー。 namespace hamigaki { namespace archivers { namespace lha { namespace unix { struct gi…

Hamigaki.Archiversにファイルをコピーして、Level0ヘッダの出力を実装しました。 lha::headerに追加したフィールドlevelでヘッダの形式を選択できます。 raw_lzh_file_sink_impl.hpp Hamigaki.Iostreamsからの移行途中なので、古い実装も残っています。 ま…

lzh_file.hppをraw_lzh_file.hppに分離して、シンボリックリンクをサポートしました。 <hamigaki/iostreams/device/raw_lzh_file.hpp> lzh_file.hppの差分 シンボリックリンクの実装方法は、 http://www2m.biglobe.ne.jp/~dolphin/lha/lha-slink.htm を参考にしました。 $ ls -l total 1 -rw-r--r-- 1 ham</hamigaki/iostreams/device/raw_lzh_file.hpp>…

テストコードが間違っていて、テストをすり抜けていたlazy matchingのバグを修正しました。 lazy matchingの修正差分 テストに使用した文字列の初期化で、 std::string(4096+1, 'a')が、 std::string('a', 4096+1)になっていました。 これ、よく間違えます。…

lazy matchingを実装しました。 sliding_window.hppの差分 lazy matchingというのは、スライド辞書から一致文字列を検索した後にすぐに出力しないで、次の位置での一致文字列を検索してみてから長くなるほうを選択する手法のことです。 例えば、「ababcbabab…

圧縮アルゴリズムの多くは圧縮がかからなかった場合に非圧縮で書き出すモードを持っています。 zlibのdeflateアルゴリズムなどは(アーカイバとしての機能がないことから当然)一定のブロック単位で圧縮/非圧縮の切り替えができます。 このため、メモリ上で入…

予定通りlzh_file_sinkが出来ました。 lzh_file.hppの差分 Level2ヘッダ固定で、まだ必要最低限の拡張ヘッダしかサポートしていません。 使い方はこんな感じです。 #include <hamigaki/iostreams/device/lzh_file.hpp> #include <boost/filesystem/convenience.hpp> #include <boost/filesystem/operations.hpp> #include <boost/iostreams/copy.hpp> #include <clocale> namespace io_e…</clocale></boost/iostreams/copy.hpp></boost/filesystem/operations.hpp></boost/filesystem/convenience.hpp></hamigaki/iostreams/device/lzh_file.hpp>

lzhuff_compressorができました。 <hamigaki/iostreams/filter/lzhuff.hpp> テストコード 基本的にこれまでのクラスを繋げるだけなんですが、1点新しい発見がありました。 template<class Sink> boost::iostreams::composite< boost::reference_wrapper<lzhuff_output_impl>, boost::reference_wrapper<Sink> > make_impl(Sink& sink) { re</sink></lzhuff_output_impl></class></hamigaki/iostreams/filter/lzhuff.hpp>…

昨日探していたLZSSの派生バージョンの名前ですが、「modified LZSS」(変形LZSS)と呼んでいる人がいたので、これを採用しました。(modifiedなんたらの例に漏れず、多分いろんなmodified LZSSがあるとは思います。) <hamigaki/iostreams/filter/modified_lzss.hpp> 変形LZSSだとSourceのEOFとビットストリー</hamigaki/iostreams/filter/modified_lzss.hpp>…

一応huffman_encoderができました。 huffman.hppの差分 まとめるつもりが昨日のグダグダコードのままです。 微妙にコンパイルエラーはありましたが、アルゴリズムはあっていたようで、一発で動きました。 追加したテスト さてLZSSとハフマンができたのでこれ…

LZSSの高速化はおいといて、ハフマン符号化の実装に入りました。 何度も書いてますが、LHAで使われているのは長さ制限付きのCanonical Huffman Codeなので、通常のハフマンより少し複雑です。 以下、まだ作りかけなのでバグっているかもしれません。

sliding_window_compressを作りました。 特許に引っかかるとマズいので、一致文字列の検索はとりえず単純な検索(通称:バカサーチ)で実装しています。 sliding_window.hppの差分 また、スライド辞書のテスト用にLZSSのラッパーを用意しました。 <hamigaki/iostreams/filter/lzss.hpp> テストコード</hamigaki/iostreams/filter/lzss.hpp>…

lh6/7対応といいつつ全然テストしてなかったので、試してみたら案の定動きませんでした。 lh6/7だとスライド辞書のサイズが大きくなっている分、一致位置のビット長のハフマンテーブルが大きくなっているようです。 lzhuff.hppの差分 手元の適当な書庫で試し…

どうもプロファイリングのやり方がマズかったようです。 VC++でもg++でも似た傾向になるだろうと考えていたのですが、Cygwin/MinGWのSjLj例外処理が非常に遅く、プログラム全体のパフォーマンスを低下させていました。 特にCygwinの場合は異常に遅いです。お…

既にLHAとはほとんど関係なくなってますが、プロファイルをとるときに-O2を指定していなかったので、もう一度。 % cumulative self self total time seconds seconds calls s/call s/call name 46.93 12.54 12.54 _Unwind_SjLj_Register 22.75 18.62 6.08 _U…

真面目にハフマンツリーを作成するようにしました。 huffman.hppの差分 ツリーの作成に時間がかかりそうで避けていたのですが、参照回数の方が圧倒的に多いため、かなり速くなりました。 この状態でgprofの結果はこうです。 Each sample counts as 0.01 seco…

ようやくLZHデコード処理を組み込みました。 対応ヘッダはLevel 0〜2で、圧縮方法はlh4〜lh7をサポートしています。 <hamigaki/iostreams/filter/sliding_window.hpp> <hamigaki/iostreams/filter/lzhuff.hpp> lzh_file.hppの差分 性能を測るため、23MBの適当なLZHファイルの展開速度を計測してみました。 ツール 時間 UNLHA32.DLL 5秒 lzh_file_so</hamigaki/iostreams/filter/lzhuff.hpp></hamigaki/iostreams/filter/sliding_window.hpp>…

既にご存知の方も多いと思いますが、gzipに複数の脆弱性が見つかっています。 http://oku.edu.mie-u.ac.jp/~okumura/blog/node/1047 修正パッチを確認したところ、自分のハフマンデコード処理にも同様の問題があったので修正しました。 huffman.hppの差分 テ…

一応、LZSSの展開までできましたが、インタフェースをどうするかで迷っています。 今のところ、インタフェースはこうなっています。 template<class Input> class sliding_window_decompressor { public: typedef char char_type; struct category : public boost::iostre</class>…

ハフマンデコーダができました。 <hamigaki/iostreams/utility/huffman.hpp> huffman_decoderはこんな感じのクラスです。 template< class Value, // 符号化前の値の型 std::size_t Bits // 符号長 > class huffman_decoder { public: typedef typename boost::uint_t<Bits>::least code_type; typedef Valu</bits></hamigaki/iostreams/utility/huffman.hpp>…

LHAがLZSSとハフマン符号化を使っていることは有名ですが、自分は今までこの２つをどう繋ぐのか知りませんでした。 ようやく理解できたのでまとめておきます。 LZSSの出力は、 (0、不一致記号) (1、一致位置、一致長) のいずれかですが、LHAのLZHUFアルゴリ…