[hfs-user] Alphabetical order of items in a catalog node

Pierre Duhem Pierre Duhem <lsduhem@duhem.com>
Tue, 20 Apr 2004 09:51:37 +0200


Mark,


MD> On Apr 19, 2004, at 5:58 AM, Pierre Duhem wrote:

>> Norton says that the alphabetical order of the items in a node is
>> incorrect. It proposes to fix the matter and does it apprently. When I
>> check in the catalog node, however, I find it put a hidden folder
>> named '0000HFS+ Private Data' (with four null at the beginning of the
>> Unicode string) at the end of the current folder.
>>
>> I thought that alphabetical order problems were a matter of the past
>> (remember the funny order of the accented letters?).
>>
>> Does it make sense for you to put an Unicode character of 0x0000 at
>> the very end of the list?

MD> Yes, it does make sense.  It's part of the way HFS Plus handles  
MD> case-insensitive comparisons with Unicode.  See the Case-Insensitive
MD> String Comparison Algorithm section of Tech Note 1150: HFS Plus Volume
MD> Format:
MD> <http://developer.apple.com/technotes/tn/ 
MD> tn1150.html#StringComparisonAlgorithm>

MD> The reason has to do with certain "ignorable" Unicode characters.  Some
MD> Unicode code points act as hints, and do not affect the comparison (a
MD> string with these ignorable characters is considered identical to a
MD> string without ignorables).  The easy way to handle them in the code
MD> was to map them to 0 during the comparison.  But since null (0) is a
MD> valid character in an HFS Plus name, it gets mapped to 0xFFFF (which is
MD> not valid Unicode) during the comparison.  That's why nulls sort last
MD> on HFS Plus.

Thanks a lot. I had read this document in the past, and this very
piece, but had not noticed this special treatment for the null
character. I'll correct my code in this sense.

Thanks again.


-- 
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com