army8735

看此图不爽，改之！

army — Fri, 03 Sep 2010 15:13:30 +0800

FileReference.load()真TM耗时

army — Thu, 02 Sep 2010 16:29:01 +0800

想尝试使用FileReference的load方法来加载本地文件，从而在客户端预先进行一些处理，发现这个方法不是一般的耗时。假如选择了一个50M的文件，load就需要8s左右！更别说后续的处理操作了！

2s内能加载完毕的话，只有10m以下的小文件，可这怎么能够行？

而且我还没看到unload方法，adobe，你该改进改进了。

可惜的是，designMode目前还无法在safari mobile版上使用

army — Tue, 17 Aug 2010 11:47:39 +0800

ipone、ipad等移动设备上，搭载的是苹果的safari mobile版本。浏览器中常用的富文本编辑器，是依靠designMode或者contentEditable运作的。

可惜的是，designMode目前还无法在safari mobile版上使用，所以在使用时得增加判断，为mobile版本的safari专门区分开富文本编辑。

/apple.*mobile.*safari/.test(userAgent)

Manufactoria：非常好玩的自动机编程游戏

army — Tue, 13 Jul 2010 14:59:29 +0800

http://www.matrix67.com/blog/archives/3306

Matrix67推荐的强大脑力游戏，这是最近我玩过的最好玩的脑力游戏，没有之一。简单地说，这是一个四进制图灵机的设计和布线问题，因此非常适合各种IT民工。前面的关都不难，直到倒数第四列，问题才复杂起来。而最后那些问题基本上对脑力有极大考验。

我目前也卡在倒数第4行了。前面的倒是全部最优解，继续杀脑细胞中。

继续开发JAse

army — Fri, 18 Jun 2010 15:45:52 +0800

http://code.google.com/p/jase/

一段日子没怎么动了，惭愧惭愧。废了一天功夫，终于把redo和undo两个操作，与高亮逻辑关联了起来。具体做法就是将语法解析部分合并到命令链当中，与编辑器脱离了。这样每次编辑器内容发生改变的时候，直接执行命令链来保存改变，无需关心高亮逻辑，这些逻辑全部放在命令链中一同处理了。

当中遇到不少问题，还有以前的一些经验，比如：

侦听textfield的textInput事件时，倘若是手动修改textfield的text，是不会触发的，这点需要相当注意。
ie输入回车时是\r\n，而其它为\n，但是到了textfield里面又会自动将\n替换成\r，这个地方非常迷惑人！在做命令链时保存的内容尤为恼人，必须对所有的内容检测一遍，删掉\r\n，将\r替换成\n。
resize事件放到flash内部了，以前是通过js侦听window的resize，这样需要经过ExternalInterface的中转，效率太低，还需要外部嵌个div之类的。现在直接侦听stage的resize，好很多。
找人重做了图标，怕openoffice说我侵权。
正在加新语种。

这里可以试用svn的每次更新版本：

http://jase.googlecode.com/svn/trunk/jase1/bin/index.html

比substr更高级的subhtml

army — Sun, 13 Jun 2010 16:16:55 +0800

subhtml，顾名思义，即截取字符串时忽略html代码，介于后台输出的某些字符串可能包含html代码，因此就不能用简单的substr来处理。不过由于后台输出的代码都是标准的，因此也少了许多校验的必要。但是，譬如自闭合标签、嵌套标签等等，需要考虑的还是很多。

目前两个版本拼杀中，结果稍后公布……

