Многие знают, что у гугла есть сервис для такой конвертации — Swiffy. Однако он существует либо как веб-приложение, либо как расширение к Flash Professional. Никакого публичного api(а тем более его документации) вроде как нет. Однако это не так.
Если внимательно присмотреться к расширению swiffy для flash, то можно заметить, что оно работает с с веб-сервисом google. А раз оно работает, то и мы попробуем. Достаточно послать на определённый url post-запрос с json-объектом:
{
apiVersion : "v1",
method : "swiffy.convertToHtml",
params : {
client = "Swiffy Flash Extension",
input = "base64Data"
}
}
где в поле input пишем закодированный base64 flash-контент. И надо не забыть в base64-кодировке заменить '+' на '-' и '/' на '_' для url safe формата.
Если всё хорошо то в ответ мы получим такой объект:
{
result : {
response : {
version : "api version",
status: "SUCESS",
output: "base64response"
}
}
}
Если произошла ошибка, ответ будет таким:
{
error : {
message: "Сообщение об ошибке"
}
}
где version — номер версии api swiffy, a output — закодированный base64 ответ. На нём остановимся.
Во-первых, для декодирования надо не забыть произвести обратную замену '-' на '+' и '_' на '/'. Далее необходимо по надобности(чтобы размер был кратен 4) добавить 1 или 2 символа '='(как указание на лишний нулевой байт). Теперь можно и раскодировать. Однако это ещё не всё. Раскодировав, мы не получим html-код, а получим gzip-архив с html-кодом. После распаковки, у нас наконец-то будет html — эквивалент(хотелось бы так думать) загруженной флешки.
Есть реализация для всего этого в npm-пакете: swiffy-convert от Rafael Belvederese.
Для .net я написал небольшую библиотечку: jdart.swiffy, которая доступна через nuget-пакет.
Использовать её очень просто:
var swf = File.ReadAllBytes("sample.swf");
var swiffyClient = new SwiffyClient();
string html5page = await swiffyClient.ConvertToHtml5Async(swf);
File.WriteAllBytes("sample.html", Encoding.UTF8.GetBytes(html5page));
Используя данный подход можно быстро преобразовать большое число флешек, либо оставить поддержку flash в интерфейсе вашего продукта, где за кулисами будет производиться конвертирование. Не стоит забывать, что не все флешки получится конвертировать и это объективный риск.
Спасибо за внимание.
Комментарии (7)
feodus
31.08.2015 12:37Тестили эту штуку.
Автор правильно сказал что конвертит не всегда правильно.
Есть еще минус — отсутствие контроля над размером получающегося файла.
Чтобы что-то поменять опять нужен Flash.
Я бы рассматривал этот тул как переходный момент.
И как мне кажется, лучше сосредоточиться на изучении GWD и ему подобных.
Invision70
31.08.2015 21:04Еще один гвоздь в крышку гроба флеша, хорошие новости.
TheRabbitFlash
01.09.2015 11:54Если бы это был бы гвоздь в крышку гроба — ни гугл, ни майкрософт не встраивали бы из коробки флеш в свои браузеры. Первый продолжает поддержку и второй — только начинает.
Тут причины иные. У гугла — реклама. На мобиле она отваливается и очень жестко. Люди не видят там флеша в браузере. А баннеры 99 из 100 именно на нем. Соотв. толку от рекламы на сайтах — ноль. Теперь все 100% юзеров будут видеть баннеры и настальгировать по временам флеш баннеров, которые можно было бы отключать.
Что касается десктопа — центральный контент блочиться таким образом не будет. Игры будут продолжать работать. И реклама в видео и в играх — тоже.
Гугл не флеш пытается прибить. Он пытается сделать так, чтоб неработающая реклама на мобиле — заработала.
olexandr17
18.09.2015 18:40Спасибо автору ;)
http://www.olexandr.org/blog/%D0%BF%D0%B5%D1%80%D0%B2%D0%BE%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%B5-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-wpf.html
Alexeyco
> 1 сентября(то есть завтра) гугл останавливает в хроме воспроизведение периферийного flash-контента
> Поэтому имеет смысл начинать переходить на так называемые html5-баннеры
Поздно мы с тобой поняли (с)…
Alvaro
)) К сожалению, именно так. Все только «начинают» переходить. Может быть, кроме AdWords. Но это особый случай)