[
https://issues.apache.org/jira/browse/SLING-12776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955836#comment-17955836
]
Konrad Windszus commented on SLING-12776:
-----------------------------------------
But unconditionally unescaping property names is potentially changing the
intended property name (which may have been written with plain JCR API or
created with a FileVault package). Just think about property name
{{myProp%3A}}. This is a valid JCR name and doesn't require any escaping.
However calling {{Text.unescapeIllegalJcrChars(...)}}
(https://github.com/apache/jackrabbit/blob/0067cea7b9024b5a07ddcbc730b67e96fe518571/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java#L550)
modifies this name to {{myProp:}}, i.e. I can no longer find the property with
Sling API with the original property name.
Also this URL escaping is only one way to express invalid JCR characters (but
not the only one).
Not sure if there is a way to fix this in a backwards compatible way (can't
think of any), however I think property names and node names should be treated
the same (i.e. either both should be escaped/unescaped automatically) or just
throw exceptions for invalid characters.
> Automatically (un)escape illegal JCR characters in resource/property names
> --------------------------------------------------------------------------
>
> Key: SLING-12776
> URL: https://issues.apache.org/jira/browse/SLING-12776
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 3.3.2
> Reporter: Konrad Windszus
> Priority: Major
>
> For JR2 and Oak the defacto standard for dealing with unsupported JCR
> characters in node/property names is using
> [o.a.j.util.Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.14/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars-java.lang.String-]
> which resembles URI encoding. Compare also with
> https://jackrabbit.apache.org/archive/wiki/JCR/EncodingAndEscaping_115513396.html.
> However the JCR Resource provider currently just simply fails for invalid
> names (when writing) and does not unescape those names when reading.
> As the Sling API does not define any limitations on resource names (except
> for "/" which is used as path separator) I would expect that invalid
> characters are transparently handled by the underlying provider.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
