問題タブ [compression]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
9 に答える
136937 参照

apache - Apacheが提供するテキストファイルにgzipの代わりにdeflateを使用するのはなぜですか?

LAMPサーバーによって提供されるhtml、css、およびjavascriptファイルに対してどちらの方法でもどのような利点がありますか。より良い選択肢はありますか?

サーバーはJsonを使用してマップアプリケーションに情報を提供するため、大量の小さなファイルがあります。

http圧縮のためにdeflateよりもgzipを選択することに関連するパフォーマンスへの影響はありますか?も参照してください。

0 投票する
6 に答える
4015 参照

networking - リアルタイム マルチプレイヤー ゲーム (コンセプトの質問)

マルチプレイヤー システムのアーキテクチャを説明しているように見える、Valve のこの記事を読んでいます。ドロップされたパケットを処理できるように、クライアントでレンダリングを数ティック遅らせているようですが、パケットを「デルタスナップショット」(隣接する 2 つの状態の差) として送信することもあります。

時間 A、B、C があり、クライアントが時間 A では正しいが、B でパケットをドロップし、C でパケットを受信するとします。時間 C での状態を正しく推定するにはどうすればよいでしょうか? C のパケットは状態 B と C の間のデルタのみを伝え (私が思うに)、クライアントは A の状態しか知りません。ここで何が欠けているのでしょうか?

0 投票する
3 に答える
3197 参照

visual-studio-2008 - WiX で生成された MSI は圧縮されていません

WiX3 を使用して MSI インストール パッケージを生成します。<Package>要素と<Media>要素の両方で圧縮フラグを指定しました。

しかし、結果の MSI はまったく圧縮されません。WinZip はそれを 2M から 600K に圧縮しました。

何か不足していますか?

私はVS2008を使用しています。

0 投票する
7 に答える
15545 参照

json - JSON エンコードされたパケットの圧縮アルゴリズム?

ネットワーク経由でパケットを送信する前に、パケットを圧縮するために使用する最適な圧縮アルゴリズムは何ですか? パケットは JSON を使用してエンコードされます。LZWはこれに適していますか、それとももっと良いものがありますか?

0 投票する
8 に答える
8327 参照

delphi - Delphi で複数のファイルを 1 つのアーカイブに圧縮するにはどうすればよいですか

Delphi を使用して、複数のファイルを 1 つのアーカイブに圧縮する必要があります。私は非常に安価なので、フリーウェア コンポーネントまたはオープン ソース コンポーネントを使用することを好みます :-)

私の主な要件は次のとおりです。

  1. アーカイブの暗号化が可能
  2. WinZip のコピーがあれば誰でも開くことができる共通のアーカイブを作成できます

使用したコンポーネントに関する提案はありますか? 無料および商用のコンポーネント/ライブラリを自由に提案してください。

0 投票する
11 に答える
11443 参照

iphone - iPhoneのsqlite3データベースのサイズを縮小するには?

編集:すべての回答に感謝します。これまでの最適化を適用した後の結果は次のとおりです。

  • 文字のソートとランレングス エンコーディングへの切り替え - 新しい DB サイズ 42M
  • ブール値のインデックスを削除 - 新しい DB サイズ 33M

本当に素晴らしいのは、iPhone のコードを変更する必要がないことです。

sqlite 形式 (読み取り専用) で保持されている大きな辞書を持つ iPhone アプリケーションがあります。現在非常に大きい DB ファイルのサイズを小さくするためのアイデアを探しています。

sqlite DB のエントリ数と結果のサイズは次のとおりです。

...エントリあたり平均約 135 バイト。

ここに私のDBスキーマがあります:

サンプルデータは次のとおりです。

最後のフィールドは、アナグラム検索の文字頻度を表します (各位置は 0..9 の範囲にあります)。2 つのブール値はサブディクショナリを表します。

次のようなクエリを実行する必要があります。

私が持っている 1 つのアイデアは、文字の頻度をより効率的にエンコードすることです。たとえば、それらを blob としてバイナリ エンコードします (多くのゼロがあるため、おそらく RLE を使用しますか?)。これを達成するための最善の方法、またはサイズを縮小するための他のアイデアはありますか? 私はルビーでDBを構築し、目的のCで電話でそれを読んでいます.

また、DB の統計を取得して、最も多くのスペースを使用しているものを確認する方法はありますか?

0 投票する
3 に答える
858 参照

c - Cで.Zファイルを解凍します

誰かがANSICで.Zファイルを解凍するためのパブリックドメイン(またはMITまたはBSDライセンス)ライブラリを教えてもらえますか?

