Bug #50224 [Com]: json_encode() does not always encode a float as a float
Edit report at https://bugs.php.net/bug.php?id=50224edit=1 ID: 50224 Comment by: chr dot tatu at gmail dot com Reported by:christian dot lawrence at calorieking dot com Summary:json_encode() does not always encode a float as a float Status: Not a bug Type: Bug Package:JSON related PHP Version:5.2SVN-2009-11-19 (snap) Block user comment: N Private report: N New Comment: The problem is still present in version 5.4.6. var_dump says this values is float, but after applying json_encode and json_decode the value gets to be an int. For the jsoncpp library there is a difference between int and float and that difference is acknowledged by the floating point. Previous Comments: [2012-07-13 23:09:50] josh dot adell at gmail dot com This is still an issue, specifically when JSON encoding for talking to APIs that don't allow mixed type arrays. For instance, json_encode(array(1.2, 2.3)) properly encodes to [1.2, 2.3] But, json_encode(array(1.0, 2.3)) encodes to [1, 2.3] which fails if the receiving end does not allow mixed-type arrays. Any chance on this ever being fixed? PHP Version: 5.3.10 [2009-11-20 10:39:53] christian dot lawrence at calorieking dot com And there lines the problem - there is no way to express the fractional part if json_encode() does not even deal with it in the first place. An integer and an integer represented as a floating point number are not the same thing because they have different types, as follows: ?php $a = 12; var_dump($a);//int(12) $b = 12.0; // This has a fractional part, hence it is a floating point number and not an integer var_dump($b);//float(12) var_dump($a === $b); //bool(false) ? Numerically they have the same value, but we all know this to be true: ?php var_dump($a == $b); //bool(true) ? There is always a fractional part of any integer when it is represented as a floating point number. It is implied and can, simply, be expressed by appending a .0 to the integer part. There is nothing in the JSON encoding rules on http://www.json.org/ which disallows this (see int frac form for specifics). Decoding a valid and legitimate encoding of an integer when it is represented as a floating point number gives the correct PHP floating point type: ?php var_dump(json_decode(12.0)); //float(12) ? Decoding an integer-encoded stream also gives the correct PHP integer type: ?php var_dump(json_decode(12)); //int(12) ? I fail to see how my bug report is bogus when json_encode() is unable to produce a perfectly valid and legitimate encoding yet json_decode() is capable of doing the right thing. Surely, the json_encode() implementation must be identifying the data type being encoded, presumably it is using equivalents for is_object() and is_array(). Why not use equivalents for is_int() or is_float() as well? A reliable data interchange format should not purport to do any type-casting from the primitive types it was provided for encoding. ie: If you encode a float then you should expect to decode a float. As far as I am concerned json_encode() is un-reliable and fails to encode my float, which I have confirmed in my results. I humbly ask that you reconsider your position. [2009-11-19 15:12:56] j...@php.net Yes, IF you were passing fractional part. But you're not. See the output of var_dump($f) in your results.. [2009-11-19 09:14:05] christian dot lawrence at calorieking dot com Take a look at the format for number at http://www.json.org/ and observe the form for a int frac. This clearly indicates that there is support for representing a floating point number, even integer floats. The json_encode() function clearly supports encoding of floating point numbers. json_decode() is capable of deserialising 12.0 as a integer floating point number. If you encode a floating point number, then one should expect to decode a floating point number. If json_encode()/json_decode() is to be used as a serious and reliable data exchange format, then there should be no loss or conversion of primitive type information. Please re-consider. [2009-11-19 08:51:56] j...@php.net There's is just number type in JSON for numbers. And as such, this is working just like it should and PHP tries it's best at guessing what type the numbers might be. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online
Req #54037 [PATCH]: [PATCH] Adds the ability to pass options to loadHTML
Edit report at http://bugs.php.net/bug.php?id=54037edit=1 ID: 54037 Patch added by: chr...@php.net Reported by:fxmulder at gmail dot com Summary:[PATCH] Adds the ability to pass options to loadHTML Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:trunk-SVN-2011-02-17 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: patch-for-adding-loadhtml-options.patch Revision: 1299136320 URL: http://bugs.php.net/patch-display.php?bug=54037patch=patch-for-adding-loadhtml-options.patchrevision=1299136320 Previous Comments: [2011-03-03 08:11:04] chr...@php.net After talking with Rob, we removed LIBXML_RECOVER again. People don't like seeing that wildly used, there were and are always a lot of discussions, if that's a good thing at all. So we just remove the constant again for now. I'll attach the new patch. If noone complains, I will commit it soon [2011-02-22 17:11:08] chr...@php.net Looks fine to me, Will commit soon to trunk [2011-02-18 00:21:20] fxmulder at gmail dot com I've also included a patch to create new constants for use as options [2011-02-17 18:57:57] fxmulder at gmail dot com Description: This patch allows passing options directly to libxml for the loadHTML and loadHTMLFile DOMDocument functions -- Edit this bug report at http://bugs.php.net/bug.php?id=54037edit=1
#20212 [NEW]: Content of form array variables will be cutted by the first 4 characters
From: [EMAIL PROTECTED] Operating system: SuSE Linux 8.0 PHP version: 4.2.3 PHP Bug Type: HTTP related Bug description: Content of form array variables will be cutted by the first 4 characters PHP 4.2.3 will cut the first 4 characters from content of form variables, if they are array's. This does not occur in PHP versions 4.1.1 and 4.1.2. The following 2 files demonstrate the bug. First the HTML form: Begin ++ html head titleDemonstrate error in form handling by PHP 4.2.3/title /head body bgcolor=white form action=http://139.18.20.141/formError.php; method=post !-- try the following URLs for action to see correctly working older systems: [PHP 4.1.1] http://www.abelard.info/formError.php [PHP 4.1.2] http://www.stura.uni-leipzig.de/sp/formError.php -- input type='checkbox' name='selectCourse[]' value='KURS_' checked=1KURS_ BR input type='checkbox' name='selectCourse[]' value='ABCD_KURS_0_1'ABCD_KURS_0_1 BR input type=submit name=submit value=Ok /form /body /html --- End -- Second, the processing PHP file: + Begin html headtitlePOST-Array test/title/head body h1POST-Array test/h1 p ?php echo 'selectCourse[0]='.$_POST['selectCourse'][0].br\n; echo 'selectCourse[1]='.$_POST['selectCourse'][1]; ? /p /body /html End If submitted by only clicking the OK-button, this should output ... selectCourse[0]=KURS_ ... but in fact it does this on older versions of PHP only. PHP 4.2.3 does output instead: ... selectCourse[0]=_ ... loosing the first 4 characters from variable content. Note: This occurs _only_ on array-like variables as above, normal variables were submitted correctly. *** Now the usual system information: You can obtain the full configuration by calling http://139.18.20.141/test.php The configure line here again: + Begin ++ './configure' '--prefix=/usr/share' '--datadir=/usr/share/php' '--bindir=/usr/bin' '--libdir=/usr/share' '--libdir=/usr/local/lib' '--includedir=/usr/include' '--includedir=/usr/local/include' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib/php/bin' '--disable-debug' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-discard-path' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-inline-optimization' '--enable-magic-quotes' '--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-memory-limit' '--enable-safe-mode' '--enable-shmop' '--enable-sigchild' '--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid' '--enable-versioning' '--with-bz2' '--with-dom=/usr/local/include/libxml2' '--with-ftp' '--with-gettext' '--with-imap=yes' '--with-jpeg-dir=/usr' '--with-mysql=/usr' '--with-png-dir=/usr' '--with-xml' '--with-zlib=yes' '--enable-xslt' '--with-xslt-sablot' '--with-mm' '--with-apxs=/usr/sbin/apxs' '--with-pcre-regex' '--without-pgsql' '--with-imap-ssl' --- End --- I have compiled PHP by getting php-4.2.3.tar.bz2 from http://de.php.net/get_download.php?df=php-4.2.3.tar.bz2 The md5 sum is OK. For APACHE I used the source RPM included in SuSE 8.0, that means version 1.3.23. ## -- Edit bug report at http://bugs.php.net/?id=20212edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20212r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20212r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20212r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20212r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20212r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20212r=support Expected behavior: http://bugs.php.net/fix.php?id=20212r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20212r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20212r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20212r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20212r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20212r=dst IIS Stability: http://bugs.php.net/fix.php?id=20212r=isapi
