[
https://issues.apache.org/jira/browse/LUCENE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772211#action_12772211
]
Steven Rowe commented on LUCENE-2019:
-------------------------------------
{quote}
Steven, by the way, I think something i havent been able to communicate
properly, is that I feel very strongly that storing noncharacters in term text
where they are treated as abstract characters, is very different than using
them as sentinel values / delimiters / etc in the index format, I think this is
ok and is what they are for.
but term text is different, search engines index human language and by putting
noncharacters in term text you are treating them as abstract characters.
{quote}
Robert, you are a proponent of the (ICU)CollationKeyFilter functionality, which
uses IndexableBinaryStringTools to store arbitrary binary data in a Lucene
index. These filters store non-human-readable terms in the index. I can think
of several other examples of using Lucene indexes to store non-human-language
terms.
Character data, in addition to representing characters, is *data*. Bits. I
would argue that you *always* need context to figure out what bits represent.
> 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
