手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:PHP

漫游(manyou)简介

本文COPY自discuz论坛,也颇为感慨,不得不承认,discuz走在了很多软件开发的前列,它以论坛为中心,辅以了supesite,uchome等不同的应用,一直以来它都是以站长为中心,目前,也渐渐开始以开发者为中心了。

以站长为中心,是我个人的见解,毕竟从很久以前,为它开发插件就不得不考虑论坛升级会怎么样,原有的程序是否会动。而目前则可以根据接口来进行开发,只要接口没变,其他的就不用管了。

下面的内容是COPY过来的。可以看看介绍。原文:http://www.discuz.net/thread-989303-1-1.html

前言

Manyou是开发者发挥才华、创造梦想的开放平台。从2008年7月7日公告推出测试至今,Manyou收悉了从开发者、站长的大量建议和咨询问题,从Manyou当前的定位、功能、应用方法和案例等问题,到Manyou未来如何实现商业模式和盈利,均有涉及。

值得欣慰的是,这些问题也是Manyou的关心点和关注方向,大多数问题是Manyou现在就能回答的,但也有一些问题需要Manyou在未来的探索中实践了之后才能与外界分享的。

为了共同的进步,Manyou愿意从现在开始,与所有的关注者共同探讨,掀开彼此合作的序幕。



互联网正在向应用迈进


互联网在中国发展已超过了十个年头,正在从单纯的信息时代逐步走向全面的应用时代。而走向全面的应用时代之前,“人”必须代替“信息”在互联网上占有更主导的地位,于是以“人”为中心的社交网络(SNS)符合了这一潮流,在今天的互联网格局里,显示出了越来越大的生命力和成长性。相对应地,Facebook、Myspace以及国内的校内、51.com的迅猛突起绝对不是一个偶然。

但是,SNS单纯有“人”或“人际”也远远不够,实现真正SNS的持久黏性与成长,则需要丰富而个性的“应用”,以符合不同人差异化的需求。“人际”与“应用”,“SNS”与“Widget”,互为支撑,缺一不可。

