log4j2新压缩算法
我希望使用log4j2 RollingFileAppender和定制的压缩算法（ZStd）。
目前为止支持的压缩算法似乎是FileExtension枚举（zip,gz,bz2,...）中的压缩算法，请参见https://github.com/apache/logging-log4j2/blob/efa64bfad3f67c5b5fed6b25d65ef5ca2212011b/log4j-core/src/main/java.org/apache/logging/log4j/core/appender/rolling/FileExtension.java，我相信不可能添加新的压缩算法（除了修补库之外）。
一个解决方案可以是使用下面建议的方法重新实现RollingFileAppender:https://logging.apache.org/log4j/2.x/manual/extending.html#appenders，但这会涉及到大量难看的复制和粘贴，这个appender真的可以做很多事情。
我希望遵循的方法是创建一个新的动作，实现AbstractAction接口，但我不知道如何告诉log4j2在翻转时执行这个动作。这可行吗？这是实现这一目标的正确方法吗？
共有1个答案
是的。翻转策略使用FileExtension根据文件扩展名自动添加一个CompressAction，但您自己只需配置一个自定义操作就可以做到这一点。虽然您可以将ZipoCompressAction作为如何实现该操作的模板，但您还需要查看DeleteAction以了解如何将自定义操作声明为插件。
-
我试图找到一种压缩算法，我可以使用它来编码一个blob，只使用16个固定长度的符号（0b0000-0b1111）。 在没有任何压缩的情况下，我可以使用这16个符号对其各自的位值进行编码（例如，符号5（0b0101）对位0101进行编码，因此如果我的blob是100位长，我需要25个符号来表示它-但这样做不会提供压缩。 我认为我需要的是一个反向霍夫曼（在某种意义上，代码是固定长度的，但它代表可变长度
-
DEFLATE 是同时使用了哈夫曼编码（Huffman Coding）与 LZ77 算法的一个无损数据压缩算法，是一种压缩数据流的算法。任何需要流式压缩的地方都可以用。目前 zip 压缩文件默认使用的就是该算法。 关于算法的原理，以及 哈夫曼编码（Huffman Coding）与 LZ77 算法，感兴趣的读者可以查询相关资料，这里推荐 GZIP压缩原理分析——第五章 Deflate算法详解 序列文
-
问题内容： python docs将此代码作为zip的反向操作： 特别是 zip（）与*运算符一起可用于解压缩列表。 有人可以向我解释运算符在这种情况下如何工作吗？据我了解，是一个二进制运算符，可以用于乘法或浅表复制…在这里似乎都不是这样。 问题答案： 像这样使用时，*（星号，在某些情况下也称为“ splat”运算符）是从列表中解压缩参数的信号。有关示例的更完整定义，请参见http://docs.
-
解析redis的lzf压缩和解压算法
-
让我澄清一下，我不是在说完美压缩，也不是说一种能够压缩任何给定源材料的算法，我意识到这是不可能的。我试图得到的是一种算法，它能够将任何源比特串编码到它的绝对最大压缩状态，这取决于它的香农熵。 我相信我听说过一些关于霍夫曼编码在某种意义上是最优的事情，所以我相信这个加密方案可能是基于此的，但这是我的问题： 考虑位串：a="101010101010"，b="110100011010"。 使用纯香农熵，
-
我有两个问题。其中一个会把话题弄得乱七八糟：） 1）我遇到了一个问题，即无法找到关于不同垃圾收集器在Hotspot中如何工作的完整信息。但我不是在谈论垃圾收集器工作的一般描述（我们在互联网上有很多这样的信息），我是在谈论具体的算法。我找到了这本白皮书（Java HotSpot虚拟机中的内存管理）http://www.oracle.com/technetwork/Java/javase/tech/m