You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by Apache Wiki <wi...@apache.org> on 2018/04/20 09:55:55 UTC
[Jackrabbit Wiki] Update of "EncodingAndEscaping" by ThomasMueller
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.
The "EncodingAndEscaping" page has been changed by ThomasMueller:
https://wiki.apache.org/jackrabbit/EncodingAndEscaping?action=diff&rev1=9&rev2=10
"[@itemID = '" + itemID.replaceAll("'", "''") + "']";
}}}
+ Note that other special characters (like "@" or ".") are ''usually'' ignored by the Lucene parser, however if a "*" (wildcard) is used, then they are ''not'' ignored. So:
+
+ {{{
+ jcr:contains(., 'hello.world') => works (all documents that contain both the exact words "hello" and "world")
+ jcr:contains(., 'hello world') => works (all documents that contain both the exact words "hello" and "world")
+
+ jcr:contains(., '*hello world*') => works (all documents that contain a word ending with "hello" and starting with "world")
+ jcr:contains(., '*hello.world*') => does not work (no results)
+ jcr:contains(., 'hello.world*') => does not work (no results)
+ jcr:contains(., '*hello.world') => does not work (no results)
+ }}}
+
== Escaping/encoding in URIs ==
There are further encoding/decoding methods in the {{{Text}}} class for dealing with URIs in a webapp. The allowed chars for JCR names contains the URI set plus a few others (eg. spaces). Thus the URI set is actually more constrained. Therefore, if you have a valid URI, you can map it directly onto a JCR path without having to worry about escaping (this is by design). If you go the other way, ie. have a JCR path and want to create an URI for it, you simply use plain URI escaping for it. To make everything simpler in the context of URIs, one suggestion is to only create JCR nodes with names that are valid URIs.