支持连接识别、字体、颜色、表情了 ! (0分)

[]

soul, 具体情况丝这样：
目前的 replace.asp 15k，大部分是用 asp 加了一部分正则表达式(主要是split)。
我把它用 Javascript 改写了，全部用正则表达式，最后大概有 8k - replace1.asp。
为的是减少 include 的字节数。如果您用上面的vbscript写法，字节数仍会很高。
理论上讲，我的那个 Javascript 可以用在服务器端、也可以用在客户器端。
问题是：
- 服务器端
您的 JScript 引擎与我的不一样，解释不了下面这句中的 ?
theString = theString.replace(//(.+?)/[//b]/gi,"<b>$1</b>");
没有这个 ?，{b}aaaa{/b}{b}bbbb{/b} 会变成 <b>aaaa{/b}{b}bbbb</b>
所以，服务器端暂时用不了这个。除非您有了新的 JScript 引擎。
- 客户器端
因为我们是做了 xsl 解析的，必须使用 <xsl:script> 和 <xsl:evel> 来调用 script
但这是 MS 定义的 xsl 标记，不是 w3c，所以我没有用。
您所说的：每个内容用 id 标记好，在内容结束后调用修改其中内容。
这个方法不一定行，而且把程序弄成那样，我连试验的兴趣都没有了。
我的解决方法是使用 IE 5.5 的 element behavior，也就是 custom tag 技术。
还记得以前我们模拟的那个大富翁 desktop，多窗口界面？同样的技术。
但是，就想上面左兄所说“要求升级到5.5就太夸张了点吧”，而且客户器端的
JScript 引擎也可能不支持正则表达式的 “?”。
结论就是：目前暂时留在服务器端吧。留在服务器端的做法有三个：
1、升级 JScript 引擎
2、改成 ASP
3、用 Delphi 做 COM
我倾向于 3，这样效率好些，又可以与语法显示集成起来，在我上次给您的 COM 中，
您可以看到两个函数：code2html，parseUBBTag，分别就是语法显示和 ubb tag 处理。
请您选择一个方案，如果选方案 1，2，就全部拜托您负责处理。
如果选方案 3，您可以选择您来做 parseUBBTag，还是有由我做。您决定吧。

方案1、具有风险性，服务器轻易不该升级什么。而且采用两种script引擎不是好办法。
负担太重。
2、3就不多说了。
我觉得问题在这几个方面。
1、到底在客户端做好，还是在服务器端做好。
2、选择解释ubb的方案，是用vbscript，还是javascript，还是com
3、和xml的结合程度。
4、如果在服务器端在什么时候进行解释。
先说明一点，如果在客户端，我的方案其实可以改动很小，其实只要在 <td>处加上一个
固定id即可。<td id=content> 如此在最后加一个处理过程即可，因为这样处理后，ie
会吧content这个id作为一个数组处理，这样就可以完全躲开那些“标准”，而且完全
不影响xml和xls。我在ie4的时候就很驾轻就熟这种方案了。
如果在服务器端，我主张采用com在输入时处理，并且另存为一个新字段。其实更好点
可以另存为一个标准目录下的xml文件，这样既减轻了服务器sql server的负担又减轻
了web server的负担，又更方便大家更新和下载数据，也更符合xml的本意。
我总是想减轻些服务器的负担，原因很简单，我想以后可以加入更多的服务。如果现在
负担就很重了，加上这个服务器还要承担一下其他政府职能，以后就很难加了。
下一步，我想把工作分两方面走，一方面是优化和整理工作，这个一做完，立刻就进行
再下一步的联合开发工作，即建立大富翁项目管理模块。另一方面，我们正在联系多方
的人，比如出版社等，从深层次上抬升大富翁的影响力。
所以我希望大富翁的这样的讨论能更多，不过总觉得缺点什么，总觉得不是很系统化，
我想我会在项目管理模块中解决这个问题。即把讨论深入到每个模块，每行代码上。
现在大富翁的只有一个大广场，我想该是造几幢房子的时候了。让专业帖子有附着力，
更系统化。

soul,我从一开始就是希望在客户端做，记得发过个 email 给您，向您极力推崇客户端的好处。
于是，我的试验摸索，是从客户端开始的，而且就是您的方案 td id=? 加 <script> 。
要知道我们的 <td>xxxx</td> 是 xslt 的结果。IE 显示 xslt 的结果时，不再执行
其中的<script>！
如果要一边运行 xslt，同时执行某些 script 的话必须把 script 放在微软的
<xsl:script> .... </xsl:script> 中，而不是 <script> .... </script>，
调用的时候，必须用微软的 <xsl:eval> .... </xsl:eval> 来触发那些 script。
但是，<xsl:script><xsl:eval> 不是 w3c 标准。
利用 IE 的 Custom Tag 倒是可以。用 xslt 输出 <tools:ubbcontent>...</tools:ubbcontent>
之类的东西，IE 一看是 Custom Tag，就会前去调用 Custom Tag 的 htc 程序。这样解决了
在 xslt 处理结束后，再调用 script 的问题。
还有一个附带的问题，就是您用 td 得到的 innerHTML 中没有换行(被 IE 过滤了)。
必须用 Custom Tag 的属性，才能保留换行 <tools:ubbcontent content="......" />
经过一番周折，我最后终于用 Custom Tag 搞定。速度还不错。但是，新问题又产生：
那就是 Script 引擎问题。
不要怕，我并没有说需要额外的，或者两个引擎， windows 本身就带有JScript引擎和
VBScript引擎。本来就是一回事情，而且 windows 本身就有的，否则 ASP 怎么运行。
以前，微软的 Script 引擎中，VBScript的正则表达式功能一直不如JScript，所以，您
看到两种Script 的混合使用。
但是，今年4，5月份间微软发布 Script 引擎 5.5 版本，使得VBScript的正则表达式功
能达到与与JScript一样的功能，并且两者都进行了功能扩充。
http://msdn.microsoft.com/isapi/gomscom.asp?TARGET=/msdownload/vbscript/scripting.asp
不幸的是，我们需要的 ? 符号处理，落在扩充后的新引擎中。老的引擎不能处理 ? 符号，
除非做大量 split 操作。就象那个 replace.asp。问题是，[blue]不是所有客户都具有 5.5 版的 Script 引擎[/blue]。
所以，我这么热衷于客户端处理的人面对如此状况，只能暂时放弃客户端处理。
看着辛辛苦苦弄出来的 Javascript 程序比原来的 ASP 简洁许多，就想加个runat=server，
来替换那个将近大一倍的 replace.asp。我的服务器是 5.5 版引擎，成功了。而您的服务器估计
是老的 5.1 版引擎，所以做上载上去后不行。最后只能恢复了原状。
因为我一直考虑的是客户端方案，只是最后不想浪费，才试着把 JScript 用在服务器端。
没有成功，说一说了升级引擎。看您说了要改写成 VBScript，才提议 ASP。
觉得 COM 可能可以提高些效率，才提议 COM 方案。
所以，上面就是提出那供您参考的那三条意见的背景情况。
对服务器端方案，我还没有多研究。很欣赏您提到的输入时处理，并且另存为一个新字段
或者 xml文件的想法。
现在问题有 52000 多个，新字段的话（建议做个新表，两个字段 id, xml），数据库容量
大概会翻一番。而文件的话就会有 52000 多个 15k 左右的文件，近 1G。
很感兴趣看看哪种方案效率高，负载小些。
因为，您操作服务器方便，所以，还是拜托您根据服务器实际情况，负责处理这个事情吧。
有结果通知我就行了。我准备做第三个 skin，不碰 ubb 了。

真曲折啊，呵呵。
我试验一下一些技术问题先。

oh........yysun, 在IE4.0以上都有正则表达式的支持。事实上在正则表达式的规范
上，IE4已经支持得非常全面了。所以你不必要求必须是IE5/5.5以上的客户端。
我有在IE4.0基础上实现过一个非常完整的客户端对HTML标志的限定。但它处理的是字
字符串(它是用来做聊天室的客户端语法检测的)，所以可能不适合你的要求。
不过，我同时也做过一个服务器端的，用的是非常快的pChar处理算法，我想可能对你
有一些参考。
我放在了这儿：
http://202.102.247.230/soft/HTMLCharPro.pas

对于语法，颜色，和图标的显示，我保留意见。
更好的内容需要更好的表现形式，但是不要喧宾夺主了。
另外，如果，能够开个新闻组就更好了。
而且可以和bbs同步更新。
想法是不是很过分，但是高手那么多，应该没有问题吧。：-）

奇怪啊，奇怪，为什么
LContent.innerHTML=LContent.innerHTML;
后回车就没了呢，取出来是对的，但一赋值就不对了。好像pre不起作用了啊。
function show() {
load_xml(menupanel, menuxml, menuxsl);
load_xml(mainpanel, mainxml, mainxsl);
chageIdcontent(mainpanel);
}
function chageIdcontent(obj)
{ var i;
var s;
for(i=0;
i< LContent.length;i++)
{
s=replaceUBB(LContent.outerHTML);
LContent.outerHTML=s;
}
}
function replaceUBB(s)
{
return s+"改改改";
}
这样倒是可以。

知道为什么了id不能设在pre这里，否则一赋值pre就失效了。
如果这样就没问题了，这样的话就可以在客户端做更多的事情了。（负担重的不做）
<tr><td bgcolor="#ffffff" id="LContent"><pre style="font-family:宋体">
<xsl:value-of select="content" /></pre>
</td></tr>
在td处有个id。然后
function show() {
load_xml(menupanel, menuxml, menuxsl);
load_xml(mainpanel, mainxml, mainxsl);
chageIdcontent(mainpanel);
//在完成后改变内容
}
function chageIdcontent(obj)
{ var i;
var s;
for(i=0;
i< LContent.length;i++)
{
s=replaceUBB(LContent.innerHTML);
LContent.innerHTML=s;
}
}
function replaceUBB(s)
{
return '<pre style="font-family:宋体">'+s+"改改改"+'</pre>';
//加上pre标记
}

非常感谢 aimingoo 和您的程序！
soul, “在完成后改变内容”而不是边解析边改，可能有戏。
我发现用 pre 取 innerHTML 有回车， div, p 则没有。
我想在 skin3 中用上 custom tag 技术。

上面写错了，
<tr><td bgcolor="#ffffff" id="LContent">
<xsl:value-of select="content" />
</td></tr>
在这里不要用pre，然后在处理之后再加上pre，这样就能很好地保持住回车了，
回车并不是被过虑了，而是pre失效了，必须自己加进去才没问题。
我们的代码还有一个小问题，就是其实该先测试一下是否存在LContent.length，如果
存在，说明有两个以上这个id，否则只有一个，不是数组。
不知道您是如何测试的，我在div，td，pre里取出来都是有回车的，但不能赋值，一赋
值回车就没了，再取就没了，我想这也许他的一种优化机制。但在赋值时候两头加上pre
后，也许这种机制就关闭掉了。然后结果就对了。
我的结果是这样，您那里如何？

我想，如果这个帖子先是那些代码，然后相应处是我们的一重重讨论，那该多好啊。

soul, 太好了。我现在没有动这部分东西，在玩 custom tag 呢。
div, td, p 是赋值时丢掉回车。可能就是这样(好像我是用 alert 试验，没有看见回车)。
pre 赋值时，不丢掉回车，但我没有想到“赋值时候两头加上pre”也能保留回车 []
上面的 xsl 应该是：<xsl:value-of select="content" disable-output-escaping="yes" />
以便完整取得 CDATA 的内容。
ftp 密码忘记了，能否再发个到 mailto:yyaun@263.net ? 谢谢。
下次一定注意先讨论代码。

yysun：不是要你注意什么呀，呜呜，您又误会了啊。
我是在设想一种论坛的形式，类似于批复一样。比如我们的论坛代码，我们公布出来，
可以分段，分函数。然后在代码的相应位置上开始我们的讨论，看上去就好像代码活了
一样，多好啊这样。

少写一句话，突然发觉怎么改写帖子没了？
我现在想想，确实老能该也不好，要不规定必须在帖子贴出后1小时内改正，否则.....
要不给个旁注？

还有我这里pre赋值也丢回车。
那句想说的话已经忘了........... :-(

soul, 不会有误会的，我们之间谁跟随啊。
我真是觉得您的建议很好，有时候我下了结论，可是没有讲清详细的依据，特别是对您比较
直接，但是总是有点让人摸不着头脑。从力求严以律己的角度出发，下次应该采用您的建议。
您设想的功能很好，很喜欢。可能需要用很多 dhtml 和 css 来做吧。

　　呵呵～～实在是没时间慢慢分析大富翁的源代码，所以 yysun 和 soul 你们讲的是啥
意思，我看不懂……痛苦！
　　谁借我个指北针用用？谢谢！

又有一个免费邮箱不免费了，我也是受害者，
往我这个邮箱发。wanghao@bjfao.gov.cn