You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Bart van der Schans (JIRA)" <ji...@apache.org> on 2008/08/05 12:26:44 UTC
[jira] Created: (JCR-1708) Impossible to import a string containing
_x0020_ with Session.importXml
Impossible to import a string containing _x0020_ with Session.importXml
------------------------------------------------------------------------
Key: JCR-1708
URL: https://issues.apache.org/jira/browse/JCR-1708
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Bart van der Schans
Fix For: core 1.4.6
The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1708) Impossible to import a string
containing _x0020_ with Session.importXml
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630993#action_12630993 ]
Jukka Zitting commented on JCR-1708:
------------------------------------
Merged to the 1.4 branch in revision 695432.
> Impossible to import a string containing _x0020_ with Session.importXml
> ------------------------------------------------------------------------
>
> Key: JCR-1708
> URL: https://issues.apache.org/jira/browse/JCR-1708
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5
> Reporter: Bart van der Schans
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: core 1.4.6
>
>
> The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1708) Impossible to import a string
containing _x0020_ with Session.importXml
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620255#action_12620255 ]
Bart van der Schans commented on JCR-1708:
------------------------------------------
I agree it's not major, it is probably the default that i forgot to change.
>From 6.4.4:
..amounts to the following: a space becomes _x0020_, a tab becomes _x0009_, a
carriage return becomes _x000D_, a line feed becomes _x000A_ and
any underscore (_) that occurs as the first character of a sequence
that could be misinterpreted as an escape sequence becomes
_x005f_.
So only replacing _x0020_ with spaces isn't enough. The import must at least handle the _x005f_ to avoid the misinterpretation.
I'll try to come up with a patch which also makes sure the export is encoded accordingly.
> Impossible to import a string containing _x0020_ with Session.importXml
> ------------------------------------------------------------------------
>
> Key: JCR-1708
> URL: https://issues.apache.org/jira/browse/JCR-1708
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5
> Reporter: Bart van der Schans
> Priority: Minor
> Fix For: core 1.4.6
>
>
> The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1708) Impossible to import a string containing
_x0020_ with Session.importXml
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg updated JCR-1708:
-----------------------------------
Priority: Minor (was: Major)
i don't consider this a 'major' issue.
> Impossible to import a string containing _x0020_ with Session.importXml
> ------------------------------------------------------------------------
>
> Key: JCR-1708
> URL: https://issues.apache.org/jira/browse/JCR-1708
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5
> Reporter: Bart van der Schans
> Priority: Minor
> Fix For: core 1.4.6
>
>
> The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1708) Impossible to import a string
containing _x0020_ with Session.importXml
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620237#action_12620237 ]
Stefan Guggisberg commented on JCR-1708:
----------------------------------------
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
for more information regarding _x0020_ please refer to the jsr 170 spec, "6.4.4 Escaping of Values".
see JCR-325 for a related issue.
> Impossible to import a string containing _x0020_ with Session.importXml
> ------------------------------------------------------------------------
>
> Key: JCR-1708
> URL: https://issues.apache.org/jira/browse/JCR-1708
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5
> Reporter: Bart van der Schans
> Fix For: core 1.4.6
>
>
> The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1708) Impossible to import a string
containing _x0020_ with Session.importXml
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCR-1708.
--------------------------------
Resolution: Fixed
Assignee: Jukka Zitting
I turned off the decodeBlanks option in revision 691550. We don't encode blanks when exporting, so there's no point in trying to (even incorrectly) decode them when importing.
Resolving as Fixed.
> Impossible to import a string containing _x0020_ with Session.importXml
> ------------------------------------------------------------------------
>
> Key: JCR-1708
> URL: https://issues.apache.org/jira/browse/JCR-1708
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5
> Reporter: Bart van der Schans
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: core 1.4.6
>
>
> The importXml uses the ValueHelper.serialize methods. The option "decodeBlanks" does a simple string replace which replaces _x0020_ in spaces (line 695 and 793). This option is always set to true unless the imported data is binary. See: BufferedStringValue and StringValue getValue methods.
> The result is that it is now impossible to import a string with _x0020_ in it, because it gets translated in a space. The simple solution would be to just turn off the declodeBlanks option, but I'm not sure why it was added in the first place. Another option would be to use real encoding instead of a replace like the o.a.j.util.ISO9075.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.