php识别图像类型为image/pjpeg格式,pjpeg是什么?

调试一套php系统,突然发现数据库里记录的jpg格式的图片附件,类型字段显示为附件image/pjpeg,很惊异,之前从来没有见过,还以为 是程序哪里出错了,在源程序里查找image/pjpeg,结果没有这样的字符串,于是google一下,相关的资料不是非常多,就网上查到的信息整理如 下:

image/pjpeg究竟是什么,与image/jpeg有什么区别?

image/pjpeg对应.jfif文件,image/jpeg对应.jpg、.jpe、.jpeg文件。
JFIF文件格式(JPEG文件交换格式,   JPEG   File   Interchonge   Format,是 progressive JPEG 的缩写)。JFIF文件格式只是将一种图像格或环绕JPEG压缩的一种简单方法,它们没有其他的更多功能。
JPEG文件格式(Joint   Photographic   Experts   Group(联合图像专家组))是一种有损压缩格式,能够将图像压缩在很小的储存空间,图像中重复或不重要的资料会被丢失,因此容易造成图像数据的损伤。 尤其是使用过高的压缩比例,将使最终解压缩后恢复的图像质量明显降低,如果追求高品质图像,不宜采用过高压缩比例。

英文原文:What is progressive JPEG?

一个错误的说法:

有人说IE下上传jpg 会被服务器端程序识别为image/pjpeg格式,但firefox则显示为正常的jpg,

“原因是ie会把 jpg、jpeg翻译成image/pjpeg,png翻译成image/x-png 。而火狐则很标准:jpg、jpeg翻译成image/jpeg,png翻译成image/png”

其实这种说法不对 的,虽然IE很烂,但这里却不是它的错,这些图片严格的讲确实是image/pjpeg格式的,firefox没有这样识别而已。

PHP与image/pjpeg

PHP GD库对image/pjpeg格式的图片支持不是非常完美,或者说是要求太严格,有时会出现这样的错误

Warning: imagecreatefromjpeg(): ‘/tmp/lalala’ is not a valid JPEG file in /path/upload.php on line 1

出现这个Warning是由于GD函数库检测发现是非标准JPEG图片格式导致。

解决方法,如果PHP版本 > 5.1.3,可以在php.ini中增加:
gd.jpeg_ignore_warning = 1

在 MIME 类型中,图像方面有这样两种: image/jpeg 与 image/pjpeg ,GD库只认识前者的传统格式,后者是 progressive JPEG 的缩写。

php官方BUG讨论区http://bugs.php.net/bug.php?id=29878

[2004-08-28 19:00 UTC] cyleriggs at kc dot rr dot com

Description: ------------ When calling ImageCreateFromJPEG() on a valid jpeg file it fails and i get errors such as the following in my php error log: <code> [28-Aug-2004 05:21:29] PHP Warning: imagecreatefromjpeg() [<a href='function.imagecreatefromjpeg'>function.imagecreatefromjpeg</a>]: '/usr/local/apache2/htdocs/pictures/Before Dad Went to Iraq/IMGP0008.JPG' is not a valid JPEG file in /home/www/pictures/index.php on line 43 </code> however as can be seen through this link the file is a valid jpeg file: http://cyle.dyndns.org/pictures/Before Dad Went to Iraq/IMGP0008.JPG Also i have a memory_limit of 25mb so this cannot be the issue. Something that might help: http://cyle.dyndns.org/phpinfo.php I am writing this code for a picture gallery browser, while most pictures load, about 10% of my pictures cannot be opened through ImageCreateFromJpeg(), however it is always the same pictures that cannot be opened. The only trend i can see is that this does not appear to be happening on small jpegs. The page that I am having problems with is http://cyle.dyndns.org/pictures/index.php. The source code for this is at http://cyle.dyndns.org/pictures/index.phps. Expected result: ---------------- The image would be loaded and code continue to execute and i get the error message described above. Actual result: -------------- Sometimes images load sometimes images cannot be opened.

[2004-08-29 08:22 UTC] pajoye@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Your jpeg file is not valid. PHP could not take care of each possible failures in image files. Desktop softwares could. Fix your image and replace it.

--Pierre

[2004-09-30 17:05 UTC] paul at gslip dot com

I disagree. I have used my code successfully on montypics.com until the upgrade to php 5.0.1. I now get exactly the same results as the original poster.
Images that worked fine on previous versions now do not. I have a sample image that can be provided. I also have code I can share with the PHP team although I cannot post it here as it is lengthy and copyrighted.

[2004-10-05 00:34 UTC] cyleriggs at kc dot rr dot com

After playing around with the images themselves i have found that converting them from jpeg to png then back to jpeg fixed the problem and yielded no quality loss. I used the linux tool set called ImageMagick to do this. I wrote a short perl script to go through all my images and fix them. Other than this i have found no other way of stopping this. one interesting fact though is that while converting the images with the imagemagick utility it complained about some corruptions, however it was still able to open them fine and convert them. Maybe PHP is being too picky about the images that it opens as despite a few corrupted bytes EVERYthing was able to open these images except for PHP.

