lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] Commented: (LUCENE-2019) map unicode process-internal codepoints to replacement character
Date Fri, 30 Oct 2009 23:38:59 GMT


Robert Muir commented on LUCENE-2019:

bq. So you think that enforcing consistency is worth the cost of disallowing some usages,
and I don't.

no, i think this a myth. I think this is the original bug that caused index corruption
* lucene used a noncharacter (happened to be U+FFFF) process-internally
* lucene also treated this noncharacter as an abstract character (it later got truncated by
some encoding routine, but basically it didn't correctly handle this case)
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.

right now you only have one you treat correctly, and thats U+FFFF.

> map unicode process-internal codepoints to replacement character
> ----------------------------------------------------------------
>                 Key: LUCENE-2019
>                 URL:
>             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
> 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:
For additional commands, e-mail:

View raw message