js上傳前壓縮
引用的 util.js
❷ js文件上傳中遇到的知識點
在前端開發中，我們經常遇到上傳文件的需求，以前都是用到時再找資料，但總是感覺對這塊不熟，最近翻資料學習了一下，記錄一下。
本文中涉及的知識點有：FileList對象，Blob對象，File對象，URL對象、FormData對象等。
本文參考 網道 ，總結而來。另外，強烈推薦網道，可以去 網道的官方 看看，是阮一峰大神發起的項目，提供互聯網開發文檔，文檔非常全面易懂。
FileList對象，是一個像數組的對象，擁有length屬性和item()方法，同時，它的每一項都是File對象。
input 標簽，將type設為file，之後得到的files屬性就是一個FileList對象。
blob 對象表示1個二進制文件的數據內容。blob對象和arraybuffer區別是，blob對象用於操作二進制文件，arraybuffer用於操作內存。
blob 對象擁有2個屬性和1個方法，分別是size(單位是位元組)、type屬性和slice()方法。
File 對象是一種特殊的Blob 對象。它在繼承了size、type屬性外，還同時有name、lastModified、lastModifiedDate等幾個屬性。
FileList 對象中的每一項都是File 對象。
拿到File 對象之後就要進行操作，下面是操作。
URL.createObjectURL(file) 允許為File 對象創建一個臨時鏈接，
FileReader 對象的屬性和方法比較多，屬性中比較重要的是result，方法中比較重要的是
FileReader 對象的所有屬性和方法可以參考 這里 ,這里就不再列出來了。
在早期的互聯網時候，提交數據都是用表單。表單提交數據有些缺陷，例如無法校驗表單數據，會刷新整個頁面等。隨著Ajax的興起，頁面表單提交數據慢慢退出歷史舞台，但有時上傳文件時我們偶爾會用到表單提交數據。
在調用構造函數new FormData(form)構造formdata對象時需要傳入form節點，如果不傳入，則默認構建空表單。如果傳入，則按照key=value的時候構建表單。
可以看看效果圖
FormData 對象主要的方法有：
cavas壓縮圖片其實很簡單，無非就是幾個步驟：
1、選擇圖片，判斷圖片是否大於2M（用File對象的size進行判斷，size的單位是位元組）；
2、用FileReader對象讀取文件成base64,
3、然後創建Image對象，賦值src屬性，在Image對象載入完成的回調里創建cavas並繪制圖片(根據圖片是否大於2M動態調整畫布大小)；
4、將cavas轉成blob，拼在formdata中用ajax上傳。
這篇文章到這里也就結束了，這篇文章包含了一些瀏覽器中提供的對象，可以看到都是很簡單的內容。
❸ js 大文件分片上傳處理如何實現
推薦採用webuploader控制項來解決。
關於WebUploader的功能說明：
大文件上傳續傳
支持超大文件上傳(100G+)和續傳，可以關閉瀏覽器，重啟系統後仍然繼續上傳。
開源
提供ASP.NET,JSP,PHP示例和源代碼，其中JSP提供MySQL,Oracle,SQL Server資料庫的配置和示例代碼。
分片、並發
分片與並發結合，將一個大文件分割成多塊，並發上傳，極大地提高大文件的上傳速度。
當網路問題導致傳輸錯誤時，只需要重傳出錯分片，而不是整個文件。另外分片傳輸能夠更加實時的跟蹤上傳進度。
預覽、壓縮
支持常用圖片格式jpg,jpeg,gif,bmp,png預覽與壓縮，節省網路數據傳輸。
解析jpeg中的meta信息，對於各種orientation做了正確的處理，同時壓縮後上傳保留圖片的所有原始meta數據。
多途徑添加文件
支持文件多選，類型過濾，拖拽(文件&文件夾)，圖片粘貼功能。上傳本地指定路徑的文件，不需要通過點擊按鈕選擇文件。
粘貼功能主要體現在當有圖片數據在剪切板中時（截屏工具如QQ(Ctrl + ALT + A), 網頁中右擊圖片點擊復制），Ctrl + V便可添加此圖片文件。
HTML5 & FLASH
兼容主流瀏覽器和低版本瀏覽器，介面一致，實現了兩套運行時支持，用戶無需關心內部用了什麼內核。而且支持IE6，IE8瀏覽器。
同時Flash部分沒有做任何UI相關的工作，方便不關心flash的用戶擴展和自定義業務需求。
基於內存映射模式進行IO操作，充分發揮操作系統性能。
MD5秒傳
當文件體積大、量比較多時，支持上傳前做文件md5值驗證，一致則可直接跳過。
如果服務端與前端統一修改演算法，取段md5，可大大提升驗證性能，耗時在20ms左右。
易擴展、可拆分
採用可拆分機制, 將各個功能獨立成了小組件，可自由搭配。
採用AMD規范組織代碼，清晰明了，方便高級玩家擴展。
❹ 如何壓縮css和js文件實現快速傳輸
大家都知道bluehost支持Gzip壓縮，但是並沒有明顯的一個開啟按鈕需要你自己配置，但是Gzip有一個缺點是不能壓縮css和js文件，但是並不說明這兩個文件不能像html文件那樣壓縮，我們可以利用一個叫Minify庫進行壓縮。
使用方法：1、下載Minify
2、解壓縮後將min文件上傳到網站根目錄
3、編寫.htaccess文件添加如下代碼：
❺ 手機移動端html5、js如何實現視頻上傳並壓縮視頻質量，或者降低手機攝像頭拍攝質量
你好 HTML5和javascript是不能壓縮視頻的，只能把視頻傳到伺服器端，由後端來壓縮視頻，也不能控制相機的拍攝質量，除非你用JAVA寫Android客戶端才可以壓縮。希望我的回答能夠幫助到你，如果還有什麼疑問可以繼續追問。
❻ vue項目中先解壓zip壓縮包再上傳
vue項目中先解壓zip壓縮包再上傳，是的。element-upload上傳圖片壓縮包→解壓縮壓縮包→獲取壓縮包的圖片文件→將內存過大的圖片進行壓縮→將壓縮之後的圖片再次製作成壓縮包→繼續上傳操作，先安裝image-conversion，jszip模塊，用於壓縮和解壓縮upload部分。
❼ 如何去選擇部署原js和壓縮js文件
用grunt，打包到dist目錄，頁面載入script的地方做個isdebug的開關。
開發時候處於debug狀態用源碼環境。發布時候修改debug狀態讓其處於壓縮代碼環境
❽ js文件過大，小程序無法發布
可以進行壓縮後再上傳。
首先將自己需要壓縮的視頻文件准備好，放置到同一個文件夾中，方便添加文件。將視頻壓縮軟體安裝到自己的電腦中，打開軟體找到視頻壓縮，點擊視頻壓縮進入到壓縮的頁面。
❾ js壓縮圖片 到固定像素以內，500k為例
本文旨在探究js壓縮圖片的兩種方式： 改變圖片長寬 ， 改變圖片質量 ，和結合了以上兩者的 最終方案 。
首先，閱讀本文需要知道canvas的兩個方法
這兩個方法具體的說明可以在MDN上查看，關於圖片壓縮，也有很多現成的博客可以直接用。但是那些博客都有個問題，並沒有關心之後圖片的壓縮質量。
我試著用一個現成的例子去跑了一下，一個1.7M的圖片壓縮到了23k，堪稱像素級毀滅性破壞。
假如一張大圖可能包含著很多文字等關鍵信息，必須上傳之後使用方能清晰辨認。所以要壓縮之後質量盡可能接近500k的。500k像素以內，就是若一張圖寬度為1024，則高度不能超過500。因為圖片有其他的信息，也是要佔大小的。即不得大於 1024*500 。
所以，根據需求，上傳圖片不能超過500k的情況下盡可能保留圖片的清晰度。當然如果可以的情況下用上面提到的 canvas.toDataURL 設置壓縮程度為0.9，0.8試試看，圖片質量可以接受，大小會有大幅度的縮小。
如果不壓縮，靠調整圖片長寬去控制上傳大小呢？
原理很簡單，就是靠不斷地縮小限定的最大寬高，直到最終長寬的積小於規定的大小。
這種方法有可能最後得出的圖片的大小會略大於規定大小，原因上文也提到過了，如果想使用這種方法，可自行再調整一下。
上面的方法有個問題，就是改變了圖片的原始長寬。如果一個圖的長寬足夠大，壓縮圖片質量，糊一點但是內容看得清也是ok的嘛。所以，跟上面同理，我們可以不斷調整圖片的質量設定直到大小合適，那麼，如何在圖片上傳之前知道圖片的大小呢？
首先，需要知道的一點是，壓縮之後拿到的base64字元串會轉成blob對象，然後傳給服務端。
可以查閱文檔，blob對象有個屬性是size
這個size就是上傳之後實際的文件大小。
參照上面的思路，可以每次改變 canvas.toDataURL('image/' + fileType, level); level的值，去調整壓縮圖片質量，然後用blob對象的size去驗證是否滿足500k以內的需求。
關於 canvas.toDataURL 的level到底是怎麼計算的，MDN文檔里也沒說，寫了個循環一次減少0.1的level壓縮了幾個圖片
用加減乘除算了一下，沒找到規律，數學不好放棄了（這個東西好像也不是能觀察出來的，看結果跟初始大小沒啥關系）。
這里要注意的是，有可能遇到超大圖片，0.1的level可能不足以壓縮到500k，所以小於0.1的時候，改變level遞減的差值繼續壓縮下去
在開始接收到圖片的時候給一個loading增加用戶的耐心好了，loading萬歲~
其實單純的壓縮質量遇到稍大的圖片，會導致頁面高頻計算，然後頁面基本就用不了了- -。有嘗試過用iphone的一個屏幕截圖（10M左右），壓的時候稍過一會，整個手機都在發燙，只能殺進程。
所以，若對長度沒有特殊的限制，可以做一個縮放，去加快壓縮的進度，提高能壓縮的圖片大小上限。
頁面到了ios上還是不行- -，可以看到最後圖片level為0.001，最長邊為764。
問題還是循環次數還是過多，計算頻率太高。從圖中可看出，對於大圖來說，初始設定的level和圖片尺寸過於寬松，可以優化一下初始level和尺寸。
有的時候還會遇到一張圖片無論如何也壓不到500k，就是上一次和這次的壓縮後大小沒有變化，這種情況需要拋錯，不讓循環繼續。
大圖片的等待時間稍長，可以給用戶先預覽一個base64的圖片增加等待耐心，方法名為 getImgBase64 ,這里都一並給出了
解決的隱患：上面這個方案會出現我需要一個500k的照片，壓到了520k之後，再壓了一次。有時候這最後的一次會特別誇張，直接將圖片弄到了幾十k。
參考了： https://github.com/WangYuLue/image-conversion
這個庫裡面有個方法 compressAccurately ,這個方法可以比較精準地壓縮。偷偷翻了一下源碼。
其實上一個方案的痛點就在於，如何在每一個壓縮循環里處理尺寸和壓縮比例。
總結
如有紕漏，歡迎指正
❿ 怎樣在客戶端 利用js 壓縮圖片 大小，然後上傳至伺服器比如2M壓縮成幾十KB
無法實現，js沒有許可權去修改本地文件的，只能是將大圖上傳到伺服器後再壓縮