> On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hi All, > > Btw, when migrating from NSString's methods to URL I've noticed > that they work a bit differently: URL's methods convert strings > from NFC to NFD (decomposed) unicode form which is demonstrated > by the example below. > > I had to additionally call .precomposedStringWithCanonicalMapping > on resulting string to convert it back to NFC form. > > This was very surprising as it wasn't mentioned anywhere in docs > and has broken non-english filename support in app.
Out of curiosity, can you explain how this breaks your non-english filename support? What OS and filesystem are you using? - Tony > Is this expected behavior or a bug? > > //let source = "/my_file.txt" > let source = "/мой_файл.txt" // problematic is letter 'й' > > let disallowedCharacters = CharacterSet(charactersIn: source).inverted > > > do { > print("--- NSString:") > let result = (source as NSString).deletingPathExtension as String > print(result) > print(result.rangeOfCharacter(from: disallowedCharacters)) > > } > > do { > print("--- String + URL:") > let result = URL(fileURLWithPath: source).deletingPathExtension().path > print(result) > print(result.rangeOfCharacter(from: disallowedCharacters)) > print(result.precomposedStringWithCanonicalMapping.rangeOfCharacter(from: > disallowedCharacters)) > } > > > --- Output: > > --- NSString: > /мой_файл > nil > --- String + URL: > /мой_файл > Optional(Range(Swift.String.CharacterView.Index(_base: > Swift.String.UnicodeScalarView.Index(_position: 3), _countUTF16: > 2)..<Swift.String.CharacterView.Index(_base: > Swift.String.UnicodeScalarView.Index(_position: 4), _countUTF16: 1))) > nil > > > Regards, > Andrey > >> On 10 May 2017, at 12:45, Eric Blachère via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Thanks for the answer ! It seems a bit weird from them to advocate using >> NSString methods in the unavailability comment. I would rather use URL when >> I can even if the conversions are a bit tedious ^^ >> >> Thanks a lot, >> Eric >> >> 2017-05-10 10:52 GMT+02:00 Brent Royal-Gordon <br...@architechies.com >> <mailto:br...@architechies.com>>: >> > On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev >> > <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> > >> > I was just wondering if there are plans to bring NSString functions >> > manipulating paths into the native String class. (such as >> > lastPathComponent, pathComponents etc...) >> > Because even if we can always make an extension of String to easily cast >> > it into NSString, it's still a bit of a shame to have to do it ;) >> >> Unfortunately, it seems like the decision not to include these methods on >> String was quite deliberate. >> >> Here's the revision where that happened: >> <https://github.com/apple/swift/commit/1f2390f1c75be65f57f189247bfe4f9b2fc11e3b#diff-d38f60064c3752f096c043e756d8f201R925 >> >> <https://github.com/apple/swift/commit/1f2390f1c75be65f57f189247bfe4f9b2fc11e3b#diff-d38f60064c3752f096c043e756d8f201R925>> >> As you can see, they had that working and chose to disable it, presumably >> because they want you to manipulate paths through `URL`. (I wish the radar >> referenced in the commit message were public, but alas, it's not.) >> >> -- >> Brent Royal-Gordon >> Architechies >> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev