- Отказаться от UTF-8, ыы, 02:19 , 07-Авг-17 (1) –1
Приведенное вами условие (распаковка) - надуманно, высосано из пальца и взято с потолка. И не имеет никакого отношения к строгим доказательствам чего бы то ни было.
- Отказаться от UTF-8, Sergey Maslennikov, 07:50 , 07-Авг-17 (2) +2
> ... условие (распаковка) - надуманноА понимаешь, если не паковать, то ответ тривиален. В случае русского языка UTF-8 уступает вдвое любой распространённой двуязычной кодировке по занимаемому месту на диске и энергозатратам на копирование и передачу. Ты можешь почитать об этом, например, в Википедии [1] или здесь же [2]. Причина в том, что в распакованном виде в UTF-8 русским буквам отведены 2-байтные коды в отличие от английских и большей части букв западноевропейских языков, которые записывают 1-байтными кодами. [1] https://en.wikipedia.org/wiki/UTF-8#Comparison_with_single-b... [2] https://www.opennet.me/openforum/vsluhforumID1/51935.html
- Отказаться от UTF-8, eRIC, 08:49 , 07-Авг-17 (3) +1
>> ... условие (распаковка) - надуманно > А понимаешь, если не паковать, то ответ тривиален. В случае русского языка > UTF-8 уступает вдвое любой распространённой двуязычной кодировке по занимаемому месту > на диске и энергозатратам на копирование и передачу. Ты можешь почитать > об этом, например, в Википедии [1] или здесь же [2]. > Причина в том, что в распакованном виде в UTF-8 русским буквам отведены > 2-байтные коды в отличие от английских и большей части букв западноевропейских > языков, которые записывают 1-байтными кодами. > [1] https://en.wikipedia.org/wiki/UTF-8#Comparison_with_single-b... > [2] https://www.opennet.me/openforum/vsluhforumID1/51935.html тогда в чем проблема, если знаете что под Unicode кодировку выделяются 2 байта и более? (UTF-8, UTF-16, UTF-32 и т.д.). Не нравится Unicode, не используйте, за универсальность нужно чем-то жертвовать >английских и большей части букв западноевропейских языков, которые записывают 1-байтными кодами потому что большинство этих букв покрываются ASCII таблицей, и в Unicode таблице тоже соответствуют первым 128 или 255 символам
- Отказаться от UTF-8, Sergey Maslennikov, 18:17 , 07-Авг-17 (13) +1
> в чем проблема, если знаетеНе помогает :( > под Unicode кодировку выделяются 2 байта и более ... Под кириллическую букву. И вот если выделенное вместе с запихнутыми туда кодами букв запаковать, то получите случай, проблема для которого задана в исходном посте.
- Отказаться от UTF-8, ПавелС, 10:25 , 07-Авг-17 (4)
>> ... условие (распаковка) - надуманно > А понимаешь, если не паковать, то ответ тривиален. В случае русского языка > UTF-8 уступает вдвое любой распространённой двуязычной кодировке по занимаемому месту > на диске и энергозатратам на копирование и передачу. Ты можешь почитать > об этом, например, в Википедии [1] или здесь же [2]. > Причина в том, что в распакованном виде в UTF-8 русским буквам отведены > 2-байтные коды в отличие от английских и большей части букв западноевропейских > языков, которые записывают 1-байтными кодами. > [1] https://en.wikipedia.org/wiki/UTF-8#Comparison_with_single-b... > [2] https://www.opennet.me/openforum/vsluhforumID1/51935.html Современность это UTF-8. Переданный файл при наличии шрифтов правильно отобразиться в любом регионе мира. В случае например с koi8-r это уже будет затруднительно. Процессоры и гигабайты уже не проблема.
- Отказаться от UTF-8, Andrey Mitrofanov, 13:21 , 07-Авг-17 (6) +1
> регионе мира. В случае например с koi8-r это уже будет затруднительно. > Процессоры и гигабайты уже не проблема.А экзабайты им.депутата Яровой?....
- Отказаться от UTF-8, ыы, 13:43 , 07-Авг-17 (7) +2
>> регионе мира. В случае например с koi8-r это уже будет затруднительно. >> Процессоры и гигабайты уже не проблема. > А экзабайты им.депутата Яровой?....Сформированы данными не имеющими к описанной проблеме отношения.
- Отказаться от UTF-8, Anonimus, 13:46 , 07-Авг-17 (8)
>> регионе мира. В случае например с koi8-r это уже будет затруднительно. >> Процессоры и гигабайты уже не проблема. > А экзабайты им.депутата Яровой?....А вот тут тогда вступает закон - а где это смогут прочитать? Без перекодировщиков koi8-r на Windows прочитать не смогут (а большинство пользователей как раз на ней), а UTF читаема. И опять же на сегодняшний момент большинство программ пишут свои сообщения в UTF, то есть у вас появляются накладные расходы изначального перекодирования UTF -> koi8-r, затем обработка и хранение, а потом опять накладные расходы перекодирования koi8-r -> UTF (для отображения). И не факт что конвертация у вас нормально пройдет (ничего не потеряется, нигде не застопорится).
- Отказаться от UTF-8, Sergey Maslennikov, 17:15 , 07-Авг-17 (9) +1
> в любом регионе мира. В случае например с koi8-r это уже > будет затруднительно.Ну, мы им инструкцию в регион зашлём. На utf-8 напишем, чтоб поняли уже наконец проблему нашу.
- Отказаться от UTF-8, Andrey Mitrofanov, 17:36 , 07-Авг-17 (10) +1
>> в любом регионе мира. В случае например с koi8-r это уже >> будет затруднительно. > Ну, мы им инструкцию в регион зашлём. На utf-8 напишем, чтоб поняли > уже наконец проблему нашу.У вас там никто задачу сформулировать не может? "если бы, да кабы", "да быстрее/бедленне, да больше/меньше", "да керосина сэкономить/потратить", "да в регионах не поймут/объясним". Секретное военное оружие -- прямо на поенете дизайните? Или думскую сис-му управления конт-тентами? Или гипертекстовый "Российский" инетернет? Или просто в поисках чего б "такого" накрутить заказчику... Вопросы надо задавать не про "вот тут у меня байтики, два или полтора". Задача ставится не так.
- Отказаться от UTF-8, Sergey Maslennikov, 17:43 , 07-Авг-17 (11)
> байтики, два или полтора300 АК не хотите? Исходное сообщение читали?
- Отказаться от UTF-8, Andrey Mitrofanov, 19:08 , 07-Авг-17 (15) +1
>> байтики, два или полтора > 300 АК не хотите? Исходное сообщение читали?Архиватор выбирается по "качелям" сжатие/время. Ну, кому, мож, и керосин экономить надо... Этих разнообразных архиваторов -- десятки. И _даже_ ключами xz можно весьма разные результаты получать -- сравните на своих карениных xz -1, -3, 5, -5, -1e, -3e, -9e по времени и сжатию. Откуда у Вас взялось "странное" желание делать архиватор-в-архиваторе (кодировкой "второй байтик" выжимать)? Импортозамещение, "отсель грозить мы будем шведам"??... Ещё раз: я хочу не 200 или 300 АК-47, а постановки задачи: с таких то ограничекниях надо достичь $того-то. А, впрочем, не.... зачем оно мне? ...не-не-не, не хочу. Но чем же было "Импортозамещение" в эмбрионе слегка интересно: "программистские" искривления очень забавны. Наверное... Я надеюсь.
- Отказаться от UTF-8, Sergey Maslennikov, 12:51 , 09-Авг-17 (52) +1
> Этих разнообразных архиваторов -- десятки.xz был у меня на лаптопе. > И _даже_ ключами xz можно весьма разные результаты получать -- сравните на > своих карениных xz -1, -3, 5, -5, -1e, -3e, -9e по > времени и сжатию. Ну, я внёс свои две копейки. Могу ещё добавить, что распространённая программка sort сортирует UTF-8 в 1.7 раза медленнее, чем KOI8-R. Другие тоже могли бы что-то в этом направлении сделать, если нужным сочтут.
- Отказаться от UTF-8, Sergey Maslennikov, 08:40 , 08-Авг-17 (20) +1
> при наличии шрифтов правильно отобразиться в любом регионе мира.Согласен с вами. Кириллический текст UTF-8 не отобразится, если в шрифте кириллицы нет. А если есть, то упомянутая вами KOI8-R отобразится быстрее, чем UTF-8, т. к. программа, которая будет отображать, тексты любых исходных кодировок сначала конвертирует в тексты унифицированной кодировки, с которыми потом и будет что-то делать -- отображать, например. Обычно это -- 4-байтная Unicode -- что-то типа UTF-32 (хороша тем, что длина кода не меняется от алфавита к алфавиту). Всё это, однако, нужно доказать. У меня есть _подозрение_ (не доказательство и даже не утверждение), что конвертация в унифицированное представление и обратно в среднем происходит быстрее, если исходная кодировка однобайтовая (упомянутая вами KOI8-R, например). Подозрение основано на том, что популярные программы из популярного дистрибутива Debian на моём лаптопе конвертируют KOI8-R -> UTF-32 -> KOI8-R быстрее, чем UTF-8 -> UTF-32 -> UTF-8. Основание слабовато, поэтому исходный пост -- это конкретный вопрос (можно ли доказать хотя бы это?), а не то, на что здесь пока пытаются отвечать.
- Отказаться от UTF-8, ыы, 09:49 , 08-Авг-17 (21)
>[оверквотинг удален] > что-то типа UTF-32 (хороша тем, что длина кода не меняется от > алфавита к алфавиту). Всё это, однако, нужно доказать. > У меня есть _подозрение_ (не доказательство и даже не утверждение), что конвертация > в унифицированное представление и обратно в среднем происходит быстрее, если исходная > кодировка однобайтовая (упомянутая вами KOI8-R, например). Подозрение основано на том, > что популярные программы из популярного дистрибутива Debian на моём лаптопе конвертируют > KOI8-R -> UTF-32 -> KOI8-R быстрее, чем UTF-8 -> UTF-32 -> > UTF-8. Основание слабовато, поэтому исходный пост -- это конкретный вопрос (можно > ли доказать хотя бы это?), а не то, на что здесь > пока пытаются отвечать.Смутные сомнения терзают меня. Вот вам строгое доказательство: Если m - "байтовость" кодировки (целые числа больше нуля) и r- затраты на единичное преобразование одного байта то m*r для многобайтных кодировок будет больше m*r для однобайтных Вы этого хотели? Вы в пятом или четвертом классе учитесь?
- Отказаться от UTF-8, Sergey Maslennikov, 10:30 , 08-Авг-17 (22)
> Вы в пятом или четвертом классе учитесь?А что, если бы я в четвёртом классе учился, вы не стали бы со мной разговаривать? Вот недавно физтеховские школьники выиграли международную олимпиаду по физике -- каждый взял высшую медаль. Смогли бы вы обыграть этих "детишек" в решении задач, а пусть даже, по программированию? > Вот вам строгое доказательство И вот смотрите. utf-8, вообще говоря, кодировка переменной длины. Вероятно, алгоритм, который разбирает текст в ней, не знает какой длины придёт к нему следующий код. Где это в вашем "доказательстве"? > Вы этого хотели? Не совсем.
- Отказаться от UTF-8, Andrey Mitrofanov, 11:15 , 08-Авг-17 (23) +1
> Вот недавно физтеховские школьники выиграли международную олимпиаду по физике -- каждый > взял высшую медаль. Смогли бы вы обыграть этих "детишек" в решении > задач, а пусть даже, по программированию?Ладно, рассказывай: * в каком классе / на каком курсе учишься, по какой специальности / безработный / на каникулах / на какой должности работаешь + форум, кажется, тут занят удалённым "программированием" с не-программистом, я наконец получу ответ хоть на один вопрос?? //да, кстати, я не программист и не буду таковым по должности: образование не позволяет. но кидане пальцами коллегами "по не-цеху" изучаю с интересом! * откуда взял интересные мысли из первого поста -- неужели сам придумал?! * что сказал начальник / воспитательница мариванна / мама-папа, прочитав первый пост? если не читал(а) -- дай прочитать, сказанное внимательно запиши? * знаком ли ты лично с "физтеховскими школьниками" и какое отношение имеешь к их Победе? Какое отношение имеет их Победа к твоим полутора-байтным затруднениям из первого поста? Обоснуй.
- Отказаться от UTF-8, Sergey Maslennikov, 15:36 , 08-Авг-17 (26) +1
> знаком ли ты лично с "физтеховскими школьниками"Нет. > какое отношение имеешь к их Победе? Завидую. > Какое отношение имеет их Победа к предположению о моём классе (4-м или 5-м)? Мне кажется, что эти товарищи могли бы "навалять" ыы, как, впрочем, и мне в решении задач по программированию, несмотря на то, что они моложе нас. Использовать для принижения сравнение со школьником неправильно -- нужно какое-то другое.
- Отказаться от UTF-8, Sergey Maslennikov, 15:41 , 08-Авг-17 (27) +1
> удалённым "программированием" с не-программистомДа, верно.
- Отказаться от UTF-8, ыы, 11:33 , 08-Авг-17 (24) –1
>> Вы в пятом или четвертом классе учитесь? > А что, если бы я в четвёртом классе учился, вы не стали > бы со мной разговаривать?Ваш вопрос - бестолковый. Очевидно же что преобразование многобайтной кодировки может занимать на конкретном железе большее время просто потому что в многобайтной кодировке- больше байт. Объем лядь, данных больше для переработки И ПОЭТОМУ лять, оно обрабатывается дольше. Строгое доказательство - m(многобайтная)*r > m(однообайтная)*r Например 4*1 > 1*1 поскольку проведя умножение получим 4>1 НО! На конкретном железе. Поскольку в зависимости от железа - обработку многобайтных данных можно сделать столь же быстрой как и однобайтных. Например можно реализовать в железе любую операцию такого преобразования за один такт. И тогда ваш тест показал бы что конвертация строк из многобайтных символов занимают не больше времени чем если бы символы были однобайтные.. и вы долго думали бы почему. Такой вопрос мог бы задать школьник... Ответ на ваш вопрос- элементарен, банален, Суть вашего вопроса - наивна и бестолкова. А разница в том учитесь ли вы в школе или уже серьезный дядечка мучающийся бездельем - в том, что если относится к вашему вопросу серьезно- то он вообще говоря странный. Но если вы школьник- то такой бестолковый вопрос в общем... ну.. формулу строгого доказательства я вам привел. > Вот недавно физтеховские школьники выиграли международную олимпиаду по физике -- каждый > взял высшую медаль. Смогли бы вы обыграть этих "детишек" в решении > задач, а пусть даже, по программированию? Вы из их числа? Надеюсь они не стали бы задавать тот вопрос что задали вы :) >> Вот вам строгое доказательство > И вот смотрите. utf-8, вообще говоря, кодировка переменной длины. Вероятно, алгоритм, который > разбирает текст в ней, не знает какой длины придёт к нему > следующий код. Где это в вашем "доказательстве"? Ну, скажу что у вас плохо с абстрактным мышлением. Для доказательства - переменная длинна или постоянная - не имеет значения. Для каждой любой итерации - m(многобайт)*r > m(одинбайт)*r Любое ваше надуманное "доказательство путем перепаковки АК" упрется в эту формулу.
- Отказаться от UTF-8, Sergey Maslennikov, 17:00 , 08-Авг-17 (28) +1
> Для каждой любой итерации - m(многобайт)*r > m(одинбайт)*rm(многобайт)*r >= m(одинбайт)*r Вы, конечно, можете считать меня сволочью и недоумком, но мне нужна была референсная нитка о том, что двуязычные кодировки могут иметь такое же право на существование, как UTF-8, и я её с вашей помощью сделал.
- Отказаться от UTF-8, ыы, 17:31 , 08-Авг-17 (30) –1
>> Для каждой любой итерации - m(многобайт)*r > m(одинбайт)*r > m(многобайт)*r >= m(одинбайт)*r > Вы, конечно, можете считать меня сволочью и недоумком, но мне нужна была > референсная нитка о том, что двуязычные кодировки могут иметь такое же > право на существование, как UTF-8, и я её с вашей помощью > сделал.m(многобайт)*r > m(одинбайт)*r
- Отказаться от UTF-8, Sergey Maslennikov, 17:37 , 08-Авг-17 (32) +1
> m(многобайт)*r > m(одинбайт)*rЯ имел в виду, что английские буквы, запятые, пробелы и знаки всякие в многобайтной кодировке одним байтом кодированы. Если текст состоит только из них, то m(многобайт)*r == m(одинбайт)*r
- Отказаться от UTF-8, ыы, 18:29 , 08-Авг-17 (36) –1
>> m(многобайт)*r > m(одинбайт)*r > Я имел в виду, что английские буквы, запятые, пробелы и знаки всякие > в многобайтной кодировке одним байтом кодированы. Если текст состоит только из > них, то > m(многобайт)*r == m(одинбайт)*r Нет m(многобайт)*r > m(одинбайт)*r Уясните наконец как выглядит текст в многобайтной кодировке и не занимайтесь фантазированием.
- Отказаться от UTF-8, Sergey Maslennikov, 18:39 , 08-Авг-17 (37) +1
> Уясните наконец как выглядит текст в многобайтной кодировке и не занимайтесь фантазированием.The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single octet with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well [1]. [1] https://en.wikipedia.org/wiki/UTF-8
- Отказаться от UTF-8, ыы, 18:57 , 08-Авг-17 (38) –1
>> Уясните наконец как выглядит текст в многобайтной кодировке и не занимайтесь фантазированием. > The first 128 characters of Unicode, which correspond one-to-one with ASCII, are > encoded using a single octet with the same binary value as > ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as > well [1]. > [1] https://en.wikipedia.org/wiki/UTF-8 Откройте Notepad напечатайте букву a (английскую) сохраните как utf-8 снова сохраните как ansi откройте проводник и сравните размер файлов.. Крепко задумайтесь, той ли работой вы занимаетесь.
- Отказаться от UTF-8, Sergey Maslennikov, 19:03 , 08-Авг-17 (39) +1
- Отказаться от UTF-8, Sergey Maslennikov, 09:10 , 09-Авг-17 (40) +1
> Откройте NotepadЭтот ваш Notepad, видимо, что-то специальное для программистов. У нас-то, простых людей, таких программ нет. Уж, звиняйте. > напечатайте букву a (английскую) > сохраните как utf-8 > снова сохраните как ansi А вы не могли бы добавить к букве 'a' ещё буковку 'b' и сообщить нам насколько поменяется длина файла? Ну, или, -- написать нам сюда коды из вашего файла с буковкой 'a' в исчислении с удобным для вас основанием? -- мы тогда расскажем, что там с вашим Notepad-ом не так.
- Отказаться от UTF-8, ыы, 10:20 , 09-Авг-17 (41)
>> Откройте Notepad > Этот ваш Notepad, видимо, что-то специальное для программистов. У нас-то, простых людей, > таких программ нет. Уж, звиняйте.Это ваши проблемы. Не мои :) >> напечатайте букву a (английскую) >> сохраните как utf-8 >> снова сохраните как ansi > А вы не могли бы добавить к букве 'a' ещё буковку 'b' > и сообщить нам насколько поменяется длина файла? на 1 байт естественно. А вы ожидали чегото еще? > Ну, или, -- написать нам сюда коды из вашего файла с буковкой > 'a' в исчислении с удобным для вас основанием? -- мы тогда > расскажем, что там с вашим Notepad-ом не так. Сомневаюсь что вы понимаете о чем говорите.
- Отказаться от UTF-8, Sergey Maslennikov, 10:26 , 09-Авг-17 (42) +1
> на 1 байт естественно. А вы ожидали чегото еще?Ну, тогда в любой кодировке байтовость одинаковая. Или как?
- Отказаться от UTF-8, ыы, 11:04 , 09-Авг-17 (44)
>> на 1 байт естественно. А вы ожидали чегото еще? > Ну, тогда в любой кодировке байтовость одинаковая. Или как?Интересная мысль :) Без указания BOM - и при наличии только английских букв - вам не удастся доказать что используемая кодировка - UTF-8. Хотя.. можете попробовать :)
- Отказаться от UTF-8, Sergey Maslennikov, 11:10 , 09-Авг-17 (45) +1
> Без указания BOM - и при наличии только английских букв - вам > не удастся доказать что используемая кодировка - UTF-8. > Хотя.. можете попробовать :)Очень просто. The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single octet with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well [1]. Если она ASCII, то она же и UTF-8. Можно наоборот, если хотите :) BOM не обязательна при хранении и обработке текста. [1] https://en.wikipedia.org/wiki/UTF-8
- Отказаться от UTF-8, ыы, 12:51 , 09-Авг-17 (51) +1
> Если она ASCII, то она же и UTF-8. Можно наоборот, если хотите > :) Человеку у которого ASCII она же UTF-8 и наоборот - сам черт не брат... - Отказаться от UTF-8, Sergey Maslennikov, 12:55 , 09-Авг-17 (54) +1
> Человеку у которого ASCII она же UTF-8 и наоборот - сам черт > не брат...Согласен. Это он эту ... UTF-8 придумал ...
- Отказаться от UTF-8, Аноним, 08:09 , 11-Авг-17 (72) –1
>Без указания BOM - и при наличии только английских букв >- вам не удастся доказать что используемая кодировка - UTF-8. >Человеку у которого ASCII она же UTF-8 и наоборот - сам черт >не брат...Здается мне, что вы оба не рограммисты. BOM - это Byte Order Mask. Вы бы хоть иногда в википедию заглядывали https://en.wikipedia.org/wiki/Byte_order_mark. Ясно же написано, что она опциональна "BOM use is optional". В вашем случае ее вставил notepad. Если создать файл echo -n a > test, то он будет совершенно одинаков в UTF-8, ASCII и даже WINDOWS-1251. Для английских букв ASCII и UTF-8 совершенно идентичны.
- Отказаться от UTF-8, ыы, 09:25 , 11-Авг-17 (74)
>>Без указания BOM - и при наличии только английских букв >>- вам не удастся доказать что используемая кодировка - UTF-8. >>Человеку у которого ASCII она же UTF-8 и наоборот - сам черт >>не брат... > Здается мне, что вы оба не рограммисты. BOM - это Byte Order > Mask. Вы бы хоть иногда в википедию заглядывали https://en.wikipedia.org/wiki/Byte_order_mark. > Ясно же написано, что она опциональна "BOM use is optional". В > вашем случае ее вставил notepad. Если создать файл echo -n a > > test, то он будет совершенно одинаков в UTF-8, ASCII и > даже WINDOWS-1251. Для английских букв ASCII и UTF-8 совершенно идентичны.Правильно. ПОЭТОМУ говорить что у вас UTF-8 имея только английские буквы - нельзя. Нет оснований считать что у вас многобайтная кодировка. Она у вас любая а не многобайтная. Доказать что вы используете многобайтную кодировку вы можете только если пометите ее BOM или используете буквы этой кодировки непосредственно. - Отказаться от UTF-8, ыы, 09:35 , 11-Авг-17 (75)
> используете буквы этой кодировки непосредственно.Имеется ввиду многобайтные буквы...
- Отказаться от UTF-8, Аноним, 09:39 , 11-Авг-17 (76) –1
> Правильно. ПОЭТОМУ говорить что у вас UTF-8 имея только английские буквы - > нельзя. Нет оснований считать что у вас многобайтная кодировка. Она у > вас любая а не многобайтная. > Доказать что вы используете многобайтную кодировку вы можете только если пометите ее > BOM или используете буквы этой кодировки непосредственно.Извините, но Вы написали глупость полнейшую. Во-первых задача не требует этого доказательства. Вы же знаете в какой кодировке записаны ваши файлы. Вы не использовали никакую другую кроме UTF-8. Во-вторых, что это за приём в доказательстве -помечать текст BOM. Это ничего не дает а только усложняет его.
- Отказаться от UTF-8, ыы, 09:52 , 11-Авг-17 (78) –1
>> Правильно. ПОЭТОМУ говорить что у вас UTF-8 имея только английские буквы - >> нельзя. Нет оснований считать что у вас многобайтная кодировка. Она у >> вас любая а не многобайтная. >> Доказать что вы используете многобайтную кодировку вы можете только если пометите ее >> BOM или используете буквы этой кодировки непосредственно. > Извините, но Вы написали глупость полнейшую. Во-первых задача не требует этого доказательства. Требует. m(многобайт)*r > m(одинбайт)*r > Вы же знаете в какой кодировке записаны ваши файлы.
Нет. Пока вы не прочитали файлы- вы этого не знаете. m(многобайт)*r > m(одинбайт)*r > Вы не использовали никакую другую кроме UTF-8. но утверждать что то что вы считываете на основании получившегося содержимого - вы не можете. такой вот парадокс :) m(многобайт)*r > m(одинбайт)*r > Во-вторых, что это за приём в > доказательстве -помечать текст BOM. Это ничего не дает а только усложняет > его. Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы должны это доказать. - Отказаться от UTF-8, Аноним, 10:01 , 11-Авг-17 (79)
> Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы > должны это доказать.Вы даже не понимаете какую чушь Вы несете. Если Вы возьмете файл в WINDOWS-1251 и допишете в него BOM он станет UTF-8 что ли. Это ваше доказательство?
- Отказаться от UTF-8, ыы, 10:09 , 11-Авг-17 (80) –1
>> Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы >> должны это доказать. > Вы даже не понимаете какую чушь Вы несете. Если Вы возьмете файл > в WINDOWS-1251 и допишете в него BOM он станет UTF-8 что > ли. Это ваше доказательство?А вы попробуйте :)
- Отказаться от UTF-8, Аноним, 10:15 , 11-Авг-17 (81)
>>> Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы >>> должны это доказать. >> Вы даже не понимаете какую чушь Вы несете. Если Вы возьмете файл >> в WINDOWS-1251 и допишете в него BOM он станет UTF-8 что >> ли. Это ваше доказательство? > А вы попробуйте :) А вот от ответа уходить не надо. Отвечайте за свои слова. Станет или не станет?
- Отказаться от UTF-8, ыы, 10:27 , 11-Авг-17 (82) –1
>>>> Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы >>>> должны это доказать. >>> Вы даже не понимаете какую чушь Вы несете. Если Вы возьмете файл >>> в WINDOWS-1251 и допишете в него BOM он станет UTF-8 что >>> ли. Это ваше доказательство? >> А вы попробуйте :) > А вот от ответа уходить не надо. Отвечайте за свои слова. Станет > или не станет?А я не ухожу. Вы попробуйте прежде чем болтать ерунду. - Отказаться от UTF-8, ыы, 10:33 , 11-Авг-17 (84) –1
>>>> Чтобы утверждать (в строгом смысле) что вы работаете с многобайтной кодировкой- вы >>>> должны это доказать. >>> Вы даже не понимаете какую чушь Вы несете. Если Вы возьмете файл >>> в WINDOWS-1251 и допишете в него BOM он станет UTF-8 что >>> ли. Это ваше доказательство? >> А вы попробуйте :) > А вот от ответа уходить не надо. Отвечайте за свои слова. Станет > или не станет?Вы глубоко невежественны в предмете разговора.Извините. Ответ: с точки зрения ПО которое этот файл будет читать - станет. В этом легко убедится проведя опыт с тем же Notepad. Что я собственно вам и посоветовал. Вам бы стоило СПЕРВА провести опыт а потом.. писать сюда глупости. Но дело деже не в этом. Дело в том, что когда у вас есть два файла, кодировку которых вы не знаете, установить какая она там- можно только прочитав эти файлы и подобрав подходящую кодировку по смыслу. и BOM в начале файла-это один из признаков по которому нам следует отнести содержимое файла к кодированному по UTF-8. - Отказаться от UTF-8, ыы, 10:38 , 11-Авг-17 (85)
>[оверквотинг удален] > Ответ: с точки зрения ПО которое этот файл будет читать - станет. > В этом легко убедится проведя опыт с тем же Notepad. > Что я собственно вам и посоветовал. Вам бы стоило СПЕРВА провести опыт > а потом.. писать сюда глупости. > Но дело деже не в этом. Дело в том, что когда > у вас есть два файла, кодировку которых вы не знаете, установить > какая она там- можно только прочитав эти файлы и подобрав подходящую > кодировку по смыслу. > и BOM в начале файла-это один из признаков по которому нам следует > отнести содержимое файла к кодированному по UTF-8.То есть человек, утверждающий что я ( Я!!! хаха :) ) говорю глупости, просто не понимает что в файлах - нет кодировки. там есть только поток байт, и кодировка- это инструмент интерпретации этого потока байт... И принимаем мы решение какая там кодировка- только попробовав понять что там... - Отказаться от UTF-8, Аноним, 10:59 , 11-Авг-17 (86)
> я ( Я!!! хаха :) ) говорю глупостиНе позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет WINDOWS-1251 текст UTF-8 или нет, если вставить BOM.
- Отказаться от UTF-8, ыы, 11:14 , 11-Авг-17 (87) –2
>> я ( Я!!! хаха :) ) говорю глупости > Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет > WINDOWS-1251 текст UTF-8 или нет, если вставить BOM.Разве спокойно и вежливо объяснять невежественному человеку его заблуждения- это позорно? Вы не понимаете очень важных вещей в том предмете, который пытаетесь обсуждать. Например вы не понимаете что в файлах - кодировки нет. Текст сохраненный вами в одной кодировке- может быть прочитан другим человеком В ДРУГОЙ кодировке. И это нормально. Демонстрацию этого я вам приводил. Даже прямым текстом отвечал. А вы проигнорировав мой прямой ответ снова его требуете. Следовательно - вы троль. - Отказаться от UTF-8, Аноним, 11:28 , 11-Авг-17 (89)
>>> я ( Я!!! хаха :) ) говорю глупости >> Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет >> WINDOWS-1251 текст UTF-8 или нет, если вставить BOM. > А вы проигнорировав мой прямой ответ снова его требуете. > Следовательно - вы троль.Троль -это тот, кто на простые вопросы не отвечает. На ваш "ответ" Вы вопрос получили. Следовательно троль -вы.
- Отказаться от UTF-8, ыы, 11:34 , 11-Авг-17 (90) –1
>>>> я ( Я!!! хаха :) ) говорю глупости >>> Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет >>> WINDOWS-1251 текст UTF-8 или нет, если вставить BOM. >> А вы проигнорировав мой прямой ответ снова его требуете. >> Следовательно - вы троль. > Троль -это тот, кто на простые вопросы не отвечает. На ваш "ответ" > Вы вопрос получили. Следовательно троль -вы.Вот мой ответ (http://www.opennet.me/openforum/vsluhforumID1/96963.html#84): "Ответ: с точки зрения ПО которое этот файл будет читать - станет." И объяснено почему. Вот ваш вопрос в ответ на мой ответ:
"Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет WINDOWS-1251 текст UTF-8 или нет, если вставить BOM. "
- Отказаться от UTF-8, Аноним, 11:42 , 11-Авг-17 (91)
>>>>> я ( Я!!! хаха :) ) говорю глупости >>>> Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет > "Ответ: с точки зрения ПО которое этот файл будет читать - станет."Вы что, в пятом классе учитесь, какая у ПО может быть точка зрения?
- Отказаться от UTF-8, ыы, 11:53 , 11-Авг-17 (92)
>>>>>> я ( Я!!! хаха :) ) говорю глупости >>>>> Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет >> "Ответ: с точки зрения ПО которое этот файл будет читать - станет." > Вы что, в пятом классе учитесь, какая у ПО может быть точка > зрения?Когда вы подрастете, и возможно все таки окончите школу, и возможно сможете поступить в высшее учебное заведение, и даже, чем черт не шутит попадете на предмет который называется "русский язык".... Не исключено, что вам объяснят что такое "переносное употребление форм глагола". Хотя по и идее, должны были вам уже это объяснить но вы вероятно на урок не явились раз моя фраза ввела вас в такое состояние :)
- Отказаться от UTF-8, Аноним, 12:06 , 11-Авг-17 (93) –1
> "переносное употребление форм глагола"Какого глагола форм? Уверен, что вы их не знаете, как не знаете о чем пишете и никогда не слышали о том, что такое доказательство.
- Отказаться от UTF-8, Andrey Mitrofanov, 11:17 , 11-Авг-17 (88)
> Не позорьтесь. Вернитесь к вопросу и спокойно ответьте без Ваших мантр станет > WINDOWS-1251 текст UTF-8 или нет, если вставить BOM.:+))) А вот такой вот роезультат - File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xf0 in position 20: invalid continuation byte считаем, как "стал" или "не слал"? Не, там не с BOM-ом дело было. Так, на всякий, "уточняю" $) вопрос. --По строгим правилам гольфа? --But of course!
- Отказаться от UTF-8, Sergey Maslennikov, 11:41 , 09-Авг-17 (47) +1
> Интересная мысль :) > ... BOM ...И вот, кстати, заметьте, Notepad оказался не моей проблемой.
- Отказаться от UTF-8, ыы, 12:51 , 09-Авг-17 (53) +1
>> Интересная мысль :) >> ... BOM ... > И вот, кстати, заметьте, Notepad оказался не моей проблемой.Вы просто не поняли сути проблемы.
- Отказаться от LSD-8, Andrey Mitrofanov, 10:32 , 09-Авг-17 (43) –1
- Отказаться от LSD-8, Sergey Maslennikov, 11:26 , 09-Авг-17 (46) +1
> Тред - памятник себе.Ну, а чего, пусть сходят, посмотрят. Вам, вот, интересно же.
- Отказаться от LSD-8, Sergey Maslennikov, 20:51 , 09-Авг-17 (56) +1
Про памятник, всё-таки, вы со зла. В организации, где я работаю, есть небольшая инфраструктура с почтой, среверами, много чем самописным, которую поддерживает 2 непрофессионала (как и вы, может быть). И тот второй насчёт перекодирования в UTF-8 говорит примерно то же, что и все. То, что мы делаем по профессии, включает программирование, но русский язык там не нужен, а вот в инфраструктуре -- да, много чего в разных кодировках, включая UTF-8. И мы ничего с этим не делали бы, но повсеместная агитация за повсеместную UTF-8 понятно к чему приведёт (ну, opennet.ru придётся на неё переключить, например). Вот я и решил сделать референсную тему, в которой другие участники (не я) могли бы квалифицированно объяснить недостатки UTF-8. Тогда любому можно было бы сказать, что так думаю не я, а совсем другие люди, что гораздо убедительнее. Ну, да, я завяз, получилось плохо. Уж извините.Намерение вбросить идею о том, что не нужно так уж сильно агитировать за повсеместность UTF-8, тоже было, конечно.
- Отказаться от LSD-8, ыы, 07:40 , 10-Авг-17 (58) –1
>[оверквотинг удален] > не нужен, а вот в инфраструктуре -- да, много чего в > разных кодировках, включая UTF-8. И мы ничего с этим не делали > бы, но повсеместная агитация за повсеместную UTF-8 понятно к чему приведёт > (ну, opennet.ru придётся на неё переключить, например). Вот я и решил > сделать референсную тему, в которой другие участники (не я) могли бы > квалифицированно объяснить недостатки UTF-8. Тогда любому можно было бы сказать, что > так думаю не я, а совсем другие люди, что гораздо убедительнее. > Ну, да, я завяз, получилось плохо. Уж извините. > Намерение вбросить идею о том, что не нужно так уж сильно агитировать > за повсеместность UTF-8, тоже было, конечно.Шел 2017 год. В космосе летала вторая китайская космическую станция. Некоторые представители памятников продолжали бороться за революционный вопрос - КОИ или UTF.
- Отказаться от LSD-8, Sergey Maslennikov, 08:04 , 10-Авг-17 (59) +2
> представители памятников продолжали боротьсяСнова начали :) > за революционный вопрос - КОИ или UTF. Но, всё-таки, раньше боролись за КОИ, а теперь за вопрос. Его и задать-то почти невозможно. И не против UTF.
- Отказаться от UTF-8, Anonymoustus, 05:31 , 03-Окт-17 (101)
> мне нужна была референсная нитка о том, что двуязычные кодировки могут иметь такое же право на существование, как UTF-8, и я её с вашей помощью сделал.Мама дорогая, это ж какое-то просто безумие.
- Отказаться от UTF-8, ыы, 13:05 , 07-Авг-17 (5)
>> ... условие (распаковка) - надуманно > А понимаешь, если не паковать, то ответ тривиален. В случае русского языка > UTF-8 уступает вдвое любой распространённой двуязычной кодировке по занимаемому месту > на диске и энергозатратам на копирование и передачу. Ты можешь почитать > об этом, например, в Википедии [1] или здесь же [2]. > Причина в том, что в распакованном виде в UTF-8 русским буквам отведены > 2-байтные коды в отличие от английских и большей части букв западноевропейских > языков, которые записывают 1-байтными кодами. > [1] https://en.wikipedia.org/wiki/UTF-8#Comparison_with_single-b... > [2] https://www.opennet.me/openforum/vsluhforumID1/51935.html UTF-8 придумана не для того чтобы обеспечить максимально быстрое исполнение или минимальный размер файлов. Вы смотрите только на одну сторону большой комплексной проблемы.
- Отказаться от UTF-8, Sergey Maslennikov, 17:50 , 07-Авг-17 (12) +1
> UTF-8 придумана не для того чтобы обеспечить максимально быстрое > исполнение или минимальный размер файлов.А что, люди ни этого ли хотят? На размер запакованного файла выбор кодировки влияет слабо, а максимально быстрой, предположительно, окажется обработка английского текста. Получается, что если сидеть на одной лишь UTF-8, то для английского языка оптимальная кодировка существует, а для русского -- нет. > Вы смотрите только на одну сторону большой комплексной проблемы. А больше пока некуда смотреть. Если окажется, что в тестах UTF-8 не уступает 1-байтным кодировкам, или это можно доказать, то и проблемы нет. Тогда только UTF-8. Или, о какой проблеме вы пишете?
- Отказаться от UTF-8, ыы, 19:12 , 07-Авг-17 (16) –1
>> UTF-8 придумана не для того чтобы обеспечить максимально быстрое >> исполнение или минимальный размер файлов. > А что, люди ни этого ли хотят?представьте себе.... Люди -хотят как правило работать поменьше и получать побольше. И железо- дешевле труда программистов. Поэтому если одой кодировкой можно решить проблему на сотне языков - то следует выбрать такую кодировку, а не изобретать и потом реализовывать сотню 8-ми битных кодировок. Это элементарно... > На размер запакованного файла выбор кодировки влияет слабо, а максимально быстрой, предположительно, > окажется обработка английского текста. Получается, что если сидеть на одной лишь > UTF-8, то для английского языка оптимальная кодировка существует, а для русского > -- нет. >> Вы смотрите только на одну сторону большой комплексной проблемы. > А больше пока некуда смотреть. Если окажется, что в тестах UTF-8 не > уступает 1-байтным кодировкам, или это можно доказать, то и проблемы нет. > Тогда только UTF-8. > Или, о какой проблеме вы пишете? О выборе решения для ИТ-инфраструктуры. Незначительное уменьшение скорости обработки (ваши 300 АК- абсолютно высосанный из пальца пример , отвлеченный и взятый с потолка. и никому ненужный и ничего не доказывающий.) - не является решающим фактором в подавляющем большинстве ИТ инфраструктур. И вам имхо стоит заняться реальными проблемами а не тем чем занимается руководящий работник когда ему делать нечего...
- Отказаться от UTF-8, Sergey Maslennikov, 17:31 , 08-Авг-17 (31) +1
> представьте себе.... > Люди -хотят как правило работать поменьше и получать побольше. И железо- дешевле > труда программистов.Верно, но людей больше, чем программистов.
- Отказаться от UTF-8, Andrey Mitrofanov, 17:44 , 08-Авг-17 (33) –1
>> представьте себе.... >> Люди -хотят как правило работать поменьше и получать побольше. И железо- дешевле >> труда программистов. > Верно, но людей больше, чем программистов.Вы хотели сказать, программисты не люди?
- Отказаться от UTF-8, Sergey Maslennikov, 17:51 , 08-Авг-17 (34) +1
> Вы хотели сказать, программисты не люди?N_людей-непрограммистов + N_людей-программистов >> N_людей-программистов N_людей-непрограммистов + N_людей-программистов == N_людей -- вот их и больше :)
- Отказаться от UTF-8, Sergey Maslennikov, 17:57 , 08-Авг-17 (35) +1
> Вы хотели сказать, программисты не люди?Программистам нужно, чтобы они кому-нибудь были нужны. Ну, т.е., им пришлось бы считаться с остальными.
- Отказаться от UTF-8, Andrey Mitrofanov, 19:14 , 07-Авг-17 (17)
>для английского языка оптимальная кодировка существует, а для русского > -- нет."Оптимальная" по каким параметрам?? ??"Желаю, чтобы всем!"(ц)ШариковПП Преждевременная обоюдоострая посконно-хлебосольно-пезанская Оптимизация всея трафика куда-то туда?
- Отказаться от UTF-8, Sergey Maslennikov, 12:30 , 09-Авг-17 (49) +1
> "Оптимальная" по каким параметрам?? ??"Желаю, чтобы всем!"(ц)ШариковПП По времени обработки.
- Отказаться от UTF-8, Andrey Mitrofanov, 12:46 , 09-Авг-17 (50)
>> "Оптимальная" по каким параметрам?? ??"Желаю, чтобы всем!"(ц)ШариковПП > По времени обработки.Посмотрите memcpy().
- Отказаться от UTF-8, Sergey Maslennikov, 13:06 , 09-Авг-17 (55) +1
> Посмотрите memcpy().А зачем? -- она не имеет отношения к разбору текста, только куски целиком копирует. И в какое её место смотреть?
- Отказаться от UTF-8: memcpy(), Sergey Maslennikov, 17:04 , 23-Авг-17 (95) +2
> Посмотрите memcpy().Неправильно я ответил. Смысл посмотреть на memcpy() есть, если предположить, что кто-то решился бы копировать внутри программ однобайтно-кодированную кириллицу. В этом случае копирование произошло бы примерно в 1.75 раза быстрее, чем копирование того же текста в UTF-8 [1]. Функция memcpy() может быть по разному реализована, но в реализациях, которые я видел, ожидаемое время копирования должно быть пропорционально размеру копируемых данных. В UTF-8 текст в 1.75 раза длиннее, чем в KOI8-R -- вот и копирует memcpy() его во столько же раз дольше. Это же соотношение можно получить экспериментально [2]. Возможно, я не уловил суть или цель совета использовать memcpy() при оптимизации путём выбора кодировки. Ссылки / сноски: [1] -- если копировать тот же текст, что упомянут в исходном посте; [2] Экспериментальная программка -- обёртка, которую я собираюсь изредка применять для тестирования функций ICU. Здесь в качестве примера тестируемой функции я вставил memcpy(): #include <stdio.h> #include <stdlib.h> #include <time.h> #include <string.h> #include <unicode/utypes.h> #include <unicode/ucnv.h> long delta_t(struct timespec *start, struct timespec *end) { time_t sec; long nsec; if ((end->tv_nsec-start->tv_nsec)<0) { sec = end->tv_sec-start->tv_sec-1; nsec = 1000000000+end->tv_nsec-start->tv_nsec; } else { sec = end->tv_sec-start->tv_sec; nsec = end->tv_nsec-start->tv_nsec; } return sec * 1000000000l + nsec; } int main() { const char fnm_initial[] = "../../anna-karenina"; FILE *fini = fopen(fnm_initial, "r"); if (fini == NULL) { fprintf(stderr, "Can't open initial file.\n"); return -1; } fseek(fini, 0L, SEEK_END); unsigned long len = ftell(fini), size = len + 1ul; fseek(fini, 0L, SEEK_SET); printf("Allocate %lu bytes to copy file \"%s\" ... ", size, fnm_initial); fflush(stdout); char *text_koi8 = malloc(size); if (text_koi8 == NULL) { fclose(fini); fprintf(stderr, "Can't allocate memory for \"text_koi8\".\n"); return -2; } printf("Done.\n"); fflush(stdout); /* Allocated */ if(fread(text_koi8, 1ul, len, fini) != len) { free(text_koi8); fclose(fini); fprintf(stderr, "Can't read file \"%s\" into the buffer.\n", fnm_initial); return -3; } fclose(fini); text_koi8[len] = '\x0'; UErrorCode uerr = U_ZERO_ERROR; /* Here it is the example of the UTF-8 buffer exact size evaluation. It is however faster to allocate 2 * len + 1ul long buffer instaed and shrink it, after converting, by realloc() to the value returned by ucnv_convert(). */ unsigned long size_u8 = ucnv_convert("UTF-8", "KOI8-R", NULL, 0ul, text_koi8, size, &uerr); if( uerr != U_BUFFER_OVERFLOW_ERROR && uerr != U_STRING_NOT_TERMINATED_WARNING && U_FAILURE(uerr) ) { free(text_koi8); fclose(fini); fprintf(stderr, "Can't evaluate UTF-8 text buffer size.\n"); return -4; } printf("UTF-8 text buffer size = %lu bytes.\n", size_u8); char *text_utf8 = malloc(size_u8); if( text_koi8 == NULL ) { free(text_koi8); fclose(fini); fprintf(stderr, "Can't allocate memory for text_utf8.\n"); return -5; } uerr = U_ZERO_ERROR; ucnv_convert("UTF-8", "KOI8-R", text_utf8, size_u8, text_koi8, size, &uerr); if( U_FAILURE(uerr) ) { free(text_utf8); free(text_koi8); fclose(fini); fprintf(stderr, "Error converting KOI8-R text into UTF-8 text.\n"); return -6; } /* At this point we have two buffers with the same text in koi8-r and utf-8. */ /* Prepare for measurements */ char *text_koi8_a = malloc(size); if( text_koi8_a == NULL ) { free(text_utf8); free(text_koi8); fclose(fini); fprintf(stderr, " Can't allocate memory for \"text_koi8_a\".\n"); return -7; } char *text_utf8_a = malloc(size_u8); if( text_utf8_a == NULL ) { free(text_koi8_a); free(text_utf8); free(text_koi8); fclose(fini); fprintf(stderr, "Can't allocate memory for \"text_utf8_a\".\n"); return -8; } /* Buffers to copy into are ready here. */ unsigned long i; struct timespec t0, t1; long Dt_call, Dt_koi8, Dt_utf8, Dt_koi8_total = 0ul, Dt_utf8_total = 0ul; double Dt_utf8_to_Dt_koi8; for(i = 0; i < 220ul; i++) { printf("------------- i = %lu -------------\n", i); /* Estimation of time for the function call itself (with copying negligibly small amount of data -- 1 byte) */ clock_gettime(CLOCK_MONOTONIC, &t0); memcpy(text_koi8_a, text_koi8, 1ul); clock_gettime(CLOCK_MONOTONIC, &t1); Dt_call = delta_t(&t0, &t1); /* (in nanoseconds) */ printf("Dt_call = %ld ns\n", Dt_call); /* Test for koi8-r */ clock_gettime(CLOCK_MONOTONIC, &t0); memcpy(text_koi8_a, text_koi8, size); clock_gettime(CLOCK_MONOTONIC, &t1); Dt_koi8 = delta_t(&t0, &t1) - Dt_call; printf("Dt_koi8 = %ld ns\n", Dt_koi8); fflush(stdout); /* Test for utf-8 */ clock_gettime(CLOCK_MONOTONIC, &t0); memcpy(text_utf8_a, text_utf8, size_u8); clock_gettime(CLOCK_MONOTONIC, &t1); Dt_utf8 = delta_t(&t0, &t1) - Dt_call; if (i > 9ul) { /* Skip first 10 experiments (wait for stabilization) */ Dt_koi8_total += Dt_koi8; Dt_utf8_total += Dt_utf8; } printf("Dt_utf8 = %ld ns\n", Dt_utf8); Dt_utf8_to_Dt_koi8 = (double)Dt_utf8 / (double)Dt_koi8; printf("Dt_utf8 / Dt_koi8 = %.5g\n", Dt_utf8_to_Dt_koi8); fflush(stdout); } puts("==================================="); printf("Dt_koi8_total = %ld ns\nDt_utf8_total = %ld ns\n" "Dt_utf8_total / Dt_koi8_total = %.5g\n", Dt_koi8_total, Dt_utf8_total, (double)Dt_utf8_total / (double)Dt_koi8_total); printf("len_u8 / len = %.5g\n", (double)(size_u8 - 1ul) / (double)len ); free(text_utf8_a); free(text_koi8_a); free(text_utf8); free(text_koi8); return 0; }
- Отказаться от UTF-8, XAnder, 19:05 , 07-Авг-17 (14)
Кодировка UTF-8 придумана вовсе не для оптимального хранения текстов, а для однозначного и независимого от платформы представления кодовых позиций Юникода в виде потока байт, точнее — октетов, сохраняя при этом совместимость с ASCII.Так уж получилось, что почти вся информация у нас хранится в виде массивов 8-битных байт и передаётся в виде потоков этих же октетов. Это наглядный пример «плевка в вечность»: отказаться от этой концепции очень непросто, даже если в том будет потребность. Таким образом, всем приходится подстраиваться под существующее положение дел, включая и Юникод. Так и появилась UTF-8. Вопрос использования той или иной кодировки для хранения тех или иных текстов — это часть более общей проблемы выбора оптимального кодирования. Причём под оптимальностью могут пониматься очень разные вещи: скорость, размер, удобочитаемость, совместимость, устойчивость к искажениям, конфиденциальность и т. д. Так что логика выбора кодировки (и не только её) в каждой задаче разная. Вам бы нужно чётко сформулировать свою задачу, тогда будет понятно, что тут обсуждать, что важно, а что второстепенно. P.S. Возможно моё сообщение кажется собранием тривиальных фактов в духе К.О. Это не кажется — это действительно так :-) Но, по-моему, кто-то должен был это сделать.
- Отказаться от UTF-8, Sergey Maslennikov, 12:27 , 09-Авг-17 (48) +1
> Это наглядный пример «плевка в вечность»Тогда уж -- "в нашу вечность". Европейские языки проблема почти не затрагивает.
- Отказаться от UTF-8, XAnder, 13:12 , 10-Авг-17 (60)
>> Это наглядный пример «плевка в вечность» > Тогда уж -- "в нашу вечность". Европейские языки проблема почти не затрагивает. Не-не-не! Дело тут не в языках, и не в кодировках. Собака зарыта уровнем глубже. Кто-то когда-то за нас решил, что вся информация в компьютерах должна быть представлена блоками с размером, кратным восьми битам. Это стало для нас (людей во всём мире) настолько естественным порядком вещей, что мало кто об этом вообще задумывается. А тема для размышлений тут весьма богатая! Не знаю как, но чую, что когда-нибудь это «ау!» нам откликнется.
- Отказаться от UTF-8, Sergey Maslennikov, 13:34 , 10-Авг-17 (61)
> чую, что когда-нибудь это "ау!" нам откликнется.Qubit-ы?
- Отказаться от UTF-8, ыы, 13:36 , 10-Авг-17 (62)
>>> Это наглядный пример «плевка в вечность» >> Тогда уж -- "в нашу вечность". Европейские языки проблема почти не затрагивает. > Не-не-не! Дело тут не в языках, и не в кодировках. Собака зарыта > уровнем глубже. Кто-то когда-то за нас решил, что вся информация в > компьютерах должна быть представлена блоками с размером, кратным восьми битам. Это > стало для нас (людей во всём мире) настолько естественным порядком вещей, > что мало кто об этом вообще задумывается. А тема для размышлений > тут весьма богатая! Не знаю как, но чую, что когда-нибудь это > «ау!» нам откликнется.Да, компьютеры на третичной логике похоронили... не заговор ли это?
- Отказаться от UTF-8, XAnder, 14:14 , 10-Авг-17 (63) –1
> Да, компьютеры на третичной логике похоронили... не заговор ли это?Я, вообще-то, про байты, а не про биты.
- Отказаться от UTF-8, Sergey Maslennikov, 14:20 , 10-Авг-17 (64) +1
> Я, вообще-то, про байты, а не про биты.А, тогда Qubit-ы, видимо, тоже, не то, что вы чуете. Но байт -- это просто степень двойки -- связан с системой исчисления.
- Отказаться от UTF-8, asphinx, 15:35 , 10-Авг-17 (65) +1
>>> Это наглядный пример «плевка в вечность» >> Тогда уж -- "в нашу вечность". Европейские языки проблема почти не затрагивает. > Не-не-не! Дело тут не в языках, и не в кодировках. Собака зарыта > уровнем глубже. Кто-то когда-то за нас решил, что вся информация в > компьютерах должна быть представлена блоками с размером, кратным восьми битам. Это > стало для нас (людей во всём мире) настолько естественным порядком вещей, > что мало кто об этом вообще задумывается. А тема для размышлений > тут весьма богатая! Не знаю как, но чую, что когда-нибудь это > «ау!» нам откликнется.Ну, вот - докатились уже с языками высокого уровня до того, что ОСНОВЫ народ не знает... :( PS: Ещё каких-то 5-10 лет назад историю происхождения байта рассказывали чуть ли не в школе, а уж про всякие курсы компьютерной грамотности с уклоном в программирование, я просто молчу - без понимания байта многие вещи вообще нельзя было сделать... PS2: https://ru.wikipedia.org/wiki/%D0%91%D0%..., если уж на то пошло. От себя добавлю, к третьей версии (как мне рассказывали примерно 25 лет назад), на заре эпохи были значительные технические трудности с организацией и хранением данных в ячейках, потому в доперсоналочные времена объём данных в 4 бита был выбран как оптимальный размер ячейки, которую можно защитить одним битом чётности с допустимой степенью гарантированной вероятности восстановления данных. Доказательную математику этого утверждения нашим, молодым тогда мозгам, естественно, приводить не стали - зачем нам тот бисер был?.. Вот как сейчас - кому тот байт нужен-то, на самом деле?... Кстати, до сих пор не пойму - 3 бита было проще и надёжнее же. И Байт сейчас был бы 6-битным... А можно вспомнить ещё, что и без того слабую советскую промышленность по созданию вычислительной техники, окончательно похоронили со всеми перспективными наработками в "весёлые" 80-90-е, приняв западные стандарты от IBM(PC) и MS(DOS). Оттуда и англоязычность языков программирования... А ещё можно вспомнить, что 60-70-е годы не было задач, где бы требовались в компьютерах заглавные и строчные буквы: 28 букв латинского алфавита+10 цифр+несколько символов математических действий+скобки, знаки препинания - это был минимальный набор символов для мало-мальски читабельного (не в кодах) "общения" между человеком и машиной. Отсюда и первые 6-битные слова, которые потом расширили до "нынешнего" байта.
- Отказаться от UTF-8, XAnder, 17:46 , 10-Авг-17 (66)
> Ну, вот - докатились уже с языками высокого уровня до того, что > ОСНОВЫ народ не знает... :( Эх, пойду уроки делать, а то предки заругаютЪ... (почти без шуток) > PS: Ещё каких-то 5-10 лет назад историю происхождения байта рассказывали чуть ли > не в школе, а уж про всякие курсы компьютерной грамотности с > уклоном в программирование, я просто молчу - без понимания байта многие > вещи вообще нельзя было сделать... Как бы донести мысль?.. Начну издалека, с ситуации, которая подтолкнула к этим идеям. Лет 5—10 назад в нашей шараге делали программу для простенького контроллера, который следил за неким колебательным процессом. С точки зрения программы процесс этот был потоком целых чисел от 0 до 450. Программа анализировала этот поток и дёргала всякие штуки по результатам анализа. При этом анализ был тем точнее, чем больше данных удавалось «держать в голове». А памяти было в обрез, и процессор довольно медленный. Казалось бы, каждому числу достаточно 9 бит. Но упаковка-распаковка 9-битных чисел в 8-битные байты привела к чрезмерному для той машинки усложнению и замедлению программы. Так что в итоге сделали по-простому — два байта на число. Работало отлично, но осадочек остался. Вот тогда я и подумал, как было бы хорошо, если бы адреса в памяти указывали на биты, а не на байты. Это было началом, и еретические мысли завели далеко — к осознанию того, что байт (в отличие от бита) — это искусственная единица, введённая произвольно и воспринимаемая некритично. История вычислительной техники — штука интересная и поучительная. Я и сам про неё когда-то много рассказывал, когда вёл «программистский» кружок в школе (было и такое, давно). Как вы верно заметили, байты были введены из-за технических ограничений «на заре времён». А их «погулявший» размер — наглядное свидетельство искусственности этой величины. Хорошенько покопавшись в прошлом и усвоив его уроки, давайте смотреть в будущее, это же так здорово! P.S. Тема окончательно свалилась в оффтоп (а был ли топ?), так что давайте сюда все потоки сознания, пока модераторы не разогнали :o)
- Отказаться от UTF-8, Andrey Mitrofanov, 17:55 , 10-Авг-17 (67)
> Как бы донести мысль?.. Начну издалека, с ситуации, которая подтолкнула к этим > идеям.Вот тут мне http://apenwarr.ca/log/?m=201708#10 тоже очень понравилось. > P.S. Тема окончательно свалилась в оффтоп (а был ли топ?), так что > давайте сюда все потоки сознания, пока модераторы не разогнали :o)
- Отказаться от UTF-8, XAnder, 18:28 , 10-Авг-17 (69)
>> Как бы донести мысль?.. Начну издалека, с ситуации, которая подтолкнула к этим >> идеям. > Вот тут мне http://apenwarr.ca/log/?m=201708#10 тоже очень понравилось.Шикарно излагает! В интересном мире мы живём, однако. layers are only ever added, never removed — в гранит!
- Отказаться от UTF-8, ыы, 18:10 , 10-Авг-17 (68) –1
>[оверквотинг удален] > и воспринимаемая некритично. > История вычислительной техники — штука интересная и поучительная. Я и сам про > неё когда-то много рассказывал, когда вёл «программистский» кружок в школе (было > и такое, давно). Как вы верно заметили, байты были введены из-за > технических ограничений «на заре времён». А их «погулявший» размер > — наглядное свидетельство искусственности этой величины. Хорошенько покопавшись > в прошлом и усвоив его уроки, давайте смотреть в будущее, это > же так здорово! > P.S. Тема окончательно свалилась в оффтоп (а был ли топ?), так что > давайте сюда все потоки сознания, пока модераторы не разогнали :o) А на заре вычислительной техники - байт то собственно и не было. Были слова. и имели они разную длину в зависимости от архитектуры. А архитектуры тогда были- кто во что горазд... Так что да, байт- величина условная.
- Отказаться от UTF-8, asphinx, 23:14 , 10-Авг-17 (70)
Я немного абзацы местами переставлю - ничего?> А памяти было в обрез, и процессор довольно медленный. [skip...] > Вот тогда я и подумал, как было бы хорошо, если бы адреса > в памяти указывали на биты, а не на байты. Это было В таких условиях люди берут в руки молоток, напильник... в смысле - ассемблер, если оно действительно "надо"... > началом, и еретические мысли завели далеко — к осознанию того, что > байт (в отличие от бита) — это искусственная единица, введённая произвольно > и воспринимаемая некритично. Так оно и есть. На ассемблере легко определяются длины данных, не привязанные к исторически сложившимся величинам... И транслятор не будет проявлять повышенный интеллект, выравнивая каждую переменную по границе слова(байта). > Лет 5—10 назад в нашей шараге делали программу для простенького контроллера, который > следил за неким колебательным процессом. С точки зрения программы процесс этот > был потоком целых чисел от 0 до 450. Программа анализировала этот > поток и дёргала всякие штуки по результатам анализа. При этом анализ > был тем точнее, чем больше данных удавалось «держать в голове». А > памяти было в обрез, и процессор довольно медленный. Казалось бы, каждому > числу достаточно 9 бит. Но упаковка-распаковка 9-битных чисел в 8-битные байты > привела к чрезмерному для той машинки усложнению и замедлению программы. Так > что в итоге сделали по-простому — два байта на число. Работало > отлично, но осадочек остался. Тех же лет 25 назад в одном из институтов морской биологии на базе IBM PC XT, с 5-мегагерцовым, если я правильно помню, процессором Intel 8086, с жёстким диском аж 40МБ были сделаны глубоководные зонды, которые снимали и сохраняли поток данных с около сотни датчиков. Помнится, были дизассемблированы и проштудированы алгоритмы работы arj, arc, lha и lzh - эффективность упаковки данных напрямую влияла на длительность нахождения зонда на глубине. Всё это умещалось в две-три сотни, что ли, секторов, безо всякого DOS-а, для экономии места. Нельзя, конечно, утверждать, что мы засунули архиваторы в 50 кБ кода, но многие идеи мы оттуда почерпнули... Мы даже BIOS хорошо разобрали на предмет работы int13h, но работа через порты сильно раздула код, да и коллега, отвечающий за этот блок часто болел - оставили опираться на функциях BIOS. "Работало отлично", безо всяких осадков - как мы накодили, так и работало...
- Отказаться от UTF-8, XAnder, 07:37 , 11-Авг-17 (71)
> В таких условиях люди берут в руки молоток, напильник... в смысле - > ассемблер, если оно действительно "надо"...Вы не поверите! Там он и был изначально. Потом, правда, заменили на Си, потому что довольно скоро стало понятно, что на разработку на ассемблере тратится слишком много времени. Да, человеческого времени, которое дороже машинного. > Так оно и есть. На ассемблере легко определяются длины данных, не привязанные > к исторически сложившимся величинам... И транслятор не будет проявлять повышенный интеллект, > выравнивая каждую переменную по границе слова(байта). Правильно ли я вас понял, что можно средствами некоторого ассемблера определять даже 9-битные данные, чтобы работать с их массивами? Если да, то нельзя ли пример? > Тех же лет 25 назад в одном из институтов морской биологии... Молодцы, что могу сказать. На безрыбье как только не извернёшься.
- Отказаться от UTF-8, asphinx, 09:44 , 11-Авг-17 (77)
> Вы не поверите! Там он и был изначально. Потом, правда, заменили на Си, потому что > довольно скоро стало понятно, что на разработку на ассемблере тратится слишком много > времени. Да, человеческого времени, которое дороже машинного.Да отчего ж не поверю - поверю. Глядя на то, какой сейчас код получается на том же gcc, можно констатировать определённые успехи компиляторов за прошедшее время. :) А можно поискать проект одного австралийца, под названием С-- - когда я его увидел спустя где-то лет 7, аж слёзы на глаза навернулись, сколько времени можно было тогда сэкономить... >> Так оно и есть. На ассемблере легко определяются длины данных, не привязанные >> к исторически сложившимся величинам... И транслятор не будет проявлять повышенный интеллект, >> выравнивая каждую переменную по границе слова(байта). > Правильно ли я вас понял, что можно средствами некоторого ассемблера определять даже > 9-битные данные, чтобы работать с их массивами? Если да, то нельзя Неправильно - можно определить массив данных (вот он - массив - будет, вероятнее всего выровнен компилятором по границе байта или слова), а какой разрядности данные там будут храниться и обрабатываться - это уже определяет сам программер в своём коде. И вот тут уже компилятор (что от MS, что от Borland, что от Watcom, также, думаю, и другие) не будет проявлять повышенный интеллект и пытаться выровнять манипуляции программиста по границе 8/16/32 бит. > ли пример? Нельзя, увы. :( Архивы наработок остались в том институте. Где-то на дискетках, если не деградировали, вероятно есть и у меня, но попробуй найди сейчас работоспособный дисковод на 5"... :( Концепцию решений помню, а вот подробности... :( Помню, - оптимизировали на битовом уровне... >> Тех же лет 25 назад в одном из институтов морской биологии... > Молодцы, что могу сказать. На безрыбье как только не извернёшься. Да... Для проекта было "выбито" очень много, как нам тогда казалось, денег... Глубоководных зондов было что-то около полусотни, а для кодинга и обработки данных были приобретены аж 3 PC-AT на 286 с EGA!... А ведь по тем временам это был громадный шаг вперёд, диссертаций на основании полученных данных было почти столько же, сколько и данных - море... Кому оно сейчас надо, кто об этом знает? Кто помнит выводы и опирается на результаты? Кто возьмётся перепроверять выкладки и подвергать сомнениям, вылавливать блох ошибок? Это уже пройденный этап, доказанные теоремы используются как аксиомы. Как и в Вашем случае с разрядностью Байта.
- Отказаться от UTF-8, Andrey Mitrofanov, 10:28 , 11-Авг-17 (83)
> Да отчего ж не поверю - поверю. Глядя на то, какой сейчас > код получается на том же gcc, можно констатировать определённые успехи компиляторов > за прошедшее время. :)Забавник. За "успехи компиляторов" ещё в 77ом году Бэкусу Тьюринговскую премию дали: компилятор фортрана практически всегда выдавал код лучше, чем [тогдашние, да] кодеры на асмах. ""В 1977 году за труды по созданию Фортрана и вклад по формализации специфицирования языков программирования награждён премией Тьюринга. Тьюринговскую лекцию «Можно ли освободить программирование от стиля фон-Неймана?»[2] посвятил комбинаторному программированию и представил [,,,]"" --https://ru.wikipedia.org/wiki/%D0%91%D1%...,_%D0%94%D0%B6%D0%BE%D0%BD > А можно поискать проект одного австралийца, под названием С-- - когда я
- Отказаться от UTF-8, asphinx, 14:36 , 11-Авг-17 (94)
>> Да отчего ж не поверю - поверю. Глядя на то, какой сейчас >> код получается на том же gcc, можно констатировать определённые успехи компиляторов >> за прошедшее время. :) > Забавник. > За "успехи компиляторов" ещё в 77ом году Бэкусу Тьюринговскую премию дали: компилятор > фортрана практически всегда выдавал код лучше, чем [тогдашние, да] кодеры на > асмах.Системное низкоуровневое программирование на фортране??? Под IBM PC XT в 1990-91 году??? Ню-ню... Мсье знает толк в извращениях!.. Я бы ещё оспорил кто из нас более забавник... Это сейчас легко в справочник в интернете залезть и цитатку выдернуть... PS: Не забываем, что интернет тогда был диал-апный и, вообще - где-то там, "за бугром". Просвещённых счастливчиков, которые знали что такое BBS и FIDO, можно было по всему Союзу пересчитать по пальцам! Спасибо, что хоть masm с tasm-ом, 2-й или 3-й версии, что ли, откуда-то были... Коллега значительно позже привёз из столицы 5-й masm, да 6-й sourcer - на него как на героя-добытчика смотрели, ходили клянчили с дискетками, хотели втихаря от начальства самовольно на доску почёта повесить... :) Встроенный в MS-DOS debug-гер - то ещё извращение!.. После него mail, tex или vi освоить - плёвое дело! Документацию по функциям DOS и BIOS на матричном принтере после работы печатали. Митинский рынок ещё не зародился вообще - народ ездил на аэродром в Тушино... Нужная информация добывалась по крупицам и с боем, зато делились ею друг с другом в кругу коллег и сподвижников легко и без оглядки. Справочники типа "Процессор 80286 и его программирование" заказывали через межбиблиотечный абонемент, ждали месяцами, а потом ночами в общаге конспектировали и переписывали!.. Фортран от Бэкуса!... Да-да-да!.. Вы бы его попробовали достать ещё вначале!.. :( Скажете, тоже...
- Отказаться от UTF-8, Andrey Mitrofanov, 09:18 , 11-Авг-17 (73)
> Тех же лет 25 назад в одном из институтов морской биологии на > базе IBM PC XT, с 5-мегагерцовым, если я правильно помню, процессором 4.77 же! |) > блок часто болел - оставили опираться на функциях BIOS. "Работало отлично", > безо всяких осадков - как мы накодили, так и работало... Раньше были времена, А теперь мгновения. Понимался раньше <ой! />, А теперь - давление.
- Отказаться от UTF-8, Led, 23:34 , 07-Авг-17 (18)
А у тебя точно все-все французские символы (которые Лев Николаевич впендюрил в эту книженцию) в твоёй кои8 правльно сохранились? А в "Войне и мире"?
- Отказаться от UTF-8, Sergey Maslennikov, 08:19 , 08-Авг-17 (19) +1
> А у тебя точно все-все французские символы (которые Лев Николаевич впендюрил в > эту книженцию) в твоёй кои8 правльно сохранились? А в "Войне и > мире"?АК был с Мошковской библиотеки. Там с текстом всё нормально -- французских букв нет. Вот так там, например, в Войне и мире: "Еh bien, mon prince. G#234;nes et Lucques ne sont plus que des apanages, des поместья, de la famille Buonaparte. Non, je vous pr#233;viens..." В целом же, да, вкрапления английских букв и всяких "nbsp;" в тестах нежелательны, т. к. они уменьшают время обработки UTF-8, изменяя результат в её пользу. Т. е., в тестах на кириллице без вкраплений проигрыш UTF-8 оказался бы больше. Переделывать я всё равно не буду. Правильный тест должен проверять алгоритм, а не собранную программу. Пусть эти тесты сделает тот, кто в этом шарит и мог бы провести их минимальными усилиями. В идеале -- докажет: существует оптимальный алгоритм преобр. <1-байтная кодировка> -> <универсальное 4-байтное представление> и обратно; существует оптимальный алгоритм преобр. <UTF-8> -> <универсальное 4-байтное представление> и обратно; сравнит их сложности. Ну, или, хотя бы, экспериментальную базу увеличит.
- Отказаться от UTF-8, ыы, 14:17 , 08-Авг-17 (25)
> В идеале -- докажет: > существует оптимальный алгоритм преобр. <1-байтная кодировка> -> <универсальное 4-байтное > представление> и обратно; существует оптимальный алгоритм преобр. <UTF-8> -> <универсальное > 4-байтное представление> и обратно; сравнит их сложности. Ну, или, хотя бы, > экспериментальную базу увеличит.алгоритм в котором участвует абстрактная 1-байтная кодировка и абстрактная же 4-байтная кодировка? могу нарисовать. Легко :) для реальных 1-байтных кодировок и реальных 4-байтных - оптимальный алгоритм будет разным. это же элементарно. если бы вы поинтересовались как устроены кодировки - вы бы это надеюсь поняли.
- Отказаться от UTF-8, Sergey Maslennikov, 17:19 , 08-Авг-17 (29) +1
> ... абстрактная 1-байтная кодировка и ... > реальных ... кодировокЧто такое абстрактная кодировка? Ну, или -- реальная? Или, чем они друг от друга отличаются?
- Отказаться от UTF-8, DeadLoco, 04:37 , 10-Авг-17 (57)
> Возможен ли строгий ответ?Да. Возможен. Геморрой, связанный с зоопарком "кодировок, эффективных для сжатия", многократно превосходит неудобства от увеличенного размера файлов в мультибайтной универсальной кодировке. В данном конкретном случае повышенный расход дискового пространства, траффика и тактов процессора - это сознательная и приемлемая плата за унификацию хранения текстов.
- Отказаться от UTF-8: геморрой, Sergey Maslennikov, 17:31 , 23-Авг-17 (96) +2
> Геморрой, связанный с зоопарком ... В данном конкретном случае повышенный расход > дискового пространства, траффика и тактов процессора - это сознательная и приемлемая > плата за унификацию хранения текстов.Ну, вы уж слишком категоричны. Тред, всё-таки, в теме "Оптимизация и тюнинг", т. е. для тех, кому геморрой не "зоопарк", а "повышенный расход". В исходном сообщении не было никакого "данного конкретного случая". Речь не о полном отказе от UTF-8, а о принятии решения -- в каких случаях стоило бы посмотреть в сторону однобайтной кодировки. Понятно, что большинство программистов не будет заморачиваться поддержкой кучи кодировок внутри своих программ, но кто-то из них мог бы согласиться вставить опциональные конвертеры на входе и выходе. Без конвертеров тоже: если программа берёт на вход и выводит текст в UTF-8, вполне могут найтись люди, которые допишут к ней внешние паковщики с конвертерами прямо на своих системах (не геморрой же!), потому что паковать непосредственно UTF-8 системам сложнее. В частности, распаковка кириллического текста в KOI8-R с последующей конвертацией в UTF-8 (+ в обратном порядке) происходит в 1.6 раза быстрее, чем просто распаковка/запаковка того же текста в UTF-8 [1]. И не так уж это очевидно. По крайней мере, я раньше предполагал обратное. А с UTF-8, да, всё хорошо, если только она использована не для кириллицы. С другой стороны, геморрой -- это тоже экспериментальный факт. Народ считает, что геморрой, значит так оно и есть. Сноска: [1] Сжатие -- xz без опций, конвертация -- iconv, текст -- в основном кириллица; если время загрузки процессов много меньше времени их работы.
- Отказаться от UTF-8: геморрой, pavlinux, 01:57 , 24-Авг-17 (97)
> Народ считает, что геморрой, значит так оно и есть.Когда я был маленький и еб....ый, я тоже думал, что каждая моя мысль революционна :) --- Хотя некоторые так и не были решены. Ну например: Бэкап, на минимальное кол-во DVD-дисков, базы данных и всей системы. В ручную, при объёме данных равному N DVD, легко влезало на N+1 DVD. Угадай как решилось?
- Отказаться от UTF-8: геморрой, Anonimous, 08:01 , 24-Авг-17 (98) +2
> ... думал, что каждая моя мысль революционна ... > например: Бэкап, на минимальное кол-во DVD-дисков ... Угадай как решилось?В смысле, кириллица станет такой же нужной, как DVD-диски?
- Отказаться от UTF-8: геморрой, pavlinux, 02:36 , 08-Окт-17 (104)
>> ... думал, что каждая моя мысль революционна ... >> например: Бэкап, на минимальное кол-во DVD-дисков ... Угадай как решилось? > В смысле, кириллица станет такой же нужной, как DVD-диски?В смысле, что писать в программе тип short int, если оно всё равно в процессоре занимает регистр длиной в long long int.
- Отказаться от UTF-8: геморрой, DeadLoco, 23:38 , 24-Авг-17 (99)
> Угадай как решилось?dump | tar | split cat | tar | restore
- Отказаться от UTF-8: геморрой, pavlinux, 04:04 , 26-Авг-17 (100)
>> Угадай как решилось? > dump | tar | split > cat | tar | restore Не, RAID с HotSwap купили. Пара дисков укатывают в сейф, пара работают.
- Отказаться от UTF-8: геморрой, ., 05:59 , 03-Окт-17 (102)
>>> Угадай как решилось? > Не, RAID с HotSwap купили. Пара дисков укатывают в сейф, пара работают. Это называется решилось?!?! Да вы под веществами! :)
- Отказаться от UTF-8: геморрой, pavlinux, 02:27 , 08-Окт-17 (103)
>>>> Угадай как решилось? >> Не, RAID с HotSwap купили. Пара дисков укатывают в сейф, пара работают. > Это называется решилось?!?!Да, бэкап есть и стабилен. Какими способами, никого ни е...т. :) Есть много других прекрасных и главное оплачиваемых дел нежели поиск решения NP-задачи.
|