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.