Comments 57
Очень вовремя! Вот только собирался использовать мультиаплоад в своем проекте и вот замечательная статья.
Довольно четко и очень понятно объяснено.
Огромное спасибо.
Довольно четко и очень понятно объяснено.
Огромное спасибо.
+1
UFO just landed and posted this here
Эх, жаль что это можно будет использовать только года через 3-4 когда умрут все браузеры которые не понимают html5
0
Не скажите, смотря для каких целей. Например, в данном случае я делал интерфейс для одной почтенной женщины-фотографа, она использует (а если бы и не использовала, то можно было бы убедить) файрфокс и ее все устраивает.
Или вот пример с gmail — они же отказались от поддержки IE6, хотя его до сих пор используют 15 (или даже 20) % пользователей, которые получают предупреждение, что их браузер устарел.
Тут два варианта: делать костыли для более старых браузеров и честно говорить пользователям, что надо обновить браузер.
Но это я так. Согласен, чтоэту технологию пока рано запускать в массы. Как минимум надо дождаться, когда все последние версии браузеров будут ее поддерживать.
Или вот пример с gmail — они же отказались от поддержки IE6, хотя его до сих пор используют 15 (или даже 20) % пользователей, которые получают предупреждение, что их браузер устарел.
Тут два варианта: делать костыли для более старых браузеров и честно говорить пользователям, что надо обновить браузер.
Но это я так. Согласен, чтоэту технологию пока рано запускать в массы. Как минимум надо дождаться, когда все последние версии браузеров будут ее поддерживать.
+2
Зря Вы так. Для массового пользователя — да, а вот для своего удобства — уже сейчас.
+2
Мало по малому, но уже можно начинать внедрять
0
К сожалению в реальных проектах придется использовать еще и альтернативный вариант загрузки, пока такой функционал не будут поддерживать основные броузеры :(
+1
UFO just landed and posted this here
UFO just landed and posted this here
Расстроило конечно, что File API не поддерживает IE9 Beta: это странно, учитывая что разработчики IE сейчас взяли курс на обильную поддержку html 5. Но как бы то ни было, очевидно, что в будущем всем браузерам придется подтянуться.Ничего странного, все просто. File API — черновик, его еще будут дописывать и переписывать. Если бы в IE9 внедрили FileAPI в текущем виде, то ничего хорошего не вышло бы. А мозиловцы вообще любят всякую экспериментальщину внедрять. Отсюда и остался в FF 3.6 метод sendAsBinary. В 4-ке уже должен быть FormData, который и описывается в последней версии черновика.
+1
Согласен, весь HTML5 пока черновик, но ничего плохого в том, если бы ИЕ поддерживал уже тоже не было бы. Вообще, остальные браузеры регулярно обновляют младшие версии (может, подверсии? как правильно?), добавляя новые возможности. А уж если в ИЕ какой-то возможности нет, то еще год-другой надо ждать, пока выйдет следующий.
0
Вот в этом-то и проблема. Если Хром, FF, Опера обновляются достаточно часто, то IE — крайне редко. Поэтому внедрять что-то экспериментальное в IE опасно, т.к. может так случиться, что через неделю после релиза черновик перепишут, выпустят новые версии браузеров и… IE останется не у дел, со старыми реализациями (и снова хаки для IE). Разработчики оперы тоже не любят экспериментальные фичи. Вспомнить хотя бы border-radius (и многие другие css3 свойства), реализовывать которые Opera Software не спешили.
А вообще, реализовывать такой функционал следует только при уверенности, что Вы сможете среагировать на изменение стандарта. Если Вы работаете над сайтом, который Вы точно будете поддерживать через полгода-год, то не страшно. А если Вы работаете над заказом, то лучше на это не рассчитывать. Иначе вместе с очередным обновлением браузеров может умереть весь новый функционал, а исполнителя и след простыл.
А вообще, реализовывать такой функционал следует только при уверенности, что Вы сможете среагировать на изменение стандарта. Если Вы работаете над сайтом, который Вы точно будете поддерживать через полгода-год, то не страшно. А если Вы работаете над заказом, то лучше на это не рассчитывать. Иначе вместе с очередным обновлением браузеров может умереть весь новый функционал, а исполнителя и след простыл.
0
вовремя… надо бы jquery plugin заделать
0
Спасибо! Применю на своем проекте, как раз не будет лишним)
0
Для скрытия инпута можно просто сделать ему visibility:hidden и растянуть поверх графического элемента
0
М… меня опередили *сворачивает черновик* =)
0
Последний год использовал www.plupload.com/.
Опенсурс библиотека для загрузки файлов. Поставил на сайт — если у пользователя оказывался не хтмл5-браузер, автоматически библиотека переключала на другой способ загрузки.
Апи очень простое, рекомендую.
Опенсурс библиотека для загрузки файлов. Поставил на сайт — если у пользователя оказывался не хтмл5-браузер, автоматически библиотека переключала на другой способ загрузки.
Апи очень простое, рекомендую.
0
Ссылка по теме: bolknote.ru/2009/11/30/~2322
0
На правах рекламы:
code.google.com/p/jquery-html5-upload/
code.google.com/p/jquery-html5-upload/
0
Спасибо
вместо $('ul#img-list') используйте $('#img-list'). Во втором случае получим элемент намного быстрей, так как будет использоваться родной document.getElementById
вместо $('ul#img-list') используйте $('#img-list'). Во втором случае получим элемент намного быстрей, так как будет использоваться родной document.getElementById
+2
Сегодня весь вечер внедрял загрузку по этому посту и нашел очень неприятную штуковину.
В частности, этот код:
> метод send() объекта XMLHttpRequest может принимать в параметре бинарные данные, что успешно и реализовано в Google Chrome
Попробовал на chrome 7 и trunk chromium 9 — они не смогли. Сейчас думаю о возможных решениях проблемы, первое, что пришло на ум — это реализация метода sendAsBinary с помощью FileWriter API. Это апи разработчики совсем недавно добавили в хромиум и firefox. Вот код:
В частности, этот код:
if (self.xhr.sendAsBinary) { // firefox self.xhr.sendAsBinary(body); } else { // chrome (W3C spec.) self.xhr.send(body); }
> метод send() объекта XMLHttpRequest может принимать в параметре бинарные данные, что успешно и реализовано в Google Chrome
Попробовал на chrome 7 и trunk chromium 9 — они не смогли. Сейчас думаю о возможных решениях проблемы, первое, что пришло на ум — это реализация метода sendAsBinary с помощью FileWriter API. Это апи разработчики совсем недавно добавили в хромиум и firefox. Вот код:
if (XMLHttpRequest.prototype.sendAsBinary === undefined && Uint8Array) { XMLHttpRequest.prototype.sendAsBinary = function(data) { var blob = new BlobBuilder(), arrb = new ArrayBuffer(data.length), ui8a = new Uint8Array(arrb, 0); for (var i=0; i<data.length; i++) { ui8a[i] = (data.charCodeAt(i) & 0xff); } blob.append(arrb); var blob = blob.getBlob(); this.send(blob); } }
0
А если взять reader.readAsDataURL,
отсечь от начала «data:image/png;base64,»
разбить оставшися текст на строки по 74 символов каждая (включая, \r\n),
Поставить хэдер Content-Transfer-Encoding: base64
и отправить?
отсечь от начала «data:image/png;base64,»
разбить оставшися текст на строки по 74 символов каждая (включая, \r\n),
Поставить хэдер Content-Transfer-Encoding: base64
и отправить?
+1
А почему по 72 именно?
0
74*
0
просто я отправил из почтовой программы Thunderbird себе письмо с вложенным файлом.
Потом я посмотрел исходный код письма.
Так вот, Thunderbird закодировал файл в строку base64 и после каждого 72 символа он ставил
\r\n (либо просто \n)
Из-за этого подумал, что 74 — это максимальная длина строки в письмах.
===
P.S. Но вот сейчас взял первое попавшееся письмо на gmail, выбрал «Показать оригинал».
Увидел, что там в строке base64 76 печатных символов.
В rfc искал чего-то ничего по этому поводу не нашёл.
Потом я посмотрел исходный код письма.
Так вот, Thunderbird закодировал файл в строку base64 и после каждого 72 символа он ставил
\r\n (либо просто \n)
Из-за этого подумал, что 74 — это максимальная длина строки в письмах.
===
P.S. Но вот сейчас взял первое попавшееся письмо на gmail, выбрал «Показать оригинал».
Увидел, что там в строке base64 76 печатных символов.
В rfc искал чего-то ничего по этому поводу не нашёл.
0
Хорошая статья, спасибо.
Но у способа есть минус: большие файлы загружаются в память, браузер висит и отжирает много памяти.
Но у способа есть минус: большие файлы загружаются в память, браузер висит и отжирает много памяти.
+1
Как справедливо отметил выше товарищ Demetros, для этой задачи лучше использовать объект FormData, который будет реализован в файрфоксе (см. описание на сайте MDC), начиная с версии 4 (в хроме уже есть, про остальные не в курсе). Очень вероятно, что браузер тогда будет кушать гораздо меньше памяти, ибо возьмет на себя всю черновую работу по чтению файлов.
Пока же можно ограничивать кол-во одновременных загрузок и максимальный размер одного файла.
Пока же можно ограничивать кол-во одновременных загрузок и максимальный размер одного файла.
0
вот метод FormData:
void append(DOMString name, Blob value);
и чего? value что должно содержать? не тело ли файла? раз у неё тип blob
void append(DOMString name, Blob value);
и чего? value что должно содержать? не тело ли файла? раз у неё тип blob
0
Вы зря ссылку внимательно не посмотрели, там есть строка:
Как видите, метод append достаточно умен, чтоб принимать и blob-данные и просто объект File. Я верю, что разработчики оптимизируют процесс чтения и загрузки дял второго случая.
formData.append("afile", fileInputElement.files[0]);
Как видите, метод append достаточно умен, чтоб принимать и blob-данные и просто объект File. Я верю, что разработчики оптимизируют процесс чтения и загрузки дял второго случая.
+1
а да, спасибо.
Я просто заходил на http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-formdata-interface
там этого нету.
Я просто заходил на http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-formdata-interface
там этого нету.
+1
За статью больше спасибо
Для MooTools тоже есть очень похожий плагин mootools.net/forge/p/uploadmanager
Для MooTools тоже есть очень похожий плагин mootools.net/forge/p/uploadmanager
0
За статью спасибо.
Приведенный плагин нужно чуть-чуть допилить — FF 3.6 не поддеоживает FileReader, но поддерживает File.getAsBinary()
} else if($.support.fileReading && xhr.sendAsBinary) {
заменить на
Приведенный плагин нужно чуть-чуть допилить — FF 3.6 не поддеоживает FileReader, но поддерживает File.getAsBinary()
} else if($.support.fileReading && xhr.sendAsBinary) {
заменить на
0
} else if(($.support.fileReading || item.file.getAsBinary) && xhr.sendAsBinary) { (извините, нечаянно нажал отправить)
0
Опять соврал — тестировал под FF 3.5. Также еще одно замечание по поводу имени файла — вместо строки
нужно
var filename = item.replaceName || item.file.name;
нужно
var filename = item.replaceName || item.file.name || item.file.fileName;
+1
xhr.setRequestHeader(«Content-Type», «multipart/form-data, boundary=»+boundary);
Запятую нужно заменить на ";"
self.xhr.setRequestHeader('Content-Type', 'multipart/form-data; boundary='+boundary);
У меня node.js(formidable) не захотела обрабатывать такую форму.
Да и ещё… если есть возможность получить правельный mime-type для файла, то почему бы его не выставить?
body += 'Content-Type: ' + params.file.type + '\r\n\r\n';
Запятую нужно заменить на ";"
self.xhr.setRequestHeader('Content-Type', 'multipart/form-data; boundary='+boundary);
У меня node.js(formidable) не захотела обрабатывать такую форму.
Да и ещё… если есть возможность получить правельный mime-type для файла, то почему бы его не выставить?
body += 'Content-Type: ' + params.file.type + '\r\n\r\n';
0
Спасибо за статью, ваши наработки оказались очень полезными.
0
На данный момент могу сказать что всё работает отлично в Mozilla Firefox 26, Chromium 27. В Opera 12.16 при Drag&Drop при перетаскивании нескольких файлов — залетает только 1, через мультивыбор из поля input:file — нормально, как и должно. А для всяких недобраузеров (кроме Opera), — просто делаются по старинке несколько input:file полей с возможностью добавить ещё, пользователи IE сами выбрали страдания, пусть наслаждаются.
0
Sign up to leave a comment.
HTML5 File API: множественная загрузка файлов на сервер