iLeichun

1、left直接截取
2、人为添加标记
3、直接给个摘要的字段，写文章时自己写摘要。
其中1、2两条在处理长文章分页时也经常用到。

在写文章时，在要截取的位置加上一个[|]，在显示摘要时，用 <%=split(rs("content"),"[|])(0)%>
在显示文章时用<%=replace(rs("content"),"[|]","")%>

一个网站怎么样去进行网站的文件夹的命名，网站文件的命名呢？这些命名是不是有什么规律呢？还是网站的名称可以随便命呢？好的网站文件夹与文件命名有利于网站的优化。

其实网站命名是可以随便命名的，但是有一种比较规则的命名：

根目录只允许存放index.html和main.html文件，以及其他必须的系统文件。

网站建设根目录下的images为存放公用图片目录，每个目录下私有图片存放于各自独立images目录.
例如：menu1images
menu2images

所有js文件存放在根目录下的script 目录
所有CSS文件存放在根目录下的style目录
所有CGI程序存放在根目录并列目录cgi_bin目录


网站建设目录建立的原则：以最少的层次提供最清晰简便的访问结构。
根目录：根目录指DNS域名服务器指向的索引文件的存放目录。

每个语言版本存放于独立的目录。例如语言设置为：
简体中文 gb
繁体中文 ig5
英 语 en
日 语 jp

每个主要功能(主菜单)建立一个相应的独立目录。

全站FLASH网站建设现在越来越流行,特别是一些品牌网站，很大一部分都是全FLASH来实现，展示其炫与酷。

的确，品牌网站利用FLASH来制作是有一定的优势，毕竟FLASH网站可以表现动态网站不能表现的一些效果。

制作全Flash网站和制作html网站类似，事先应先在纸上画出结构关系图，包括：网站的主题、要用什么样的元素、哪些元素需要重复使用、元 素之间的联系、元素如何运动、用什么风格的音乐、整个网站可以分成几个逻辑块、各个逻辑块间的联系如何、以及你是否打算用Flash建构全站或是只用其做 网站的前期部分等等，都应在考虑范围之内。

实现网站设计效果多种多样，但基本原理是相同的：将主场景作为一个"舞台"，这个舞台提供标准的长宽比例和整个的版面结构，“演员”就 是网站子栏目的具体内容，根据子栏目的内容结构可能会再派生出更多的子栏目。主场景作为"舞台"基础，基本保持自身的内容不变，其它"演员"身份的的子 类、次子类内容根据需要被导入到主场景内。

从技术方面讲，如果你已经掌握了不少单个Flash作品的制作方法，再多了解一些swf文件之间的调用方法，制作全Flash网站并不会太复杂。

参考流程：网站结构规划—> Flash场景规划—>素材准备—>分别制作—>整体整合

企业网站建设，要充分考虑网站的各方面需求，对网站建设前要进行合理规划，网站建设过程中对一些细节问题要执行到位，同时也要考虑到后期的网站推广成本！网站建设要符合以下标准：

1、网页设计具有营销功能。网站建设都具有营销功能，有效的降低后期的网站推广成本！
2、网站建设要体现企业客户的专业性。只有专业性，才能提高网站的整体形象。
3、网站建设不能脱离企业的实际情况，强调根据企业规模做事做适合企业发展的网站。
4、网站建设符合企业的发展需要现阶段发展需要，也要强调进行网站远景规划。
5、网页设计符合国际WEB标准和中国互联网协会网站建设指导规范。符合标准的网站更加有利于网站的推   广。
6、网站建设在制作过程中充分考虑到搜索引擎的需求要，即如何设计才能更好的让搜索引擎收录。
7、网站建设充分考虑到用户体验，提高潜在客户的转化率 。
8、网站建设符合国际网络营销指导标准。有利于企业基于网站平台实施网络营销。

只有符合网站建设标准的网站，才能降低最终的总整体成本，才能最终实现低投入，高回报的投资。网站建设不但要考虑好技术问题，更要考虑网站的营销的“软”问题，因为这才能最终保证网站的效果，保证企业对网站投入的收益，也才能保证网站建设后期的综合推广成本。
 

对于品牌网站，我们一般采用的是动态式设计，这里讲的动态并不是采用动态制作网站，而是可以借用视频效果体现品牌。比如说一段广告或是一个几秒的FLASH来展示企业的高贵形象。而对一般的较小的企业，我们又应该怎么去设计才能体现企业的形象呢？

小企业，我们在设计的时候也要考虑一些问题，怎么把握小企业网站外观设计？

有时，你一眼就能认出，某网站属于小型企业，这是因为网站的外观设计和结构往往会暴露出相关信息，例如：怪异的字体，主页内容只有一栏，有时还是居中格式设计，贫乏的正文、错误的链接、不同网页的格式各不相同……

对于那些希望在网上取得丰厚收益的小企业来说，有许多问题需要考虑，这些问题的核心就是：给访问者以信心！通过网络与你的公司做生意，需要取得每个第一次来访者的信任，他们对你的了解是从网站开始的，而且很大程度上是从网站外观来进行判断。因此提醒小企业：注意企业网站外观设计！

看看自己的网站，客观公正地评价一下，是否可以称得上可靠的、专业的业务场所？如果回答是否定的，那么应该考虑更新设计你的网站了。这听起好像是一项庞大的工程，实际上，如果方法得当，也许不需要太大的工作量。

向同行学习，可以少缴学费，因为别人已经为找到最好的模式付出了代价。如果你销售原料，就参考原料网站的领先者，不要仅仅浏览，还要深入挖掘内容的细节。打印出你所在行业前十位网站的主页，并排订在墙上，分析别人是如何做的，为什么这样做，找出他们设计的共同点并指出他们的区别。

研究别人的运作方式和效果是一个聪明的办法，你可以受到许多启发，避免为自己的错误付出沉重代价，从而建立一个让访问者充满信心的网站。
 

一、问题起因
在某项目释放后Bug统计的附件《释放后问题》里有：  
问题  原因  分析  备注 
CSV处理时，如果处理的主题数过多，发生URL参数上限的错误；  可变长度的参数通过URL方式传递，会造成这种潜在的错误发生。  1、属于2次发生问题，开发方面没有及时通过checklist等方式向组员传达相关注意事项；
2、测试时没有作大批量数据的测试；  1、作为经验添加至CheckList中，加强组内共享、检查的效果；
2、加强测试点是否完备的检查，重点关注对开发方面共性问题的测试； 
通过对模块原有GUI状况确认，进行CSV输出时，输出结果很大的场合，CSV文件的内容不能输出。  没有考虑到POST数据量存在128K的大小限制。  这属于新问题，以前从未遇见过，也没有进行过大规模的数据量测试  已将此类检查列出CheckList中 

做为一种经验积累，这些问题、原因及解决办法将被列入Checklist，那么：
第一个问题：URL参数上限的提法准确吗？上限是多少？
第二个问题：为什么POST时数据有限制？限制是128K吗？ 
二、问题分析
1、第一个：
1）URL不存在参数上限的说法。该问题实际是IE对URL有长度限制的问题。
2）HTTP协议规范也没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。[参1]
3）“可变长度的参数通过URL方式传递”实际是说提交表单时使用了GET方法，而不是POST方法。造成这种潜在错误的是使用GET方法提交表单数据。因为GET方法将数据放在URL里传递给服务器处理。
4）注意这个限制是整个URL长度，而不仅仅是你的参数值数据长度。
5）既然是IE对URL长度的限制，那么不管是GET方法还是POST方法都存在这个限制。
(关于FORM的GET和POST方法具体内容请参考相关资料[参2]) 
建议：
1）了解应用程序所在的环境，如Web应用的浏览器、服务器环境，了解其特定的参数限制情况。
2）提交复杂数据尽量使用POST方法。注意FORM不写method属性时默认是使用GET方法。
结论(写入Checklist)：
对使用GET方法提交数据时，在IE环境下，需要考虑URL长度2083字节的限制。
2、第二个：
1）理论上讲，POST是没有大小限制的。HTTP协议规范也没有进行大小限制。
2）“POST数据量存在128K的大小限制”不够准确，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。
3）对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。对于需要处理超过100K表单域数据的解决办法，请参考后面的[参3]。
4）由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制[参4]。我们还需要注意：
    IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
    IIS 6.0默认上传文件的最大大小是4MB。
    IIS 6.0默认最大请求头是16KB。
    IIS 6.0之前没有这些限制。
建议：
1）弄清楚运行环境的默认设定值有助于你的设计及对出现的问题做快速的解决。
2）应该考虑服务器版本。各个版本的IIS对这些参数的默认设定都不一样，有必要的话，找资料整理出一份对照表。这样开发与测试时都有个参考。
3）IIS 6.0的这些限制实际只是它的默认设定值而已，实际应用环境你可以修改它们。
    在WINNTsystem32inetsrvMetaBase.xml里默认定义了：
        AspBufferingLimit="4194304"           对应于上传文件最大大小
        AspMaxRequestEntityAllowed="204800"    对应于POST最大数据量
结论(写入Checklist)：
使用ASP时，需要考虑POST表单每个域一般读取处理时有100KB的限制。充分考虑是否使用Request.Binary



本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gaozhigang/archive/2009/08/14/4445458.aspx

GET方式传值的最大长度

都有些道理。引用其中一些观点：

get
首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系 了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。 　　注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。

【get方式提交数据的大小，http协议并没有硬性限制；而是与浏览器及服务器、操作系统有关。第二篇文章里，就有谈到用apache测试，使用get方式，url最长可达8167b。其中跟帖留言中还有谈到代理的因素在里面，可能url太长还没到服务，就已经被代理拒绝掉了。第一篇的留言讨论很能学到东西哦~ 】

post
理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在 80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。

　　对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个 限制。

　　由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：

1).IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
2).IIS 6.0默认上传文件的最大大小是4MB。
3).IIS 6.0默认最大请求头是16KB。
IIS 6.0之前没有这些限制。[见参考资料5]

　　所以上面的80K，100K可能只是默认值而已(注：关于IIS4和IIS5的参数，我还没有确认)，但肯定是可以自己设置的。由于每个版本的 IIS对这些参数的默认值都不一样，具体请参考相关的IIS配置文档。

【post方式，传送数据最大理论上没有限制，取决于服务器设置和内存大小。】