後端如何存儲圖片

Ⅰ web圖片一般存在後端哪裡

web圖片一般存在Java後端。
web前端上傳圖片到Java後端，並保存到本地。一般來說，圖片在後端的存儲方式分為兩種：一，可以將圖片以獨立文件的形式存儲在伺服器的指定文件夾中，再將路徑存入資料庫欄位中，二，將圖片轉換成二進制流，直接存儲到資料庫的Image類型欄位中。

Ⅱ 探求Oracle資料庫怎樣存儲圖片

商品圖片，用戶上傳的頭像，其他方面的圖片。目前業界存儲圖片有兩種做法：
1、 把圖片直接以二進制形式存儲在資料庫中
一般資料庫提供一個二進制欄位來存儲二進制數據。比如MySQL中有個blob欄位。Oracle資料庫中是blob或bfile類型
2、 圖片存儲在磁碟上，資料庫欄位中保存的是圖片的路徑。
一、圖片以二進制形式直接存儲在資料庫中
第一種存儲實現(PHP語言)：
大體思路：
1、將讀取到的圖片用php程序轉化成二進制形式。再結合insert into 語句插入數據表中的blob類型欄位中去。
3、 從資料庫取出圖片展示的時候。則是直接發送圖片內容
4、
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row->this_image;
實現代碼如下：
$PicturePath = 『/tmp/xxxjgjgj.jpg』;//假設這是上傳的圖片，php放在一個臨時文件夾。腳本執行完畢後自動刪除了。
$imgStream = fread(fopen($PicturePath, "r");
$blob_img = fread(fopen($imgStream, "r"), filesize($PicturePath));
$sql =」 INSERT INTO Images (this_image) VALUES ($blob_img)";
註：this_image就是數據表中一個blob欄位類型的欄位
================取出展示圖片代碼
$result=mysql_query("SELECT * FROM Images WHERE PicNum=$PicNum") or die("Cant perform Query");
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row-> this_image;
總結：處理代碼感覺還真比較麻煩。其實，我從來沒用過在資料庫中以二進制存儲圖片的做法。我們用得更多的是存儲圖片的路徑，實際圖片是在磁碟上保存的(圖片二進制放到資料庫,把資料庫的負擔弄重了)。
據我了解，互聯網環境中，大訪問量，資料庫速度和性能方面很重要。一般在資料庫存儲圖片的做法比較少，更多的是將圖片路徑存儲在資料庫中，展示圖片的時候只需要連接磁碟路徑把圖片載入進來即可。因為圖片是屬於大欄位。一張圖片可能1m到幾m。
有個原則：圖片盡量不要存儲在資料庫中(是指不要二進制形式保存到欄位，而只保存圖片的路徑)。這樣的大欄位數據會加重資料庫的負擔，拖慢資料庫。在大並發訪問的情況下很重要。這是一個經驗。去看看dba對資料庫性能調優方面的分析都能得到這個答案的：就是圖片不要存儲在資料庫中。
就像這個規則一樣：文章分為標題、作者、添加時間、更新時間、文章內容、文章關鍵字
文章內容一般是比較長的。經常使用text欄位去存儲。文章的內容就屬於大欄位。一般文章內容可以拆分到單獨一個表中去。不要與文章信息存儲在一張表裡面。
我理解的原理是：mysql中一張表的數據是全部在一個數據文件中的。如果大欄位的數據也存儲在裡面。程序展示列表，比如文章列表。這個時候根本不需要展示文章內容的。但是仍然會影響速度，資料庫查找數據其實就是掃描那個數據文件，文件容量越小，速度就會越快(為什麼單表的容量在1g-2g的時候基本上要分表了)。拆分出去到一張單獨的表，就是單獨的文件了。我覺得，舉一反三，相互獨立，分離的思想不僅在系統開發中用到，在現實生活中經常存在的。相互混合，就會造成相互影響。小巧，簡潔是一種思想。
可以看看這篇翻譯的文章，
http//developer.51cto.com/art/201211/364472.htm
作者建議，三種東西永遠不要放到資料庫里,圖片，文件，二進制數據。作者的理由是，
對資料庫的讀/寫的速度永遠都趕不上文件系統處理的速度
資料庫備份變的巨大，越來越耗時間
對文件的訪問需要穿越你的應用層和資料庫層
把圖片縮略圖存到資料庫里？很好，那你就不能使用nginx或其它類型的輕量級伺服器來處理它們了。
給自己行個方便吧，在資料庫里只簡單的存放一個磁碟上你的文件的相對路徑，或者使用S3（備註：亞馬遜雲服務）或CDN之類的服務。
============================================================
關於mysql中的blob類型
bolb像int型那樣，分為blob、MEDIUMBLOB、LONGBLOB。其實就是從小到大，
blob 容量為64KB ，MEDIUMBLOB 容量為16M，LONGBLOB 容量為4G。
說實話，圖片用這樣子存儲用得還真少。使用php函數serialize進行序列化的值，我看到有人存入這個欄位中去。
php手冊：serialize返回字元串，此字元串包含了表示 value 的位元組流，可以存儲於任何地方。
mysql中blob欄位存儲圖片有個通信大小的設置：
圖片要傳輸給mysql存儲起來，那麼需要涉及到數據通信。mysql中有個配置是限制通信數據大小的。
my.conf配置文件中的max_allowed_packet，mysql默認的值是1M。
好多圖片尤其是原始圖可能不止1m。傳輸的數據(也就是圖片)超過這個設置大小。結果就會出錯
呵呵，限制挺多。感覺好麻煩。這樣子明顯佔用與mysql交互的通信時間嘛。延長響應時長了。我直接丟個圖片路徑」images/xxxx」給mysql。沒這么耗費資源。
其實所謂的性能，最關鍵是資料庫性能。因為隨著資料庫數據量增大，大部分時間耗費是在php，Java等語言等待資料庫返回數據的過程中耗費時間。
網站訪問量大了後，具體的語言不是瓶頸，瓶頸都在資料庫。用c，，php，java,net都能操作mysql資料庫獲取數據。語言之間可能存在速度執行差異，但是其實這種差別已經很小了。至少我覺得，給予用戶感覺不到明顯。執行相差0.0001秒用戶感覺並沒有明顯的區別。可能說，大並發(很多用戶同時訪問)的時候，就會體現到差別了。其實我覺得，大並發訪問是資料庫瓶頸。等待資料庫給予數據。沒達到一定級別實在體現不了差別。資料庫數據量達到一定級別。語言相差0.001s會給予用戶體驗上的差別。我想，這也是為什麼php很適合做web開發了。解析頁面速度快(解釋型語言，不需要編譯)。可以用java來與資料庫打交道獲取數據。php不直接操作資料庫，而是調用java提供的數據介面，獲取數據，馬上展示在頁面中。這是利用了php的頁面執行速度快的一個優勢。
備份圖片數據和遷移數據方便
圖片以二進制形式存儲在資料庫，有一個好處：備份的時候方便。直接備份資料庫，圖片也跟著備份。換句話說，遷移環境的時候是方便。
而圖片放在磁碟上的話，資料庫中存儲的只是圖片路徑。備份資料庫後。磁碟上的圖片也要跟著備份才行。
不過我覺得，備份這個好處不是很明顯。圖片在磁碟上，備份磁碟也沒很大的事情。打包壓縮也可以了。互聯網環境畢竟與傳統的軟體開發不同，web開發比較關注網站速度。也就是資料庫的速度。就像互聯網開發中，有時候為了速度，用空間換時間的做法比較普遍，所以往往在設計資料庫的時候並不一定遵循傳統資料庫設計三大範式。
資料庫中保存的是圖片路徑的話，在web開發環境下，其實有個更好處，就是cdn加速。就是下面要進行總結的地方。
二、資料庫中保存圖片路徑
一般是這樣子的：
按照年月日生成路徑。具體是按照年月日還是按照年月去生成路徑，根據自己需要(不一定是按照日期去生成)。
理解為什麼要分散到多個文件夾中去才是關鍵，涉及到一個原理就明白了：
操作系統對單個目錄的文件數量是有限制的。當文件數量很多的時候。從目錄中獲取文件的速度就會越來越慢。所以為了保持速度，才要按照固定規則去分散到多個目錄中去。
圖片分散到磁碟路徑中去。資料庫欄位中保存的是類似於這樣子的」images/2012/09/25/ 1343287394783.jpg」
原來上傳的圖片文件名稱會重新命名保存，比如按照時間戳來生成，1343287394783. jpg。這樣子是為了避免文件名重復，多個人往同一個目錄上傳圖片的時候會出現。
反正用什麼樣的規則命名圖片，只要做到圖片名稱的唯一性即可。
比如網站的並發訪問量大，目錄的生成分得月細越好。比如精確到小時，一個小時都可以是一個文件夾。同時0.001秒有兩個用戶同時在上傳圖片(因為那麼就會往同一個小時文件夾裡面存圖片)。因為時間戳是精確到秒的。為了做到圖片名稱唯一性而不至於覆蓋，生成可以在在時間戳後面繼續加毫秒微秒等。總結的規律是，並發訪問量越大。就越精確就好了。
我現在還沒碰到需要這么精細的。概率比較少。
有個方面總結一下：為什麼保存的磁碟路徑，是」images/2012/09/25/1343287394783.jpg」，而不是」 /images/2012/09/25/ 1343287394783.jpg」(最前面帶有斜杠)
我的理解：
連那個斜杠都不要。這里也是做到方便以後系統擴展。
在頁面中需要取出圖片路徑展示圖片的時候，如果是相對路徑，則可以使用」./」+」images/2012/09/25/1343287394783.jpg」進行組裝。
如果需要單獨的域名(比如做cdn加速的時候)域名，img1.xxx.com,img2.xxx.com這樣的域名，
直接組裝 「http//img1.xxx.com/」+」images/2012/09/25/1343287394783.jpg」
當然資料庫是可以在前面加斜杠/保存起來,/images/2012/09/25/ 1343287394783.jpg
其實不方便統一。比如相對路徑載入圖片的時候，則是」.」+」 /images/2012/09/25/ 1343287394783.jpg」
可能我還沒體會到壞處，以後會遇到問題的。不過，遵循慣例不加斜杠」 images/2012/09/25/ 1343287394783.jpg」就對了。
涉及到一個新問題：為什麼大部分系統都不會域名保存進去，像這樣子http//wwwxxx.com/images/2012/09/25/1343287394783.jpg保存到資料庫中
曾經與一個上海的網友聊天，他也是習慣不會把域名保存資料庫中過去。但當時我們兩聊的時候，他對」域名保存進去的做法」與」不保存域名進去」也沒有一個明確利弊。他就覺得，沒有什麼明顯的區別啊。
了解的知識越多，越有利於我們做決定。可能就是一個」感覺區別不是很大」的影響下，去做一個決定，反而對後面是比較大的影響的。至少是增加自己的工作量了。
其實把域名保存進去，也不是什麼滔天大罪的事情。但凡是經驗豐富的開發人員都不會這樣子做。這是一個經驗積累出來的，所以上海那個網友也對此並沒有明顯的概念很正常，他說他不知道cdn方面的(當然覺得存個域名進去沒什麼大不了的)。需要了解cdn知識，什麼情況下會用到cdn知識。
雖然是做開發人員，不需要關注運維和伺服器之類的知識。不過了解一些就有利於理解了。
這里涉及到cdn加速。
關於cdn原理(就是內容分發網路)
cdn，我理解其本質就是為了解決距離遠產生的速度問題，使用就近的服務。
從中國請求美國一台伺服器上的圖片。一般比較慢，因為距離這么遠，網路傳輸是存在損耗的，距離越遠，傳輸的時間就越長。一般會看到瀏覽器左下角顯示：「已響應,正在傳輸數據..」。這不是伺服器本身問題了。實際上伺服器早就響應請求，把數據發給客戶端，但是網路問題，就一直在傳輸，沒傳完了。
在中國，是南北距離遠的問題。南北還會涉及到跨網，南方用戶使用電信居多，北方用戶網通居多。兩個線路需要跨越，會有時間延遲。北京到廣州的距離，如果直接請求
cdn加速就是適應這個需求產生的：現在不請求美國的伺服器。直接在中國安放節點(節點是比較籠統的詞語，可以理解成一台伺服器，也可以理解成一個機房，就是一個點嘛)，請求距離近的節點。這樣子就不需要那麼遠的距離了。
記得以前在長沙的網站，團購以城市分站的形式。北京和長沙用的是同一套程序。伺服器在長沙。北京用戶訪問北京站的時候,實際上需要遠距離訪問長沙的伺服器。速度怎麼都快不起來。跟伺服器性能完全沒關系。當時不懂這些。不清楚怎麼折騰。看那本《前端優化技巧》，想辦法去做js代碼壓縮，瀏覽器緩存之類的。實際上瞎折騰。不是說這些前端優化不重要，哲學上有主次矛盾之分，瓶頸在哪裡就去突破哪裡。沒解決主要矛盾，問題並不會迎刃而解。當時也不是資料庫瓶頸。如果去優化資料庫。也不會明顯改善。就那點數據量。根本就達不到瓶頸。哪裡談得上主要矛盾。隨著後來去其他公司工作，接觸一些東西，類似不找瓶頸的優化例子發生在身邊好幾次了，先沒找到瓶頸就瞎去優化。我的同事可能是抱著多多益善的心態去做的，但主要矛盾(技術上說是瓶頸)沒找到，也沒改善。
當時如果沒想到是距離問題。也就不會想到cdn，當時其實我根本不知道cdn服務。我只知道，google這些網站肯定在中國部署的伺服器，要不然，中國用戶還去訪問美國的伺服器，那再好的伺服器都會速度慢的。
由於自己搭建cdn環境和機房的資金比較大（需要大量的伺服器），也需要人力維護。反正一般的公司弄不起，其實根本不劃算。淘寶以前用商用的cdn服務，後來商用的扛不住了，就搭建了自己的cdn網。我不知道新浪有沒有自己搭建，但其實我覺得跟淘寶的特點有關，店鋪很多，無論是商品還是交易記錄總計起來商品很多的圖片，圖片都是靜態的部分，cdn本來就是用來做靜態的(圖片，css，js等)請求分發用的。
我之前在網上看到一句話，cdn網路不是一般的公司玩得起的。
一般的公司自己搭建cdn網路成本高，所以就有商業的cdn提供付費租用服務，這是一項很成熟的業務，很多這樣的公司，大部分全國性的互聯網公司都會使用到cdn。
總結：cdn服務。對於靜態內容是非常適合的。所以像商品圖片，隨著訪問量大了後，租用cdn服務，只需要把圖片上傳到他們的伺服器上去。
例子：北京訪問長沙伺服器，距離太遠。我完全可以把商品圖片，放到北京的雲服務（我覺得現在提供給網站使用的雲存儲其實就是cdn，給網站提供分流和就近訪問）上去。這樣子北京用戶訪問的時候，實際上圖片就是就近獲取。不需要很長距離的傳輸。
自己用一個域名img.xxxcom來載入圖片。這個域名解析到北京的雲服務上去。
做法:資料庫中保存的是」 images/2012/09/25/1343287394783.jpg」,
這些圖片實際上不存儲在web伺服器上。上傳到北京的cdn伺服器上去。
我從資料庫取出來，直接」img.xxxcom/」+」 images/2012/09/25/1343287394783.jpg」
比如如果還有多個，就命名img1.xxcom、img2.xxcom
反正可以隨便。所以如果把域名直接保存進去。就顯得很麻煩了。遷移麻煩。
像淘寶，凡客，亞馬遜這些電子商務網站，我們看到請求的時候，下面往往會有
img1.xxx.cdncom
img2.xxx.cdncom
其實他們保存在資料庫中的是相對路徑。有些是不需要在資料庫保存的，縮略圖可以實時訪問的時候用程序生成(節省很多存儲空間)
實際上，把域名保存在資料庫中，非常不利於系統遷移。一旦換個域名的話，原來保存在資料庫中的是「wwwabc.om/images/xxxxxx「,因為路徑都在資料庫中寫死了。下回換個域名就用不了了。那個時候自己去寫sql語句批量更新欄位吧。
幾個術語：
icp，Internet Content Provider，也就是網路內容提供者。聯想到我們運營一個網站需要icp備案了嗎？你自己運營網站，你就是icp服務商
IDC（Internet Data Center)，互聯網數據中心。IDC的概念，目前還沒有一個統一的標准。通俗點，就是提供機房託管(伺服器租用和託管)，域名注冊之類的。
關於淘寶的圖片存儲
了解到：淘寶以前使用了商用的存儲。但是沒法滿足需求。據說，到2010年，淘寶網後端保存著286億張圖片。商用的系統系統沒法滿足需求的時候。他們就自己開發了一個tfs。大規模的小文件在磁碟上讀取，需要磁碟磁頭頻繁的尋道和換道。大並發情況下和大量的操作確實很麻煩。其實借鑒了當時google公布的gfs設計論文。google有相冊服務。為每個用戶提供上傳圖片存儲。
估計，google是率先實現這種小文件網路存儲系統的。
有個觀點比較好：對於老闆們而言，往往覺得，用錢能解決的都不算問題。但問題在於，你遇到的問題，別人都沒遇到過。那這個時候你就沒有經驗可以參考或者直接拿來使用。只有自己參考一些思路去創造技術了。
三、關於圖片進行雲存儲(cdn加速)
曾經看過這個，這個是比較適合創業公司的。價格相對便宜
https//wwwupyun.com/
介紹提到，我們在全國各地部署了55個CDN節點，500多台伺服器，電信，聯通，移動和教育網的4線帶寬。
其實，現在的雲存儲本質就是一個cdn服務商。你把靜態的圖片上傳到他提供的伺服器上去(ftp方式上傳或者api形式編寫程序上傳)。他為你做就近節點訪問。
計費方式：按照流量付費，99元購買100g。怎麼算流量。每次訪問文件的大小累加，比如一個1m的文件，訪問一次流量就加1m。
我個人理解，對於圖片的量不大的情況下，使用這種雲服務，好處不是節省存儲空間。你自己的伺服器100g的空間可能創業型公司都沒用完，不是什麼存儲空間不夠用，然後去用雲存儲。以前我對cdn比較模糊，有這么點理解，或者以為是分散網站web伺服器流壓力，伺服器分流。這些好處是有的。但是，只要理解了cdn產生的背景和解決的關鍵問題後，就會明白雲存儲關鍵好處在於：給用戶就近節點訪問，加速。
我覺得，如果不是出於這個考慮，或者達不到這樣的目的。用其他方案也完全可以替代。何必使用雲存儲呢？就是你無非有實力做到全國多個節點去部署服務，才需要租用cdn來幫你，畢竟他們是規模產生的效益，專注於解決這個領域。

Ⅲ JS怎麼保存圖片到本地

js沒有操作本地文件的許可權，可以藉助.net,php等後端語言才行的，將圖片提交之後，返回個下載地址，window.open就自動下載了。
但是圖片可以是svg的話

function saveAs(Url,filename){
var blob=new Blob([''], {type:'application/octet-stream'});
var url = webkitURL.createObjectURL(blob);
var a = document.createElementNS(xhtml,'a');
a.href = Url;
a.download = filename;
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', true, false, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null);
a.dispatchEvent(e);
webkitURL.revokeObjectURL(url);
2.saveAs(data,"new.svg")

Ⅳ 前端js生成base64編碼後端c#怎麼保存成圖片

string base64= "xcuivosfoamfodamf;mzxcvl;。。。。。";
byte[] byteimage = Convert.FromBase64String(base64);
System.IO.File.WriteAllBytes(@"c:\test.jpg", byteImage);

就存到C盤下了， 文件名是test.jpg

Ⅳ html5 canvas在線生成圖片後怎麼樣保存到資料庫(伺服器端)而不是本地

canvas畫布保存為圖片：

functionconvertCanvasToImage(canvas){
varimage=newImage();
image.src=canvas.toDataURL("image/png");
returnimage;

canvas參數為你的canvas對象，返回一個圖片對象，你可以將這個image放到網頁結構中，如果要保存圖像，可以將canvas.toDataURL("image/png")返回的base64格式的圖片數據放到input（type=hidden）中，用戶點擊上傳按鈕（或設置表單自動提交），將base64格式的數據上傳

形如：

data:image/png;base64,/oMwlEs8yMgvJVcjyMbSYaERogCC0/kYEBAG/wdxC2W2tUAAAAAElFTkSuQmCC

伺服器端接收到字元串（以上字元串可以直接在瀏覽器中打開，IE低版本就算了，能用canvas的瀏覽器都可以）後根據data:image/png得知應該保存的文件類型擴展名（png），然後將base64,後面的base64編碼字元串解碼(後端語言實現，如PHP用base64_decode()函數)，將解碼後的二進制數據以二進制的形式保存到伺服器上（圖片形式）

如果存資料庫，可以直接存base64編碼，讀取時候解碼也行，圖片建議以文件形式存儲，資料庫不適合存大文件

Ⅵ thinkphp 後端 怎麼保存summernote 上傳的圖片

能雜保存~改用啥保存用啥保存
http://www.kancloud.cn/manual/thinkphp/1876
上傳表單
在ThinkPHP中使用上傳功能無需進行特別處理。例如，下面是一個帶有附件上傳的表單提交：
<form action="__URL__/upload" enctype="multipart/form-data" method="post" >
<input type="text" name="name" />
<input type="file" name="photo" />
<input type="submit" value="提交" >
</form>

注意，要使用上傳功能 你的表單需要設置 enctype="multipart/form-data"
多文件上傳支持
如果需要使用多個文件上傳，只需要修改表單，把
<input type='file' name='photo'>

改為
<input type='file' name='photo1'>
<input type='file' name='photo2'>
<input type='file' name='photo3'>

或者
<input type='file' name='photo[]'>
<input type='file' name='photo[]'>
<input type='file' name='photo[]'>

兩種方式的多附件上傳系統的文件上傳類都可以自動識別。
上傳操作
ThinkPHP文件上傳操作使用Think\Upload類，假設前面的表單提交到當前控制器的upload方法，我們來看下upload方法的實現代碼：
public function upload(){
$upload = new \Think\Upload();// 實例化上傳類
$upload->maxSize = 3145728 ;// 設置附件上傳大小
$upload->exts = array('jpg', 'gif', 'png', 'jpeg');// 設置附件上傳類型
$upload->rootPath = './Uploads/'; // 設置附件上傳根目錄
$upload->savePath = ''; // 設置附件上傳（子）目錄
// 上傳文件
$info = $upload->upload();
if(!$info) {// 上傳錯誤提示錯誤信息
$this->error($upload->getError());
}else{// 上傳成功
$this->success('上傳成功！');
}
}

上傳類對圖片文件的上傳安全做了支持，如果企圖上傳非法的圖像文件，系統會提示 非法圖像文件。 為了更好的使用上傳功能，建議你的伺服器開啟finfo模塊支持
上傳參數
在上傳操作之前，我們可以對上傳的屬性進行一些設置，Upload類支持的屬性設置包括：

屬性
描述

maxSize 文件上傳的最大文件大小（以位元組為單位），0為不限大小
rootPath 文件上傳保存的根路徑
savePath 文件上傳的保存路徑（相對於根路徑）
saveName 上傳文件的保存規則，支持數組和字元串方式定義
saveExt 上傳文件的保存後綴，不設置的話使用原文件後綴
replace 存在同名文件是否是覆蓋，默認為false
exts 允許上傳的文件後綴（留空為不限制），使用數組或者逗號分隔的字元串設置，默認為空
mimes 允許上傳的文件類型（留空為不限制），使用數組或者逗號分隔的字元串設置，默認為空
autoSub 自動使用子目錄保存上傳文件 默認為true
subName 子目錄創建方式，採用數組或者字元串方式定義
hash 是否生成文件的hash編碼 默認為true
callback 檢測文件是否存在回調，如果存在返迴文件信息數組
上面的屬性可以通過兩種方式傳入：
實例化傳入
我們可以在實例化的時候直接傳入參數數組，例如：
$config = array(
'maxSize' => 3145728,
'rootPath' => './Uploads/',
'savePath' => '',
'saveName' => array('uniqid',''),
'exts' => array('jpg', 'gif', 'png', 'jpeg'),
'autoSub' => true,
'subName' => array('date','Ymd'),
);
$upload = new \Think\Upload($config);// 實例化上傳類

關於saveName和subName的使用後面我們會有詳細的描述。
動態賦值
支持在實例化後動態賦值上傳參數，例如：
$upload = new \Think\Upload();// 實例化上傳類
$upload->maxSize = 3145728;
$upload->rootPath = './Uploads/';
$upload->savePath = '';
$upload->saveName = array('uniqid','');
$upload->exts = array('jpg', 'gif', 'png', 'jpeg');
$upload->autoSub = true;
$upload->subName = array('date','Ymd');

上面的設置和實例化傳入的效果是一致的。
上傳文件信息
設置好上傳的參數後，就可以調用Think\Upload類的upload方法進行附件上傳，如果失敗，返回false，並且用getError方法獲取錯誤提示信息；如果上傳成功，就返回成功上傳的文件信息數組。
$upload = new \Think\Upload();// 實例化上傳類
$upload->maxSize = 3145728 ;// 設置附件上傳大小
$upload->exts = array('jpg', 'gif', 'png', 'jpeg');// 設置附件上傳類型
$upload->rootPath = './Uploads/'; // 設置附件上傳根目錄
$upload->savePath = ''; // 設置附件上傳（子）目錄
// 上傳文件
$info = $upload->upload();
if(!$info) {// 上傳錯誤提示錯誤信息
$this->error($upload->getError());
}else{// 上傳成功 獲取上傳文件信息
foreach($info as $file){
echo $file['savepath'].$file['savename'];
}
}

每個文件信息又是一個記錄了下面信息的數組，包括：

屬性
描述

key 附件上傳的表單名稱
savepath 上傳文件的保存路徑
name 上傳文件的原始名稱
savename 上傳文件的保存名稱
size 上傳文件的大小
type 上傳文件的MIME類型
ext 上傳文件的後綴類型
md5 上傳文件的md5哈希驗證字元串 僅當hash設置開啟後有效
sha1 上傳文件的sha1哈希驗證字元串 僅當hash設置開啟後有效
文件上傳成功後，就可以使用這些文件信息來進行其他的數據操作，例如保存到當前數據表或者單獨的附件數據表。
例如，下面表示把上傳信息保存到數據表的欄位：
$model = M('Photo');
// 取得成功上傳的文件信息
$info = $upload->upload();
// 保存當前數據對象
$data['photo'] = $info['photo']['savename'];
$data['create_time'] = NOW_TIME;
$model->add($data);

單文件上傳
upload方法支持多文件上傳，有時候，我們只需要上傳一個文件，就可以使用Upload類提供的uploadOne方法上傳單個文件，例如：
public function upload(){
$upload = new \Think\Upload();// 實例化上傳類
$upload->maxSize = 3145728 ;// 設置附件上傳大小
$upload->exts = array('jpg', 'gif', 'png', 'jpeg');// 設置附件上傳類型
$upload->rootPath = './Uploads/'; // 設置附件上傳根目錄
// 上傳單個文件
$info = $upload->uploadOne($_FILES['photo1']);
if(!$info) {// 上傳錯誤提示錯誤信息
$this->error($upload->getError());
}else{// 上傳成功 獲取上傳文件信息
echo $info['savepath'].$info['savename'];
}
}

uploadOne方法上傳成功後返回的文件信息和upload方法的區別是只有單個文件信息的一維數組。
上傳文件的命名規則
上傳文件的命名規則（saveName）用於確保文件不會產生沖突或者覆蓋的情況。命名規則的定義可以根據你的業務邏輯來調整，不是固定的。例如，如果你採用時間戳的方式來定義命名規范，那麼在同時上傳多個文件的時候可能產生沖突（因為同一秒內可以上傳多個文件），因此你需要根據你的業務需求來設置合適的上傳命名規則。這里順便來說下saveName參數的具體用法。
採用函數方式
如果傳入的字元串是一個函數名，那麼表示採用函數動態生成上傳文件名（不包括文件後綴），例如：
// 採用時間戳命名
$upload->saveName = 'time';
// 採用GUID序列命名
$upload->saveName = 'com_create_guid';

也可以採用用戶自定義函數
// 採用自定義函數命名
$upload->saveName = 'myfun';

默認的命名規則設置是採用uniqid函數生成一個唯一的字元串序列。
saveName的值支持數組和字元串兩種方式，如果是只有一個參數或者沒有參數的函數，直接使用字元串設置即可，如果需要傳入額外的參數，可以使用數組方式，例如：
// 採用date函數生成命名規則 傳入Y-m-d參數
$upload->saveName = array('date','Y-m-d');
// 如果有多個參數需要傳入的話 可以使用數組
$upload->saveName = array('myFun',array('__FILE__','val1','val2'));

如果需要使用上傳的原始文件名，可以採用FILE傳入，所以上面的定義規則，最終的結果是 myFun('上傳文件名','val1','val2')執行的結果。
直接設置上傳文件名
如果傳入的參數不是一個函數名，那麼就會直接當做是上傳文件名，例如：
$upload->saveName = time().'_'.mt_rand();

表示上傳的文件命名採用時間戳加一個隨機數的組合字元串方式。
當然，如果覺得有必要，你還可以固定設置一個上傳文件的命名規則，用於固定保存某個上傳文件。
$upload->saveName = 'ThinkPHP';

保持上傳文件名不變
如果你想保持上傳的文件名不變，那麼只需要設置命名規范為空即可，例如：
$upload->saveName = '';

一般來說不建議保持不變，因為會導致相同的文件名上傳後被覆蓋的情況。
子目錄保存
saveName只是用於設置文件的保存規則，不涉及到目錄，如果希望對上傳的文件分子目錄保存，可以設置autoSub和subName參數來完成，例如：
// 開啟子目錄保存 並以日期（格式為Ymd）為子目錄
$upload->autoSub = true;
$upload->subName = array('date','Ymd');

可以使用自定義函數來保存，例如：
// 開啟子目錄保存 並調用自定義函數get_user_id生成子目錄
$upload->autoSub = true;
$upload->subName = 'get_user_id';

和saveName參數一樣，subName的定義可以採用數組和字元串的方式。
注意：如果get_user_id函數未定義的話，會直接以get_user_id字元串作為子目錄的名稱保存。
子目錄保存和文件命名規則可以結合使用。
上傳驅動
上傳類可以支持不同的環境，通過相應的上傳驅動來解決，默認情況下使用本地（Local）上傳驅動，當然，你還可以設置當前默認的上傳驅動類型，例如：
'FILE_UPLOAD_TYPE' => 'Ftp',
'UPLOAD_TYPE_CONFIG' => array(
'host' => '192.168.1.200', //伺服器
'port' => 21, //埠
'timeout' => 90, //超時時間
'username' => 'ftp_user', //用戶名
'password' => 'ftp_pwd', //密碼 ),

表示當前使用Ftp作為上傳類的驅動，上傳的文件會通過FTP傳到指定的遠程伺服器。
也可以在實例化上傳類的時候指定，例如：
$config = array(
'maxSize' = 3145728,
'rootPath' = './Uploads/',
'savePath' = '',
'saveName' = array('uniqid',''),
'exts' = array('jpg', 'gif', 'png', 'jpeg'),
'autoSub' = true,
'subName' = array('date','Ymd'),
);
$ftpConfig = array(
'host' => '192.168.1.200', //伺服器
'port' => 21, //埠
'timeout' => 90, //超時時間
'username' => 'ftp_user', //用戶名
'password' => 'ftp_pwd', //密碼 );

$upload = new \Think\Upload($config,'Ftp',$ftpConfig);// 實例化上傳類

目前已經支持的上傳驅動包括Local、Ftp、Sae、Bcs、七牛和又拍雲等。

Ⅶ 圖片一般是放在網站後台的那個目錄

存儲圖片一般用兩種方法，一個是二進制存儲圖片，有點麻煩，網上有很多，得自己學，講也講不清楚
另一個是把圖片直接存在項目路徑中，就是在項目中建個文件夾，把圖片放到里邊，讀虛擬路徑就行了，例如（~/images/1.jpg），這個就需
要把圖片先存放在本地機器上，一般都用這種，其它的方法暫沒發現

Ⅷ java web項目中有很多的圖片，如何存放

一般有兩種情況，
一種是前端開發需要顯示的圖片，這個是頁面構成必須的元素，一般這些會做 動靜分離，後台介面 跟 前端資源會部署在不同的伺服器上，有不同的優化，一般會有轉發的伺服器，判斷是後台介面，就轉發到後台的伺服器，如果是前端資源，就轉發到前台的伺服器。一般情況下，前端伺服器，跟後台的伺服器，是分離開的，有不同的人去管理，如果項目小的話，可能就全放在一個。這個優化的化，你可以去了解下 CDN原理。這個是用來優化靜態資源載入情況的。
另一種情況是，顯示的圖片，不是前端構成的，是用戶上傳文件產生的，這種情況下，現在一般有專門的對象存儲，用過 七牛雲，跟阿里的。這個的邏輯是文件上傳的時候，不是上傳到我們自己的伺服器，上傳到專門的雲伺服器，我們自己資料庫只需要保存這些上傳文件的地址，真正使用的時候，把連接給前端，前端自動會根據內容到專門的雲伺服器上去獲取。所有的安全，優化，帶寬，緩存命中，這些都有由雲伺服器去保證。 簡單來說，只有有錢，這些東西根本不會成為你項目的瓶頸。
作為技術，我們討論的應該不是這些。圖片會做備份，這個可以有專門的磁碟陣列去實現，簡單來說，就是上傳的內容保存到磁碟的時候，會自動多保存幾個備份到不同的磁碟上。還是那句話，多去了解下CDN的原理，最後這段，個人理解，不一定對。

Ⅸ 做後端，用Java怎麼處理從客服端傳過來的圖片，我想了下，是把圖片的地址和圖片本身分開來存儲，圖片

其實這個很簡單，別人發請求給你，你得到這個圖片，是個file，那你喜歡保存在哪裡都可以，之後要查看圖片，跟你有JSP上的圖片是一樣的查看方法