Comments 55
Столкнулся недавно с таким моментом, что хром в 11 версии не захотел эту кодировку применять. А так может лучше было бы ваш проект на старых добрых фреймах сделать. И грузить там по необходимости html документы.
Спасибо за идею) С windows-1251 я много работаю на своей работе, пока что проблем с ней не ловил в браузерах. А по поводу iframe: все же цель сделать 1 файл для скачивания, который можно запустить просто кликнув по нему, а любая механика с iframe предполагает, что я буду загружать рядом лежащие файлы через него. Не уверен будет ли это вообще работать без веб-сервера, особенно доступ js к подгруженному в iframe контенту, ведь браузеры сильно ограничивают возможности подгрузки чего-либо, когда html запускается не по http(s).
А MHTML не подходит? Сто лет не видел, но он же вроде для того и сделан. Или наверное есть какая-то свежая его реинкарнация.
Еще можно гонять html в пдф файле. Там наверное проще тоже будет ресурсы внутри хранить.
C MHTML много вопросов поддержки. Я его не использовал никогда, поэтому опыта 0 и нужно исследовать тщательно какие браузеры его смогут открывать локально, а какие нет. В любом случае, если не ошибаюсь, MHTML предполагает упаковки всего контента вверху документа, так, как это происходит при отправке писем. Тут сразу 2 проблемы:
размер, так как там используется base64, а он всего 75% эффективность имеет
не получится сделать прелодер.
С PDF вероятно не получится никак. У меня используется достаточно современные API для рендера, которые поддерживаются только в браузерах. Не проверял, но очень сомневаюсь, что читалки PDF под капотом имеют встроенный браузер со всеми наворотами, типа Web Workers, IndexedDB, Canvas и прочее. Да и вроде лишь некоторые читалки вообще способны динамику делать в PDF, все остальные - тупо рендер статический, без динамических скриптов.
А у него есть какой-то общий базовый для всех стандарт? Хотел как-то переводить в него справки из chm, но не смог найти ни одного варианта кодирования в mhtml, чтобы последний отображался в любом браузере, любой версии.
А просто, как в старые добрые времена, отдать .zip-файл, в котором надо кликнуть index.html?
да можно и rar, чего уж там, у всех крякнутый где-то да найдется :)
Но если серьезно, то идея была сделать с максимальной доступностью. К примеру, zip на планшете или телефоне открыть может быть проблемой, да и рядовой пользователь может не понять что он скачал и как это открыть (уровень владения ПК у всех разный).
Также в идее с zip нет уникальности или какого-либо "открытия". Мне нравится мыслить креативно, искать новые пути. И вот показалось интересным возовом упаковать проект в один html, сделав его максимально компактным, с высокой доступностью и безопасностью.
Зато трафик может сэкономить. Во всяком случае, можно выложить две версии - решение исторических костылей веба в виде одного .html для тупого быдла и .zip для тех, кто понимает, и экономит трафик.
zip не поможет ничего сэкономить, точнее максимум 2%, именно та избыточность, которую добавляет Base223.
Оригинальные 168МБ данных уже сжаты разными Brotli и gzip/deflate. Так что сверху накладывается где-то 2% избыточности от Base223 и получается html весом 170МБ. Так что zip ничем тут не поможет для трафика, если оригинальный контент им сжимать или итоговый HTML им сжимать .
А вы не рассматривали хранение контента после загрузки документа в ObjectUrl вместо IndexDB?ArrayBuffer > Blob > URL.createObjectURL
На первый взгляд это выглядит разумным, но может столкнулись с какими то ограничениями?
У меня гибридно. В IndexedDB я первоначально сохраняю, а далее в завимости от того, куда нужны данные выгружаю их в один из следующий форматов:
в ArrayBuffer, если данные нужны в бинарной форме. В частности сама анимация рисуется через JS, поэтому мне нужен массив байт для работы рендера.
в string, если это текстовые данные (css, js, json и тд);
в ObjectUrl через createObjectURL , если мне просто нужна ссылка на файл, чтобы отобразить в img теге или загрузить в Audio объект.
А где тут 96 ASCII-символов, 95 же только получается?
В варианте кодировки с 96 символами я использовал алфавит, где был либо символ <, либо символ переноса строки. Оба эти символа допустимо использовать в блоке script. Если их оба использовать, то алфавит будет аж 97! Но все же для защиты от случайного закрытия тега скрипта, символ < нужно убрать.
а символ 0x7F?
Он запрещен в HTML во всех кодировках совместимых с ASCII.
Т.е. документ будет не валидным, если будет присутствовать такой символ что в utf8, что в cp1251
Да нет. Я в контексте вопроса выше от @vybo У вас в статье написано
безопасно в HTML можно использовать только 96 символов,
Минус 0x7F, получается 95. То есть вы 96-м считаете, судя по картинке, табуляцию (0x09), но это не очевидно. При простом рендере HTML табуляция эквивалентена пробелу (как и перевод строки 0x0A). Понятно, что вы рассматриваете содержимое HTML как поток сырых данных и, видимо, учитываете то ли табуляцию, то ли перевод строки как отдельный символ, но в вашей исходной фразе нет такого пояснения, и я с vybo запутались в вашем подсчёте символов.
да, понял теперь про что вы. Так и есть, при рендере HTML многие пробельные символы схлопываются. Но для нас важен сам контент, он само собой никуда не схлопывается если брать textContent от узла DOM. Табуляцию безопасно использовать, а вот перенос строки нужно много тестов на разных ОС, так как в некоторых случаях \n (т.е. 0x0A) не читался назад. А вот с \r (0x0D) совсем беда была. Поэтому чтобы сильно не рисковать я решил исключить \n из алфавита, хотя в теории можно его использовать, нужно просто все тесты перепроверить на разных устройствах.
И кстати, & бы тоже убрать для надежности, да и на все <33 тоже полагаться - ну такое себе, мало ли кто испортит документ по пробельным символам/переводам строк (да, включая табы).
В теге script использовать & безопасно. Этот символ неотъемлемая часть js, в котором используется для операторов И и побитовое И.
А пробелы и табы просто так никто не будет трогать в документе. Если речь про использование Base223 где-то ещё, то само собой алфавит нужно пересматривать под ту задачу, к которой он применяется. В моем случае html файл собирается и его содержимое никто менять не должен. Точно также, как если собрать бинарник, его трогать нельзя, перестанет работать.
не добрался до дома чтобы проверить, что же станет с вашим файлом после применения расширения SingleFileZ :)
Использование кодировки отличной от UTF8, в случае хромиум подобных браузеров и v8, имеет серьезный недостаток - потеря возможности кеширования данных связанных с интерпретацией и оптимизацией javascript кода.
Иными словами, при каждой новой загрузке такого файла, весь процесс проходит так как в первый раз.
Да, все отличные от UTF-8 кодировки накладывают различные особенности в работе браузера. Если рассматривать какой-нибудь сайт, где важна скорость загрузки, кеширование всего, и кучу разных метрик web vitals, то полностью поддерживаю, только utf-8 нужно использовать. То, что vk.com и pikabu.ru используют cp1251 связано с пресловутым "исторически сложилось", так как слезть с кодировки, когда у проекта вся база в ней, весь код написан с учетом однобайтовой кодировки - это титанический труд, когда проект очень большой и в нем миллионы страниц и пользователей. Если новый проект - само собой только utf8 и ничего другого.
Однако в моем случае речь идет про скачиваемый файл, который и так кеширования не будет изменить никакого. Для такого сценария можно закрыть глаза на использование однобайтовой кодировки в угоду уменьшения размера файла.
А если сначала deflate, а потом уже base64? Картинки, конечно, не пожмутся, а вот скрипты очень даже да.
Из минусов:
- работает не у всех и чем дальше, тем больше не у всех
- нужно тратить ресурсы на декодирование
Получить 170 мегабайт вместо 220 того стоит?
Пока что да, стоит. Проект будет расти и через пару лет будет весить 220 уже в исходном виде, поэтому со старта искал вариант уменьшить размер.
А почему не у всех работает? И почему чем дальше, то не у всех? Эта кодировка никуда не планирует исчезать, повторюсь - она входит в спецификацию HTML как обязательная для поддержки браузерами.
В любом случае как только объявят, что cp1251 будет выпиливаться из поддержки основных браузеров, тогда я поменяю способ кодирования на Base85, или снова сяду за анализ вариантов и что-нибудь подберу оптимальное на замену cp1251. Но пока что нет ни намека, что какой-то браузер будет не поддерживать cp1251. Или я ошибаюсь и где-то поддержки нет?
А что такого важного в разнице между 170 и 200 мегабайт, что нужно ставить под угрозу функционал?
Вы свой диск экономите или пользовательский?
Вижу вот такие проблемы:
дольше качаться будет. Не у всех высокоскоростной интернет.
я плачу за трафик. Не так много, $0.005 за ГБ, но с учетом, что на проект иногда наплывами заходят в день по 80 тыс человек, то трафик порой за месяц выходит в $100+.
чем больше по размеру HTML, тем больше браузеру нужно ресурсов для его загрузки. Это сказывается на скорости чтения файла: больше обращений к диску, больше объема данных на сканирование, больше объема данных для работы с памятью.
вопрос совести. Мне, как программисту, не дает покоя, что я делаю что-то неоптимальное. В данном случае риски фантомные пока что, я реальных рисков не вижу, поэтому путь оптимизации через использование cp1251 выглядит точно диким, но рабочим и на сегодняшний день не опасным на горизонте. Но согласен, что завтра все может поменяться.
чем больше по размеру HTML, тем больше браузеру нужно ресурсов для его загрузки. Это сказывается на скорости чтения файла: больше обращений к диску, больше объема данных на сканирование, больше объема данных для работы с памятью.
У Вас есть сравнение этих затрат с затратами на специфическое кодирование?
Тут и замеры не нужны, обработка кодирования значительно дольше делается и более ресурсоемкая априори. Браузер как-никак сверхбыстрая штука нынче.
Но, как в статье и описано, декодирование делается ленивое, т.е. только когда требуется нужный ресурс. Не все 170 МБ сразу нужны для рендера. Поэтому декодирование делается лишь малой части от этого объема. А далее пользователь скролирует анимационную сцену и при подгрузке новых ресурсов налету делается декодирование. Чисто по визуальному и функциональному поведению все хорошо - браузер на разных устройствах успевает декодировать Base223 налету так, что глазу это практически незаметно. Результат меня удовлетворил. Однако, если даже предположить, что декодирование было бы долгим, то я все равно бы остался на выбранном варианте, просто искал способы ускорить декодирование, в частности применение wasm или webgpu.
Я понимаю ваши опасения касательно моего выбора. Внутри меня где-то чуйка тоже шепчет "куда ты лезешь, используй base64 и не выпендривайся". Но все же рациональная оценка ситуации говорит о том, что риски не такие большие, и в случае чего я всегда могу заменить способ кодирования на другой. Итого: файл значительно меньше, визуально никаких проблем с декодированием налету нет, поддержка cp1251 стабильная и нет предпосылок считать, что браузеры откажутся от этой кодировки в обозримом будущем.
А вариант с архивацией не рассматривался? Можно же заархивировать файлы в архив, вставить через data-uri, а при загрузке разархивировать и вставить на стриницу через eval. При средней степени сжатия в 92% для текста и потерями base64 итоговый размер будет в 178 МБ × (1 - 0.92) × 1.25 ≈ 17.8 МБ
98% всего объема, что добавляется в html документ - это уже сильно сжатые файлы: анимация, музыка, jpg и прочее. Эти данные практически не сжимаются больше.
2% - это всякие текстовые файлы, типа js, css, json и пр. Они предварительно сжимаются gzip, и далее кодируются через Base223.
Т.е. документ и так сильно сжат, сильнее его не сжать. Вы можете попробовать скачать его и сжать https://floor796.com/data/floor796.html
К примеру через zip он сожмется с 171 МБ до 168МБ, т.е. сократит ту избыточность, что добавляет кодировка Base223 назад в оригинальный размер данных.
Уже несколько лет за твоей работой слежу. Огромное спасибо!
Добрый день! Тоже практически ежедневно заглядываю уже много лет. Автор, подскажите пожалуйста в квесте подпространственный тюнер, куда копать. Уже все передумал.
Добрый день)
Нужно подобрать правильную настройку тюнера. Для этого на экранчике на самом тюнере показывается подсказка, что нужно позвонить в сервис, и указывается на то, что номер телефона сервиса можно получить, если выдернуть штекер какой-то. Уточните, это уже прошли и штекер нашли?
Нет, штекер сейчас ищу. в корабле пробовал. теперь по всей площади пошел. Рядом не нашел. еще пирамиду искал.
Тогда если нужна подсказка где штекер: его можно найти где комната с голограммами переключающимися. По задумке эти голограммы разработаны то же фирмой, что и тюнер.
Да, теперь пытаюсь понять что такое а77) верхние переключатели вижу, не могу понять почему 77. Неужели подобрать сопротивление? Клад был проще) Спасибо)
Ну, я снова оставлю в спойлере ответ, если никак не получится, то смотри спойлер: там 8 тумблеров, каждой переключается в 2 состояния, т.е. по сути 8 значений от 0 до 1. Думаю так как мы на Хабре сейчас, то должно сразу быть понятно, что это двоичная форма байта. Т.е. задача ввести 77 число в двоичной форме. Можно так и загуглить "число 77 в 8 битах"
Перерыл всю карту и перетыкал все штекеры. Пока не нашел. Рядом штекер только в корабле и он не работает)
Хочу поблагодарить за этот огромный труд. И за проект и за развитие и за офлайн.
Есть некоторые мысли, идеи.
Первая мысль. При запаковке проекта в офлайн вовсе не обязательно использовать тот же стек технологий. Веб очень ущербен в плане производительности. Очень многое в нём плохо из-за длинного шлейфа обратной совместимости.
Я бы подумал над производством конвертера, который бы одной кнопкой создавал Unity или Unreal Engine проект. Это же просто 2D сцена и спрайты.
Вторая мысль. При локальном запуске уже будут достаточные вычислительные ресурсы при рендере, чтобы пропускать анимацию через нейронку для апскейла и увеличения FPS анимации (опционально).
С производством этих технологических решений вполне могут помочь современные AI агенты. Многое можно навайбкодить даже.
А теперь представь, что это будет анимировано. Будоражит воображение.
Спасибо)
По поводу Unity и Unreal. Я больше веб-разработчик, поэтому мне ближе WebGL, WebGPU и библиотеки под него, типа Three.js. Для перевода моего проекта с рендара на потоках js в рендер на шейдерах видеокарты без сторонних библиотек нужно много работать. Я уже начинал это делать на WebGPU, придумал как создать рендер на шейдере но, забросил, пока что не возвращался. Но если перевести, то проблемы в производительности почти не будет. Но и сейчас их толком нет. Сейчас проекту нужен обычный 12fps, и согласно статистике проекта, большая часть пользователей успешно успевает рендерить 12fps. Т.е. проблемы с производительностью из-за использования рендера через канвас на js практически нет. Я делаю ставку на будущее, что и устройства, и браузеры - все будет ускорятся, а следом за ними мой проект. Его ещё рисовать как минимум 5 лет до 100 блоков, а там посмотрим ;)
пропускать анимацию через нейронку для апскейла и увеличения FPS анимации
Я бы хотел этого избежать. В моей анимации все криво, непрофессионально, редуцированно - все это часть образа, итог ручной работы. Именно это и должно быть во всех копиях проекта. Т.е. я специально не делаю интерполяцию (хотя могу запрограммировать её и без ИИ), специально не применяю трехмерные куклы для ускорения рисования, у меня в редакторе даже нет вставки картинок извне и нельзя печатать текст (специально), все рисую вручную, все тексты на экранах, все "копии" чего-либо (хотя 100 раз проще было бы вставить картинку, чем её перерисовывать). Я запретил все это со старта специально, чтобы у проекта был свой шарм, идея - все нарисовано от руки. Я не переделываю старые части проекта, которые рисовал ещё более криво и редуцированно, чем сейчас, также по причине того, что проект содержит историю изменения стиля и качества рисовки, это часть работы) Под редуцированием имею в виду прием в анимации для сокращения кадров, из-за этого анимация выглядит резкой, не такой естественной.
Итого, я целенаправленно не применяю ни ИИ, ни другие вещи, которые бы улучшали уже нарисованные сцены.
Да, безусловно этот шарм есть и я его чувствую. Если такова воля творца, то именно так и должно быть. Я далёк от искусства, а тут это именно оно, притом с большой буквы.
Прошу прощения если мои мысли резанули душу творца. Не хотел обидеть. Лично мне, как человеку с бедным графическим воображением, проще, когда детали додумывают за меня, но тут речь только про меня. Никому не навязываю свой подход к восприятию прекрасного )
Я там ещё один коммент накатал до того, как пришёл твой. Просто не смотри )
мне в любом случае приятно обсуждать это, так что спасибо за идеи)
Рисовать утомительно, всегда хочется упростить (при том, что я по профессии программист уже больше 20 лет и привык искать пути полегче), и уже не раз думал, что неплохо бы обучить нейронку в помощь в рисовании. Но потом всякий раз отрезвляло то, что я делаю - это творческая работа не для заработка, а для вау-эффекта и искусства в целом. И важно до последней анимации в этом проекте сохранить подход: нарисовано все должно быть от руки без замены человека нейронкой. Тогда ценность проекта сохранится, так как для его создания не применялся ИИ и другие сильные упрощения. Знаешь как в спорте, допинг запрещен. Вот тут применение ИИ - это чистый допинг :D
О, ещё мысль пришла. Можно объявлять конкурс на новые квадраты. Для этого нужно предоставить контракт и публичный API для тестирования. Публикацию не гарантировать. Оставлять последнее слово за автором проекта. Так можно привлечь авторов и наращивать вселенную коллективно. Конечно, заранее нужно подумать о юридическом оформлении, чтобы авторы безусловно и навсегда лишались всех прав на интеллектуальную собственность, кроме, собственно, авторских (они неотчуждаемы).
Ещё одна мысль. Контента во floor796 уже, кмк, достаточно чтобы попытаться обучить модель, которая сможет генерить новые сцены по текстовому описанию.
А где можно увидеть результат? Я пропустил ссылку в тексте?
Ссылку побоялся оставлять в тексте статьи, так как могли посчитать рекламой.
Сам проект https://floor796.com/
Ссылка на скачивание https://floor796.com/data/floor796.html
Спасибо за статью!
А чем конкретно смысл использования IndexedDB в этой цепочке? Кэш?
Вау, я столько отсылок ко всему, чтобы было создано за последние 100 лет еще никогда не видел ;D
Упаковка проекта с большой анимацией в один HTML файл или как кодировка Windows-1251 избавила от лишних 52МБ