function subhtml_yy(html, n){
	var str = html.split(/<.+?>/g), dstr;
	var m = 0;
	for (var i = 0, l = str.length; i < l; i++) {
		dstr = str[i].replace(/([^\x00-\xff])/g, '$1 ');
		m += dstr.length;
		if (m > n) {
			str[i] = dstr.substr(0, m - n).replace(/([^\x00-\xff])\s/g, '$1');
			break;
		}
	}
	str.length = i + 1;
	var regexpstr = str.join('(<.+?>)')
	var parts = html.match(new RegExp(regexpstr));
	var unclose = [];
	for (var i = 1, l = parts.length; i < l; i++) {
		if (parts[i].match(/\/>$/))
			continue;
		else if (parts[i].match(/^<\//))
			unclose.pop();
		else
			unclose.push(parts[i]);
	}
	return (parts[0] + unclose.reverse().map(function(tag){
		return '</' + tag.match(/\w+/)[0] + '>';
	}).join(''));
}

function subhtml_army(str, limit) {
	var state = false, tag = [], c = '', i = j = index = index2 = 0;
	str = str.replace(/([^\x00-\xff])/g, '$1 ');
	for(var len = str.length; i < len && j < limit; i++) {
		c = str.charAt(i);
		if(c == '<') {
			if(str.charAt(i + 1) == '/') {
				i += tag.pop().length + 1;
			}
			else {
				index = str.indexOf('>', i + 2);
				if(str.charAt(index - 1) != '/') {
					index2 = str.indexOf(' ', i + 2);
					if(index2 < index && index2 != -1) {
						tag.push(str.slice(i + 1, index2));
					}
					else {
						tag.push(str.slice(i + 1, index));
					}
				}
				i = index;
			}
		}
		else {
			j++;
		}
   }
   str = str.substr(0, i).replace(/([^\x00-\xff])\s/g, '$1');
   if(tag.length) {
		str += '</' + tag.reverse().join('></') + '>';
   }
   return str;
}

测试对象

关键词的 的关键词的关键词的关键词关键词关键词

算法1（正则）

结果（14）: 关键词的 的关键

耗时（1000次）: 19

算法2（逐字遍历）

结果（14）: 关键词的 的关键

耗时（1000次）: 13

测试对象2

关键词的关键词的关键词的关键词的关键词的关键词

算法1（正则）

结果（14）: 关键词的关键词

耗时（1000次）: 17

算法2（逐字遍历）

结果（14）: 关键词的关键词

耗时（1000次）: 9

测试对象3

关键词关键词关键词关键词关键词关键词关键词关键词关键词关键词关键词关键词关键词

算法1（正则）

结果（14）: 关键词关键词关

耗时（1000次）: 13

算法2（逐字遍历）

结果（14）: 关键词关键词关

耗时（1000次）: 11

maxthon2.5.13和ie7内核出现冲突bug

army — Fri, 04 Jun 2010 11:47:21 +0800

今早测试人员发现，新更新的maxthon2.5.13浏览土豆时全乱了，图片不加载js不执行，着实让人吓了一跳。苦心检查半天，才发现是遨游本身的问题……这种情况下看所有网站都会出错，奇怪的居然还是2.5.13正式版，看来遨游的测试这下错大了。

flash player在不同浏览器中的表现也不一样

army — Tue, 25 May 2010 15:28:30 +0800

前阵子adobe和乔布斯大战，我作为as的拥护者，自然会导向adobe一方，不过今天发现乔布斯的一些抨击倒并不是空穴来风。

经常出现的那种js切换图片效果，如果变成js切换flash的话，自然也没什么大不了。切换图片时要么是几张图片轮播，要么是直接更改图片的href；切换flash时要么时call一个flash的侦听方法，要么是直接重写这一段html代码。

在第2种方法的情况下，明显能感觉出来几种浏览器的区别，无论是老的flash player也好、还是新的10.1也好，皆是。这里面google不愧和adobe合作，chrome来回切换丝毫没有问题；firefox很偶尔才会在切换时出现问题；而ie则太频繁了。猜测这也和chrome单进程的模型有关，这样切换时上一个遗留的flash不会造成内存泄漏。

土豆网的死循环

army — Mon, 17 May 2010 15:27:55 +0800

http://blog.notsobad.cn/?p=644

今天内部流传了下这篇，哀悼日的死循环。凑巧那几天土豆的几个前端去北京参加adobe的大会，不知道谁写的这个东西……

其实这个bug做过开发的人都知道，经常会犯的小失误，只是实际使用的时候一下就能发觉，所以在自己测试的环节就能找到。但也由于这个缘故，使得人们经常没在意它……

发现一个flash player 10.1 rc4的bug

army — Fri, 07 May 2010 16:31:18 +0800

adobe昨天公布的rc4，咱就迫不及待地用了，结果发现一个bug，这个在rc2中没有。

flash.net.NetStream，在使用seek(offset:Number)进行跳转后立刻togglePause()来暂停流（假设当前状态是播放），读取流的time属性并没有更新到offset。在rc2中确实更新正确了。