В Google Docs добавлена одна из самых ожидаемых функций — поддержка форматов MS Office 2007, а именно .xlsx и .docx. Они появились в списке поддерживаемых форматов, который уже включает в себя .doc, .odt, xls, .ods, .ppt, .csv, .html, .txt, .rtf и другие.



Импорт документов в новомодных форматов происходит стандартным образом, через меню “Upload”. Система сама определит формат документа и импортирует его в базу с сохранением всего форматирования.



Если нужно конвертировать сотни/тысячи файлов, то это можно сделать с помощью Google Documents List API.

via Google Docs Blog

На хабре довольно часто проскакивают статьи, в которых упоминаются файлы plist. При этом никто не считает нужным объяснить, что это за файлы такие.
Пришлось гуглить самому :)
Файл plist (Property List) — это XML-файл настроек приложения, имеющий расширение .plist. Хорош этот формат тем, что он удобочитаемый, быстрый в обработке, а для разработчиков в Mac OS есть готовые средства для работы с ним.
Многие plist-файлы с настройками приложений лежат в Home > Library > Preferences (например, com.apple.finder.plist, com.skype.skype.plist). Название файла состоит из 4 частей: com.компания.приложение.plist.
Вот, вроде, и всё. Буду рад, если кто-то дополнит или поправит.

CPIO — это достаточно старый (1990 год), но в то же время очень удобный вариант архива. Он достаточно прост, и, возможно поэтому, получил широкое распространение. Например данный формат используют RPM, initramfs ядра Linux, а также установщик архивов «pax» от Apple.

Данный архив позволяет собирать любое число файлов, директори и других объектов файловой системы (символических ссылок и т.д.) в единый поток байт.

Давайте на примерах рассмотрим формат этого архива.

Задался я однажды целью портировать данную игру на более современные платформы. Но понятное дело игра является далеко не open source и когда-то в далеком 1994 году разработчики брали за нее ни много ни мало 25 баксов, а посему все игровые ресурсы нужно было либо перерисовывать, либо потрошить единственный игровой архив. Чем я и занялся.

Добрый всем!
Всё началось со шкафа со старыми играми. Лет 10 назад взял у друга игру, положил её в тумбочку и вспомнил о ней через 10 лет. Заинтересовался, что за игра такая, мне неизвестная. Оказалось, что это танковая аркада 1999 года, от фирмы 3DO, о похождениях супер-американского танка во время войны в заливе.

Формат архивов 7-Zip довольно гибкий и позволяет, например, включать весь архив как один из файлов внутри самого архива, лишь немного считерив. Разберём формат на примере: создадим почти вручную архив с именем «Рекурсивный.7z», содержащий два файла: «Какой-то файл.txt» с содержимым «Hello, Habrahabr!» и «Рекурсивный.7z», копию самого себя.

Краткая документация по формату входит в LZMA SDK. Архив начинается со следующей структуры размером 32 байта. Все позиции внутри архива кодируются как смещения относительно конца этой структуры.

сигнатура, 6 байт: { '7', 'z', 0xBC, 0xAF, 0x27, 0x1C };
версия формата, два байта { Major, Minor }, 7-Zip 9.20 пишет сюда { 0, 3 };
CRC следующих трёх полей, 4 байта;
смещение основного заголовка относительно конца этой структуры, 8 байт;
размер основного заголовка, 8 байт;
CRC основного заголовка, 4 байта.

Далее следуют данные файлов без какой бы то ни было информации о самих файлах и о границах данных. Основной заголовок, который описывает всё содержимое архива, размещается в конце архива.

Основной заголовок может быть сам по себе упакован (а также зашифрован). Поскольку он содержит структурированные данные (типа имён файлов), коэффициент сжатия достаточно неплохой. Именно для возможности подобного сжатия вся информация о файлах в 7z собрана в одном заголовке и полностью отделена от сжатых данных файлов. Признак упакованности — первый байт основного заголовка: он должен быть равен 1 у неупакованного заголовка и 0x17 у упакованного. Для создания архива вручную мы не будем ничего сжимать.

Вы никогда не замечали, что у функции AGGREGATE в Excel у второго набора аргументов неправильное описание аргументов? Фактически, во втором наборе описания аргументов взяты вперемешку из второго и первого наборов. Этот баг точно воспроизводится в Excel 2010, 2013. Мне стало интересно почему так происходит, ведь не могут же в Microsoft так халатно относиться к интерфейсу одного из своих основных продуктов. Итогом стал полный разбор формата файлов локализации MS Office.

При создании программы на ассемблере (для примера будет приведён FASM) из-под ОС Windows возникает вопрос о том, какой выбрать формат файла.
Для определения формата создаваемого исполняемого файла используется директива «format» со следующим за ним идентификатором формата.
Под катом краткое описание COM-программы и EXE-программы форматов MZ и PE с шаблоном программ (в виде традиционного «Hello World!»).

