Настройка декодирования данных в файлах .AAE изображений, сделанных iPhone

К сожалению, это еще не полный ответ. Кому-то это может помочь, но есть еще кое-что, чего я не понимаю.

Самый полезный ответ, который я нашел, пришел с http:// rae.tnir.org/archives/2016/02/data-inside-apples-aae-files. Он берет содержимое атрибута data и пропускает его через декодер base64. Это затем дает ему двоичный список, который он преобразует в понятный XML, связанный с настройками замедленного движения на фотографии.

Сделаем это более подробно.

Начните с информации о его adjustmentData:

    <key>adjustmentData</key>
    <data>
    YnBsaXN0MDDRAQJac2xvd01vdGlvbtIDBAUXV3JlZ2lvbnNUcmF0ZaEG0QcIWXRpbWVS
    YW5nZdIJCgsUVXN0YXJ0WGR1cmF0aW9u1AwNDg8QERITVWZsYWdzVXZhbHVlWXRpbWVz
    Y2FsZVVlcG9jaBABEQEMEQJYEADUDA0ODxUWEhMQAxEC4SI+AAAACAsWGyMoKi03PEJL
    VFpganBydXh6g4WIAAAAAAAAAQEAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAI0=
    </data>

Мы собираемся декодировать значение data в base64. Пробелы и разрывы строк не имеют значения. Используйте https://www.opinionatedgeek.com/codecs/base64decoder, потому что мы собираемся хотите сохранить результат, поскольку он сам является двоичным, и конвертеры, которые просто отображают текстовые результаты, не смогут правильно его отобразить. Скопируйте поле data (YnBs.....AAI0=), расшифруйте его и загрузите полученный файл. Обратите внимание, что он начинается с bplist, что указывает на то, что это двоичный plist для использования в экосистеме Apple.

Теперь нам нужно расшифровать двоичный plist. Он не объясняет, как это сделать, но другие сайты утверждают, что вы можете просто открыть его в TextMate, и он знает, как его отобразить. Верно. Другое предложение Apple в комментарии выше — запустить plutil -convert xml1 TheDownloadedFile, и он изменяет файл на месте с двоичной версии на XML-версию. (Похоже, они работают на Mac, который я позаимствовал, чтобы проверить его.) Однако я работаю в Windows, и ни одно из предложений не помогает. Однако мне удалось найти плагин bplist для Notepad++ для Notepad++. Конечным результатом для меня, отображаемым в Notepad++, является

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>slowMotion</key>
    <dict>
        <key>regions</key>
        <array>
            <dict>
                <key>timeRange</key>
                <dict>
                    <key>start</key>
                    <dict>
                        <key>flags</key>
                        <integer>1</integer>
                        <key>value</key>
                        <integer>268</integer>
                        <key>timescale</key>
                        <integer>600</integer>
                        <key>epoch</key>
                        <integer>0</integer>
                    </dict>
                    <key>duration</key>
                    <dict>
                        <key>flags</key>
                        <integer>3</integer>
                        <key>value</key>
                        <integer>737</integer>
                        <key>timescale</key>
                        <integer>600</integer>
                        <key>epoch</key>
                        <integer>0</integer>
                    </dict>
                </dict>
            </dict>
        </array>
        <key>rate</key>
        <real>0.125000</real>
    </dict>
</dict>
</plist>

См. также декодирование данных из файла plist. Статья, ссылка на которую содержится в комментарии, также оказалась очень полезной. Его plist не является изображением AAE, но тот же процесс работает. Я бы подозревал, что это будет для любого plist.

Кроме твоего. И мой. Я не знаю почему.

Значение adjustmentData data в этом исходном вопросе не расшифровывается как нечто, начинающееся с bplist. Тот же декодер (https://www.opinionatedgeek.com/codecs/base64decoder) выполняет декодирование это:

mO@@†˜+) 箠I4у൓0´v̾4»þ§J8xڽ誽ŸXb,‘ҙ,F¦Bºӽ¾d쓗܀Z,V籲ϠPˆšpޛWΐ¦(˜Ÿrƀܶ:ࠨG-Ϡ5ɃviлwXþ‘ˆ¾ÿ&‡C%(Ȗb֮ŽҚIPk‡|;˜Тš•~㱚ږkA9@‹“
“헟‡ˑ]ۚq<QͯË䡸塸Ib]JX]ꂮ9žoo+…3!jhԶ^ໟ

У меня не было большего успеха ни с каким другим декодером, ни с пробелами. И у меня та же проблема с AAE, которая сама привела меня в этот беспорядок. Я отмечаю, что и у вас, и у меня есть data с частыми / символами, а две истории успеха, которые я связал, - нет. Мне они "кажутся" разными кодировками, но я не специалист по кодированию.

Я также немного подозрительно отношусь к adjustmentFormatVersion в оригинальном AAE. Рабочий пример был еще на 1.1. У нас 1.4 и 1.6. Интересно, раньше содержимое было двоичным списком, но больше не является им.

adjustmentData, вероятно, является вспомогательными данными приложения, упомянутыми в документации Apple PhotoKit. :

Этот объект предоставляет определяемый приложением «рецепт», который вы можете использовать для реконструкции редактирования.

Когда ресурс редактируется, Photos сохраняет объект PHAdjustmentData, предоставленный приложением (или расширением), редактировавшим ресурс. Этот объект предоставляет любую информацию, необходимую для восстановления редактируемого актива с использованием предыдущей версии содержимого актива. Когда пользователь пытается отредактировать ресурс с помощью вашего расширения, Фото вызывает этот блок, чтобы узнать, может ли ваше расширение обрабатывать прошлые корректировки ресурса.

Поскольку это данные, специфичные для приложения, и теперь они сильно закодированы (больше не просто двоичный plist), я предполагаю, что это какой-то заархивированный объект NSData (образец индивидуальная реализация). Однако, не зная, на что сопоставляются байты (что делают кодировщики Photos.app, какие перечисления требуются), мы, вероятно, не сможем их дальше декодировать. (Для справки, у меня в системе есть файлы AAE версии 1.8.)

Начиная с iOS 8 (2014 г.) они были вероятно, легко декодируемыми. . Если мы когда-нибудь найдем какой-нибудь справочный код или реконструируем его (из Photos.app или где-то еще), будет несложно закодировать информацию в сценарий оболочки .swift.