[ 
https://issues.apache.org/jira/browse/SLING-12776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17959542#comment-17959542
 ] 

Konrad Windszus edited comment on SLING-12776 at 6/10/25 5:55 PM:
------------------------------------------------------------------

What about adding automatic node name escaping also for node write operations 
and first try to escape automatically during read and fall back to using the 
unescaped name in case this a valid JCR name as well in case no node was found 
with the escaped name? WDYT [~cziegeler]?

However this kind of fallback is probably too much effort when it comes to 
paths.


was (Author: kwin):
What about adding automatic node name escaping also for node write operations 
and first try to escape automatically during read and fall back to using the 
unescaped name in case this a valid JCR name as well in case no node was found 
with the escaped name? WDYT [~cziegeler]?

> 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)

Reply via email to