Hello,
Where’s the DetectFileFormat function for Aspose.Zip to detect and distinguish the different Zip supported formats? Usage sample?
Hello @australian.dev.nerds, we have not such a function.
Generally, you can detect an archive format basing on file extension. If you open the archive with incorrect class, e. g. zip archive with RarArchive
class you’ll get an exception.
Heart breaking, to not to have the lovely DetectFileFormat for Aspose Zip!
Yes. Here is how you can detect archive format by extension:
FileInfo fi = new FileInfo(filename);
switch (fi.Extension)
{
case ".zip":
using (Aspose.Zip.Archive zip = new (filename))
{ ... }
break;
case ".rar":
using (Aspose.Zip.Rar.RarArchive rar = new (filename))
{ ... }
break;
...
}
Hello and thanks for your help, btw, not sure if the select case was serious or an input josh
Anyway, currently testing Aspose Email trial and found that some other SDKs also have DetectFileFormat, so please register a feature request for Zip :: DetectFileFormat to detect file format without loading / creating the file actually.
Thanks.
We opened a ZIPNET-937 issue for this feature and let you know on any progress with it. This won’t be soon.
Hello and thanks for consideration, how late you mean, perhaps by the end of Jan 2023?
The end of Jan 2023 seems realistic.
Hello, fixed for 23.1?
Hello, may be, but can’t guarantee this feature in 23.1 version. In 23.2 it sure will appear.
Hello and thanks for the great news, will this support all formats that are currently supported by Aspose Zip mentioned here?
To clarify, I’m currently working with Aspose Email to embed it to my app, and when opening files, I don’t rely on their extension, but the result of lovely Aspose function: DetectFileFormat
So it’s vital for DetectFileFormat to cover all currently supported formats by the SDK itself.
Thanks
Yes, this feature is already implemented and will be released soon. It will support all formats from SDK.
I second this, especially because there is no way to share the “entries” classes and I had to do this workaround:
public sealed class AsposeGenericArchiveEntry
{
public readonly bool IsDirectory;
public readonly string Name;
public readonly Action<Stream> Extract;
public AsposeGenericArchiveEntry(Aspose.Zip.ArchiveEntry entry)
{
IsDirectory = entry.IsDirectory;
Name = entry.Name;
Extract = s => entry.Extract(s);
}
public AsposeGenericArchiveEntry(Aspose.Zip.Rar.RarArchiveEntry entry)
{
IsDirectory = entry.IsDirectory;
Name = entry.Name;
Extract = s => entry.Extract(s);
}
...
}
Could it be possibile to let them implement a common interface? I have some function that should not care what kind of archive is the input coming from.
What I found more confusing is that “Aspose.Zip.Archive” does only support “Zip” files whereas “Aspose.Words.Document” does automatic detection based on the filename.
Seeing that Rars are to be opened with “Aspose.Zip.Rar.RarArchive” I would have expected that Zips had “Aspose.Zip.ZipArchive” as a class name but this is probably due to retrocompatibility.
Thanks
Hello @usernameisalreadyinuse, we thought about a common interface for archives and entries of various kind. This will be implemented one day, but not in January version.
Hello and thanks for the great addition, is my usage ok?
Please share usage sample + ArchiveFormat.Unknown enum feature request in case it’s not any of the other enums!
Usage sample:
ArchiveFormatDetector afd = new ArchiveFormatDetector();
ArchiveFormatInfo info = afd.GetFormatInfo("archive.bin");
Console.WriteLine($"Detected format: {info.Format}, class: {info.Class.FullName}");
GetFormatInfo
returns null
in case unknown format. Doesn’t it fit your necessity?
Hello and thanks for your help, yep I see can’t use ArchiveFormatDetector as a static method and need to make an instance of it, unlike other FileFormatDetect functions in Aspose Email/Cells/Imaging/Words.
About the unknown format, I’d try to stay away from null as much as I can, specially when returning enum values which is a bit odd, if you look into the other Aspose functions:
Email.FileFormatType.Unknown
Cells.FileFormatType.Unknown
Words.LoadFormat.Unknown
Imaging.FileFormat.Undefined
All have unknown, specially that it’s just one line of code, for example:
…
Unknown = 20 (or 16)
End Enum
BTW, it was just a suggestion, I’m fine and so thankful for your kind and great addition
@denis.kudelin What is your opinion on ArchiveFormat
expansion with Unknown
item?
This will also require ArchiveFormatInfo.Null
instance or nullable result of GetFormatInfo
, what are somewhat breaking change…
I don’t like this idea. I don’t think that empty/unknown instances of ArchiveFormatInfo
class should exist. If we only returned an Enum, then this would be the correct solution. But we can try to consider ArchiveFormatInfo
as a struct and add ArchiveFormat.Unknown
as the default value. Then default(ArchiveFormatInfo)
will mean what we need. But all this is doubtful, in my opinion.