问题标签 [lzw]

我正在使用 iText v5.4.2。我正在尝试解析 PDF 文件中的图像。对于某些 PDF 文件中的某些图像，我得到 NullPointerException。可以在此处下载带有“错误”图像的 PDF 文件：https ://dl.dropboxusercontent.com/u/3585277/LZW_Error.pdf

这是一个简单的演示：

当我使用长度为 256 的符号表（字典）时，我的 LZW 压缩工作，编码器和解码器都使用 256 并且一切正常，但是当我将这个数字增加到 512、1024、4096 时，解码的文件输出不一样与第一个输入文件...任何提示？

源代码：

LZWEncoder.java：

LZWDecoder.java：

LZWst.java：

LookAheadIn.java：

There is definitely a line but I don't understand why cant the Scanner see it ..

Here is the beginning of the file :

Below is my code for getting it:

But I am getting the error:

The file book1_enc is an output of my LZW encoding algorithm.When I am passing the file to my Decoder I would like the decoder to know the size of dictionary which is 256 in this case...Thanks for reading...

我将压缩数据（在客户端使用 js 进行 LZW 压缩）发送到服务器。问题是数据在使用 SQL 保存到数据库后会损坏。

所以我的问题是，我应该使用什么排序规则来实现这一点？（我目前的一个是 latin1-default collat​​ion）

我已经检查了在从客户端到服务器的数据传输过程中是否出现问题，反之亦然，方法是向 HTTP-Server 发送编码数据并立即将其发送回（PHP-echo）而不进行处理。我可以正确解码 LZW。所以肯定是数据库的问题。

有关架构的更多信息：我只有一个包含 3 个列的表。“数据”是“BLOB”的类型。（我也试过 TEXT）。user_id 是 INT，类型是 VARCHAR。

这就是我保存数据的方式：

我尝试使用 LZW 压缩方法压缩 zip 文件（以下链接中提供的代码），

http://rosettacode.org/wiki/LZW_compression#C

它创建的编码文件长度比原始文件大小太长，这是什么原因？请任何人帮助我了解实时发生的事情。

我有一个程序可以使用 LZW 算法并使用哈希表来创建压缩文件。我的压缩文件当前包含对应于哈希表索引的整数。这个压缩文件中的最大整数在 46000 左右，可以很容易地用 16 位来表示。现在，当我使用以下代码将此“compressedfile.txt”转换为二进制文件“binary.bin”（以进一步减小文件大小）时，我在“binary.bin”文件中得到 32 位整数。例如，如果我的压缩文件中有数字 84，它会在我的二进制文件中转换为 5400 0000。

我的问题是我不能在 '5400 0000' 中丢弃结尾的 '0000'，这会在我的文件中占用额外的 2 个字节。每个整数都是这种情况，因为我的最大整数是 46000，只能使用 2 个字节来表示。是否有任何代码可以以这种方式设置我的二进制文件的基础？我希望我的问题很清楚。

我正在尝试实现 LZW 压缩和解压缩技术。我的程序将任何文件作为 InputStream 并将其读入字节数组。然后它对其应用压缩算法，并在字符串变量中返回编码字节。

然后我应用返回原始数字的解压缩算法。

现在为了检索原始文件，我必须将此字符串的内容传输到字节数组中，然后将此数组写入输出流。

将解压缩字符串的内容复制到字节数组是我的问题所在。

到目前为止，我的代码的输出看起来与此有关-

原始 = -119807871131026100001373726882000170001686000 .....

压缩 = [91, 45, 49, 49, 57, 44, 32, 56, 48, 261, 55, 56, 265, 49, 261, 49, 51, 270, 264, 32, 50, 54, 273, 261 , 274, 280, 270, 272, 32, 55, 283, 55, 50, 261, 54, 267, 262, ...]

解压 = [-119, 80, 78, 71, 13, 10, 26, 10, 0, 0, 0, 13, 73, 72, 68, 82, 0, 0, 0, 17, 0, 0, 0, 16, 8, 6, 0, 0, 0, -16, 49, -108, 95, 0, 0, 0, 1, 115, 82, 71, 66, 0, -82, -50, 28, -23 , 0, 0, 0, 4, 103, 65, 77, 65, 0, 0, -79, -113, 11, -4, 97, 5, 0, 0, 0, 32, 99, 72, ,. .....]

请帮我弄清楚如何将字符串的内容复制到字节数组中。谢谢！

我想用来从shapefilegdal_rasterize生成 TIFF 。.shp通常结果很大，所以我想使用LZW compress option对其进行压缩。

我试图用命令这样做

但似乎该--config COMPRESS LZW选项没有任何效果。（结果与没有选项时的大小完全相同。）

也许我对如何使用这个选项有一些误解。

I am building an LZW encoding algorithm, which uses dictionary and hashing so it can reach fast enough for working words already stored in a dictionary.

The algorithm gives proper results when ran on smaller files (cca few hundreds of symbols), but on the larger files (and especially in those files which contain of less different symbols - for example, it gives the worst performance when ran on a file which consists only of 1 symbol, 'y' let's say). The worst performance, in terms that it just crashes when dictionary is not even close to being full. However, when the large input file consists of more than 1 symbol, dictionary gets close to being full, approximately 90%, but again then it crashes.

Considering the structure of my algorithm, I am not quite sure what is causing it to crash in general, or crash so soon when large file of just 1 symbol is given. It must be something about hashing (first time doing it, so it might have some bugs).

The hash function I am using can be found here, and from what I have tested it, it gives good results: oat_hash

LZW encoding algorithm is based on this link, with slight change, that it works until the dictionary is not full: LZW encoder

Let's get into code:

Note: oat_hash is changed so it returns value % CAPACITY, so every index is from DICTIONARY

}

Apache Commons Compress 仅适用于存档文件（如果我错了，请纠正我）。我需要类似的东西

LZW 只是一个例子，可以是任何类似的东西。谢谢你。