Search for text within Excel files

[fiveolddogs]

I need to search a folder with couple hundred excel workbooks for several text strings. Since the files are in hex, this is not working. I did find an old zabkat blog post from 2007 which suggests this is possible with iFilters.

Is there a way to do this in 2016?

[nikos]

what you need is any recent version of xplorer2 professional (NOT lite) and make sure you tick the SEARCH ALL FILES option (should be on by default). For more information see here www.zabkat.com/blog/where-is-that-document.htm

[fiveolddogs]

Yes, I am using Xplorer2 Ultimate 3.1.0.1. I do have "Search all files" selected.

Here is a screenshot showing the Excel file, the Find Files dialog with parameters, and the search results.

And here is a link to the Excel file I am trying to search within.

Thanks.

[Robert2]

Using your file, searching for “hold” or “hold payment” works normally here (Windows 10 x64, xplorer² 3.1.0.1 ULT [Unicode] x64).
Have you got enough elevated rights to search the C: drive?

[fiveolddogs]

Yes, I am logged in as Administrator.

Could it be an obscure Xplorer2 option? I don't mess around with the options too much, but the settings were brought in from my install on a previous PC.

[Kilmatead]

For what it's worth, you need to be sure that Windows is actually indexing the contents of .XLSX files, as here. It may not be doing this for the files' current location by default.

.XLSX files are actually renamed ZIP archives which (when associated as Office XML format files) the indexer will sort properly, and then x2 can search them. If their contents have not been indexed in this manner, x2 can't locate the content because it doesn't recognize .XLSX as an archive format whose contents have been scrambled (so even raw binary hex-searching for text wouldn't work).

[Robert2]

On my Windows system, only the Properties are indexed for all listed file types (“Index Properties Only”). X2 can still find “hold” or “hold payment” in your .XLSX file…

[Kilmatead]

The option as to properties only or properties & contents is actually on an individual file-type basis (it is not a "blanket" setting, regardless of how it appears), so if you click on each type in that indexing options listview, you may see the option change accordingly depending on which filetype you're highlighting.

Also, in this case, the text "hold" is actually contained in an .XML file (named sharedStrings.xml) which is in a subfolder of the "jacket" zip/.XLSX named "xl". .XML files are set by default as content indexed - and even if they weren't, some filetypes of a known textual-nature (such as XML, txt. etc) are content-indexed automatically, and so may disregard that setting.

Since you have Excel installed on your system and the filetypes are registered, the indexer knows to look through archived content as well, and will thus find the XML file by default. x2 is slightly agnostic that way - for example, if Excel is not registered on one's system, .XLSX is an unknown-filetype and the indexer won't know it's actually an archive, so it uses the text-filter by default, which will always fail.

[Robert2]

You are right. The .XLSX file type is content-indexed on my system too. But I don’t have Excel installed, only Apache OpenOffice.

[Kilmatead]

I would surmise that OpenOffice for all its attempts at being compatible with MS Office, knows how to register each filetype accordingly, which is pretty simple in this case since Windows handles ZIPs natively.

For example, I have no office-ware of any type installed on my machine, and so .XLSX is a completely unknown filetype. Since there appears to be no way to directly tell x2 that it's really just a zip-folder, there is no searchable means by which I could locate that text (short of literally renaming all .XLSX files to .ZIP, which would be crazy). It might not hurt if Nikos added such a manual association when needed (applied when "archived content" is ticked as a search-option), as the same concept could apply to .JAR files, etc, as well).

You are right.

I am, regrettably, quite aware that I really should "get out more".

[Robert2]

But I do have MS Word 2007 installed, and it seems it comes bundled with the “Microsoft Filter Pack”. Here is from Microsoft Filter Pack:

The document formats that get added by the filter pack are .docx, .docm, .pptx, .pptm, .xlsx, .xlsm, .xlsb, .zip, .one, .vdx, .vsd, .vss, .vst, .vdx, .vsx, and .vtx whcih are basically all the new document formats that have been introduced in Microsoft Office 2007.

An IFilter allows the Windows Indexing Service and Windows Desktop Search to index the contents of files, so that search results include those when you are using the search tools on the operating system.
…
Note that the program works with Windows Desktop Search and Windows Search

There are more details about these MS Filters at Enhance Windows/Exchange Search using Microsoft Filter Pack
HTH.

[Kilmatead]

Microsoft Filter Pack

And that would appear to be the solution for those who wish to search within Office Filetypes without actually having any Office-ware installed. (Despite the link saying it's only for XP, Vista, and Server Editions, I can confirm it works in Win7 x64/x86). Simple, one-click stuff.

It should be added, however, that it does still require the user to have Indexing available and applied to the requisite working folders. I imagine there still may be a few old stalwarts out there who would baulk at such an affronting injustice to their liberties. God bless 'em.

[nikos]

Yes, I am using Xplorer2 Ultimate 3.1.0.1. I do have "Search all files" selected

the first question is if this file is somewhere under c:\xfer which is the root of your search. OTherwise it won't be found
then check if you have the filters installed and enabled. Use the quick previewer panel, set to DRAFT mode and select this XLSX file; do you see a plain text preview or just random gibberish?

[fiveolddogs]

For what it's worth, you need to be sure that Windows is actually indexing the contents of .XLSX files, as here. It may not be doing this for the files' current location by default.

It was evidently an indexing issue. Just going into my indexing settings in Control Panel and looking at my settings (I made no changes, I swear) appears to have fixed the problem. The OS on this new Dell system seems to be a little glitchy. Anyway, I really appreciate all the info in this thread. Thanks to all.