You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might be another issue classified under the #1015 umbrella.
Summary:
The String(data:encoding:) constructor fails on Linux when encoding is kCFStringEncodingDOSLatinUS.
Steps To Reproduce: ZIPFoundation is doing the following:
let dosLatinUS = 0x400
let dosLatinUSEncoding = CFStringEncoding(dosLatinUS)
let dosLatinUSStringEncoding = CFStringConvertEncodingToNSStringEncoding(dosLatinUSEncoding)
let codepage437 = String.Encoding(rawValue: dosLatinUSStringEncoding)
let encoding = self.centralDirectoryStructure.usesUTF8PathEncoding ? .utf8 : codepage437
This code works on Apple platforms, but fails on Linux.
The reason CP437 is needed for ZIP file decoding is that the ZIP Specification specifies that the encoding is CP437, unless a UTF-8 flag is set. So for legacy ZIP files, CP437 must be assumed (although in practice, encodings were far more random).
The text was updated successfully, but these errors were encountered:
In the context of the pitch about string encoding names, a suggestion to add new static properties to String.Encoding received some kind of negative feedbacks.
This might be another issue classified under the #1015 umbrella.
Summary:
The
String(data:encoding:)
constructor fails on Linux when encoding is kCFStringEncodingDOSLatinUS.Steps To Reproduce:
ZIPFoundation is doing the following:
This code works on Apple platforms, but fails on Linux.
The reason CP437 is needed for ZIP file decoding is that the ZIP Specification specifies that the encoding is CP437, unless a UTF-8 flag is set. So for legacy ZIP files, CP437 must be assumed (although in practice, encodings were far more random).
The text was updated successfully, but these errors were encountered: