[
https://issues.apache.org/jira/browse/LUCENE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772164#action_12772164
]
Steven Rowe commented on LUCENE-2019:
-------------------------------------
Lucene is not an application.
Again, quoting from section 16.7 (emphasis mine):
bq. *Applications* are free to use any of these noncharacter code points
internally but should never attempt to exchange them.
The forbidden operation is exchanging non-characters across the *application*
boundary.
Asking Lucene to store non-characters for you is not a violation of the Unicode
standard. Lucene agreeing to do so is not a violation of the Unicode standard.
If a Lucene user later uses a Lucene index to exchange data (of whatever form)
across the application boundary, that's on the user, not on Lucene.
(I'll skip the Lucene-as-a-weapon metaphor. You can thank me later.)
> map unicode process-internal codepoints to replacement character
> ----------------------------------------------------------------
>
> Key: LUCENE-2019
> URL: https://issues.apache.org/jira/browse/LUCENE-2019
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Robert Muir
> Priority: Minor
> Attachments: LUCENE-2019.patch
>
>
> A spinoff from LUCENE-2016.
> There are several process-internal codepoints in unicode, we should not store
> these in the index.
> Instead they should be mapped to replacement character (U+FFFD), so they can
> be used process-internally.
> An example of this is how Lucene Java currently uses U+FFFF
> process-internally, it can't be in the index or will cause problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
