如何_直接_从 .JAR 中的子目录获取文件列表 - JAVA
我正在寻找一种直接获取 .jar 内指定子目录内所有文件的列表的方法。
这类似: How do I list the files inside a JAR file?
但是不幸的是,上面列出的方法将迭代整个 .jar 中的所有文件。当使用包含许多文件的 .jar 时,这似乎不切实际,就像我的情况一样。必须有一种方法可以直接路径到 .jar 中的子目录并迭代其内容,而不必迭代 jar 的所有内容,然后过滤结果以找到您关心的那些条目。
大致是我所拥有的:
public static ArrayList<String> loadInternalFileListing(MetaDataType type, MetaDataLocation location, String siteId)
{
ArrayList<String> filenameList = new ArrayList<String>();
URL url = getInternalFile(type, null, location, siteId);
JarURLConnection juc = null;
JarFile jarFile = null;
try
{
juc = (JarURLConnection) url.openConnection();
jarFile = juc.getJarFile();
Enumeration<JarEntry> entries = jarFile.entries();
for(JarEntry jarEntry = entries.nextElement(); entries.hasMoreElements(); jarEntry = entries.nextElement())
{
...//logic here
}
}
... //catch, handle exceptions, finally block and other logic
return filenameList;
}
变量: url ->: jar:file:/C:/jboss-4.2.2.GA/server/username/tmp /deploy/tmp8421264930467110704SomeEar.ear-contents/SomeBusiness.jar!/subdir1/subdir2/subdir3/subdir4/
路径: /subdir1/subdir2/subdir3/subdir4/ 正是我想要迭代的位置。
调试显示 juc 确实已正确创建并指向正确的路径。 jarFile 然后按照预期,只给我 jar 文件路径,这就是为什么我丢失子目录以及为什么我开始在根目录迭代的原因。这都是有道理的。这显然不是正确的方法。必须有别的办法!
搞乱 JarURLConnection 理论上指向我感兴趣的正确目录,并没有透露任何有用的信息。有JarURLConnection.getInputStream()。调试器表明这最终保存了一个ZipFileInputStream,但我无法访问它,并且进一步查看它看起来就像ZipFile<的ZipFileInputStream /em> - 这让我回到了第一个方。
I'm looking for a way to directly get a list of all files within a specified sub-directory within a .jar.
This is similar: How do I list the files inside a JAR file?
But unfortunately the method listed above will iterate over all files in the entire .jar. When working with a .jar with many files in it - this seems impractical as is my case. There has to be a way to directly path to a sub directory within the .jar and iterate over its contents, without having to iterate over all contents of the jar and then filter the results to find those entries that you care about.
Here is roughly what I have:
public static ArrayList<String> loadInternalFileListing(MetaDataType type, MetaDataLocation location, String siteId)
{
ArrayList<String> filenameList = new ArrayList<String>();
URL url = getInternalFile(type, null, location, siteId);
JarURLConnection juc = null;
JarFile jarFile = null;
try
{
juc = (JarURLConnection) url.openConnection();
jarFile = juc.getJarFile();
Enumeration<JarEntry> entries = jarFile.entries();
for(JarEntry jarEntry = entries.nextElement(); entries.hasMoreElements(); jarEntry = entries.nextElement())
{
...//logic here
}
}
... //catch, handle exceptions, finally block and other logic
return filenameList;
}
The variable: url ->: jar:file:/C:/jboss-4.2.2.GA/server/username/tmp/deploy/tmp8421264930467110704SomeEar.ear-contents/SomeBusiness.jar!/subdir1/subdir2/subdir3/subdir4/
The path: /subdir1/subdir2/subdir3/subdir4/ is exactly where I want to iterate.
Debugging reveals that juc is indeed created correctly and pointing to the correct path. jarFile then as expected, just gives me the jar file path which is why I lose the subdirectories and why I start iterating at the root. This all makes sense. This clearly isn't the correct way. There has to be another way!
Messing around with the JarURLConnection which theoretically points to the correct directory I am interested in, doesn't reveal anything useful. There is JarURLConnection.getInputStream(). Debugger indicates that this ultimately holds a ZipFileInputStream, but I can't get access to it, and looking further it looks like its just the ZipFileInputStream to the ZipFile - which puts me back at square one.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
抱歉,没有其他方法,至少没有标准 java 库。 zip 文件仅包含条目列表,其中没有“随机访问”查找。可能还有其他库可以为您解析列表并创建某种条目的层次结构图,但无论哪种方式,一些代码都需要遍历所有条目才能找到您需要的内容。
sorry, there isn't another way, at least not with the standard java libraries. a zip file just contains a list of entries, there is no "random access" lookup in it. there may be other libraries out there that parse through the list for you and create some sort of hierarchical map of entries, but either way, some code needs to iterate through all the entries to find what you need.