ありがとう!

0 投票する
8 に答える
45333 参照

ios - iPhone 解凍コード

iPhone でファイルまたはディレクトリを解凍するためのコードを書こうとして本当に行き詰まりました。

以下は、単純なテキスト ファイルを解凍するために使用しているサンプル コードです。

ファイルを解凍しますが、破損しています。

0 投票する
5 に答える
2466 参照

java - What are my options to store and query huge amounts of data where a lot of it is repeating?

I am evaluating options for efficient data storage in Java. The data set is time stamped data values with a named primary key. e.g.

Could be a stock price at a given point in time, so it is, I suppose, a classic time series data pattern. However, I really need a generic RDBMS solution which will work with any reasonable JDBC compatible database as I would like to use Hibernate. Consequently, time series extensions to databases like Oracle are not really an option as I would like the implementor to be able to use their own JDBC/Hibernate capable database.

The challenge here is simply the massive volume of data that can accumulate in a short period of time. So far, my implementations are focused around defining periodical rollup and purge schedules where raw data is aggregated into DAY, WEEK, MONTH etc. tables, but the downside is the early loss of granularity and the slight inconvenience of period mismatches between periods stored in different aggregates.

The challenge has limited options since there is an absolute limit to how much data can be physically compressed while retaining the original granularity of the data, and this limit is exacerbated by the directive of using a relational database, and a generic JDBC capable one at that.

Borrowing a notional concept from classic data compression algorithms, and leveraging the fact that many consecutive values for the same named key can expected to be identical, I am wondering if there is way I can seamlessly reduce the number of stored records by conflating repeating values into one logical row while also storing a counter that indicates, effectively, "the next n records have the same value". The implementation of just that seems simple enough, but the trade off is that the data model is now hideously complicated to query against using standard SQL, especially when using any sort of aggregate SQL functions. This significantly reduces the usefulness of the data store since only complex custom code can restore the data back to a "decompressed" state resulting in an impedance mismatch with hundreds of tools that will not be able to render this data properly.

I considered the possibility of defining custom Hibernate types that would basically "understand" the compressed data set and blow it back up and return query results with the dynamically created synthetic rows. (The database will be read only to all clients except the tightly controlled input stream). Several of the tools I had in mind will integrate with Hibernate/POJOS in addition to raw JDBC (eg. JasperReports) But this does not really address the aggregate functions issue and probably has a bunch of other issues as well.

So I am part way to resigning myself to possibly having to use a more proprietary [possibly non-SQL] data store (any suggestions appreciated) and then focus on the possibly less complex task of writing a pseudo JDBC driver to at least ease integration with external tools.

I heard reference to something called a "bit packed file" as a mechanism to achieve this data compression, but I do not know of any databases that supply this and the last thing I want to do (or can do, really....) is write my own database.

Any suggestions or insight ?

0 投票する
15 に答える
3908 参照

image - ウェブコミックの画像圧縮

おそらくこのあたりの多くの人々が私はいくつかのウェブコミックを読んだ。Drowtalesは私のお気に入りですが、それは重要なことではありません。

長い間、私の頭の後ろで考えが私を悩ませてきました:ウェブコミックは描かれた絵です。写真ではありません。多くの冗長性(色が少ない、色が平らな領域など)が必要であるため、ロスレス品質を維持しながら、非常に高速で簡単に圧縮できる必要があります。それでも、それらを圧縮するための最良のツールは、同じ古い不可逆JPEGであるようです。

どうして?より良いものが発明されていませんか?私はデータ圧縮の専門家ではないので、より良いアルゴリズムを見つけるための私自身のわずかな試みは無益でした。私が見つけた最高のものはPngcrushでしたが、それでも圧縮の点でJPEGよりはるかに遅れています。

これについて専門家の意見を聞きたい。私のこの考えは愚かで失敗する運命にありますか?それとも、人々が見つけた、または私が調べることができる方法はありますか?

もちろん、これはロード時間を短縮したいという利己的な欲求から来ています。:)

追加:一部の人々は要点を見逃しているように見えるので、明確にします:

ウェブコミック画像は、簡単に圧縮できるように、多くの冗長性を備えている必要があります。どういうわけか、それらをロスレスでJPEGよりも小さくなるように圧縮することはできませんか?または、少なくとも品質を維持しながら、JPEGよりも適切に圧縮します。

それらはWeb用であるため、専用のコンプレッサーはおそらくPNGまたはJPEGを出力するはずです。より良い結果を得るために、修正されたアルゴリズムで圧縮されただけです。