Я полагаю, что Windows в настоящее время по умолчанию использует UTF-16 для «Unicode», но это может быть и в будущем.Unicode vs. UTF-8
По этой причине, было бы лучше использовать
[System.Text.Encoding]::UTF8.GetString($someByteArray)
вместо следующих ?:
[System.Text.Encoding]::Unicode.GetString($someByteArray)
Этого не может быть в будущем.
Unicode не является потенциально-переменной кодировкой; это просто Microsoft (печально вводящее в заблуждение) имя для UTF-16LE.
Это не изменится. Даже если Microsoft приступит к внедрению Windows API изначально в UTF-8 или UTF-32 (что-то не появляется никогда), System.Text.Encoding.Unicode должен оставаться UTF-16LE, так как это определяется спецификацией .NET.
было бы лучше использовать
UTF8вместоUnicode?
Используйте UTF8, если массив содержит UTF-8 закодированных байт, и использовать Unicode, если они находятся в UTF-16LE.
Если вы хотите выбрать, какое кодирование используется для хранения данных в покое, UTF-8 обычно является лучшим выбором для соображений экономии пространства.
во-первых, да Windows defaults to UTF-16. Лично я хотел бы использовать UTF-8, потому что большинство приложений, которые я пишу, должны общаться с приложениями Linux или с некоторой формой http, так что UTF-8 более вероятен.
Кроме того, даже если весь ваш код используется с системами Microsoft, его легко конвертировать в UTF-8, и простой заменяющий регулярный выражение может изменить все на Unicode (UTF-16), если .NET начал его требовать.
Блестящий ответ. Спасибо. Однако как вы можете быть уверены, что Microsoft не изменит его? Разве им не разрешено изменять спецификацию .NET, если они этого хотят? Какие последствия это могло бы иметь, если бы они это сделали? –
Они могут, безусловно, изменить любое определение API в новой версии .NET, но они никогда не намекали на то, что определение Unicode, char или String может быть изменено, поэтому это был бы большой сюрприз для совместимости. В любом случае MS действительно * сдержанно нарушают старые API. Последний раз, когда произошла смена внутренней строковой кодировки, произошел переход от Windows 9x к NT, и старые (ANSI) API доступны по сей день. (Мы по-прежнему имеем дело с наследием этого, поскольку приложения C-stdlib по-прежнему не соответствуют строковым интерфейсам ANSI и не поддерживают UTF-8 в msvcrt.) – bobince