我正在从SEC文件中提取PDF。他们通常是这样的：
无论出于何种原因，我将原始PDF保存为.text文件，然后尝试运行
class TestClass{
private void privMethod()
{
System.out.println("TestClass Method");
}
public static void main(String... args)
{
TestClass obj=new SubClass();
obj.privMethod();
}
}
class SubClass extends TestClass
{
private void privMethod()
{
System.out.println("SubClass Method");
}
}
来自python uudecode -o output_file.pdf input_file.txt函数或允许从命令行执行命令的任何其他python函数，生成的PDF文件已损坏。如果我直接从命令行运行同样的命令就没有损坏。
仔细查看从python脚本输出的PDF文件时，看起来该文件过早结束。从python执行命令行命令时是否存在某种输出限制？
谢谢！
答案 0 :(得分：1)
这个脚本在Fedora 21 x86_64上使用uudecode 4.15.2在Python 3.4.1下运行时运行良好：
import subprocess
subprocess.call("uudecode -o output_file.pdf input_file.txt", shell=True)
使用链接的SEC文件（长度：173,141 B; sha1：e4f7fa2cbb3422411c2f2968d954d6bb9808b884），解码的PDF（长度：124,557 B; sha1：1676320e1d9923e14d19451c16688198bc93ca0d）在查看时显示正确。
您的环境中可能还有其他原因导致问题。您可能需要在问题中添加其他详细信息。
从python执行命令行命令时是否存在某种输出限制？
如果按＆＃34;输出限制＆＃34;你的意思是由uudecode写的文件的大小，然后是。唯一类型的＆＃34;输出限制＆＃34;在创建子进程时，当您通过subprocess或stdout=PIPE时，使用stderr=PIPE模块时需要担心。如果子进程将足够的数据写入这些流中的任何一个，并且您的脚本没有定期消耗它们，则子进程将阻塞（请参阅subprocess模块文档）。在我的测试中，uudecode没有向stdout或stderr写任何内容。