Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed an subtle issue causing files with certain Unicode characters not be found from a ZipFile #6

Merged
merged 8 commits into from May 9, 2013

Conversation

mz2
Copy link
Contributor

@mz2 mz2 commented Oct 26, 2012

There is a subtle issue in ZipFile.m with how the file contents dictionary is parsed for -initWithFileName:mode: and then queried in -locateFileInZip: . If -locateFileInZip: is called with a string that uses a different Unicode normalization form than what was used to encode the file names and used as the key in the contents dictionary, the file info object is not found (the ZipFile 'contents' dictionary would have its keys in a different Unicode normalisation form).

To give an example, here are two strings which look exactly similar to the eye but have different hash codes (and therefore different keys in an NSDictionary):

(gdb) print (NSUInteger)[@"Contents/Resources/N. Engl. J. Med. 2009 Hütter.pdf" hash]
$5 = 523423533613971934
(gdb) print (NSUInteger)[@"Contents/Resources/N. Engl. J. Med. 2009 Hütter.pdf" hash]
$6 = 13774458812937735516

In an error case I encountered, the string I received from another component in the application uses the 2nd kind of representation, whereas Objective-Zip the first kind. Requiring a certain Unicode normalization form as arguments given to -locateFileInZip: is not practical, therefore my suggested solution uses uses the Normalization Form D as the 'contents' dictionary keys (the file info 'name' strings), and converts the string given as an argument to -locateFileInZip: to this same form.

mz2 added 5 commits July 6, 2012 23:34
…ocating files in a Zip file: if -locateFileInZip: is called with a string that uses a different Unicode normalization form than what was used to encode the file name, the file is not found (the ZipFile 'contents' dictionary could have its keys strings in a potentially different Unicode normalisation form).
@mz2
Copy link
Contributor Author

mz2 commented Oct 26, 2012

Oops, this pull request appears to contain also the ARC compatibility changes and some API changes I made earlier. The last bug fix commit bfd3f2c is however self contained. I'll try to remember to create a separate more minimal pull request with just that bug fix.

roustem added a commit that referenced this pull request May 9, 2013
Fixed an subtle issue causing files with certain Unicode characters not be found from a ZipFile
@roustem roustem merged commit c1fec43 into agilebits:master May 9, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants