后端如何存储图片

Ⅰ 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上的图片是一样的查看方法