データを外部チップに渡すために、UUencodeでエンコードしようとしているデータのストリームがあります。チップは一度に512バイトの生データを受け入れます。UUencodeで512バイトをエンコードします。
私が理解している限り、データは45バイトの11行（エンコード後は60バイトになります）と17バイトの残りの1行に変換する必要があります。
明らかに、17バイトは3の倍数ではないため、uuencodeされたセグメントに直接マップできませんが、uuencodeされたデータを取得すると、最後の行は24個のエンコードされたバイト（または18個のrawバイト）を返します。
これは、合計で513バイトのデータがあることを意味します。私の質問は、これは私のuuencodeアルゴリズムの欠点ですか（純粋に数学的な観点からはそれがどのようになり得るかはわかりませんが）、あるいは、余分なバイトはどこから来て、どうすれば再びそれを取り除くことができますか？
UUEncoding 512バイトを使用すると、（513ではなく）684エンコードされたバイトが取得されます。長さが384バイトの入力データストリームは、正確に512バイトにエンコードされます。
UUEncodingは、3バイナリバイトの入力データセグメントを4テキストバイトの出力データセグメントに変換するための手段にすぎません。長さが3バイトでない入力セグメントには、長さが3バイトになるまでnullバイトが埋め込まれます。UUEncodingアルゴリズムには、元のデータ長の表現はありません。
これを、ストリームを特定の長さの行に分割してデータストリームに情報をフォーマットおよび追加し、エンコードされた各データ行の前に行長インジケーターを追加するUUEncodeファイルと比較してください。この例では、最後の17バイトは24バイトにエンコードされますが、このデータ行の前には、行の長さが18ではなく17になるバイトがあります。
パディングを取り除く唯一の方法は、データの長さをエンコードすることによって、最初にパディングがそこにあることを知ることです。