Исправление
Napilnik,
(текущая версия)
:
Восьмера былинна и именно переменной длинной знака, на сколько мне известно.
Обрабатывать её погано, поменял один символ в тексте на один же но другой длины и получи изменение длины файла и сдвиг всех последующих байтов. Преобразование массива байтов в набор символов тоже доставляет - почти та же разархивация данных но без плюшек архива.
Например для английского там вообще будет один байт.
Потому у него большое лобби среди буржуев - им хорошо и не волнует.
И только для китайских/тайских/ивритов будет от двух и пока не лопнет.
Символы псевдографики из IBM 866 и некоторые кавычки с тире трёхбайтные, так что не только.
То есть это, вроде как, формат достигающий компроммиса между объемом данных и гибкостью.
За счёт !«№;»;и. В случае с утф-32 логично использовать формат архивации всех мелких файлов на лету поддерживаемый ОС, тогда и обработка байтов будет проще и места на диске займёт меньше утф-8, но буржуям это не надо - у них и так восьмибитная кодировка.
Исходная версия
Napilnik,
:
Восьмера былинна и именно переменной длинной знака, на сколько мне известно.
Обрабатывать её погано, поменял один символ в тексте на один же но другой длины и получи изменение длины файла и сдвиг всех последующих байтов. Преобразование массива байтов в набор символов тоже доставляет - почти та же разархивация данных но без плюшек архива.
Например для английского там вообще будет один байт.
Потому у него большое лобби среди буржуев - им хорошо и не волнует.
И только для китайских/тайских/ивритов будет от двух и пока не лопнет.
Символы псевдографики из IBM 866 трёхбайтные, так что не только.
То есть это, вроде как, формат достигающий компроммиса между объемом данных и гибкостью.
За счёт !«№;»;и. В случае с утф-32 логично использовать формат архивации всех мелких файлов на лету поддерживаемый ОС, тогда и обработка байтов будет проще и места на диске займёт меньше утф-8, но буржуям это не надо - у них и так восьмибитная кодировка.