村里有位兄弟发过的PHP6的安装配置方法.
http://www.phpx.com/happy/archiver/tid-130496.html

带有Unicode的PHP6即将发布
http://blog.chinaunix.net/u/1608/showart.php?id=164479

还有，这是谁的站，竟然来村里采集村长封他IP。
http://www.php998.cn/475/

PHP6:支持Unicode是大改进
http://moyu.cnlog.org/2007/01/php6unicode.html

Prepare for PHP 6 为php6 （上）做准备，附个人理解
http://nickfan81.spaces.live.com ... d3407eb4c!375.entry


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

最近发现很多人装php6时装不上，那我就干脆给大家简单说明一下安装方法吧（本文需要具有一定的PHP安装基础）！
首先需要安装包，可以到以下地址下载：
apache2.2: http://down.chinaz.com/L/100_Lastuptime_Desc_1.asp
php6: http://snaps.php.net


第一步：将apache安装到c:/apache下，装完后可在浏览器中输入 http://localhost查看是否成功运行了！如果运行错误，80%以上的可能是由于端口问题，请修改c:/apache/conf/httpd.conf中的Listen和ServerName这2个配置为其他未占用的端口！

第二步：将php6解包到c:/php下，然后将c:/php/php.ini-recommended 复制成 c:/php/php.ini ，或者直接改名也可！然后请正确配置php.ini，尤其要注意extension_dir参数，将其改为 "c:/php/ext/"。

第三步：配置c:/apache/conf/httpd.conf。在文件最后加上以下内容：

LoadFile "c:/php/libmysql.dll"
LoadModule php5_module "c:/php/php6apache2_2.dll"
AddType application/x-httpd-php .php
PHPIniDir "C:/php"

其中要注意的是LoadModule参数中应该是 php5_module 而不是 php6_module。
LoadFile "c:/php/libmysql.dll" 的目的是为了让PHP支持php_mysql.dll扩展

最后保存，重起APACHE就可以运行PHP了！

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

Cal Evan：这是另一条我的关于2006年开放源码大会的系列采访的报道。这次，我得到特许坐到了Andrei Zmievski 的旁边并和他谈论Unicode、Yahoo和其它PHP话题。Andrei出生在乌兹别克斯坦，在16岁的时候去美国学习。他现工作于Yahoo的底层架构的团队，并且在攻读语言学硕士学位。
在我大声呼喊出他的名字后，他耐心地坐下来，采访开始了。下面就是采访的过程。

Andrei，让我们来谈论一下有关PHP6中的Unicode，因为你在其中起到至关重要的作用。首先你能告诉我们为什么Unicode对PHP是重要的？

好的，事实上，Unicode应该在5年前就存在于PHP中了。不过非常糟糕的是人们没有在PHP中加入它。早就应该做一些事情为那些不是美国和英国本土出生的软件开发者提供国际数据接口，让他们的工作更简单。所以，从那时起就建立了许多临时的解决方案，例如mbstring，现在我们可以丢弃它了。

我们给PHP引入Unicode支持的真实想法是因为每一个高层次的，以web为导向的语言都应该具备这个功能。原因非常的清晰，处理国际化的文档、多语言的文档需要合适的工具。他们在语言层面必须能可靠的应用。这背后的推动力大多是因为Yahoo在国际上的多角色，我们也曾经经历过其他程序员经历过的问题：在需要创建支持国际化workarounds和完全不同的库的应用软件，如果Unicode存在于PHP会让事情就会简单得多。
对于我来说，它的开端是我在最初写出提议，建议Yahoo让我去做这方面的事情。

谢谢你对背景的介绍。现在，让我们来谈谈项目本身。我想，现在每个人脑子里的第一个问题应该是，这个项目进行得怎么样？

进行得很好。不过，这一年的早些时候进展得有点缓慢，因为我在Yahoo还有其他的事；所以，这样依靠Zend，想尽办法，在最后的两个月，将项目赶上了。我们现在正稳步前进。我的目标是在2006年第四个季度的时候能预先发布一些PHP的Unicode。希望这个发布会在第四季度的中期进行。能早一些更好。那就是说这有一些需要支持Unicode API接口扩展的栏目表。在第一列扩展中可能有12或者15个。那样，在我们预先发布PHP6的时候结合支持Unicode在语言中的代码就会足够多。人们可以使用，并且让我们有时间回顾。它不是beta版,更不是alpha版；它只是Unicode的预先发布。

太好了，我知道大家会盼望Unicode的预先发布，去测试。当你在PHP中实现Unicode的时候，最大的障碍是什么？

实际上，实现国际化的问题点并不在于技术而在于思维的转化。你必须训练你自己和其他人，它真正意味着什么。你不得不丢弃诸如这样的偏见：“我们一贯以这种方式去做，那为什么不可以以同样的方式处理。”这回答起来是很容易的，但实际套用以前的方法会第一时间遇到困难。在怎样使PHP国际化这个开端问题上已经遇到了一些阻力。但是大家现在正在接受那种思维并接近我们的目标。
真的，转变思维是很难的，但它正在发生。因为大家都明白我们是住在一个国际化的世界里而并不只是单个的国家。

你能告诉我们关于细节方面的事情，它什么时候转化？要用多长时间？首先做的是什么？

就如同PHP的核心Zend Engine引起人们关注的时间一样，我说情况会有90%或95%的相似，现在面临的挑战是使第一列扩展修改完成。已经有了一些好的发展开端，XMLReader已经完成而且大家正在为其他扩展工作。我们也会仔细搜查PHP的标准函数并且浓缩他们。我自己已经开始做那部分了，希望有人加入我。
另外一件事就是关于documentation。某些函数会被微小地改变作用因为它们现在支持Unicode了。那就需要在PHP手册中备注和说明。还需要一个对Unicode的介绍：它对PHP的意义，和它在PHP6中能做些什么。这些都还没有做，但是我想是应该花一些时间去做使它呈现在documentation前部的。

如果可以的话让我们来谈论下你在Yahoo的工作吧。你能告诉我们你在那工作的一些项目吗？

在Yahoo,除了在PHP方面的工作以外，我同其他Yahoo的开发者为Apache1.3和2.0版本创建客户端补丁。我们使它适合Yahoo的需要。

我知道Yahoo仍主要运行PHP4，你有PHP5的首次使用的时间表吗？

很多Yahoo 的properties都在移往PHP5。在这里我没有确切的数据在受伤，但是我们正在向PHP5转移。

好的，现在让我们把关注点调向未来：关于PHP6，你能在PHP的未来看到什么？

你要知道，如果我早知道，我就去股票市场上打赌而不是做现在的事情了。PHP在适合才出现的技术方面非常擅长。它也非常地擅长于使新技术与Web相结合。所以，我认为不管未来几年会出现什么样的新技术，PHP都会快速地去适应。
对于Unicode来说，它实际上是一项老技术了。不像AJAX，Unicode已经存在了大概10到15年了。所以这有点不同的是，我们正在去适合一项老技术，而不是一向新的。在其他技术方面，我想PHP至今为止都做得很好。就PHP7来说，你不能说它以后会变成的样子完全和使用者希望的不一样。使用者通过请求和讨论同样对开发有很大的作用。

Along those same lines，is there any one piece that you think PHP is missing?

个人认为，从对一个语言的看法来说，我想PHP需要支持像first class objects这样的函数。Closures也会很好。那只是我个人的观点，从一个web技术来看，我并不认为它缺少什么。

明显地，靠雇佣你，还有Rasmus, Sara Goleman, Jeremy Johnstone，以及其它PHP组织的高级会员，使Yahoo能够自己持续地使用PHP，为什么他们选择PHP作为他们的粘合语言？

我不知道你是否看过Michael Radwin’s presentation的那个话题。如果你没看，能在线看到。基本上，Yahoo拥有许多互联网技术去开发front-end页面和站点。对于任何一项技术，个个都需要投入维持费用，培训，开发工具，测试等等。要把关注点要集中在哪一部分容易出问题，因为我们必须要去维护。我们开始寻找的时候，我们想要那种可以共享的语言，以使我们能够轻松地雇佣那些已经经过培训的开发者。我们同样需要那种有积极地维护的并且有美好前景的语言，这样Yahoo就 不必担心承受独自开发的负担。最后，我要了一些已经有的证实记录，以便我们能够审查什么地方出错了，做了一些测试后就决定用PHP。

那么，让我们现在向后看一点，你是怎样进入PHP组织的呢？

