Jump to content

(Archived) No global "all notes" search results for "contains" string or embedded alphanumeric strings

Recommended Posts

Evernote is my preferred, favorite application for all devices. I use several desktops (Windows XP/7/8/8.1 and Mac OSX 10.8/10.7/10.6) and a variety of mobile devices (primarily iOS 7/6 - ipad, iphone and Android). However, my primary purpose for keeping my notes is Evernote is for "searching" to retrieve information I need on a daily basis. There can be inconsistencies in search for embedded text, credit card digits, etc. so I've learned not to rely on it.


I've also seen differences between mobile and desktop, but still working on variations to document this more fully.


Evernote will not find embedded characters which do not START with the first character of a string.

In short, it will not find embedded characters of a string which do not include the first charater.


For example, create a note with the following four lines:



1234 5678 9012 3


test this mash of characters


Evernote can find,


"5678", but not "56789"

"this mash", but not "s mash", not "ash of", not "mashofcharacters"



"1234", "1234 5678" ... but not "2345" and not "34 5678"


or any subset of "1234567890123", that does not begin with "1"


it will not find

"est this mash" or "234 5678"


it will find

"5678 90", but not "678 90", etc.


The indexing scheme, relies on the "starting character" of a whole word, whole string for returning notes.


But if you "open" the note, all the failed searches above, using the CTRL-F, Apple-F or mobile app, top right seach within note, will succeed, so it's only the global search indexing that has this issue. 


This anomaly is likely intentional, to reduce index time and size.

Link to comment
  • 2 weeks later...

Correct. This is by design. See http://dev.evernote.com/doc/articles/search_grammar.php. This is how any search that goes to the service is handled. Clients can use other search rules, but all of them that I know of use this one.


Internal note search doesn't obey the rules of the search grammar.


Hi jefito.


I've just come across this when trying to perform a search today. Do you have any ideas on how I can get around this?


My example is that I was searching for some specific SQL keywords and couldn't remember it's entire name (sp_msforeachdb). Therefore I was just searching for (foreachdb). The latter producing no results as it wasn't the what the word starts with.


Luckily my tags are fairly comprehensive so I could narrow it down to then manually find the note I was looking for.


If Evernote has been designed to not search in such a way. How do they perceive users to perform these searches (Contains rather then Starts With) as I can foresee this happening quite often. Allowing for the potential of users making duplicate notes on the topic thinking that one doesn't already exist.


I'm a new user to Evernote so apologies if I miss something obvious! However, I can see why they're doing this as it's likely to do with the way these words are indexed to allow for quick searching.



Link to comment
  • Level 5*

I've just come across this when trying to perform a search today. Do you have any ideas on how I can get around this?

In terms of the Evernote search grammar (what's used on the server, what the API exposes, and what the clients ostensibly adhere to), there appears to be no way around this. See the search grammar doc, Search Terms section: http://dev.evernote.com/doc/articles/search_grammar.php#Search_Terms


There could be third-party solutions, but they'd need to do their own indexing / search, as far as I know, since the API doesn't support 'contains' search.

Link to comment
  • Level 5*

It seems crazy that I can't search within a note like this. I was searching a Cisco config file for "9" in the phrase "Vlan649" and it did not find the "9" in this word. How in the world do you work around this? Seems like such a logical thing to be able to do.

Nevertheless, Evernote-provided search doesn't let you do this.

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...