Вы когда-нибудь работали с виртуальными машинами, создавали виртуальные диски? Если да, то наверняка вы обратили внимание на такие удобные возможности, как динамическое увеличение размера диска (возможность хранить только то, что было записано) и возможность создания snapshot'ов — моментальных снимков состояния диска. Если вам интересно узнать, каким именно способом достигаются эти возможности и как хранятся данные в VHD и VHDX файлах — добро пожаловать под кат.

После того, как сразу два букмарклета, работавшие в Google Chrome и Firefox, отказались работать в Internet Explorer 11, причём не выдавали в консоль никаких сообщений об ошибках и вообще не подавали признаков жизни, я стал разбираться, в чём же дело.

Сначала я решил, что дело в лимите на длину URL и тем самым на длину букмарклета. В IE 7 ограничение было в 2083 символа, в IE 11, по уверениям экспериментировавших пользователей, лимит увеличили. Нужно было выяснить опытным путём, какова теперь эта граница.

Но сперва небольшое предисловие.

Google Chrome хранит закладки в JSON, Firefox — в базе данных sqlite. Поэтому названия у закладок могут быть произвольные. IE хранит каждую закладку как отдельный файл, например, в папке %userprofile%\Favorites\Links. Поэтому браузер будет корректировать названия закладок, чтобы они подходили под нормы файловой системы (заменять знаки вопроса, например). Поэтому же в IE не могут быть в одной папке две закладки с одинаковым именем, а в Google Chrome и Firefox — могут (закладки в них могут быть даже вообще без имени, только со значком сайта или стандартным заменителем).

После значительной задержки публикую продолжение цикла своих статей.
Для ознакомления:

• Steam Protocol 2 и Steam Files — Введение
• Steam Files. Часть 1 — GCF/NCF

В данной статье я затрону оставшиеся форматы файлов:

• BLOB — устаревший формат данных, служащий контейнером для двоичных данных. Содержал в себе базовые параметры (IP-адреса серверов, CRD-запись и еще много чего);
• CDR (Content Description Record) — бинарный файл, содержащий данные о приложениях и их файлах кеша. На данный момент не используется;
• VDF — бинарный/текстовый файл, содержащий множество данных и имеющий структуру, зависящую от конкретного применения. Разработан как замена BLOB и CDR;
• PAK — ранее использовался в Half-Life 1, великое наследие Quake 1, уже не используется;
• VPK — новый формат игровых архивов внутри самих игр, активно используется на данный момент. Подробное описание файла имеется на официальном ресурсе. В статье описана только первая версия формата.

Статья представлена только для ознакомления, поскольку актуальной информации здесь относительно мало, а примеров алгоритмов почти нет — всё можно просмотреть в упомянутом ранее репозитории.

Это перевод статьи ребят из Aristotle Interactive.
Говорят, фотография стоит тысячи слов. Но в сети, фотография может занимать тысячу килобайт и больше! По данным HTTP Archive, изображения в среднем занимают до 64% веб-страницы. Учитывая это, оптимизация изображений — крайне важный аспект, особенно принимая во внимание то, что многие пользователи просто уйдут с сайта, если он не загрузится за несколько секунд.

Проблема с оптимизацией изображений в том, что мы хотим сохранить размер изображений, не жертвуя при этом качеством. Предыдущие попытки создать типы файлов, которые бы оптимизировали изображения лучше, чем стандартные JPEG, PNG и GIF, успеха не возымели.

В своём развитии мне пришлось пробежаться по нескольким этапам в нескольких направлениях: Java → Objective C → Swift, Web → Enterprise → Mobile, XML → JSON. Этим путём я шёл на протяжении более 15 лет, подолгу и внимательно задерживаясь на каждом этапе. Нужно идти дальше. За мобильными приложениями можно придумать что-то (наверное, пока не хочется), языков вообще пруд-пруди, ничего интереснее JSON'а не придумали. А зачем его менять?

Дальше я расскажу почему мне не очень нравится JSON для некоторых применений и как, по моему мнению, его можно доработать, чтобы стало немного удобнее.

Сразу должен отметить, что не рассматриваю KTV, как замену JSON. И ни в коем случае не рассматриваю его для использования в JavaScript'е. Это будет неудобно и неправильно. С другой стороны, ситуация, когда система описания объектов JavaScript'а используется в других языках для работы с типизированными данными — тоже странная, и её хочется поправить.

Если вам интересно, что послужило изначальной причиной создания такого формата — можно почитать про S2 и про причины создания формата KTV

Я, в целом, планировал публикацию про KTV для ссылки из других статей, чтобы, когда я их опубликую (например, вот эта, про S2) — можно было сослаться и не было бы вопросов, что такое KTV, и откуда оно возникло. Но тема оказалась больная. Поэтому я решил, что нужно немного подробнее рассказать, откуда возникла такая, странная на первый взгляд, идея.

Прикладываю к статье опросы. Помогите мне, пожалуйста, разобраться, в ситуации. :-)

Пару месяцев назад, отдыхая от реализации новых возможностей вроде q_auto и g_auto, я прикалывался в нашем командном чате по поводу того, как различные форматы хранения изображений будут сжимать однопиксельную картинку. В ответ Orly, редактор блога, попросила меня написать пост об этом. Я сказал: «Конечно, почему бы и нет. Но это будет очень короткий пост. Ведь что можно рассказать про один пиксель».

