Почему случается так, что кодировка UTF-8 используется при взаимодействии со средой UNIX/Linux?
Примечание: Когда мы создаем группу, строки, имеющие Null, игнорируются. Если у нас есть 3 строки, одна из которых имеет значение Null, то среднее значение делится на 2, а не на 3, потому что третье значение было Null. Ключевым моментом здесь является использование функции Window () .
from pyspark.sql.functions import avg, col, when
from pyspark.sql.window import Window
w = Window().partitionBy('fruit')
#Replace negative values of 'qty' with Null, as we don't want to consider them while averaging.
df = df.withColumn('qty',when(col('qty')<0,None).otherwise(col('qty')))
df = df.withColumn('qty',when(col('qty').isNull(),avg(col('qty')).over(w)).otherwise(col('qty')))
df.show()
+-----+---+---+
|fruit| id|qty|
+-----+---+---+
| Pear| 04|6.0|
| Pear| 05|2.0|
|Mango| 06|6.0|
|Mango| 07|4.0|
|Mango| 08|2.0|
|Apple| 01|5.0|
|Apple| 02|1.0|
|Apple| 03|3.0|
+-----+---+---+
8 ответов
Частично, потому что файловые системы ожидают, что NUL ('\0') байты завершит имена файлов, таким образом, UTF-16 не работал бы хорошо. Необходимо было бы изменить много кода для внесения того изменения.
Как jonathan-leffler упоминания, главной проблемой является нулевой символ ASCII. C традиционно ожидает, что строка будет пустая завершенный. Таким образом, стандартные функции струны до будут дросселировать на любом символе UTF-16, содержащем байт, эквивалентный пустому указателю ASCII (0x00). В то время как можно, конечно, программировать с поддержкой широкого символа, UTF-16 не является подходящим внешним кодированием Unicode в именах файлов, текстовых файлах, переменных среды.
Кроме того, UTF-16 и UTF-32 имеют и ориентации с прямым порядком байтов и с обратным порядком байтов. Для контакта с этим Вам или будут нужны внешние метаданные как тип MIME или Ориентация Байта Mark. Это отмечает,
Где UTF-8 используется прозрачно в 8-разрядных средах, использование BOM вмешается в любой протокол или формат файла, который ожидает определенные символы ASCII вначале, такие как использование "#!" в начале сценариев оболочки Unix.
У предшественника к UTF-16, который назвали UCS-2 и не поддерживал суррогатные пары, были те же проблемы. UCS-2 нужно избежать.
Я полагаю, что, когда Microsoft начала использовать кодирование двух байтов, символы выше 0xffff не были присвоены, так использование кодирования двух байтов означало, что никто не должен был волноваться о символах, являющихся различными длинами.
Теперь, когда существуют символы вне этого диапазона, таким образом, необходимо будет иметь дело с символами различных длин так или иначе, почему кто-либо использовал бы UTF-16? Я подозреваю, что Microsoft приняла бы другое решение, если бы они были desigining их поддержка unicode сегодня.
Да, это по причинам совместимости. UTF-8 назад comptable с ASCII. Linux/Unix был базирующийся ASCII, таким образом, он просто делал/делал смысл.
Современные Unixes используют UTF-8, но это было не всегда верно. На RHEL2 - который только несколько лет - значение по умолчанию
$ locale LANG=C LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=Локаль C/POSIX, как ожидают, будет 7-разрядным совместимым с ASCII кодированием.
Однако как Jonathan Leffler заявил, любое кодирование, которое допускает байты NUL в последовательности символов, неосуществимо на Unix, поскольку системные API не осведомлены локали; строки, как все предполагается, являются последовательностями байта, завершенными \0.
Я полагаю, что это главным образом назад совместимость, которую UTF8 дает с ASCII.
Для ответа на вопрос 'об опасностях' необходимо указать то, что Вы подразумеваете под 'взаимодействием'. Вы означаете взаимодействовать с оболочкой с libc, или с надлежащим ядром?
Я думаю, что это - потому что программы, которые ожидают вход ASCII, не смогут обработать кодировку, такую как UTF-16. Для большинства символов (в диапазоне 0-255), те программы будут рассматривать высокий байт как NUL / 0 символов, которые используются на многих языках и системах для маркировки конца строки. Этого не происходит в UTF-8, который был разработан, чтобы избежать встроенного NUL's и быть агностиком порядка байтов.
Я думал, что 7-разрядный ASCII был прекрасен.
Серьезно, Unicode является относительно новым в схеме вещей, и UTF-8 обратно совместим с ASCII и использует меньше пространства (половина) для типичных файлов, так как это использует 1 - 4 байта за кодовую точку (символ), в то время как UTF-16 использует любые 2 или 4 байта за кодовую точку (символ).
UTF-16 предпочтителен для внутреннего использования программы из-за более простых ширин. Его предшественник UCS-2 был точно 2 байта для каждой кодовой точки.