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?
Yes, it does make sense. It's part of the way HFS Plus handles case-insensitive comparisons with Unicode. See the Case-Insensitive String Comparison Algorithm section of Tech Note 1150: HFS Plus Volume Format: <http://developer.apple.com/technotes/tn/ tn1150.html#StringComparisonAlgorithm>
The reason has to do with certain "ignorable" Unicode characters. Some Unicode code points act as hints, and do not affect the comparison (a string with these ignorable characters is considered identical to a string without ignorables). The easy way to handle them in the code was to map them to 0 during the comparison. But since null (0) is a valid character in an HFS Plus name, it gets mapped to 0xFFFF (which is not valid Unicode) during the comparison. That's why nulls sort last on HFS Plus.
-Mark