平台是windows server 2003（32位系统） + Apache/2.2.9 (Win32) + PHP/5.2.17，在使用正则表达式 preg_match_all （如 preg_match_all("/ni(.*?)wo/", $html, $matches);）进行分析匹配比较长的字符串 $html 时（大于10万字节，一般用于分析采集回来的网页源码），Apache服务器会崩溃自动重启。
在Apache错误日志里有这样的提示：
[Thu Apr 11 18:31:31 2013] [notice] Parent: child process exited with status 128 -- Restarting.
[Thu Apr 11 18:31:31 2013] [notice] Apache/2.2.9 (Win32) PHP/5.2.17 configured -- resuming normal operations
[Thu Apr 11 18:31:31 2013] [notice] Server built: Jun 13 2008 04:04:59
[Thu Apr 11 18:31:31 2013] [notice] Parent: Created child process 2964
[Thu Apr 11 18:31:31 2013] [notice] Disabled use of AcceptEx() WinSock2 API
[Thu Apr 11 18:31:31 2013] [notice] Child 2964: Child process is running
[Thu Apr 11 18:31:31 2013] [notice] Child 2964: Acquired the start mutex.
[Thu Apr 11 18:31:31 2013] [notice] Child 2964: Starting 350 worker threads.
[Thu Apr 11 18:31:31 2013] [notice] Child 2964: Listening on port 80.
经过查阅Apache官方以及论坛资料后，发现win平台下用正则 preg_match_all 或preg_match 分析比较长的字符串时，导致apache崩溃重启的原因是windows平台下默认分配的线程堆栈空间 ThreadStackSize 太小导致的。 win32默认只有256KB，而在 linux下默认值是 8M，这就是为什么同样的程序在 linux平台下正常，而在 win平台下不正常的原因。
根据PCRE library的官方说明：256 KB 的堆栈空间对应的pcre.recursion_limit大小应该不超过524。
Here is a table of safe values of pcre.recursion_limit for a variety of executable stack sizes:
下面就是一张Stacksize和pcre.recursion_limit对应的建议安全值，超过这个数值就极有可能发生堆栈溢出，apache crash:
Stacksize pcre.recursion_limit
64 MB 134217
32 MB 67108
16 MB 33554
8 MB 16777
4 MB 8388
2 MB 4194
1 MB 2097
512 KB 1048
256 KB 524
如果你没有调整堆栈大小，就必须在使用正则的PHP页面最开头加入：
<?php
ini_set("pcre.recursion_limit", "524"); // PHP default is 100,000.
?>
查看具体的错误可以使用下面的代码：
$resultsArray = preg_match_all("/table.*?<a>/isU", $html, $contents);
if ($resultsArray === 0){
echo get_pcre_err();
}
function get_pcre_err(){
$pcre_err = preg_last_error(); // PHP 5.2 and above.
if ($pcre_err === PREG_NO_ERROR) {
$msg = 'Successful non-match.';
} else {
// preg_match error!
switch ($pcre_err) {
case PREG_INTERNAL_ERROR:
$msg = 'PREG_INTERNAL_ERROR';
break;
case PREG_BACKTRACK_LIMIT_ERROR:
$msg = 'PREG_BACKTRACK_LIMIT_ERROR';
break;
case PREG_RECURSION_LIMIT_ERROR:
$msg = 'PREG_RECURSION_LIMIT_ERROR';
break;
case PREG_BAD_UTF8_ERROR:
$msg = 'PREG_BAD_UTF8_ERROR';
break;
case PREG_BAD_UTF8_OFFSET_ERROR:
$msg = 'PREG_BAD_UTF8_OFFSET_ERROR';
break;
default:
$msg = 'Unrecognized PREG error';
break;
}
}
return($msg);
}
对于正则的修饰符 isU 说明：
i: 表示in-casesensitive，即大小写不敏感
s: PCRE_DOTALL，表示点号可以匹配换行符。
U: 表示PCRE_UNGREEDY，表示非贪婪，相当于perl/python语言的.*?，在匹配过程中，对于.*正则，一有匹配立即执行，而不是等.*搜索了所有字符再一一返回
在使用正则表达式时，我们应该尽量避免递归调用，递归容易导致堆栈溢出。比如：
/<table((?!<table).)*?</a>/isU 就会发生错误，而使用 /<table.*?</a>/i 就正常。
那么如何增加win平台下 ThreadStackSize 的大小呢？ 在apache的配置文件 httpd.conf 里启用 “Include conf/extra/httpd-mpm.conf”（删除前面的注释#），然后在 httpd-mpm.conf 文件里的 mpm_winnt_module 配置模块里设置 “ThreadStackSize 8400000”即可（大约8M）。
<IfModule mpm_winnt_module>
ThreadStackSize 8400000
ThreadsPerChild 200
MaxRequestsPerChild 10000
Win32DisableAcceptEx
</IfModule>
这里需要注意的是，32位的Apache程序只能最多使用大约2GB内存空间！ 因此，ThreadStackSize 和ThreadsPerChild 的值相乘后（8M * 200）不应该超过2G，否则无法启动apache，出现的错误日志如下：
[Thu Apr 11 20:02:45 2013] [crit] (OS 8)存储空间不足，无法处理此命令。 : Child 4832: _beginthreadex failed. Unable to create all worker threads. Created 212 of the 220 threads requested with the ThreadsPerChild configuration directive.
通过上面的提示，飘易可以告诉大家的是在我的这台服务器上，当线程堆栈大小设为8M时，我可以设置的线程数最多是212个。
在使用ftp软件上传下载php源文件时，我们偶尔会发现在本地windows下notepad++编辑器写好的php文件，在使用ftp上传到linux服务器后，php文件的换行符全部丢失了，导致php文件无法正常运行。
这个时候，再次通过ftp软件把刚才上传的php文件下载到本地windows，用notepad++编辑器打开后，发现php源代码变成了一行，换行丢失。
发生这种情况的原因是什么呢？飘易就以一句话概括下：
由于linux下换行是n，而windows下换行是rn，当ftp软件在上传时，默认是以ASCII方式上传的，而ASCII方式上传文件有个特点，会将文件里的换行符进行适当处理以符合上传服务器的运行环境。在这个过程中，部分文件就会处理不当，出现换行符丢失的bug。（注意，不是全部php文件，是小部分的php文件会出现这个问题）。
上诉问题尤其在php源码里有单行注释符“//”时，会导致php源文件直接无法运行。因为源码变成了一行代码后，单行注释符把//后面所有的代码都注释掉了。
FTP上传bug解决方法:
方法1: 将单行注释符 // 改成 多行注释符 /* 注释文字 */ 这样即使换行符丢失，也不影响后面源码的执行。（但是下载到本地二次修改时，依然是件头疼的事！）
方法2: FTP上传php文件不要使用ASCII模式，全部使用二进制方式。这是最保险的。 如何设置ftp软件以二进制方式Binary上传，请网络搜索下自己使用的ftp软件的设置方式。
【知识补充：FTP的ASCII和Binary传输模式】 ：
FTP有ASCII和Binary两种传输模式：
Binary模式不会对数据进行任何处理。
Ascii模式会将回车换行转换为本机的回车字符。
由于WINDOWS和UNIX的行结束符不一样。所以从WINDOWS用Binary传输方式传输文本文件到UNIX时可能会出现^M。同样从UNIX用Binary方式传输文件到WINDOWS时，也可能出现回车换行显示不正确的问题。
WINDOWS下新建ftp_ascii.txt内容如下：
hello word!
WINDOWD TO UNIX !
TEST FTP ASCII;
我们分别用两种模式上传到UNIX.
ASCII模式正常
vi ftp_ascii.txt
hello word!
WINDOWD TO UNIX !
TEST FTP ASCII;
二进制模式 Binary有问题
vi ftp_ascii.txt
hello word!^M
WINDOWD TO UNIX !^M
TEST FTP Binary;
由此可知我们采用ASCII模式传输文本可以避免传输中的^M问题。 FTP中虽然ASCII模式可以避免^M的问题。但大多数情况还是选择Binary方式，这样可以保证传输的内容不会被改变。尤其是在传输可执行文件如php源码时, 大多选用binary方式。
在FlashFXP中可以在菜单->会话->传输模式中 选择ASCII ,BINARY ,自动三种模式。
另外，我们以ssh登录sftp的方式上传文件时，也可以避免换行丢失的问题。
502 bad gateway不一定全是nginx,apache之类引起的，也有可能是由其他模块引起的，例如：php
1,查看php-fpm和nginx的log
# vim /var/log/nginx/error.log
recv() failed (104: Connection reset by peer) while reading response header from upstream
# vim /var/log/php-fpm/error.log
WARNING: [pool www] child 29522 exited on signal 11 (SIGSEGV - core dumped) after 2165.472759 seconds from start
2,由php的eaccelerator导致502 bad gateway错误
我根据上面的二个错误，在网上找方法大部分都说是由nginx或者apache引起的，最近并没有动nginx的配置，不可能好好的就不行了，当看到有说php扩展apc，有可能会引起502 bad gateway时,因为eaccelerator根apc差不多，猜想会不会是eaccelerator引起502呢？
# mv /etc/php.d/eaccelerator.ini{,bak}
# /etc/init.d/php-fpm restart
重启后问题解决。开始的时候，我以为是cache目录和log目录的权限导致502的，就算改了所属用户，并且在加上777权限，也还是502错误
本文我们来分享用php的phpExcel类生成的excel当列名超过26列大于Z时的解决方法，供大家参考学习。我们生成excel都会使用phpExcel类,这里就来给大家介绍在生成excel列名超过26列大于Z时的解决办法,这是phpExcel类中的方法,今天查到了,记录一下备忘,代码如下:
| 代码如下 | 复制代码 |
| public static function stringFromColumnIndex($pColumnIndex = 0) { // Using a lookup cache adds a slight memory overhead, but boosts speed // caching using a static within the method is faster than a class static, // though it's additional memory overhead static $_indexCache = array(); if (!isset($_indexCache[$pColumnIndex])) { // Determine column string if ($pColumnIndex < 26) { $_indexCache[$pColumnIndex] = chr(65 + $pColumnIndex); } elseif ($pColumnIndex < 702) { $_indexCache[$pColumnIndex] = chr(64 + ($pColumnIndex / 26)) . chr(65 + $pColumnIndex % 26); } else { $_indexCache[$pColumnIndex] = chr(64 + (($pColumnIndex - 26) / 676)) . chr(65 + ((($pColumnIndex - 26) % 676) / 26)) . chr(65 + $pColumnIndex % 26); } } return $_indexCache[$pColumnIndex]; } | |
将列的数字序号转成字母使用,代码如下:
| 代码如下 | 复制代码 |
| PHPExcel_Cell::stringFromColumnIndex($i); // 从o开始 | |
将列的字母转成数字序号使用,代码如下:
| 代码如下 | 复制代码 |
| PHPExcel_Cell::columnIndexFromString('AA'); | |
希望本文所述对大家的php程序设计有所帮助。
JpGraph是一个非常不错的图形类库了，我们可以直接使用它生成各种柱状图,饼图,折线图并且还可以增加文字说明了，在增加英文数字时没有问题，但增加中文汉字说明时会发现乱码问题，对此小编整理了一些解决JpGraph中文乱码问题的方法供各位参考。JpGraph为什么会出现中文乱码
在JpGraph中默认是要把字符串转成utf8的，但是如果你的文件本身就是utf8的，并且要用中文字体，它还会转一遍，结果多转了一次，就会出现乱码。如图所示
JpGraph使用详解之中文乱码解决方法
取前篇的代码片断如下
| 代码如下 | 复制代码 |
|
//设置图表的标题字体、大小 //和上面标题对应，设置标题的字体和大小 把它改为 //设置图表的标题字体、大小 //和上面标题对应，设置标题的字体和大小 | |
使用php函数据中文由UTF-8转为GB2312，记住由于iconv本身的一个bug，iconv在转换字符"—"到gb2312时会出错，所以在需要转成的编码后加上 "//IGNORE" 。
FF_SIMSUN表示中文简体，对应的字体文件是simsun.ttc，虽然FF_CHINESE和FF_BIG5也表示中文但是它们对应的字体文件是不同的，所以不要弄错。
下面是正确转换后生成的图
下面是本例调试的完整代码
| 代码如下 | 复制代码 |
|
require_once ('jpgraph/jpgraph.php'); $data1y=array(0,8,9,3,5,6); // Create the graph. These two calls are always required $graph->SetShadow(); // Create the bar plots // Create the grouped bar plot // ...and add it to the graPH $graph->title->SetFont(FF_SIMSUN,FS_BOLD); $graph->Stroke(); | |
当然了，我这里只介绍了一种方法，还有一种就是修改源码，但不推荐。因为我觉得改动源码可能会给其它地方带来意想不到的麻烦。
使用JpGraph，要知道其版本、运行服务器以及操作系统的息息，不能张冠李戴，否则麻烦多多。
好了，至此JpGraph使用介绍也就这么多了。