当我为一个小的web公司开发在线发布系统的时候，我开始用PHP。我们使用了卖主所有的语言和数据库。我们转移向PHP基于和Yahoo同样的原因，我们想要一种语言能有积极地维护和更丰富的功能。
当Covalent分布Apache作为PHP 2/FI。我们关注到它，虽然它看起来非常好但是我们并没有立即采取行动直到6个月以后PHP3的出现。那是一个很大的改进，所以我们开始学习它。在我们开始移植并应用到PHP的时候，我开始注意一些PHP本身缺少的东西。我注视着API并且想了一下，好的，我实际上可以把那些缺少的块写出来。我是这样开始的：最开始在心中筹划，之后我浏览邮件列表看见人们提交的补丁需求，所以我决定以提供帮助开始这件事情。我最初写了WDDX extension，接着就继续贡献，越来越多。

为了更有精神一些，让我们从笼统的概念去看科技。什么样的新科技的出现或是将要出现真正地使你高兴？

就我个人的爱好，那当然我与我学的和我喜欢的有关的，计算机语言学和自然语言学的处理。这将应用于许多问题搜索引擎到问题分析，信息恢复，信息推论，这一类的问题。我想它将会在接下来的两、三年内，比目前为止应用得更多。

最后，你每天都会浏览的website或blog是什么呢？

Planet-php.org是一个非常好的集合PHP的blog。但是，我真正的兴趣是摄影，有一个叫做The Daily Dose of 的站点每天都有摄影爱好者上传图片，我非常喜欢。


（这篇文章写给那些慷慨给我他生命中30分钟的人，非常感谢Andrei花时间和我谈话。对PHP6的预先发布，迫不及待。）




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


PHP6:支持Unicode是大改进
PHP6支持Unicode，这有利于国际化，这样软件开发者就很方便地提供国际数据接口，从而可以丢去mbstring。在PHP.ini中可以设定是否开启支持Unicode。PHP6 中提供了Unicode方式保存字符串的能


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


Prepare for PHP 6 为php6 （上）做准备，附个人理解

As you may be aware the core PHP group of developers all met in Paris on November the 11th and 12th 2005. The minutes from the meeting are fascinating reading, but there is a lot to go through. So I've gone through all of the points raised and chewed them over from a developers point of view. Your comments as always are welcome. Before I get started however I'd just like to make one thing very clear: what you read here (or in the original minutes) are in no way the 'fully 100% decided' end results / changes that we'll see in PHP6. They will most likely all be discussed further (on internals and wider), but even so we can take the information presented in the minutes as being the PHP teams most 'current' way of thinking about any given subject.
Unicode

Unicode support at present can be set on a per request basis. This equates to PHP having to store both Unicode and non-Unicode variants of class, method and function names in the symbol tables. In short - it uses up more resources. Their decision is to make the Unicode setting server wide, not request wide. Turning Unicode off where not required can help performance and they quote some string functions as being up to 300% slower and whole applications 25% slower as a result. The decision to move it to the php.ini in my mind does take the control away from the user, and puts it into the hands of the Web Host.
If you compile PHP yourself or are responsible for this on your servers then you may be interested to know that PHP 6 will require the ICU libs (regardless if Unicode is turned on or off). The build system will bail out if the required ICU libs cannot be found. In a nutshell, you'll have another thing to install if you want to compile PHP.

个人理解：基本上这个意思就是说php6以后会全面支持unicode的编码，也就是说用多国语言的变量名这种代码一样可以被执行。但是这个是一个可选项如果打开支持系统效率会低很多，关闭这个支持会快一些。
个人评价：感觉对中文用户来说，估计只有老师喜欢这项功能，谁没事开关输入法去定义变量呢？万一输入个中文空格，然后找不到错，估计会导致失眠时间延长。。。


Register Globals to go

Say goodbye folks, this one is finally going. It will no longer be an ini file setting, and if found it will raise an E_CORE_ERROR, pointing you to the documentation on why it's "bad". This means that PHP6 will finally break all PHP3 era scripts (or any script using reg globals) with no recourse at all but to re-code it. That's a bold move, but a needed one.

个人理解：Register Global 将永久为Off，并且在php.ini中不再会有设置选项，如果你的代码中试图去设置它为On，将会产生一个 E_CORE_ERROR 错误。php6的这条变化将会对那些还停留在php3时代的coder的代码产生无可救药的后果，唯一的解决办法就是re-code it --重新编码。这是很重大的动作，也是必须作的事！
个人评价：本人不是php3时代介入的，但我知道写兼容代码所付出的效率代价是很大的。。。觉得这个是必要的一步，这也是让新加入php行列的人以新的方式理解php的新起点，当然知道历史也是很必要的，最重要的是知道why?--明白web安全的要求对语言产生的影响，也能让人写出更健壮的代码。

Magic Quotes to go

The magic quotes feature of PHP will be going, and as with register globals it's going to raise an E_CORE_ERROR if the setting is found anywhere. This will affect magic_quotes, magic_quotes_sybase and magic_quotes_gpc.

个人理解：Magic Quotes将会不再使用，如果在代码中出现调用将会产生一个E_CORE_ERROR错误。这将会影响到的函数有 magic_quotes, magic_quotes_sybase 和 magic_quotes_gpc

个人评价：写兼容环境设置代码的朋友们估计要不爽了，当然除非你完全不在乎error信息。以后php6的代码一切quotes都靠自己add了，呵呵，zend终于把这个费力非效率但只讨好一小部分懒人的东西去掉了，从此自己的代码中终于可以又少了几行了。




Safe Mode to go

This may please developers who have web hosts that insist upon safe mode! But it will now go totally, again raising an E_CORE_ERROR if found. The reason is that apparently they felt it gave the 'wrong signal', implying that it made PHP secure, when infact it didn't at all. open_basedir will (thankfully) be kept.

个人理解：Safe Mode 将会被去掉，但open_basedir将会被保留。如果在代码中出现相关设置，将会产生一条 E_CORE_ERROR 错误。

个人评价：whooo!!!，终于，终于~~~~，这个变化我想是讨好开发者的吧，毕竟开发者多了才会有host提供商去装相应的CGI。而host把这个safe mode 设置为on就以为安全了，其实这是一个错误的想法，也就是说这个设置给了他们一个错误的信号（原文'wrong signal'），open_basedir的设置保留我想这也是无可厚非的，除非你本身就没打算去注意安全问题。

'var' to alias 'public'

PHP4 used 'var' within classes. PHP5 (in its OO move) caused this to raise a warning under E_STRICT. This warning will be removed in PHP6 and instead 'var' will mean the same thing as 'public'. This is a nice move but I if anyone has updated their scripts to work under E_STRICT in PHP5 it will be a redundant one for them.
个人理解：类中的var方式申明的属性将会默认为public的权限，而不再会在E_STRICT级别的错误下产生一个warning。
个人评价：自己写代码的时候虽然很喜欢用 E_ALL | E_STRICT的设置来保证自己的代码尽量理想，但是当你不得不去使用ADOdb/Smarty之类的外部库的时候，不知道你看到满眼的var: Deprecated做何感想？


Return by Reference will error

Both '$foo =& new StdClass()' and 'function &foo' will now raise an E_STRICT error.
个人理解：传递引用将会产生一个E_STRICT级别的错误。
个人评价： Life is simple, so keep it simple.

zend.ze1 compatbility mode to go

ze1 always tried to retain old PHP4 behaviour, but apparently it "doesn't work 100%" anyway, so it will be removed totally and throw an E_CORE_ERROR if detected.
个人理解：zend1引擎的兼容模式将会被去掉，zend1引擎总是尝试着去兼容老的PHP4代码，但显然无法做到100%兼容。所以会完全去处，如果检测到使用则会触发一个E_CORE_ERROR错误。
评价：自己在4上停留的时间不算太长，所以不是很在乎。

Freetype 1 and GD 1 support to go

Support for both of these (very very old) libs will be removed.
个人理解：古董级的Freetype1和GD1的库的支持将会被去除。

dl() moves to SAPI only

Each SAPI will register the use of this function as required, only the CLI and embed SAPIs will do this from now on. It will not be available elsewhere.
个人理解：dl()将会只对CLI和嵌入的SAPI模式有用。

FastCGI always on

The FastCGI code will be cleaned up and always enabled for the CGI SAPI, it will not be able to be disabled.
个人理解：FastCGI模式将会在CGI SAPI模式中被设置为on并且无法关闭。

Register Long Arrays to go

Remember the HTTP_*_VARS globals from yesteryear? Well if you're not already using $_GET, $_POST, etc - start doing so now, because the option to enable long arrays is going (and will throw an E_CORE_ERROR).
个人理解：Register Long Arrays 将会被去除，大家不要再用HTTP_*_VARS这样的全局变量去访问相应的数据了，从现在开始做起。和上面一样如果出现了则会产生一个E_CORE_ERROR错误。



累了，剩下的有时间再翻。


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