Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <618221601.1256946779356.JavaMail.jira@brutus>
Date: Fri, 30 Oct 2009 23:52:59 +0000 (UTC)
From: "Steven Rowe (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2019) map unicode process-internal
 codepoints to replacement character
In-Reply-To: <1105014567.1256840399442.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772184#action_12772184 ] 

Steven Rowe commented on LUCENE-2019:
-------------------------------------

bq. by disallowing all noncharacters as term text, lucene is *more free* to use them as delimiters, and sentinel values, and such, as specified in chapter 3 of the standard.

Lucene is more free, but Lucene's users are not.  Quite the contrary.

IMHO, Lucene's users (applications that incorporate the Lucene library) should be able to use Unicode data in ways that the standard allows ("Applications are free to use any of these noncharacter code points internally").

U+FFFF was chosen for Lucene-internal use for reasons very similar to those you're bringing up, Robert: something like "who would ever want to use non-characters in an index?"  However, this choice does not obligate Lucene to take the same action for all other non-characters.

I think the fix here is documentation, not proscription.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org