Not sure what you're suggesting. Hash (#) is in STRINGCHAR.
Can you please double-check your/my statement. All I can see is STRINGCHAR being defined as a set of all Unicode character with specific set of excluded symbols. The # (hash) symbol is 6th excluded symbol.
It looks OK, since ESCAPEDSTART seems to cover it:
ESCAPEDSTART does not cover this, because it is covering only the case when the # (hash) symbol is in the beginning of the attribute value where it MUST be escaped. If the # (hash) symbol is not in the beginning of the attribute value it does not have to be escaped (defined in RFC 4514).
Do you have a unit test that triggers this?
The single line of code in the bug description can reproduce the issue. Do you require a real unit test?
I've updated DnParserImpl.jj (see the attached patch) so it is compliant with LDAPv3 (i.e. RFC 4514).
Only problem is that now it is not fully backward compatible because LDAPv3 does not define attribute values enclosed within double quotes. However in the Spring LDAP project there is no unit test for such functionality. Existing unit tests are working with the new parser.
The correct solution might be to have two parsers (one LDAPv2 and one LDAPv3) and allow developers switching between them (e.g. via JVM property). I also suggest to add new unit tests for unescaped hash, space and equals sign within an attribute value.
For Spring LDAP users with the same problem, I am also uploading archive with generated parser sources (see the attached archive). You can include them within your project to override the default implementation.