# \[F\] Filter " " can falsely match " "
**URL:** https://community.mp3tag.de/t/f-filter-can-falsely-match/15615
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [March 26, 2014, 11:40am UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615 "2014-03-26T11:40:02Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 11:40am UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/1 "2014-03-26T11:40:02Z")
(Note: Topic Title is faulty. This forum post form's changed its two consecutive space characters to one, and I can find no way to edit the Topic Title.)
Here, Filter "" falsely matches a track having as its only tag field [EDIT:] TITLE having as value a string having no "", but having "" at start.
[EDIT:]
[EDIT:]
PS Help [https://docs.mp3tag.de/filter](https://docs.mp3tag.de/filter) says
> [@](#):
>
> Returns only files that contain every word in the string as a word or substring thereof. A word is a contiguous sequence of characters excluding the space character.
but I take it this is intended to say "...that contain every word or quoted string..." since Help also says
> [@](#):
>
> Notes
> If or contains spaces, it should be enclosed in double quotation marks, e.g., album IS "Moon Safari".
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 26, 2014, 12:14pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/2 "2014-03-26T12:14:35Z")
> [@chrisjj](#):
>
> (Note: Topic Title is faulty. This forum post form's changed its two consecutive space characters to one, and I can find no way to edit the Topic Title.)
>
> Here, Filter "" falsely matches a track having as its only tag field a string having no "", but having "" at start.
If you want to filter for something like spaces at the beginning of a string you would have to use an expression as the function you use only applies to words. A double-space is no word, a word has to have at least one visible character.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 12:21pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/3 "2014-03-26T12:21:00Z")
> [@ohrenkino](#):
>
> WHich filter operator do you use?
As the screenshot shows, none. But using operator HAS gives the same result.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 26, 2014, 12:26pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/4 "2014-03-26T12:26:37Z")
> [@chrisjj](#):
>
> As the screenshot shows, none. But using operator HAS gives the same result.
Cannot verify that: a single space at the beginning of title plus the filter expression
%title% HAS " "
leads to no hits.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 12:36pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/5 "2014-03-26T12:36:12Z")
> [@ohrenkino](#):
>
> Cannot verify that
Sorry to be unclear. I used TITLE, as per Help's spec [https://docs.mp3tag.de/filter](https://docs.mp3tag.de/filter) "Filter expressions are simple expressions that consist of tag field names, filter keywords and text." and got:
> [@ohrenkino](#):
>
> : a single space at the beginning of title plus the filter expression %title% HAS " " leads to no hits.
I get the same. I note that this form accords with Help's examples, but not Help's spec.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 26, 2014, 12:48pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/6 "2014-03-26T12:48:40Z")
> [@chrisjj](#):
>
> ...
> I get the same. I note that this form accords with Help's examples, but not Help's spec.
I get different results for
TITLE HAS " " -\> hit (just the one with a leading space)
title HAS " " -\> hit (just the one with a leading space)
%title% HAS " " -\> no hit
" " -\> all tracks with a space in the data somewhere
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 26, 2014, 12:48pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/7 "2014-03-26T12:48:53Z")
> [@chrisjj](#):
>
> ... Here, Filter "" falsely matches a track having as its only tag field a string having no "", but having "" at start. ...
You did not specify which tag-field exactly should be examined.
There might be some other tag field in the record of tag-fields, which contains two consecutive space characters?
But there seems to be something special, indeed.
TITLE HAS " "
(one space)
... does show the file with TITLE string having only one leading space character.
TITLE HAS " "
(two spaces)
... does show also the file with TITLE string having only one leading space character.
TITLE HAS " "
(three spaces)
does not show the file with TITLE string having only one leading space character.
"%TITLE%" HAS " "
(two spaces)
does not show the file with TITLE string having only one leading space character.
"%TITLE%" HAS " "
(one space)
does show the file with TITLE string having only one leading space character,
and of course all other files having at least one space character in the tag-field TITLE.
This works exact.
TITLE MATCHES "^ "
(one space)
... does show the file with TITLE string having only one leading space character.
TITLE MATCHES "^ "
(two spaces)
... does not show the file with TITLE string having only one leading space character.
DD.20140326.1505.CET
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 12:54pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/8 "2014-03-26T12:54:40Z")
> [@ohrenkino](#):
>
> I get different results for
> TITLE HAS " " -\> hit (just the one with a leading space)
> title HAS " " -\> hit (just the one with a leading space)
> %title% HAS " " -\> no hit
> " " -\> all tracks with a space in the data somewhere
Thanks. FTR, the reply form verifies those four " " as two spaces.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 1:01pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/9 "2014-03-26T13:01:49Z")
> [@DetlevD](#):
>
> There might be some other tag field in the record of tag-fields
I thought my "its only tag field" made clear there is no other tag field in the track, but I have updated the report to be clearer. Thanks.
---
### Author:  [@chrishirst](https://community.mp3tag.de/u/chrishirst)
#### Post date: [March 26, 2014, 3:50pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/10 "2014-03-26T15:50:25Z")
> [@](#):
>
> This forum post form's changed its two consecutive space characters to one, and I can find no way to edit the Topic Title.)
Not the forum, but HTML will only display a single whitespace character no matter how many are in the source code. (it's that regexp readibility thing again)
It also does not display tabs (Vert or Horiz), line breaks (LF), new lines (CR).
To display all white space on a HTML document it has to be enclosed in a
```
```
element.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 5:14pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/11 "2014-03-26T17:14:39Z")
> [@Chris Hirst](#):
>
> Not the forum, but HTML will only display a single whitespace character no matter how many are in the source code.
Not quite. e.g. this forum's HTML displays them fine in TEXTAREA.
Elsewhere, this this forum software needs only to encode repeated space characters appropriately - using .
---
### Author:  [@chrishirst](https://community.mp3tag.de/u/chrishirst)
#### Post date: [March 26, 2014, 7:51pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/12 "2014-03-26T19:51:08Z")
Ah, but a is a form input field not a HTML display element.
There are some deprecated elements that also display as 'plain text', ` which was intended for displaying code snippets and which displayed by default as "tele-type" characters.`
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 26, 2014, 9:13pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/13 "2014-03-26T21:13:13Z")
> [@Chris Hirst](#):
>
> Ah, but a is a form input field not a HTML display element.
Agreed, but you said HTML not "HTML display element" 🙂
---
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [March 27, 2014, 2:06pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/14 "2014-03-27T14:06:03Z")
There's some kind of bug here. Here's what I find. I'm not going to go through every permutation for number of spaces and fields with leading and trailing spaces and every other thing. I think that if Florian just knows there's a related bug, he should be able to track it down and fix all instances.
TITLE=xxx (no leading or trailing spaces)
title HAS " " (one space) matches
%title% HAS " " (one space) does not match
* * *
And a general comment: I really wish this language would be cleaned up to either _require_ surrounding %% or to _not allow_ them when addressing field contents. The Help shows both, and it's obvious that even the behavior can be affected by which one is used. This needs to be made more rigid.
Ideally, the plain would address the field _name_, not its contents, while %% would be required when referring to data within the field. Thus, expressions like this would be valid:
%artist% HAS morrison
artist MISSING
and the following would be invalid:
artist HAS morrison
%artist% MISSING
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 27, 2014, 2:32pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/15 "2014-03-27T14:32:11Z")
> [@JJ Johnson](#):
>
> And a general comment: I really wish this language would be cleaned up to ...
Florian, I am not in the habit of saying "I told you so" 🙂 but can I just say you might find it useful to reread the warning I gave you by email on 16/09/2009, before you switched to this new filter syntax. And to reread your reply!
Good luck.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 27, 2014, 5:19pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/16 "2014-03-27T17:19:36Z")
> [@JJ Johnson](#):
>
> ... This needs to be made more rigid. ...
Yes, many scripting errors could be avoided and many life time can be saved, when the Mp3tag's scripting language(s) would not so loose defined as it is.
Much time is lost by the repeated need to try, what is allowed to use, what works now and what does not.
Regarding the filter expression there is defined this rule:
If in HAS/IS/GREATER/LESS/EQUAL/MATCHES contains $ or % it should be enclosed in double quotation marks and will be treated as a format string instead of a tag field name.
Since the given filter examples do not follow this rule, why should the simple user follow?
DD.20140327.1919.CET
---
### Author:  [@chrishirst](https://community.mp3tag.de/u/chrishirst)
#### Post date: [March 27, 2014, 5:40pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/17 "2014-03-27T17:40:19Z")
> [@chrisjj](#):
>
> Agreed, but you said HTML not "HTML display element" 🙂
Hoy! I do the nit-picking around here if you don't mind. 😃
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 27, 2014, 10:24pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/18 "2014-03-27T22:24:45Z")
Okay! 🙂
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 20, 2014, 8:32am UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/19 "2014-04-20T08:32:07Z")
I've fixed this with Mp3tag v2.59.
```
[2014-04-13] FIX: filtering for field HAS " " was also matching files without blanks.
```
Thanks for reporting!
Kind regards
Florian
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:07pm UTC](https://community.mp3tag.de/t/f-filter-can-falsely-match/15615/20 "2018-12-28T14:07:00Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.