LINUX.ORG.RU
ФорумTalks

Внезапно пришёл мэйнстримный патч для свежего screen'а, включая улучшение работы с неюникодными локалями

 , ,


1

3

Сабж. Теперь screen версии 4.6.1. Changelog:

Version 4.6.1 (10/07/2017):
  * Fixes:
        - problems with starting session in some cases
        - parallel make install
        - segfault when querying info on nonUTF locale
Скачать: ftp://ftp.gnu.org/gnu/screen/screen-4.6.1.tar.gz

★★★★★
Ответ на: комментарий от Meyer

UTF-32 как раз-таки нужен. UTF-8 недостаточно из-за его непредсказуемости, костыльности и глючности. Каждый символ должен занимать конкретное число байт. Это резко снижает расходы на математику при разборе строк. При этом UTF-8 зачем-то перегрузили структурами со служебными битами. Нет бы использовать биты в последующих байтах в последовательности по полной. Зачем-то сделали часть из них служебными, и они зачем-то должны точно соответствовать определённой первым байтом структуре, а иначе всё ломается...

Может быть, конечно, я ещё недостаточно знаю про UTF-32, и там тоже есть грабли, однако...

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

UTF-32 гарантирует только фиксированный размер кодпоинта, размер символа во всех вариантах юникода переменный как ни крути, что в UTF-8, что в UTF-32

Так что UTF-32, скорее не нужен, чем нужен

Gary ★★★★★
()
Ответ на: комментарий от Gary

Тем не менее, тут уже можно сразу начинать применять таблицы модификаторов и прочее (если они актуальны, поскольку тексты бывают разные, и особенности конкретного текста или его разбора могут быть известны заранее). А в UTF-8 чтобы до этого добраться нужно ещё для начала каким-то образом разобрать строку на отдельные codepoint'ы.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

То, что названо костыльностью и глючностью, на самом деле обеспечивает самосинхронизацию. Напомню, UTF-8 — это транспортная кодировка, именно поэтому используется префиксный код, он помогает обнаруживать сбои в передаче.

bormant ★★★★★
()
Ответ на: комментарий от bormant

Ну, если так, то тогда понятно почему оно так сделано. Однако, это можно было реализовать и, например, разбавляя текст дополнительными служебными байтами, которые потом автоматически удалялись бы.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

UTF-32 как раз-таки нужен. UTF-8 недостаточно из-за его непредсказуемости, костыльности и глючности. Каждый символ должен занимать конкретное число байт. Это резко снижает расходы на математику при разборе строк

В современных языках не нужно думать о количестве байт в строке.

NextGenenration ★★
()
Ответ на: комментарий от saahriktu

Рекомендую на календарь посмотреть. Тут уже скоро третье десятилиете двадцать первого века начнётся.

NextGenenration ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.