[swift-corelibs-dev] Foundation: NSString init detect encoding
andybest.net at gmail.com
Wed Jun 21 11:51:34 CDT 2017
Is the preferred approach to mirror Foundation as closely as possible (e.g.
under Linux basically do nothing), or is implementing something like
stringEncodingForData under the hood preferable in this case?
On 21 June 2017 at 17:43, Tony Parker <anthony.parker at apple.com> wrote:
> Hi Andy,
> On Jun 21, 2017, at 7:39 AM, Andy Best via swift-corelibs-dev <
> swift-corelibs-dev at swift.org> wrote:
> I've been looking at the init(contentsOfFile, usedEncoding) initializer
> for NSString in corelibs-foundation.
> Am I right in thinking that this method should use some method to attempt
> to detect the character encoding of the file before returning a decoded
> In this case, the Foundation implementation just looks at an extended
> attribute of the file to see if it contains the encoding. If it doesn’t
> have the xattr then we don’t attempt to guess (name of xattr is
> Foundation has another API which attempts to guess the encoding of a data
> blob, but I think we left it out of the swift-corelibs stubs:
> + (NSStringEncoding)stringEncodingForData:(NSData *)data
> encodingOptions:(nullable NSDictionary<
> NSStringEncodingDetectionOptionsKey, id> *)opts
> convertedString:(NSString * _Nullable *
> usedLossyConversion:(nullable BOOL
> *)usedLossyConversion API_AVAILABLE(macos(10.10), ios(8.0), watchos(2.0),
> - Tony
> If so, I've been working on a pure Swift library to detect string
> encodings, and wondered if continued work on it might be useful for
> implementing this missing method?
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev