小编M. *_*ace的帖子

我一直在尝试解决 Java 程序中的内存问题，其中我们将整个文件加载到内存中，对其进行 base64 编码，然后将其用作发布请求中的表单参数。这是由于文件太大而导致 OOME。

我正在开发一种解决方案，可以通过 Base64 编码器将文件流式传输到 Http Post 请求的请求正文中。我在所有流行的编码库（Guava、java.util.Base64、android.util.Base64 和 org.apache.batik.util）中注意到的常见模式之一是，如果库支持使用 Streams 进行编码，则 Encoding始终通过 OutputStream 完成，而解码始终通过 InputStream 完成。

我无法找到/确定这些决定背后的理由。鉴于许多流行且编写良好的库都与此 api 设计保持一致，我认为这是有原因的。将这些解码器之一调整为输入流或接受输入流似乎并不困难，但我想知道这些编码器以这种方式设计是否有有效的架构原因。

为什么常见的库通过OutputStream进行Base64编码，通过InputStream进行Base64解码？

支持我的主张的例子：

java.util.Base64
 - Base64.Decoder.wrap(InputStream stream)
 - Base64.Encoder.wrap(OutputStream stream)

android.util.Base64
 - Base64InputStream  // An InputStream that does Base64 decoding on the data read through it.
 - Base64OutputStream // An OutputStream that does Base64 encoding

google.common.io.BaseEncoding
 - decodingStream(Reader reader)
 - encodingStream(Writer writer)

org.apache.batik.util
 - Base64DecodeStream implements InputStream
 - Base64EncodeStream implements OutputStream