[2004-10-05 05:33 UTC] derick@php.net

PHP only reads non-coprrupted files - there is no bug here.

[2004-10-06 23:18 UTC] cyleriggs at kc dot rr dot com

Okay, so how about a feature suggestion than, i think that there should be the option in GD that allows you to try and open images that have a few corrupted bytes. If other programs can open them just fine what would be the harm in allowing programmers to choose to live with the corruptions?

[2004-10-07 05:12 UTC] derick@php.net

Corrupted files are invalid, and may crash an application if attempted to use. That's why we will not implement that. (Actually, it's not a PHP issue either, it has to do with how libgd handles opening files).

[2004-10-12 13:23 UTC] paul at gslip dot com

Has anyone at php verified that the images are corrupt? In what way are they corrupt?
Here's what I know:
1- These images were supported with no issues whatsoever before I 'upgraded' to php 5.x

2- Every other piece of software I own, including Windows Image Viewer, Photoshop, Paint, IE, Netscape, Imagemagick, etc. open the files with no complaint.

3- A visual inspection of the files on the byte level show nothing out of the ordinary.

That all leads me to believe that the images are not corrupt and that PHP or GD has a bug.

Please, stop being so stubborn and at least look at the problem. I can show you hundreds of examples of where this is happening on the web. Just do a google search for 'is not a valid JPEG file in' to see for yourselves how many sites are having this issue.

I suspect there's some new twist on the JPEG format that new digital cameras are using ,or something along those lines, that GD and PHP just aren't yet up to speed with.

Let's get this solved folks.

[2006-02-05 15:09 UTC] pajoye@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

Thank you for the report, and for helping us make PHP better.

You can now allow the jpeg decoder to be more tolerant/weak:

error_reporting(E_ALL);
// 0 is the current behavior
ini_set('gd.jpeg_ignore_warning', 1);
$im = imagecreatefromjpeg($file);

Php 5.1.3+ will contain the fix.

Enable Root login on Fedora 12/fedora 12 下启用root用户登录X

linux fedora 12 下 root用户通过x界面登录默认是禁用的,网上查询启用方法,google中文里搜索,说是修改/etc/pam.d/gdm文件,注释掉一行就可以,但修改过却还不能登录的,于是在google.com里搜索,看老外们怎么讲查到下面一篇文章,里面说要修改两个文件,

/etc/pam.d/gdm

/etc/pam.d/gdm-password

这样才可以,明确指出不像Ubuntu那样。

原文如下,作者说直接修改root为其它随意的字符串,如test,但或许注释会更好。

http://www.linuxreaders.com/2009/11/19/root-login-on-fedora-12/

Root Login on Fedora is not as easy as Ubuntu Root Login, here you need to modify two files to get root access.

You need to modify content of following files

/etc/pam.d/gdm

/etc/pam.d/gdm-password

You’ll find pam_succeed_if.so user != root quiet in above files, replace root with anything e.g test

I replaced root with test & was able to login to system using root.

OR Comment the entire line.

[Comment the entire line recommend!]

php调试利器 xdebug

php调试利器 xdebug

xdebug官方网站http://xdebug.org/

在Linux下编译安装XDebug

引用
tar -xzf xdebug-2.0.0RC3.gz
cd xdebug-2.0.0RC3
/usr/local/php/bin/phpize
./configure --enable-xdebug
cp modules/xdebug.so /usr/local/php/lib/php/extensions/no-debug-non-zts-20020429/

注:/usr/local/php/lib/php/extensions/no-debug-non-zts-20020429/不同的PHP版本路径不同,也不一定要放在该路径,可以在zend_extension_ts中自行指定xdebug.so所在位置。

