[
https://issues.apache.org/jira/browse/SLING-12776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17966254#comment-17966254
]
Carsten Ziegeler commented on SLING-12776:
------------------------------------------
That comment is 13 years old and I still think that this is how it *should* be
- however during these 13 years I learned it the hard way that such changes
cause more trouble than they solve.
If you really want to tackle this, put it behind a configuration which uses the
old behaviour by default. You can then turn this on for your applications
> 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)