新しいアーカイバプラグインを開発するスレ

今、多数のアーカイバが統合アーカイバAPI仕様を元に作られていますが、
開発者と利用者の利便を考えると既に時代遅れで、使いやすいとは言えません。
なら、いっそ新しい仕様を造ってしまおうYo！という目的のスレです。

圧縮解凍ソフトいいのはどれ？ Part6
ttp://pc2.2ch.net/test/read.cgi/software/1043165952/
プロジェクトページ
ttp://hikoboshi-arcm.sourceforge.net/

詳細は＞2-5ぐらい

プロジェクト概要
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BAbout%5D%5D
API仕様(策定中)
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHPD_API%5D%5D
雑談
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BLounge%5D%5D

・Unix、Macの事情に詳しい方
・プログラムや文章を作ってもらえる方
・圧縮形式一覧を拡充してもらえる方
・その他、意見番さん(煽りは勘弁)
いつでもお待ちしております。おながいします。

FAQ
Ｑ．目的は？
アーカイバを扱う新しいプラグイン仕様の開発。
Ｑ．統合アーカイバとやること被ると思うが？
被りますが何か？
Ｑ．具体的には何をやってるの？
プロジェクトページをご覧ください。
Ｑ．ソース(もしくはバイナリ)はまだ？
仕様やら何やらが固まり次第書き出します。バイナリはﾏﾀｰﾘとお待ちください。
Ｑ．誰がやってるの？
(ここで言う)営農ギコでつ。よろしゅう。
Ｑ．そんなことより聞いてくれよ>>1よ(以下略
このスレか、プロジェクトページ各所に設けてあるフォームへどうぞ。

このプロジェクトに関連した話題以外は、各種圧縮スレへどうぞ。

人柱以外にはなんにも手伝えないけどおめ
焦らず良いもの作ってくらさい。期待しとります。

スレタイトル見てただの依頼スレだったらあーやってこうしてやろうと思ったのだが

>>1
板違い
そういうことはプログラム板でやろうね

そう言えば肝心なところでｗ
もぅ、お茶目なんだから♥

>>7
この板でもプロジェクトやってるスレはあるので。
ユーザ側の意見を伺うには、こちらが良いと判断した次第。

もちろん、ム板とかLinux板とかにも（スレは立てないものの）色々と
伺ってみようかと。

あ、もちろん細かい開発などの話はプロジェクトページの方をメインにヨロです。
こちらはテスト版提供とか、全般的な要望が中心つことで。

激しく着たい

ネタ振ってくらはい。

テスターはアーカイバの作者が対象だよね？
具体的にどんな機能つけるの？

>>13
別にアーカイバ作者ではなくても( ﾟДﾟ)ｳﾏｰ
アーカイバDLL経由せずにやりたいもんで、互換性とか検証してくれる方はやぱ必要。

機能としては、普通に圧縮解凍その他を、なるべくシンプルにするべく考えてます。

非常に期待しています。
統合アーカイバ＋αレベルではなく、世界標準を目指して欲しい。

情報むしりとって、その挙句シェアウェアにするんだろ？

朝っぱらから妄想の華やかな人が。

>>16
しっかり読んでね。

>>16

「修行中のアマグラマーである漏れは、シェアウェアなど作る資格なし。」
・・・と思ってまつよ(笑

もちろん、ここで作った物はできる限りソース付きのフリーソフトにします。

rarや7zを扱えるDLLは出来るの？
それが無ければはっきり言って使えない。

7zはオープンソースだから問題ないでしょ。
rarは圧縮は無理。解凍はどうだろ。

>>21
解凍はなんとかなると思う。
圧縮も、内部で rar.exe を呼び出す方法で実現可能。UNIX でも同じ。

要するに今までと同じって事ですね。

>>22
rar.exe を呼び出すって、結局コマンドラインを送るって事？
それじゃ、統合アーカイバとやることいっしょじゃん。
ってことは統合アーカイバに皮をかぶせるだけでOKってことになるけど。
7zは7-Zip自体UNIXに対応してないけどできるのかな？

とりあえず物がでるのを待とうぜ

結局lzhとかzip以外は統合アーカイバのラッパで終わりそうなﾖｶﾝ。
まぁ、それでも使いやすくなるならいいけど。

>>24
シェアウェアとかの影響で、内部で扱えない場合は、その方法しか無かったりする。
でも統合の方とはやってることが違うと思う。

7zは・・・ソース見る限り、激しくWindows(・∀・；)
UNIXに移植するとなると大変っぽい。

>>26
ラッパは(やむを得ない場合を除き)なるべく避けたい。

これってユーザが使いやすくなる云々の次元ではなく
・マルチプラットホーム
・共通仕様
というところに重点があるというだけで、あんま長所は無いかも。
強いて言えば設定が容易になるくらいかな。

エンドユーザーにとってのメリットはｳﾆｺｰﾄﾞ対応ぐらい。

作者さん達には結構大きなメリットがあると思うので期待してますが。

新Deaces作成中NAOさんも巻き込んでみると面白くなりそうかな（野次馬）。

LHAのおっさんもキボンヌ

>>29
ウニコードにするとどんな良い事があるの？

>>31
ファイル名

ファイル名ってアーカイバに格納するファイル名のこと？
それだったら7zのように圧縮形式自体がunicodeで格納する仕様じゃなければ
一般のアーカイバで解凍できなくなって激しく迷惑なんですけど。

そんな話なのか？

DLL内の文字処理でunicode使うってのならエンドユーザにはほとんど恩恵ないし。
処理内容によるがむしろ文字コード変換のために余計時間がかかるかも。
unicode版でビルドするなら速くなるだろうが、その場合win9x系で使えなくなるしな。

って、良く見たら>33でアーカイバとアーカイブ（書庫）間違えてた。

WinRARなんかはunicodeファイル名は無理やりs-jis変換して格納するね
このあたりは各アーカイバで仕様が違ってくると思うので対応が難しいと思う
対応できたとしてもそのアーカイバでしか利用できないアーカイブができてしまう

>>35
Windowsでunicodeファイル名が作れる以上、もうunicodeに対応するしかない。
ユーザが作ったファイルを扱えないアーカイバなんて、これから先許されないと思う。
XP,2000は内部的にもunicodeベース。
速度も裏でSJISにコード変換しているほうが時間がかかる。素直にunicodeを使った方がいい。
ビルドに関してはアプリはW系とA系のAPIをラップすればいいとおもう。
少なくともSJISに拘っていたら、世界標準にはなれない。

>>37
うん、漏れも実は同意見だよ

でもなぁ、他のアーカイバで解凍できないアーカイブができちゃうんだし
いくら『世界標準』だっていっても実際には殆どのアーカイバで解凍でき
ないのが現状なんだしなぁ・・・ま、SYNさんと同じ考えではあるんですが・・・

＃unicodeファイル名が格納されているLHA書庫って不気味でちょっと面白い

>>37
すでにファイル名がUnicodeで格納されるのを想定して作られてる形式・・・
（たとえば7z。rar3.xもそうだっけ？）を扱う場合は 当然アーカイバ側も
Unicodeで処理するべき、というのなら激しく同意。

あるいは、今後作られる書庫形式（DGCAとかね）がUnicodeファイル名を
扱えないなんてのは許されん、というのも猛烈に同意。64bitのファイル
サイズとか日時管理、についても同じことが言えると思う。

けど、既存のlzhとかzipとかを扱う統合ライブラリを作る（>>1さんが
考えてるのはとりあえずはこれだよね？）、ってんなら要するに今存在する
他のアーカイバでは解凍できない書庫を作成してしまおう、ってことに
なるわけだから、これは賛成できない。euc-jpとsjisですら混乱してるのに
余計わけがわからなくなるだけだろうから。

---

SYNさんの構想としては、古い書庫形式との互換性とかは切ってしまって、
これからの時代にあったunicode/64bitなフォーマットを統一的に
扱えるAPIを設計しよう、ということ？
その辺はっきりしないせいで混乱を呼んでるような気がする。

>>40
ちょっと混乱あったかなぁ？
LZHやらRARやら、ファイル名を Shift-JIS で格納するものについてはShift-JIS に
変換して格納するつもり。無理に Unicode にして互換性を無くしたくない。

そのような形式だと、少々速度は落ちそうだし、一部文字の欠落も考えられるが。

・・と書くと、プラグインを作る側で大変かと思うが、その辺は補助ライブラリで
文字コード変換のための関数を用意するつもり。

>>35
ちなみに、Win95 以降なら普通に Unicode とか W 系関数は扱えたような。
ただ、UNIX 側の事情はまだ調査中。

>>37
＞Windowsでunicodeファイル名が作れる以上、もうunicodeに対応するしかない。
たしか9xは扱う事が出来なかったはず。
＞XP,2000は内部的にもunicodeベース
NT系のみで考えるのであれば確かに速くなる、が、9x系も考えると遅くなる。
と言う訳で9x系は捨てNT系だけに絞るのというのであればそれもアリかとはと思う。
9x系の人は既存の奴でも使ってくれと言う事で。(個人的にそれは嫌だが）
しかしlha等のunicodeでファイル名を格納する事を考えていない形式に
無理矢理unicodeで突っ込むとか言うのは不正書庫を生むだけなので論外。

>>41
W 系関数は扱えないです。

>>39
>＃unicodeファイル名が格納されているLHA書庫って不気味でちょっと面白い
LHAでは日本語ファイル名は ShiftJIS使うのは仕様で決まっているので、単なる不正書庫ですね。

>>37
Unicode はベンダ毎に一部文字の割り当てが違ったりしてるので
逆にユーザに混乱を与えるかもしれません。

日本以外でもこーゆー事が起こっているのかは知らないですが。

>>43
そぉ？

ﾏｼﾞで最初のWin95(Kernel32.dll)
...
0154 0003541c CreateDirectoryW
0155 000073f1 CreateEventA
0156 00035452 CreateEventW
0157 00007893 CreateFileA
0158 00007479 CreateFileMappingA
0159 00035476 CreateFileMappingW
0160 00035488 CreateFileW
...

普通に関数名あるのだが。
ただ、使えるかどうかは試してない。

LHAは和製なのでShiftJISでいいと思う。
っつーか作者のおっさんが決めることだと思われ。

>>45
細かい問題だなぁ・・・　(・∀・；)
どうすりゃいい？できれば標準仕様の Unicode に沿いたいが・・。

>>47
・・・でいい、というか、Shift-JIS「 じゃなきゃ」混乱するという見解。

ま、拡張ヘッダで Unicode ファイル名を入れることは可能だけどね。
そのうち Unlha32.dll の作者さんが実装するかもしれんし。

別にユーザーに直接的なメリットはほとんどない、ってんでも
作者さん等にメリットがあるなら一向に構いません。

>>42
つか、MSDNにはっきり書いてあった・・・。(；´Д｀)
>Windows95 では Unicode 規格をサポートしていません。

API を避ける方法をとるにしても、Win95 のサポートは大変そー。

＃98以降なら( ﾟДﾟ)ｳﾏｰということが言える。

Win95はサポート終わってるし、Meも今年でサポート終了。
NT系推奨で9xでは多少速度落ちるって感じでも構わないと思う。

>>48
>ま、拡張ヘッダで Unicode ファイル名を入れることは可能だけどね。
で、非互換の問題が増える、と。
個人的には、LHAみたいな「枯れた」と思われている形式に
わざわざトラブルの種になるような拡張をして欲しくないです。
UNLHA32.DLL の作者さんが同じ意見かどうかは知らないけど。

もし互換性とろうとすると、結局 ShiftJIS のファイル名入れなきゃいかんし。

俺の言いたいことみんなが書いてくれちゃってる

>>52
いくらLHAがかれた存在でもシェアはGCAより遥か上なんだよね

>>52
僕は LHA 形式の拡張はするつもりはありません。一応。

ただでさえ LHA は拡張ヘッダのカタマリだし。いじりたくない(w

俺は何だかんだ言ってソフト配布しる時はLZHだったなぁ。

規格がunicode+64bitにしようというだけで、実際に書庫内でどういうデータになっているかは
関係ないのではないでしょうか。
別に書庫が架空の文字コードを持っていても、受け渡しでunicodeにすればOKだと思います。
扱えないファイル名を受け取ったら、現状のようにエラーを返せば良いわけで、
過去の形式を拡張する必要は全く無いと、個人的には思います。

おまえらがあーだこーだいてる間に完成させちまいますた

と一度言ってみたかったんです。

>>50
MSDNのWindows95ってWindows9x系のOSを指すんじゃないかな？
だから98もMeもダメだと思う。試してないからわからないけど･･･。
つーか、マルチプラットホームを目指すならWin32APIを使うのは無しでしょ。

>>59
だからラッパーを使って各OSに対応するようにするんでしょ。
第一、ファイル処理回りはAPIを使うかか処理系依存の関数使うかの
2択しかないはずだが｡
（Cにはファイル移動・削除関数がないし）

>>54
吉崎さん、多忙で開発がストップしているのだし、この際、統合アーカイバ作者
とも皆で話し合って拡張ヘッダの仕様を決めれば良いのでは？
昔のNifty FLABOみたいに

＃ でも面倒そう(無理があるかも)＜unicode

>>59
となると、真に Unicode のファイル名が扱えるのは NT 系のみ、ということか・・。

ま、どっちにしてもWin32のfopen()系関数じゃ4GB超えのファイルサイズは
扱えないみたいだし、ラッパーは必須かと。
＃Unixだと、libcのfopen64()系でなんとかなる・・・のか？(汗

>>61
Unlha32.dll の作者さんに相談すればなんとかなりそうなのだが。

>>62
ためしに統合アーカイバの開発系MLで提案してみたら？
ttp://www.csdinc.co.jp/archiver/dev/ml.html

>>60
あれ？renameやremoveってCじゃ無かったけ？
確かコピーは無かったと思うけど･･･。
いまいち純粋なCは分かってなかったりする。
ただ、これらもユニコードは使えないんだよなー。
VC++なら_tremoveでいけるけど。

>>64
ごめん、調べたらあったわ｡
ないのはディレクトリ周りの関数だっけな？　←自信がなくなってきた

Win9x の Unicode 対応だけど、これを使えば可能っぽい。
ttp://download.microsoft.com/download/platformsdk/Redist/1.0/W9XMe/EN-US/unicows.exe

つことで、ファイル周りの関数を実装中。
しかし、Win はいいが Linux 辺りはどう対応すべきか。
Glibc がそのまんま Unicode 対応なら楽なのだが。

LHA拡張ヘッダの仕様を統合アーカイバの開発系MLで提案しる

>>67
やりたきゃ自分でやれば良いのに…

正直LHAの拡張仕様は(ﾟ�听)ｲﾗﾈ


つーかヤメレ

>>69
不可能なことは無いし、互換性がなくなることは無い(拡張ヘッダにまだ空きある)。

で、>>67さん、提案して(　ﾟдﾟ)ﾎｽｨ。

>>70
きちんとした提案があれば他のアーカイバも従うのではないかと思うのであるがなぁ

>>69
漏れは全体の事を考えて発言している

>>71
>他のアーカイバも従う
・・・のか？

対応済：7Z
言えば対応できそう；LZH
苦労かも：ARJ、ZIP、TAR、・・・
無理ぽ：ISH、CAB、・・・

統合の方で、仕様拡張の融通が利くのは Unlha32.dll ぐらいだと思う。

LHAにunicodeが欲しい。Unlha32.dllにも働きかけてくらさい
64ビットタイムスタンプとファイルサイズ拡張ヘッダはUNLHA32.DLLの
拡張ヘッダ仕様に従えばいいんだし

まぁ、全体のことを考えてても他力本願なことしか言わないんでは意味はなかろ

要望だったのだが

CABは某社のお気に入りだからね。

>>69
公開MLで潰しておいたほうが安全では？

>>77
とか言われると提案しにくいなぁ(・∀・；)

さぁ！労農ギコ氏が漢を上げられるかどうか！非常に見物です！ｗ


ま、多少強引に行っちゃっても大丈夫なんでない？

女の子はリードしてくれる男の人が好きです。

でもレイプは嫌いです。

UnicodeはUTF-8使うって書いて有るけど
NTの内部はUTF-16LEじゃなかったでしたっけ？

>>82
UCS-2だと思ったけど、サロゲートペアに対応していたっけ？
まぁ、どっちでもいいのだけど、UTF-8へのコンバートは軽いし、
UTF-8の方が過去の文字列処理の資産が利用できるので、いろいろと楽ですし、
ASCII文字(7bit)だけを使っている人は、特に何も考えずにUTF-8へ対応できるので、
有利な面が多いと思います。

>>83
内部はどうか知らないですけど、少なくともAPIに渡す文字はワイド文字じゃないと。
その度にわざわざ変換させるつもりなのかな？
それともそのまま突っ込んでも問題なく動作するのか。
それにマルチバイト文字とワイド文字の変換なら
nkf使わずともmbtowcやらwcstombsで一発で出来るし。
ま、どっちにしろ文字変換にかかる負荷など
圧縮・解凍の負荷に比べたら無視できるレベルのもんですけど。

っつか、そんなに Unicode 使いたいなら .NET やら Java やら使えば…

>>84
マルチバイト文字⇔ワイド文字の変換はテーブルも必要で、かなりのコストがかかりますが、
UTF-8⇔UCS-2の変換はテーブル不要で負荷はほとんど無視できます。
文字列処理に関しては、APIに渡す時だけワイド文字にしてでも、
それ以外はUTF-8を使ってASCII感覚で処理する方が楽だと思います。
本当ならOSでUTF-8をサポートすべきだと思いますけどね。A系、W系、U系とあると嬉しい。
自分はWinAPIにU系のラッパを用意して、OSによってA系とW系を呼び出すようにしています。

>>86
>それ以外はUTF-8を使ってASCII感覚で処理する方が楽だと思います。
扱うんだったら UCS-2 のが楽じゃないの？
ASCII 感覚ってのが具体的に何のこと言ってるのか良くわからんけど。

>>87
まぁ確かに何を楽と思うかは人それぞれですし、UCS-2の方が楽な人もいるとは思います。
ただ、ソースコードを含む、あらゆるテキストを世界で何かに統一するとしたら、UTF-8が良いとは思いませんか？
ASCII文字で書かれた物は既にUTF-8にもなっているわけですし。

この新しいアーカイバプラグインの登場によって、統合アーカイバDLLも
刺激され、お互い良い意味で発展すると面白い
個人的にはLHAの昔からのファンなのでＭｉｃｃｏ氏にも奮起して頂いて
unicode対応、あと、幻だったLevel3ヘッダ形式に対応したりするとますます
面白いのだけどなぁ。新形式でlh8なんかも対応しちゃったりして

>>88
いや、テキストを保存する訳じゃないしそんな例えは全く見当違いかと。
それからAPIに渡す時だけワイド文字にしてってのもAPIが使われるのは1度だけじゃないんですよ。
あらゆる場所で使われる訳ですしいくら負荷が軽いといっても積もれば山ですよ。
それにDLLを使う側から見ればファイル名とかをUTF-8なんかで返されたら
自分たちも変換しなくちゃ使うことが出来やしない。
DLL使う側にもnkf使わす気ですか。扱いにくくしてどうするんですか。
ついでにASCII文字しか使わない人はそりゃいいかもしれませんが
だからと言ってマルチバイトの事を無視する事は出来ないです。
マルチバイトのことを考えてない海外製のソフトはたくさんありますがあれと同じですよ。

>>85
そうですねぇ、.NET使うのが一番手っ取り早いかも。
これならマルチプラットホームの対応もデフォですし。

>>90
ファイル名処理をテキスト処理の一部と見なすか否かという違いではないでしょうか。＞見当違い
USC2⇔UTF8は変換といっても数行のコードを書くだけですし、
負荷も引数のキャストと思えば、気にするほどではないでしょう。
それを気にするなら、現状の裏のSJIS⇔UCS2変換コストの方が遥かに重いです。
また世界では、ASCII文字しか考えていない人が多いという実情は変えようが無いです。
国産でもSJIS以外のマルチバイトのことを考えている人がどれだけいるでしょうか？
あと、ワイド文字の場合、将来U+110000以降の文字が出て来た時にどうするのですか？

>>89
Level 3 ヘッダは UNLHA32.DLL で実装されていますし、
-lh8- も既に使われていますね。

>>91
>あと、ワイド文字の場合、将来U+110000以降の文字が出て来た時にどうするのですか？
WindowsAPI 等と歩調を合わせて変更していけばよいのでは？

それに U+110000 まででもファイル名に使う文字集合としては十分な気がします。

>>92
そうなの？ やっぱりさすがだなぁ・・・。

案外、unicodeなんかも既に拡張ヘッダで対応しているのかも・・・。
コメントアウトされていたりして。

>>94
あー… 誤解されると困るので一応補足。

>>92 に書いたのは Level 3 ヘッダは幻でもなんでもなく、
-lh8- も既に誰かが使っちゃってるので今更使えない、って意味です。

なんか既に役者が揃っているような予感がしますが・・・
unicode対応に向けてのLHA拡張ヘッダ仕様をここで一気に決めちゃったら(笑)

>>91
文字の保存コードがどうのこうのは単純に内部処理と置き換えられるものじゃないですよ。
で、USC2⇔UTF8は変換はキャストと思えばいいってキャストと比べれば遥かに重いですし
キャストを多用するプログラムなんて決してよい物だとは思えません。
それからSJIS⇔UCS2変換を問題にするのならSJIS⇔UTF8変換を問題にしないのは変では？
次にマルチバイトを考えない人が居るからこそワイド文字を使おうってんじゃないですか。
ワイド文字なら考える必要も無く対応できます。

結局UTF-8は標準から外れ混乱とプログラムの複雑化と速度低下を引き起こし
ユーザの利便性を下げるものでしかないとおもわれ。
利点としてはACSCIIしか使わない極一部の人がそのまま移行できるのと
将来Windowsの仕様が大きく変わらなければ使うことが出来ない
U+110000以降の文字が扱えるといったとこぐらいかな？

ファイルに保存する文字コードはUTF-8をってのならまだ分かりますがね。

64Bit&Unicode(8か16かは未定)対応なファイル処理ライブラリを書いてるとこでつ。
しかし、実際にUTFの問題とか・・・ややこしぃ。

>>82
そだったかな、つことでMSDN見てみたけどやっぱUTF-16っぽい。

>>85
それじゃあ面白ない。

>>86
W系の扱いが謎なんすよね。
_UNICODE定義してればUnicodeになるんだけど、じゃないとMBCS。
まぁ、今回MBCSは使わない方針ですが。

Win9xでは、Microsoft Layer for Unicode(unicows.dll)使って楽すべきかどうか。

>>95
誰か使ってるのか・・。て誰？LHA32？

LHAのおにいさん降臨(･∀･)ﾏﾀﾞｰ?

>>98
Unicodeについていろいろ書こうかと思ったけど
DBCS使うとの事なのでもう止めときます。
でも.NET Frameworkは選択肢の1つとして考慮したほうがいいかと思います。
7-Zipなんかも今後.NETで他のプラットフォームに対応させるそうだとか。

>>97
>それからSJIS⇔UCS2変換を問題にするのならSJIS⇔UTF8変換を問題にしないのは変では？

問題にするというより、現状のXPや2000でマルチバイトを使っている時は気にしてないのなら、
UCS2⇔UTF8は負荷として気にする必要がないということです。SJIS⇔UTF8については、
2000やXPではそんな変換パスは不要です。それに、この規格が広まる頃にはWin9x系は
絶滅していると思います。
とはいえ、おっしゃるとおりのワイド文字の方のメリットを考えるのなら、この規格はワイド
文字(UTF16orUCS2)にした方がいいでしょうね。ただ私個人はそれが理解できないので、
余計な事を言って混乱させないためにもここは引いて見守るだけにします。

この際後方互換を諦めるのも手なのかもね。ME使ってる人間が言うのもなんだけど。

とりあえず SJIS/EUC⇔UTF-8⇔UTF-16 の変換関数は用意しようかと。
もうわけわからんというのが本音なんですが、対応しなきゃ先に進めないもんで。

>>100
>.NET Frameworkは選択肢の1つ
なるほど。

といっても、統合の方で出た話題なんですが、Win32 DLLの状態では.NETに
対応することは難しいようです。
COMでラッパー書けばいいようですが、色々と制約あるようで。

>>100さん、V?.NETでのプログラム書けます？
漏れは.NET方面はあまり知識ないもんで(；´Д｀)