Zip標準に対するALZipの立場と哲学

■コンピュータ産業に置いて標準とは
1.Global標準とは
公益と標準化の為に設立された団体により開発/修正されながら管理する標準。
適法な手順により意義提起及び修正要請が可能な標準を意味する。
＊ISO（国際標準化機構）-ISO
＊IETF（国際インターネット標準化機構）-RFC

2.De facto標準とは
市場で多く使われて標準のようになったケース、ユーザの立場以外に市場の利益が反映される。標準の公開及び変更に対する権利並び義務が曖昧であり、変更事項に対する牽制及び意義提起が難しいのが実情。

■圧縮形式と圧縮アルゴリズム
実際データの圧縮を行うのが圧縮アルゴリズムであり、圧縮形式と圧縮アルゴリズムは別の機能を行います。圧縮アルゴリズムとは純粋にデータの量を減らすための機能のみ担当して、圧縮形式はアルゴリズムにより作成された圧縮データの格納方法を提示します。圧縮形式の中にはデータを解凍して原本ファイルとして復元するための、原本ファイルの属性情報とファイルコメント等の付加機能を提供するための情報が含まれます。一般的な圧縮形式では多数の圧縮アルゴリズムを選択して使用されています。

■ZIP形式と標準の問題
Zip形式は一般的にDeflate圧縮アルゴリズムを通じて圧縮されます。DeflateアルゴリズムはRFC-1951で管理されている国際標準です。しかしZip圧縮形式は特別な標準が存在せず、ただ原作者であるPKWareによるDe facto標準のみ存在します。

■ALZipとZip標準
Zip形式で主に使用されるDeflate圧縮アルゴリズムはRFC-1951で管理されている国際標準ですが。Zip形式は別途の国際標準が存在せず、原作者であるPKWareによるDe facto標準のみ存在する状況です。

PKWareはAppnoteという形で標準を管理していますが、2003年PKWareはAppnoteに公開せず、自社製品へのみ強力な暗号化機能を追加しました。これを非難していたWinzipは自社だけの暗号化方式を適用するようになりました。これによりZip形式には深刻な交換性の危機を向かうようになりました。
幸いに2004年両社間でお互いの方式を尊重し相互支援することに合意に至りましたが、この事件は今までもZip標準に置いて、協力な暗号化支援方式が2種類に分かれてしまう汚点を残すようになりました。

もしPKWareとWinzipの中で特定の会社が相手を牽制する力がなかったら、片方の一方的な勝利として終わったはずです。その理由はZip形式の標準がDefacto標準のみ存在したからです。
ここで両社が合意をした理由は何だったのでしょうか。両社は「ユーザの不便と混乱は即ちZip形式の没落を意味し、結局自社の損失を意味する」ことを熟知していたからです。

新しい方法や標準を作って追加するのは実際、簡単です。もし市場で絶対的な地位を持っていて、ユーザ数も確保している場合、それが実質的な標準になりえます。然しそれにより招かれるユーザの混乱と不便を回避することは簡単ではありません。

Zip形式は、今も持続的に拡張されています。しかし最初の設計当時の構造的な問題によりZip形式の拡張は下位交換性へ多くの問題を露呈しています。
ESTsoftのALZipは「下位交換性を最大限考慮してDe facto標準に従う」という哲学を持っています。全世界の有数のプログラムが新しい圧縮形式を発表するなかで、無条件的に新しい機能を支援しようとすると最新ALZipで作成したファイルが旧バージョンで解凍が出来ないようになることもあり得るのです。

これはユーザに多大な混乱を招くようになりますので、新しい圧縮形式を支援するには下位交換性を考慮して時間を持って長期的に進行していかなければなりません。

またZip形式は世界的に最も広く使われている形式であり、何よりも交換性が大事です。その交換性は単純に同一製品の下位バージョンとの交換性を超えて、業界全般に掛けて広く共有されている趨勢を反映しなければなりません。
ある圧縮ソフトが作成したファイルが他のソフトのユーザが解凍出来なければ、何の意味もありません。従ってALZipは世界どのような解凍ソフトウェアのユーザでも解凍できる交換性を持ったZipファイルのみ圧縮します。また、解凍に置いても標準に立脚して最大限反映できるように努力しております。そして交換性のイシューがあるか、既存形式では支援しない機能の要求事項は交換性イシューから多少自由な独自形式を通して解決するために努力しています。

【ZipのUnicode支援】
Zip形式は最初考案時、Unicodeに対する考慮が全然されておりませんでした。1991年Unicode協会からUnicode1.0が制定された以後、数多い圧縮ソフトウェア開発社は色んな方法を動員してZip形式内にUnicode形式のデータを保存させるため独自的な努力をしてきました。しかしその都度、業界からの呼応を得ず、独自的に自社が作ったファイルでのみ、Unicode形式で圧縮を解凍する形に留まっている状況でした。以後2006年9月PKWareは既存ファイル名の領域をUTF-8(Unicode)形式で保存する方法をAppnoteに追加しましたが、この事情を知らず公開されたプログラム及びまだ支援できないプログラムが誤動作する下位交換性を混乱させる方式でした。この方法が定着されない状況が続いて、業界では2008年の末ごろから少しずつ支援が始まっている状況です。然し今だにも数多い交換性のイシューが存在しています。ALZipではまだ日本で公開していない8.0beta1バージョンからその方式に対する解凍のみ支援しており、圧縮は下位バージョン交換性のイシューの問題で支援していない状況です。

【大容量ファイル支援】
Zip形式が最初開発された1986年当初はGiga Byteという単位は創造を遥かに超える単位だったので、当然、Giga Byte単位の圧縮は考慮されていませんでした。
Zip形式は基本的に4Byte単位でファイルのサイズとデータの位置を保存しているので、それお超える容量の保存が出来ない実情でした。然し時代が急変して大容量データが一般化されるようになってPKWareはZip64という新しい形式を発表するようになりました。しかし1Byteのデータでも節約しなければならない圧縮ファイルのと特性と各ソフトウェアの圧縮方式のと特性によりサイズと位置を8Byteで保存するZip64形式は当初数多い交換性の問題を引き起こしましたが2004年から業界で受け入れるようにあり、現在は殆どのソフトウェアがZip64形式の解凍を支援するようになりました。ALZipも2005年からZip64形式による大容量ファイルの解凍を支援しています。

【分割圧縮支援】
Zipの分割圧縮は2002年以前から既にPKWareにより公開されましたが、当時は支援するソフトウェアが殆どありませんでした。以後2002年末Winzipによる支援が始まりました。ALZipを初公開した1999年当初は分割Zipファイルは標準方法論がない状況でしたが、当時の遅いネットワーク等の問題でユーザからの分割に対する要求が多かったので、自社独自のALZ形式での分割機能を提供する様になりました。分割Zipの解凍は基本的に支援しております。

ALZipはユーザの圧縮解凍の基本的なニーズと先進的なニーズに答える為に日々
努力を重ねております。
皆様に使えるツールとして進化していけるように応援をお願い致します。

ALTools.jp