[
https://issues.apache.org/jira/browse/JCR-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17727941#comment-17727941
]
Yegor Kozlov edited comment on JCR-4935 at 5/31/23 12:44 PM:
-------------------------------------------------------------
I changed the fix to escape illegal characters to unicode code points, similar
to how File Valult does it. The XML would like something like
{code:xml}
<node
property1="\u0003"
property2="O\u0019K"
/>
{code}
was (Author: yegor.kozlov):
I changed the fix to escape illegal characters to unicode code points, similar
to how File Valult does it. The XML would like something like
{code:xml}
<node
property1="\u0003"
property2="\u0019"
/>
{code}
> session.exportDocumentView() generates unparsable XML if a JCR Property
> contains invalid XML character
> ------------------------------------------------------------------------------------------------------
>
> Key: JCR-4935
> URL: https://issues.apache.org/jira/browse/JCR-4935
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
> Affects Versions: 2.21.17
> Reporter: Yegor Kozlov
> Assignee: Julian Reschke
> Priority: Major
> Attachments: image-2023-05-29-14-58-05-591.png
>
>
> I came across this issue in AEM, where user content can contain all kinds of
> special characters. In my case it was a 0x3 character (^C) in a node property
> which was written in the JCR XML as-is, and it resulted in a unparsable
> output.
> !image-2023-05-29-14-58-05-591.png|width=968,height=305!
> IMO control characters, non-characters and out-of-unicode-range characters
> should be skipped when writing XML. These can come from user data and can act
> as a "poison pill" breaking the export/import functionality.
>
> The PR is coming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
