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.
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
> <[email protected]> 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 <[email protected]
> <mailto:[email protected]>>:
> > On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev
> > <[email protected] <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