Похоже, я был сильно неправ.

Что можно сделать с одним пикселем?

В ранние годы веба однопиксельные картинки часто использовались как костыли для вещей, которые сейчас делаются через CSS. Создание отступов, линий, прямоугольников, полупрозрачных фонов – много чего можно сделать, просто масштабируя пиксель до нужных размеров. Ещё одно использование пикселей, дожившее до наших дней – маячки, средства для отслеживания и аналитики.

В отзывчивом веб-дизайне однопиксельные картинки используются как временные заглушки в ожидании загрузки страницы. Большинство браузеров не поддерживают HTTP Client Hints, поэтому некоторые варианты с отзывчивыми изображениями ждут полной загрузки страницы, чтобы подсчитать актуальный размер картинок, а затем заменяют однопиксельные картинки нужными изображениями при помощи JavaScript.


Сломанная картинка

Позвольте я расскажу вам об одной классной фиче, которую мы с коллегами из Postgres Pro недавно запилили в утилите pg_filedump. Фича эта позволяет частично восстанавливать данные из базы, даже в случае, если база была сильно повреждена и инстанс PostgreSQL с такой базой уже не запустишь. Конечно, хочется верить, что потребность в таком функционале возникает крайне редко. Но на всякий случай нечто подобное хотелось бы иметь под рукой. Читайте дальше, и вы узнаете, как данная фича выглядит в действии.

В прошлой статье мы узнали, как при помощи утилиты pg_filedump можно восстановить данные, или, по крайней мере, какую-то их часть, из полностью убитой базы PostgreSQL. При этом предполагалось, что мы откуда-то знаем номера сегментов, соответствующих таблице. Если мы знаем часть содержимого таблицы, ее сегменты действительно не сложно найти, например, простым grep'ом. Однако в более общем случае это не так-то просто сделать. К тому же, предполагалось, что мы знаем точную схему таблиц, что тоже далеко не факт. Так вот, недавно мы с коллегами сделали новый патч для pg_filedump, позволяющий решить названные проблемы.

Как формат JPEG произвел в свое время революцию среди форматов изображений, так и новый формат FLIF обещает такого же масштаба событие для дизайнеров и веб-разработчиков.

FLIF (Free Lossless Image Format) – новый формат файлов для изображений, обеспечивающий беспрецедентное сжатие без потерь. Файлы получаются:

• На 14% меньше, чем WebP, без потерь
• На 22% меньше, чем BPG, без потерь
• На 33% меньше, чем сжатый через ZopfliPNG PNG-файл
• На 43% меньше, чем обычные PNG-файлы
• На 46% меньше, чем оптимизированные по Adam7 чересстрочные PNG-файлы
• На 53% меньше, чем JPEG 2000, без потерь
• На 74% меньше, чем JPEG XR, без потерь

На Хабре уже опубликовано пару статей на тему FLIF. Но мы пойдем дальше: какую еще практическую пользу несет формат, кроме меньшего размера для большинства типов изображений (в частности, для типов без потерь качества)?

Начнём с вводных. Мы разрабатываем программу, которая будет сохранять свои данные в файл, и при этом…

• будет расширяться, и существенно (отпадают уровни и сохранения большинства игр: после пары патчей бросаем игру и пишем новую);
• тем не менее программа не рассчитывает на то, чтобы быть стандартом (отпадает LibreOffice). То есть по формату сохранения она должна быть совместима только с собой-старой и собой-новой;
• все её данные надо держать одномоментно в памяти; СУБД типа SQLite не даёт каких-то преимуществ (отпадают базы переписки в почте или мессенджере);
• но файл сохранения будет очень велик (отпадают программы фотопроявки вроде Lightroom, где документ — это всего лишь положения сотни-другой ползунков: мелочь по сравнению с 40-мегабайтным RAW);
• нет нужды в ручной корректировке файлов (отпадает пользовательский интерфейс типа «файл конфигурации», присущий, например, серверу Apache).

Таких программ на самом деле немало. Это AutoCAD, Photoshop, Microsoft Office (будем честными: даже пытаясь протащить его через ISO, «мелкомягкие» рассчитывали, что он будет совместим в первую очередь с самим собой).

И для простоты добавим ещё одно требование, которое отбросит все три этих программы, но довольно реалистичное (ему отвечают Windows 10 и куча программ помельче).

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

Этот файл — ROM консоли NES. И одновременно ZIP-файл. Он одновременно полностью функционален и как NES ROM, и как ZIP-файл.

Что находится в этом ZIP-файле? Исходный код ROM.

Что случится, если скомпилировать этот исходный код? Он создаст NES ROM, который также является ZIP-файлом, содержащим исходный код этого NES ROM.


Запущенный ROM

Этот NES ROM можно «прожечь» на картридж NES и он будет работать на NES. Даже если конвертировать все данные с картриджа, образ NES всё равно будет ZIP-файлом.