Windows安装:
1. 登录www.xdebug.org,在下载您需要的版本,建议下载Windows binaries,免去手工编译,根据你的php版本选择其中的PHP5.2或5.3的,下载php_xdebug-xxxx.dll文件;建议下载稳定版,而不是beta版,当然beta版一般也不会出问题.
2. 将下载的php_xdebug-xxx.dll放到C:\php5\ext目录,重命名为php_xdebug.dll;路径根据您的php安装路经不同可能有所有同.
3. 编辑php.ini,加入下面几行:
extension=php_xdebug.dll
[Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir="J:\php_xdebug_output"
xdebug.profiler_output_dir="J:\php_xdebug_output"
后面的目录“J:\php_xdebug_output”为你想要放置Xdebug输出的数据文件的目录,可自由设置。
4. 重启Apache (或iis);
可以专门写几行有错的代码,看看出错信息显示不何不同。
再用var_dump()输出一个数组,看看显示是不是友好多了,至少不用查看html源文件才能看到清晰的数组结构.

linux 下媒体播放器mplayer+kmplayer

在fedora12下安装mplayer总是有很多问题,好几年前就用Linux,但仅仅是安装一下,草草用用,并没真正深入学习,很多地方都是一知半解,最近在fedora12下安装了官方svn最新的mplayer,但总是出一些这样那样的问题,装了kmplayer,设置播放核心为mplayer,很多问题都没有了,而且kmplayer在很多操作方面更容易上手一点,不你mplayer那样让人感觉到怪怪的。

MSSQL数据库超时 80040e31

今天早上碰到了导致超时的一种不常见的特殊情况。特整理如下:
早上CSDN的论坛回复和发帖都一直报超时,错误信息是最常见的那种:

Microsoft OLE DB Provider for SQL Server 错误 '80040e31'
超时已过期
/Expert/reply.asp,行 110

服务器上看CPU、内存,都非常非常的低呀,这么低的占用率也能导致超时,我晕。后来到处查看,后来在事件日志中看到一个非警告的日志:

事件类型: 信息
事件来源: MSSQLSERVER
事件种类: (2)
事件 ID: 17055
日期:   2005-8-23
事件:   9:39:00
用户:   N/A
计算机:   ********
描述:
5144:
数据库 '*********' 中文件 '***********' 的自动增长在 453 毫秒后已取消或出现超时。使用 ALTER DATABASE 设置更小的 FILEGROWTH 或设置新的大小。

我倒竟然是数据库文件在增加的时候超时了。而不是平常常以为的具体的SQL语句超时。把 FILEGROWTH 设置为一个更低的值,ok 一切都恢复了。

FILEGROWTH 的设置就是在数据库的 Enterprise Manager 中,对数据库的属性的如下窗口进行设置:

一旦你的数据库文件大了后,上述超时就可能出现。这时候不要简单地以为服务器压力太大了。也许就是你的一个设置导致了超时。

反馈

# re: 数据库超时的其中一种情况

2005-8-23 10:35 by ghj1976

默认SQL Server 在数据库文件满了后,是自动增加原数据库文件的10%大小,用来继续使用。

如果你的数据库文件很大了,这时候麻烦就来了,CSDN 论坛的这次问题就是在增加这个数据库文件的时候超时了。

然后其它所有的新增操作都会报超时,而这时候其实CPU、内存占用率都非常非常的低。

# re: 数据库超时的其中一种情况

2005-8-23 10:36 by ghj1976

解决方法就是把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。

# re: 数据库超时的其中一种情况

2005-8-23 10:38 by rIPPER

dba哪去了? :)

# re: 数据库超时的其中一种情况

2005-8-23 12:30 by ocean

没错,微软有专门一篇文章说这个问题:

http://support.microsoft.com/?id=305635

# re: 数据库超时的其中一种情况

2005-8-23 13:36 by Jacob

这是一个很土的问题,然而在企业的生产环境中经常遇到。不仅是数据文件满会导致此问题,日志文件满也一样。
某一条数据更新语句在数据库或日志文件即将满的时候执行,数据库增长的IO操作会导致延时,此延时会阻塞其他数据库操作,连锁反应,形成blocking。
其实此时找出一条正在阻塞的更新语句,在查询分析器中执行,此时是没有超市时间的。忍过几分钟,当这条语句执行完后,数据文件就会增长完成,所有的blocking也就解开了。
正如楼上的朋友所问,"dba哪去了?"。文件的监测和日志的truncate,本来就应该是dba常抓不懈的工作。

# re: 数据库超时的其中一种情况

2005-8-23 23:39 by ocean

其实此时找出一条正在阻塞的更新语句,在查询分析器中执行,此时是没有超市时间的。忍过几分钟,当这条语句执行完后,数据文件就会增长完成,所有的blocking也就解开了。
----------------------------
这句话好像不对,按照KB上的,这个申请文件增长的请求是被操作系统拒绝的,所以不是等几分钟执行完语句就能增长的。解决的方法还是把文件的增长大小设置为一个固定数值而不是百分比。

# re: 数据库超时的其中一种情况

2005-8-23 23:54 by Benny Ng

我还是不明白..那我要做的措施是什么?(针对这个情况)

# re: 数据库超时的其中一种情况

2005-8-24 15:53 by 怡红公子

我在一年多以前就说过这个事情。
另外,用SQL2005就不容易遇到这个问题了哦。
数据库增加10G的大小也不过就是3秒钟。

# 哈哈!你被贴了。

2005-8-24 17:40 by 透明

http://gigix.blogdriver.com/gigix/936726.html

# re: 数据库超时的其中一种情况

2005-8-25 1:43 by 流言社

哎,到处都是“你小子被贴了”

# re: 数据库超时的其中一种情况

2006-3-8 10:45 by zjbmax

遇到数据库中很多进程被阻塞或死锁的情况怎么解决?(就是在sql2000的企业管理器的“管理”中的“当前活动”“锁/进程ID”中发现的)

Pages: Prev 1 2 3 4 5 6 7 8 9 10 11 12 13