拿Facebook来说,截至2008年7月15日,从Facebook的第三方应用分析网站adonomics.com(http://adonomics.com/)可以获得的数据是,当前Facebook已有32350个应用(app),并且有超过9亿人安装了这些应用中的一个或多个,而为投入这些应用的开发者则超过了20万人。

Facebook Facts
There are 904,333,228 installs across 32,350 apps on Facebook with over 200,000 developers currently evaluating the platform.
These applications were used 34,175,797 times in the last 24 hours and have a combined valuation of $442,611,700.

一个月前,在Google的开放日上,李开复说互联网的第一个时代是Web1.0时代,第二个时代是Web2.0时代,第三个时代则是开发者的时代。不管他的排序是不是最准确的预言,但相信他的本意是在告诉我们,今天的互联网正在向“开发者的平台”方向迈进。如果要为这正在(或即将)到来的一幕作为一个历史对比的话,可以想象一下Windows刚出现时诞生“中文之星”、“KV100”、“超级解霸”、“OICQ”等操作系统软件(OS software)的场景。互联网应用(Web apps)将逐渐浮出水面,也许它也有机会创造另一个王志东、王江民、梁肇新或马化腾。

李开复说:互联网经历了三个时代的变迁。
第一个时代是Web1.0的时代,大家通过媒体的报道和文章的撰写来了解资讯和新闻。
第二个时代是web2.0的时代,我们看到的分享的互联网的时代,也就是说个人可以经过博客,经过BBS等其他的方式都可以发表他们的意见,引起了很大的轰动,也造成了很多人与人之间、网友与网友之间的互动。
那么互联网的第三个时代,应该是开发者的时代。开发者的崛起,让网络从一个文字的,社区性的一个平台,变成一个可以提供无限应用的,能够汇集众多开发者的智慧,提供技术应用的互联网时代。

从开发者与站长的角度出发,UCenter Home和Manyou的定位选择



Manyou与UCenter Home,一个希望服务于应用,一个希望服务于SNS。或者说,一个服务于开发者,一个服务于站长。这就是Comsenz对Manyou以及UCenter home的定位。我们将以最大的开放来面对这一定位。“开放是一种心态,共赢的心态。”这是大C的原话,也是Comsenz立场和态度。如果说Comsenz做这些事情没有梦想,不是为了发展和成长,那是谎话;如果说Comsenz仅仅为了自己的发展,违背了我们服务了七年的站长、陪伴Comsenz多年的开发者(如插件作者、第三方开发者)的成长和利益,那更是蠢话。

Manyou开放平台(Manyou Open Platform,即MYOP)希望是嫁接在开发者、站长之间引导公平游戏规则的贡献者和建立者。“在某种程度上,是为站长和应用开发者这两个供需双方,建立一种公平的市场经济体制。”

目前,UCenter home已经有超过15000家网站在安装使用,这些网站中的大多数都在期待包含MYOP功能的UCenter Home 1.5版本平台,以实现在运营时,有大量的应用可供选择服务于他们的网民。拿地方网站暨阳社区来说,有很多本地上班族经常泡,肯定正需要象“记录心情”、“互赠礼物”、“休闲棋牌”、“个人理财”等方面的应用;拿旅游社区驴友录来 说,一定还需要“在外地手机也能写博客”、“匹配结伴出行”等更个性化的应用。千千万万的网站,还需要更多千千万万种类的特色应用,显然,这是 Comsenz的能力所不能承受的。尽管Comsenz过去也在Discuz!的基础上发展了多个产品,服务了更广泛的应用,但总体而言种类还是个位数的 (而且还蛮累的啦)。

所以,我们希望一切有开发能力的开发者、一切有志于共创未来的开发者,能够携手与Manyou,共同服务于广大的站长和网民。

Manyou的工作原理很简单,她一边嫁接与支持MYOP协议的无数个网站,一边串联开发者提供的无数个应用,从而实现开发者的应用能够通过传递到各个网站上,以供网民自由选择采用。并且,Manyou仅是一个虚拟的机制,是一个交换数据的协议,而并非是一个实体。她面向开发者唯一比较直接的一个功能就是,审核应用的安全性和稳定性,以确保网站使用者的基本利益。

用下面这张图片,也许就能比较清晰地交代这种关系,如下图:






从零出发的两个准备



如果您清楚了Manyou的定位,并认可了Comsenz的立场和态度,那么,下一步的开发行动就是非常简易而方便的事情了。

在做开发之前,先需要了解MYOP的基本协议和开发过程中遵守的原则,您可以先登录Manyou开发者指南网站 http://wiki.developer.manyou.com/。在这个网站上,主要内容包括:
1、MYOP简介
2、MYOP应用服务协议
3、快速上手的指南文档
4、两个示范案例及相应的原理
      *  创建“Hello world”程序  
      *  Manyou应用开发进阶(“茶花女”的案例)
5、Manyou开发的接口文档Manyou Markup Language(MYML)Manyou Query Language(MYQL)MYJS标准JavaScript的扩展等技术资料。
6、关于Manyou的一些问题Q/A列表。(更多问题,亦可参考大C的答问帖查看:http://www.discuz.net/viewthread.php?tid=982973&highlight=

做完了Manyou知识的准备,您就可以到Manyou的开发者测试环境网站http://uchome.developer.manyou.com/)上开始行动了。

1、第一步,如果您已经是Discuz.net的会员,直接登录会员帐号即可登录Manyou开发者测试环境网站(http://uchome.developer.manyou.com/),否则的话,您还需要再注册一个会员登录帐号。
2、第二步,点击“开始”菜单的“开发者”,了解“开发者首页”的每一项信息;
   BTW:这也是一个UCenter home 1.5版本的网站,如果您的应用在该网站上测试通过,基本可表明你的应用符合了体验,符合了可以应用的基本条件。
3、第三步,在“开发者首页”的右上角,有一个“创建新应用”的按钮,点击之并按照向导一步步动作,就能提交您的应用进行测试了。
4、等待审核通过,成为正式的面向所有会员的应用;
   BTW:已通过审核的所有应用列表,可以在点击“开始”菜单内的“我的应用”,并再点击“查看所有应用”获得。
5、在UCenter home1.5版本及Manyou正式版本发布之后,通过审核的所有应用,将能在所有同意MYOP协议的UCenter home网站上运行。








蕴藏的机会第一个留给插件开发者



这是一个机会。但对于Comsenz来说,这也是一个全新的挑战。Comsenz的历史经验是,每个产品都是按照自己的周期和节奏来发布,比如Discuz!,每一个版本的升级往往是,2个月或3个月一个小版本,10个月或12个月一个大版本,非常有规律。但是,它的弊端在于,首先我们不能紧随潮流,随时升级发布,随时响应站长和网民的需求;其次,众口难调,我们每一个版本开发的新功能不能适应每一个站长的需求,有的站长需要,有的不需要,最多能满足多数站长都需要的功能。

在此之前,大量的有创新意识的插件开发者、模板作者扮演了至关重要的角色,他们通过有创意的插件和模板调补了市场上这一空白,为追求个性的站长找到了解决方案,在一定程度上缓解了这一矛盾。

但根本的矛盾依然没有解决。对我们的大量站长来说,我们至少要面临一个痛苦的抉择,必须在每一次升级平台软件(如Discuz!)之时,先卸载了所有的插 件应用,然后才能再升级,再安装与升级的新版本匹配的插件,每次这种工作都很痛苦,“象脱了一层皮”。对插件开发者而言,所有的应用发布无法展开持续有效 地升级,由于插件必须伴随平台软件才能升级时,周期不由自己来掌控,非常被动,而更为郁闷的是,插件开发者无法从站长那里获得任何与应用有关的数据,跟踪 应用的进展,更无法从中获得用户的反馈。Comsenz深知,广大插件开发者在官方论坛上经常呼吁希望官方出台一个标准。

今天的Manyou,正是朝这样一个标准努力的。Manyou希望,真正能帮助广大插件开发者扩大自由和权利。开发者的自由 是:1)开发的过程更自由;2)升级的过程更自由;3)获得网站和用户使用的途径更自由、更方便。为开发者争取的权利则是:1)与站长的接触和沟通更便 利、更对等;2)获得应用反馈信息、数据的能力更多;3)获得收益的可能性更大。

所以,我们期望把蕴藏的机会第一个先留给一直支持Comsenz的插件开发者,从而实现广大插件开发者成为应用开发者,与站长实现共同升级与成长。当然,我们也愿意更多的人加入进来!Comsenz期待任何有志于此的第三方合作者,无论是公司还是个人。

请加入Manyou,一起行动吧!


PS:补充需要说的是,商业模式和收益方式现在是任何从事互联网的公司或个人经常都会提及的问题。同样,我们也认可互 联网上的另外一个“硬道理”:有人用就有价值。我们相信,商业模式和收入方式是水到渠成的东西,第三方应用一旦有了足够的用户才使用,它的价值将随之应运 而生,这种收益途径包括但不限于:广告、会员费、交易收入等方式。机会不会给等的人,只会给有准备的人。希望我们在今天,就能为明天准备充分,有更好的平台、更好的应用给更多的用户。

附录
1、开发者在开发过程中如有任何技术难题请联系,胡东海,hudonghai#comsenz.com,010-51282255-243
2、如有相关市场合作可联系,张翔,zhangxiang#comsenz.com,010-51282255-829,13811110355

Tags: discuz, comsenz, uchome, manyou, ucenter

优化递归的效率

原文来自博客园,把代码全部翻译成了PHP的,因为这些东西对PHP同样适用。

函数递归调用是很常见的做法,但是它往往是低效的,本文探讨优化递归效率的思路。
1.尾递归转换成迭代
尾递归是一种简单的递归,它可以用迭代来代替 比如 求阶乘函数的递归表达

PHP代码
  1. <?php  
  2. function  f( $n = 0)  
  3. {  
  4.     if($n<=0)return 1;  
  5.     return $n*f($n-1);  
  6. }  
  7. ?>  

可以转换成完全等价的循环迭代

PHP代码
  1. <?php  
  2. function f($n = 0)  
  3. {  
  4.     $r=0;  
  5.     while$n-- > 0)  
  6.         $r *= $n;  
  7.     return $r;  
  8. }  
  9. ?>  

尾递归是最简单的情形,好的编译器甚至可以自动的识别尾递归并把它转换成循环迭代。


更多看详细

» 阅读全文

Tags: php, 递归, 效率, 优化

关于PHP版本升级的一些相关问题

PHP版本一直在更新,同样我们的代码也会随着服务器上的PHP版本的更新而不得不进行更改,但每次PHP的更新,几乎只是显示fix了多少多少BUG,但究竟会在版本升级的时候带来哪些问题,自己一点也不清楚 。

其实翻开PHP的手册,你也能找到这些,现在方便了,到我的博客上下载乔楚编译的最新的手册,翻开左侧树的最后一个节点:Appendices,找到:

大小: 11.61 K
尺寸: 305 x 89
浏览: 2204 次
点击打开新窗口浏览全图

展开这三个节点,你会看到在版本更新的时候,PHP的核心加了哪些方法,去除了哪些函数(事实上这很重要,或许在你以前的项目里一直在采用XXX方法,但新版本去掉了,很可能你的程序就不能再运行了。。。)

当然你更应该看的是:Changes in reference handling,这里面介绍的是一些老的代码写法和应用在新的代码里会出错的例子,如果你的代码里沿用了这些旧的方法,那么,你先考虑一下升级的代价吧。

Tags: 升级, bug, 解决方案

最新PHP手册,英文版,含回复,感谢乔楚

感谢乔楚(honestQiao)对最新的PHP手册进行了编译,并为我们免费提供。
在这里我就不称呼乔楚为乔XX了,乔楚,资深UNIX工程师,PHP高级开发人员,国内最初的smartTemplate里也有他的功劳(好象是这个吧,没记错应该),如今,他又为我们提供了这样一个手册,方便PHP开发人员。

大家一起为我们的乔楚鼓掌。谢谢

下载地址为:php_manual_en.docs.chm

Tags: 手册, 英文版, 最新, 乔楚, 编译

谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词[转摘]

同样,翻出以前的文章,当然,也是转贴的,不过对于PHP开发人员来说,BOM这个问题应该算是很严重的,经常性会遇到header already sent,但就是找不到有输出。什么原因呢?BOM应该占了很大的比例。所以还是翻出老文章,再加强一下记忆。


来源:http://www.goalercn.com/html/tech/program/c/157.html    作者:未知  
 
 
    这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念,增进知识,类似于打RPG游戏的升级。整理这篇文章的动机是两个问题:

问题一:
使用Windows记事本的“另存为”,可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件,Windows是怎样识别编码方式的呢?

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节,分别是FF、FE(Unicode),FE、FF(Unicode big endian),EF、BB、BF(UTF-8)。但这些标记是基于什么标准呢?

问题二:
最近在网上看到一个ConvertUTF.c,实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式,我原来就了解。但这个程序让我有些糊涂,想不起来UTF-16和UCS2有什么关系。
查了查相关资料,总算将这些问题弄清楚了,顺带也了解了一些Unicode的细节。写成一篇文章,送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂,但要求读者知道什么是字节,什么是十六进制。

0、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前面?如果将6C写在前面,就是big endian。还是将49写在前面,就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,其中一个皇帝送了命,另一个丢了王位。

我们一般将endian翻译成“字节序”,将big endian和little endian称作“大尾”和“小尾”。

1、字符编码、内码,顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码,为了处理汉字,程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030,对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

有的中文Windows的缺省内码还是GBK,可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符,普通人是很难用到的,通常我们还是用GBK指代中文Windows内码。

这里还有一些细节:

GB2312的原文还是区位码,从区位码到内码,需要在高字节和低字节上分别加上A0。

在DBCS中,GB内码的存储格式始终是big endian,即高位在前。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析:在读取DBCS字符流时,只要遇到高位为1的字节,就可以将下两个字节作为一个双字节编码,而不用管低字节的高位是什么。

2、Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容(更准确地说,是与ISO-8859-1兼容),与GB码不兼容。例如“汉”字的Unicode编码是6C49,而GB码是BABA。

Unicode也是一种字符编码方法,不过它是由国际组织设计,可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set",简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载:历史上存在两个试图独立设计Unicode的组织,即国际标准化组织(ISO)和一个软件制造商的协会(unicode.org)。ISO开发了ISO 10646项目,Unicode协会开发了Unicode项目。

在1991年前后,双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果,并为创立一个单一编码表而协同工作。从Unicode2.0开始,Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在,并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码,是由UTF(UCS Transformation Format)规范规定的,常见的UTF规范包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一贯风格,清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

3、UCS-2、UCS-4、BMP

UCS有两种格式:UCS-2和UCS-4。顾名思义,UCS-2就是用两个字节编码,UCS-4就是用4个字节(实际上只用了31位,最高位必须为0)编码。下面让我们做一些简单的数学游戏:

UCS-2有2^16=65536个码位,UCS-4有2^31=2147483648个码位。

UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows),每行包含256个cells。当然同一行的cells只是最后一个字节不同,其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中,高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节,就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下:

UCS-2编码(16进制)  UTF-8 字节流(二进制) 
0000 - 007F  0xxxxxxx 
0080 - 07FF  110xxxxx 10xxxxxx 
0800 - FFFF  1110xxxx 10xxxxxx 10xxxxxx 

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间,所以肯定要用3字节模板了:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 110001 001001, 用这个比特流依次代替模板中的x,得到:11100110 10110001 10001001,即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。

UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码,UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码,定义了一个算法。不过由于实际使用的UCS2,或者UCS4的BMP必然小于0x10000,所以就目前而言,可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案,UTF-16却要用于实际的传输,所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM
UTF-8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是“乙”?

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想法:

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF(读者可以用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料
本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我还找了两篇看上去不错的资料,不过因为我开始的疑问都找到了答案,所以就没有看:

  1."Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
  2."Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
 


顺便说一下:记事本保存成UTF8默认是带BOM的,好象没有办法去掉;editplus在选项里可以进行选择:始终带BOM,智能识别,不带BOM这些选项。所以,尽量是选择不带BOM比较好。

Tags: utf8, bom, ucs, php, 乱码