greensea 的 blog

到后台风格界面模板dispbbs(1)
找到
  if (obj){
  if (obj.offsetHeight>300){
  obj.style.overflow='hidden';
  obj.style.height='300px';
  }
修改成
  if (obj){
  if (obj.offsetHeight>550){
  obj.style.overflow='hidden';
  obj.style.height='550px';
  }
这样图片高度限制就是500

注意，代码中写的高度要比实际要限制的高度多50px，这多出来的50px是为了显示签名下面的文字，比如“符合XHTML标准”。如果仅仅设置为500的话，当某个图片是500px时，图片下面的文字将无法显示

说是经验教训，其实也是软件的Bug，唉……

1、
NTFS大小写问题导致的文件被误覆盖
使用IE进行FTP上传操作，本地的磁盘格式为NTFS，并且设置了文件名区分大小写，服务器上的文件名设置为不区分大小写
远程目录上有一个abc.mdb文件
本地目录上有一个Abc.mdb文件
问题出在这里
如果我们从本地目录上上传一个abc.mdb文件，IE会提示是否覆盖
但是，如果我们上传的是Abc.mdb（注意大小写）的话，IE将不会提示，直接上传该文件。并且上传完毕后还能在远程目录看到Abc.mdb和abc.mdb两个文件
但是实际上，远程目录上只有一个文件，就是刚刚上传上去的Abc.mdb
IE并没有进行提示，就直接覆盖上去了
我就是因为这样，弄丢了一个数据库，哭啊````

2、CuteFTP的文件下载的鬼
CuteFTP（我使用的是CuteFTP 8.x版本）在进行下载文件的时候，如果设置为“如存在同名文件则不提示直接覆盖”的话，CuteFTP将首先删除本地文件，然后才开始下载。这样就出现一个问题。如果远程文件在传输的时候出现错误（实际上不仅限于这种情况，文文末我会说我遇到的那种情况），那么文件无法完全下载完，如果这个时候服务器上的文件正好又出了什么问题的话，那么这个文件就丢失了。有人说可以用EasyRecovery恢复，我遇到这个情况的时候已经马上停止对文件所在磁盘分区的一切操作，并立即使用EasyRecovery尝试恢复，可是，恢复失败，根本没有找到那个文件，天知道CuteFTP是用什么方法删除的。
我遇到的情况是，我上传一个数据库文件，上传到一半的时候，我发现传输停止了，我想是网络的问题，于是停止传输，这时已经把文件的差不多一半上传到服务器上了（看文件大小可知）。我再次尝试上上传，可是总出错，我确定网络没有问题后，看看日志，竟然说“找不到目录”。我倒，那我刷新目录看看，一切正常，目录列表可以出来。然后我再尝试重命名服务器上的上传到了一半的文件，这时提示是“找不到该文件”，我的天啊！！怎么会这样。接下来我就很顺理成章的尝试能不能下载，可是，这回出现的提示是，无法读取文件，我无语……。我想那算了，先不管了，回头来看看本地的那个文件，然而，这时我发现，我的文件找不到了，这时我才想到是CuteFTP在进行文件下载前把它删除了的，可是服务器却无法返回数据流，等于说，本地文件，被删除了……

就这样，又丢了一个数据库。（后来我用服务器上的上传了一半的文件恢复了一半的数据，还算好吧，我再看看以前备份的数据库有没有那部分无法恢复的数据）

两个数据库，两个教训，要牢牢记住啊

今天一口气把还没有看的零给看完了，呼~~~还算是美好的结局。看完12集我还以为才人真的要回去（貌似应该说回来……）了，让我感觉比AIR还悲伤。
这样说，因为才人可以很熟练的操作此类机械，所以如果飞机有故障的话才人坐上去也应该会知道故障出在哪里，应该如何修复。材料可以用摩法解决，用摩法制造飞机零件应该不成问题。燃料问题也很好解决，那个什么老师一个晚上就能复制出4桶，可见产量还是很高的。接下来是日食，日食是没一两年就会发生一次，虽然不在同一个地方发生，但是有飞机，可以很容易地到达将要发生日食的那个地方。至于日食什么时候发生，也没问题，这个摩法世界已经可以计算出日食发生的时间。最后就是到我们这个世界时的降落问题以及空中管制问题，如果惊动军方的话肯定麻烦大了，所以可以用封属性的摩法进行垂直降落，然后用什么魔法把飞机隐藏起来。接下来，想办法弄到一点我们这个世界的货币，用摩法对其进行复制（才人他们情况特殊，就不要追究法律责任了吧……），然后乘坐我们这个世界的交通工具即可回到日本。
这样，才人和零就可以在我们的世界住一段时间，然后回到魔法世界去一段时间，如此反复。才人既可以回家，零也不会离开家，最重要的是，两人可以永远在一起了。
零和零之使魔，好幸福……
羡慕死……
我的零啊，好想和你在一起

因为我要同时使用PHP和ASP，并且我使用的是XP操作系统，IIS连接限制为10。如果全部都让IIS来处理的话是不行的，因为我也要对外开放访问。因此，我使用了Apache+IIS，并且让Apache作为IIS的代理以实现这两个服务器的并存。
IIS我指定为81端口，然后让Apache对从gsea.com.cn域名进入的请求全部转入gsea.com.cn:81，也就是转入IIS。
IIS上我设置了个bbs的虚拟目录，放置动网论坛。
问题在这里出现。
从gsea.com.cn/bbs访问的时候，出现“该页无法显示”。但是从“gsea.com.cn:81/bbs”却可以正常访问。
首先我排除了IIS的问题，因为从81端口直接访问是可以正常显示的。初步推断，问题出在代理这个环节上。
我把bbs下index.asp删除，然后从gsea.com.cn/bbs访问，出现IIS的禁止浏览目录的提示。
这样可以肯定是代理这个环节出问题了。
我把index.asp改名为index.htm，再次访问，可以正常显示。也就是说，只有ASP页面才会出这个问题。
然后我访问Dv_getCode.asp这个文件，是生成验证码的（注：该文件仅仅使用了Adodb.Stream，没有使用数据库等之类，也就是说和动网系统几乎没有什么联系），可以正常生成验证码。
我又把bbs这个虚拟目录指向其他的ASP程序，不指向动网论坛了，可以正常显示。
这样就说明是动网论坛的问题了。
可是问题出在哪里呢？
我直接访问conn.asp文件，可以被解析，没有出现“该页无法显示”。
打开conn.asp文件，仔细看了看，先后修改了几个地方，都不行。然后我把Response.Buffer = True改成False，访问论坛首页，这下能解析一部分了，不过没有完全解析，出现了ASP错误，提示在Dv_ClsMain.asp 388行又错误，于是我打开Dv_ClsMain.asp，找到388行，发现这个是一个处理禁止使用代理访问论坛的代码块，如果使用代理，则  Response.Status = "302 Object Moved" ，我猜测302应该就是会使浏览器出现“该页无法显示”的状态代码（这和404找不到网页是差不多的）。 代理…代理……Apache不是作为IIS的代理的吗？问题就是出在这里了，通过Apache转向到IIS时，动网论坛认为是使用代理访问，所以就输出这个错误，这也就说明了为什么可以通过81端口访问而不可以通过80端口间接从Apache来访问。
原因知道了，接下来也就好解决了。
取消禁止使用代理访问的设置（当初我这样设置是为了抵御CC攻击），这样就可以直接通过gsea.com.cn/bbs来访问了。问题解决。

这是一个很难发现原因的错误，我回想一下，是通过慢慢排除可能的原因，慢慢测试，逐步定位问题根源，总的来说这个问题解决还是比较快的，也许花了半个小时吧，也不太记得使用了多少时间。
嗯…这次解决这个问题……又得到了宝贵的经验了，哈哈

如果我没记错的话

应该是DV6.0帖子列表部分是用JS输出的

这样对搜索引擎很不友好

于是动网在7.0版本取消了用JS输出帖子列表，改普通的HTML输出

之后在7.1

当时XHTML方兴未艾

很多网站都开始尝试XHTML

没错，XHTML对搜索引擎是比HTML更友好

动网那个时候也加入了这个行列

记得是在更新公告里说

帖子列表输出采用DIV+CSS，对搜索引擎更友好

看看现在的帖子列表，全部都是DIV

我想问，表格是作什么用的？

表格难道不是为了以表格方式显示数据的吗？

帖子列表，以及帖子相关的信息，输出不应该是表格数据的形式吗？

为什么要使用DIV？

难道搜索引擎看到DIV就会给你网站更高的优先级吗？

表格有表格存在的理由

表格是为了输出表格类型的数据的

既然是表格类型的数据就应该用表格输出

用DIV，其内容表现根本没有表格的好

放着表格好好的一个东西不用，去用DIV

根本就是把简单的事情复杂化

表格类的数据，你用表格输出，反而对搜索引擎是更友好的

不知道动网在下一个版本会不会使用表格而不是层

-------------------------

PS

刚才看了看PHP版本，帖子列表已经基本采用表格了，不过还有一点层穿插在里面。我没有仔细研究这些层又没有用，暂时就不发表评论了


-----------------------------
再PS一下

XHTML的一个重要目标是表现型与内容相分离，所以代码应该尽量结构化，尽量使用CSS来控制布局