巨大な入力ファイルを base64 でエンコードしてテキスト出力ファイルにしようとしていますが、入力ファイルをビットごとにエンコードできるかどうか、または全体を一度にエンコードする必要があるかどうかを調べようとしています。
これは AS/400 (iSeries) で実行されますが、それが何か違いをもたらすかもしれません。私は独自の base64 エンコード ルーチン (RPG で記述) を使用していますが、これは非常にうまく機能しており、サイズ制限がない限りは問題ありません。
ベストアンサー1
不可能です少しずつしかし一度に3バイト、または3バイトの倍数で構いません。!。
言い換えると、入力ファイルを 3 バイトの倍数のサイズの「チャンク」に分割すると、チャンクを個別にエンコードし、結果として得られる B64 エンコードされた部分を (当然ながら対応する順序で) 組み合わせることができます。最後のチャンクのサイズは、必ずしも 3 バイトの倍数である必要はありません。そのサイズのモジュロ 3 値に応じて、対応する B64 値にこれらのパディング文字 (通常は等号) がいくつか含まれることになりますが、これは、そのようなパディングが含まれる (および必要な) 唯一の部分であるため、問題ありません。
デコード方向では、B64 でエンコードされたデータを 4 バイトの倍数に分割する必要があることを除いて、同じ考え方です。必要に応じて並列または個別にデコードし、デコードされた部分を一緒に追加して (これも同じ順序で) 元のデータを再構成します。
例：
「ファイル」の内容 = "Never argue with the data." (Jimmy Neutron).
ストレートエンコード =Ik5ldmVyIGFyZ3VlIHdpdGggdGhlIGRhdGEuIiAoSmltbXkgTmV1dHJvbik=
さて、チャンクで：
"Never argue --> Ik5ldmVyIGFyZ3Vl
with the --> IHdpdGggdGhl
data." (Jimmy Neutron)-->IGRhdGEuIiAoSmltbXkgTmV1dHJvbik=
ご覧のとおり、この順序でエンコードされた 3 つのチャンクの量は、ファイル全体で生成されたコードと同じになります。
デコードも同様に行われ、4 バイトの倍数であれば、任意のチャンク サイズになります。エンコードに使用するサイズ間に何らかの対応関係を持たせる必要はまったくありません。(ただし、各方向を 1 つのサイズ (たとえば 300 と 400) に標準化すると、統一性が高まり、管理しやすくなります。)