How to integrate PHP and R on Windows? - php

Having some issues integrating PHP and R. I am working from this article:
http://www.r-bloggers.com/integrating-php-and-r/
R is installed and is verified working with our R script:
Rscript C:\inetpub\wwwroot\client\includes\decisionTreePredictor.R 20 10 O 1000 10000 5000 0.2 10.2
Printing a single value that is a result of its calculations:
[1] "0"
(The path to Rscript.exe is set in the Windows environmental variables)
I have a PHP script in place that is using exec() which tests successfully with commands such as:
$result = exec('dir',$output,$returnVar);
echo "<br>result ". print_r($result,true);
echo "<br>output <pre>". print_r($output,true) , "</pre>";
echo "<br>return ". print_r($returnVar,true);
returning:
result 2 Dir(s) 117,749,354,496 bytes free
output
Array
(
[0] => Volume in drive C is C_DRIVE
[1] => Volume Serial Number is 7EB2-A074
[2] =>
[3] => Directory of C:\inetpub\wwwroot\client\temp
[4] =>
[5] => 05/17/2014 10:29 PM .
[6] => 05/17/2014 10:29 PM ..
[7] => 05/16/2014 09:24 AM 5,181 dbimporttest.php
[8] => 05/17/2014 10:29 PM 0 routput.txt
[9] => 05/17/2014 11:42 PM 701 rscripttest.php
[10] => 05/16/2014 04:59 PM 425 whoami.php
[11] => 4 File(s) 6,307 bytes
[12] => 2 Dir(s) 117,749,354,496 bytes free
)
return 0
When I try to run the R script within the exec command, it fails:
$result = exec('Rscript.exe C:\inetpub\wwwroot\client\includes\decisionTreePredictor.R 20 10 O 1000 10000 5000 0.2 10.2',$output,$returnVar);
echo "<br>result ". print_r($result,true);
echo "<br>output <pre>". print_r($output,true) , "</pre>";
echo "<br>return ". print_r($returnVar,true);
Returning:
result
output
Array
(
)
return 1
I am running:
Windows Server 8 R2
IIS 8
PHP 5.5
R 3.1

Unable to get exec() to work or output errors that are usable, I decided to seek an alternative route. Using the COM class seems to have given me what I was looking for.
Here is the final, operational code:
$command = 'C:\Program Files\R\R-3.1.0\bin\Rscript.exe C:\inetpub\wwwroot\client\includes\decisionTreePredictor.R 20 10 O 1000 10000 5000 0.2 10.2';
$pCom = new COM("WScript.Shell");
$pShell = $pCom->Exec($command);
$sStdOut = $pShell->StdOut->ReadAll; # Standard output
$sStdErr = $pShell->StdErr->ReadAll; # Error
echo "<pre>$sStdOut</pre>";
Odd that I couldn't get exec() to do the job as that seems be the solution preferred by most bloggers discussing R/PHP integration.
Anyway, I hope this solution helps anyone else that finds themselves in my situation!
P.S. You will want to make sure the extension is on in php.ini (it is off by default on install): extension=php_com_dotnet.dll

Related

php base64_decode part corrupt using xampp on windows 7

I have a problem with some third party php scripts not decoding properly using xampp on windows 7. The process is that the script sends an encrypted payload to an external server where it is decrypted and returned. We have no access or control of the external server. The relevant code is:
$response = $provider->request('package/decode/' . $endpoint, 'POST', $params);
$data = $response->toXml();
if (isset($data->object)) {
$object = (string)$data->object;
$object = base64_decode($object);
$object = unserialize($object);
}
if (isset($data->related_objects)) {
$relatedObjects = (string)$data->related_objects;
$relatedObjects = base64_decode($relatedObjects);
$relatedObjects = unserialize($relatedObjects);
}
The $object decodes with no problem. The $relatedObjects does not and looks corrupt part way through:
YToxOntzOjEyOiJQbHVnaW5FdmVudHMiO2E6MTA6e3M6MzI6ImQ0NzM2NzJjM2YyNzk2NjVhYTNmNWJlNjBjMzU2MjYyIjthOjg6e3M6MTM6InByZXNlcnZlX2tleXMiO2I6MTtzOjEzOiJ1cGRhdGVfb2JqZWN0IjtiOjA7czoxMDoidW5pcXVlX2tleSI7YToyOntpOjA7czo4OiJwbHVnaW5pZCI7aToxO3M6NToiZXZlbnQiO31zOjU6ImNsYXNzIjtzOjE0OiJtb2RQbHVnaW5FdmVudCI7czo2OiJvYmplY3QiO3M6NzU6InsicGx1Z2luaWQiOjAsImV2ZW50IjoiT25SaWNoVGV4dEJyb3dzZXJJbml0IiwicHJpb3JpdHkiOjAsInByb3BlcnR5c2V0IjowfSI7czo0OiJndWlkIjtzOjMyOiIwMDMzMTExNjBkMDkwYzUxY2FjN2E5Mzg4ZDQzMDNiNyI7czoxMDoibmF0aXZlX2tleSI7YToyOntpOjA7aTowO2k6MTtzOjIxOiJPblJpY2hUZXh0QnJvd3NlckluaXQiO31zOjk6InNpZ25hdHVyZSI7czozMjoiZDVhYjlmMTVjOWY3ODNkZTJhNDFiMzZjMTlkMTUwNGQiO31zOjMyOiI3YzczZTg3OGI5MzZiOTRmMGQzZmVhNjJhNzIzMGM0MyI7YTo4OntzOjEzOiJwcmVzZXJ2ZV9rZXlzIjtiOjE7czoxMzoidXBkYXRlX29iamVjdCI7YjowO3M6MTA6InVuaXF1ZV9rZXkiO2E6Mjp7aTowO3M6ODoicGx1Z2luaWQiO2k6MTtzOjU6ImV2ZW50Ijt9czo1OiJjbGFzcyI7czoxNDoibW9kUGx1Z2luRXZlbnQiO3M6Njoib2JqZWN0IjtzOjc5OiJ7InBsdWdpbmlkIjowLCJldmVudCI6Ik9uTWFuYWdlclBhZ2VCZWZvcmVSZW5kZXIiLCJwcmlvcml0eSI6MCwicHJvcGVydHlzZXQiOjB9IjtzOjQ6Imd1aWQiO3M6MzI6IjZkMTdjMDRhZTkyNjQ4ZTUzNTk0MjViODI5NWUzOWQ1IjtzOjEwOiJuYXRpdmVfa2V5IjthOjI6e2k6MDtpOjA7aToxO3M6MjU6Ik9uTWFuYWdlclBhZ2VCZWZvcmVSZW5kZXIiO31zOjk6InNpZ25hdHVyZSI7czozMjoiZDYyYzc1NGM3OTEzYzhlNTE3NWNkMzVhNTJmMWUzMGQiO31zOjMyOiI2ZTUxNGI1MTYwNGNmMzdmODQ2ZTY3N2U5YzVhYzA5MCI7YTo4OntzOjEzOiJwcmVzZXJ2ZV9rZXlzIjtiOjE7czoxMzoidXBkYXRlX29iamVjdCI7YjowO3M6MTA6InVuaXF1ZV9rZXkiO2E6Mjp7aTowO3M6ODoicGx1Z2luaWQiO2k6MTtzOjU6ImV2ZW50Ijt9czo1OiJjbGFzcyI7czoxNDoibW9kUGx1Z2luRXZlbnQiO3M6Njoib2JqZWN0IjtzOjcyOiJ7InBsdWdpbmlkIjowLCJldmVudCI6Ik9uRG9jRm9ybVByZXJlbmRlciIsInByaW9yaXR5IjowLCJwcm9wZXJ0eXNldCI6MH0iO3M6NDoiZ3VpZCI7czozMjoiZTY0MGZjM2Y5NDUyNzQ5MWRkZjc1NzM3ZTEwMDI2NjAiO3M6MTA6Im5hdGl2ZV9rZXkiO2E6Mjp7aTowO2k6MDtpOjE7czoxODoiT25Eb2NGb3JtUHJlcmVuZGVyIjt9czo5OiJzaWduYXR1cmUiO3M6MzI6IjljNjBhY2FiODQ0OGI4ZTEzMDI4MDE1Njg1MzE1YzZiIjt9czozMjoiMDg2ZWUyMjUxODljMmVmN2Y2ODBiZDVhZTY0YjQ5NjQiO2E6ODp7czoxMzoicHJlc2VydmVfa2V5cyI7YjoxO3M6MTM6InVwZGF0ZV9vYmplY3QiO2I6MDtzOjEwOiJ1bmlxdWVfa2V5IjthOjI6e2k6MDtzOjg6InBsdWdpbmlkIjtpOjE7czo1OiJldmVudCI7fXM6NToiY2xhc3MiO3M6MTQ6Im1vZFBsdWdpbkV2ZW50IjtzOjY6Im9iamVjdCI7czo3ODoieyJwbHVnaW5pZCI6MCwiZXZlbnQiOiJPblJpY2hUZXh0RWRpdG9yUmVnaXN0ZXIiLCJwcmlvcml0eSI6MCwicHJvcGVydHlzZXQiOjB9IjtzOjQ6Imd1aWQiO3M6MzI6ImM0NWQ1OGU5ZmVkNWQ5NDcyZTlmMDExMDU2YjNhMDg3IjtzOjEwOiJuYXRpdmVfa2V5IjthOjI6e2k6MDtpOjA7aToxO3M6MjQ6Ik9uUmljaFRleHRFZGl0b3JSZWdpc3RlciI7fXM6OToic2lnbmF0dXJlIjtzOjMyOiIxMWJlZDhiOGYyZWQxOWEyZTVkZmEwYWY2MjU1NDJmOSI7fXM6MzI6ImIyOGFkZTdjNDQ4ZmRjMmJkMzdlZTBlNGQ0ODEyMTE1IjthOjg6e3M6MTM6InByZXNlcnZlX2tleXMiO2I6MTtzOjEzOiJ1cGRhdGVfb2JqZWN0IjtiOjA7czoxMDoidW5pcXVlX2tleSI7YToyOntpOjA7czo4OiJwbHVnaW5pZCI7aToxO3M6NToiZXZlbnQiO31zOjU6ImNsYXNzIjtzOjE0OiJtb2RQbHVnaW5FdmVudCI7czo2OiJvYmplY3QiO3M6NzM6InsicGx1Z2luaWQiOjAsImV2ZW50IjoiT25UVklucHV0UmVuZGVyTGlzdCIsInByaW9yaXR5IjowLCJwcm9wZXJ0eXNldCI6MH0iO3M6NDoiZ3VpZCI7czozMjoiZjg1MWU0OTdmZDg5ZDBiY2Y4MDRmNGVmZDRmOTVlMmMiO3M6MTA6Im5hdGl2ZV9rZXkiO2E6Mjp7aTowO2k6MDtpOjE7czoxOToiT25UVklucHV0UmVuZGVyTGlzdCI7fXM6OToic2lnbmF0dXJlIjtzOjMyOiJjN2M5YTA4MWUyY2E4ZTI4ZGU2OTViMmUwYzM3MzhhMCI7fXM6MzI6IjIwOTFkOGFlMjQ3ZmY0NzQwMjI3NmU4NGUwNDY3ZDMwIjthOjg6e3M6MTM6InByZXNlcnZlX2tleXMiO2I6MTtzOjEzOiJ1cGRhdGVfb2JqZWN0IjtiOjA7czoxMDoidW5pcXVlX2tleSI7YToyOntpOjA7czo4OiJwbHVnaW5pZCI7aToxO3M6NToiZXZlbnQiO31zOjU6ImNsYXNzIjtzOjE0OiJtb2RQbHVnaW5FdmVudCI7czo2OiJvYmplY3QiO3M6NzQ6InsicGx1Z2luaWQiOjAsImV2ZW50IjoiT25UVk91dHB1dGUG2ApmKwV9XbLEl8hy9QJ6yTZ2NnvVRfTjhvx3hq3ZXLDI21gcc0/UMBXxXTkbVOlOtapxOTH1eK3xIXwKkPy38Y5zLjHFaNyK5cPoQpP5FbP1qjUNUrgrbQGKeEfRGsIAbtzHT2qTxzgY7z/epePkvclKqWa194ZevVGKQN0z0jLLZ2REY/ZSadUQVP/LcIew8P//MvY/8YeFF5mxyutlTdRJ9oMwRZ5pMI2wT/mmsx2aeeVh1WcFP7/OqEzhHT8XIUwV96DYv/aFmetP6avi1ygnWTVZpnuXWmoSorfgwnAUzU76j3iv4f0szvn8BG6IvvXxMOuTCazD6H0lteI4KKSW6VAIj205AxFOuEqUp9iHcb4O2e/vkDW8Rn0ayfVIOagnMcU1oshb41KNZezuJBdv99IpbKOKnSy3SnPf+RzdkLWuFWek7I51O9xYzxdMiwot0alVPjZcepC2k9NAH/oQ0Uj2ks0djW6lwDXfYUAJkzem3qTwUj0eEac/fIKZAd84GBy3Bgef+migngUrnqRWyTqpJ8S0Jt61XzQogNrSrB8ZuqT+vbrkaLDBtTI49MmvlMcN0bf2PAhkoaMSwISL3d4iv4FRPaNUhtHe3XyWomnZwjckCOUEHdPC7ptUBkYGlatqNw259eQi2QubaCR87JX8FPUo1U5pQiVqK74QHBc8gVTfoybY2cMtMZ3qmzBymsn6ugeeGEoW6C+0nAqqhJOp7ZNJ4Y30rnMyjrcqX1L1dGClu1HMAhZ1HR7iYMlB2EDSlkxMzrBWdeUqXon0yuKltLLr9BlFtY0in/6NKRy6CQnIdsQvp0ZhBiHVUsdPNmTX7OI/arvkvKT7Pw8UcRkraDJgCJm+GQ5lLi7E22diyxwtPCYaR0936XIGWqzcJFUGSaWApH3y8q8c8+3FOlmpdxali1mDfO4zQT05D+B7EADFxnPoXdXaUSd/enArOOJO8NFqMTwgJ2Z2ujaBLpkojPE4aJLdzihqEvPA3gd8dwZBw5vsSDDpajiz9/vCh7YgDJwotKCXw41qRWDD6hKeyfkosVEqUOMZn0nxG9RHVdrKdH2KJquaLdndgTzOOCnPcU753TcG6sjVnSokexmx2/KA2P5+wjNe8G8cO61OhfuXGFLE7LslNc+urnVeLYAsN+SnBZYeFF+XooXK1JiZtIUo3JHKi037T1qevfvy6EcHaALwGBUPmR7J9H+YckekfEaMK4TC6dCb5fwNaDKSpYk9GNj5mVzQ676PzvWffcS8o2ZdqFryUM0GNr0sSVRhlo7rYjjPGUOu1hIhrBNGEcOePBRutK3V8HstKmTDdyIB6dGtS3D+8MhZOz6DBu8DlNerqsYXxKA7qlQ5cfVrM+CpO4yUobiqQfCQaTkXMp2352ORppa+9VG0tVa74eZnyHQgugz8d4XRxBo4VA5vMOCA3yg34+q2/CayXEPE6VAlIhf1agZ3vfRBxVZEUSWR0SV1ut5Y9crHkBoEjF9m/NEO/Os7mD69tSsJelsO3gfhuzZX8FgZSpOX3mwrdjoS0h/w3s1BKkg6srOZ9zbFx/34xTZBIwYBwfV4i3GzSZiFY0NiqT/3hXkaWZqzv4IuT4J9AZOUFjZxpdkdDbCo3nXEhDcg/DdISg1WbPuFjOHed50GD2el/Y+cS3cKrbwzVWom/Jt8dwTSPfU+j+w5IpEDOC85VYl+G4nqs9pxnbNw9eB9yPCUrCg9p5EJzwdOrvXX6DmkmLZ9+1I3+9T0TUQ9vsi10CnCdIF2tjdWR+vbxJkBDfIL9Ji0dfw4TtSZm+NtqER4GvbhcIq9sA1Lnf7Sy8jbd/ifhR0804bCvcvRTCa+zHDwauGYyV9jXd4fKLI7CAai8ot29x1hTypyzDcGCU0xKZgHAHRSxHd2tiEYUmvUJzhg7prdXwgdSEexe/hLRAHVNxo3G7JPV/D86YUdex8Ya+lbnwF1+V7k2Yz7uUehLkt6r1LpbMCdFwFvXvhQkd8QWoM3qlFNtkV0KeyI99nOPOAQqRJ5tlqmKNYHgVGs29y1DGltSQP5dN4LTbOFKsHl0kSKQFEqTqguU+qP8sLe/ID3Vvn1HslwqqWIvq5PLpjJtoS39lMQdWhxAuZNSccFP/2Rdrzx9IWuRbIQuRTa48Gtf3RJBZysslo6DrfYnEdvReE1aGMXV/tEiOFYyZsrKgSzvpaVVmN7uQRwPqOsNakBPjdz4ibEN0ZYpuoYDlJos/VxhlNi/KLbFosufeEXbqDx5eSWYl6BNRgnB2+qX/AO+hNuanN4Y711Sx8AJReInSUlgCG1QPrej7ZAYp+v1j1+i3oQw45Qtm2gBmFmWlMU4moDXZHwYNK0+OUfggZ8IESROYL85bQft+IvQMqGodgdEFY0ztWB3EItOVW6wS21HpMJ8CKJdqGFRSPuq9qoewjqRFkduG/Vnn1xib1tWz3OpILecoCCLehiaFN+rWX5ZN7cw3acJRq29oILLaw/I7teu119ASNo3J2OjJ1Ct6QYJB0FSa5Jsr4EhnZaf0r6VI7MM7aOAe1XMOXP0F2ks1Ash057XMxLdkdB8EKGQPm4w0aYxRbRoY4UK8nxERZHyxb4XpxIfN1mHXMV2TalbyyxB3dMLK80csIPzRRPdpvUnFRNynw1ZaJUrypTZfWBnf2eNbT6ynWrWmrBR5+jKuOwevGidfh5tE6U4prLU8as+/ARq/E4TfVfjUesfDSbyRqd/FDxpHeI3pVTwW4gsA==
Result:
a:1:{s:12:"PluginEvents";a:10:{s:32:"d473672c3f279665aa3f5be60c356262";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:75:"{"pluginid":0,"event":"OnRichTextBrowserInit","priority":0,"propertyset":0}";s:4:"guid";s:32:"003311160d090c51cac7a9388d4303b7";s:10:"native_key";a:2:{i:0;i:0;i:1;s:21:"OnRichTextBrowserInit";}s:9:"signature";s:32:"d5ab9f15c9f783de2a41b36c19d1504d";}s:32:"7c73e878b936b94f0d3fea62a7230c43";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:79:"{"pluginid":0,"event":"OnManagerPageBeforeRender","priority":0,"propertyset":0}";s:4:"guid";s:32:"6d17c04ae92648e5359425b8295e39d5";s:10:"native_key";a:2:{i:0;i:0;i:1;s:25:"OnManagerPageBeforeRender";}s:9:"signature";s:32:"d62c754c7913c8e5175cd35a52f1e30d";}s:32:"6e514b51604cf37f846e677e9c5ac090";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:72:"{"pluginid":0,"event":"OnDocFormPrerender","priority":0,"propertyset":0}";s:4:"guid";s:32:"e640fc3f94527491ddf75737e1002660";s:10:"native_key";a:2:{i:0;i:0;i:1;s:18:"OnDocFormPrerender";}s:9:"signature";s:32:"9c60acab8448b8e13028015685315c6b";}s:32:"086ee225189c2ef7f680bd5ae64b4964";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:78:"{"pluginid":0,"event":"OnRichTextEditorRegister","priority":0,"propertyset":0}";s:4:"guid";s:32:"c45d58e9fed5d9472e9f011056b3a087";s:10:"native_key";a:2:{i:0;i:0;i:1;s:24:"OnRichTextEditorRegister";}s:9:"signature";s:32:"11bed8b8f2ed19a2e5dfa0af625542f9";}s:32:"b28ade7c448fdc2bd37ee0e4d4812115";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:73:"{"pluginid":0,"event":"OnTVInputRenderList","priority":0,"propertyset":0}";s:4:"guid";s:32:"f851e497fd89d0bcf804f4efd4f95e2c";s:10:"native_key";a:2:{i:0;i:0;i:1;s:19:"OnTVInputRenderList";}s:9:"signature";s:32:"c7c9a081e2ca8e28de695b2e0c3738a0";}s:32:"2091d8ae247ff47402276e84e0467d30";a:8:{s:13:"preserve_keys";b:1;s:13:"update_object";b:0;s:10:"unique_key";a:2:{i:0;s:8:"pluginid";i:1;s:5:"event";}s:5:"class";s:14:"modPluginEvent";s:6:"object";s:74:"{"pluginid":0,"event":"OnTVOutputeØ
f+}]²ÄÈrõzÉ6v6{ÕEôãüw­Ù\°ÈÛXsOÔ0ñ]9TéNµªq91õx­ñ!|
ü·ñs.1ÅhÜåÃèBù³õª5
R¸+mxGÑÂnÜÇOjÇ8ï?Þ¥ãä½ÉJ©fµ÷^½Q#Ý3Ò2ËgdDcöRiÕTÿËp°ðÿÿ2ö?ñ±ÊëeMÔIö0Ei0°Où¦³yåaÕg?¿Î¨Lá?!L÷ Ø¿öëOé«â×('Y5Y¦{Zj¢·àÂpÍNúx¯áý,Îùün¾õñ0ë ¬Ãè}%µâ8(¤éPm9N¸J§Øq¾Ùïï5¼F}ÉõH9¨'1Å5¢È[ãReìî$o÷Ò)l£,·Jsßùݵ®g¤ìu;ÜXÏL
-Ñ©U>6\z¶Ó#úÑHöÍn¥À5ßa# 7¦Þ¤ðR=§?|ß8·úh +¤VÉ:©'Ä´&Þµ_4(ÚÒ¬º¤þ½ºäh°Áµ28ôɯÇ
Ñ·ö<d¡£ÀÝÞ"¿Q=£TÑÞÝ|¢iÙÂ7$åÓÂîTF«j7
¹õä"Ùh$|ìüõ(ÕNiB%j+¾<Tߣ&ØÙÃ-1ê0rÉúºJè/´
ª©íIáô®s2·*_Rõt¥»QÌuâÉAØ#ÒLLΰVuå*^ôÊ⥴²ëôEµ"þ)º ÈvÄ/§Fa!ÕRÇO6d×ìâ?j»ä¼¤û?q+h2¾e..ÄÛgbË-<&GOwérZ¬Ü$UI¥¤}òò¯óíÅ:Y©w¥Y|î3A=9à{ÅÆsè]ÕÚQ'zp+8âNðÑj1< 'fvº6.(ñ8hÝÎ(jóÀÞ|wAÃìH0éj8³÷û¶ (´ ÃjEÃêÉù(±Q*PãIñÔGUÚÊt}&«-ÙÝ<Î8)ÏqNùÝ7êÈÕ*${±ÛòØþ~Â3^ðo;­NûRÄì»%5Ï®®u^-,7ä§_¢ÊÔ´(ÜÊMûOZ½ûòèGhðÉôrG¤|F+ÂéÐåü
h2¥=Øù\Ðë¾Îõ}ļ£f]¨ZòPÍ6½,ITaëb8ÏC®Ö!¬FÃ<n´­Õð{-*dÃw"éÑ­KpþðÈY;>ï׫ªÆÄ ;ªT9qõk3à©;¡¸ªAði92·çc¦¾õQ´µV»áægÈt ºüwÑÄ8To0àß(7ãê¶ü&²\CÄéP%"õjw½ôAÅVDQ%Ñ%uºÞXõÊÇ_füÑüë;>½µ+ z[Þá»6WðXJÞl+v:ÒðÞÍA*H:²³÷6ÅÇýøÅ6A#Áõxq³IcCb©?÷yY³¿.O}6q¥Ù
°¨ÞuÄ7 ü7HJ
VlûáÞwg¥ýKw
­¼3Uj&ü|wÒ=õ>ì9"8/9U~ê³Úq³põà}Èð¬(=§ ÏN®õ×è9¤¶}ûR7ûÔôMD=¾ÈµÐ)Âtv¶7VGëÛÄ
òô´uü8NÔãm¨Dxöáp½°
KþÒËÈÛwø<Ó½ËÑL&¾ÌpðjáÉ_c]Þ(²;¢òv÷aO*rÌ7 M1)tRÄwv¶!RkÔ'8îÝ_HG±{øKDÕ77²OWðüé{ké[uù^äÙû¹G¡.Kz¯RélÀo^øPßZ7ªQM¶Et)ì÷ÙÎ<à©y¶Z¦(ÖQ¬ÛܵimIùtÞM³ÁåÒD#QN¨.SêòÂÞü÷VùõÉpª¥¾®O.ɶ·öSuhqæMIÇ?ýv¼ñô®E²¹ÚãÁ­tI¬²Z:·ØGoEá5hcWûDáXÉ+*³¾Vc{¹p>£¬5©>7sâ&Ä7FX¦êRh³õqSbü¢Û.}án ñåäb^5'oª_ðúnjsxc½uK%%%!µ#úÞ¶#b¯Ö=~zÃP¶m afZSâj]ðÒ´øå| D9üå´·â/#Ê¡ØV4ÎÕÜB-9UºÁ-µ ð"v¡E#î«Ú¨{êDY¸oÕ}q½m[=ΤÞr-èbhS~­eùdÞÜÃv%¶ö-¬?#»^»]}#hÜB·¤$I®I²¾vZJúTÌ3¶íW0åÏÐ]¤³P,N{\ÌKvGAðB#ù¸ÃFÅÑ¡+ÉñGËø^H|ÝfsÙ6¥o,±wL,¯4rÂÍOvÔTMÊ|5e¢T¯*Seõý5´úÊu«ZjÁG£*ã°zñ¢uøy´NâËSƬûð«ñ8Mõ_G¬|4ÉüPñ¤wÞSÁn °
There are no php errors or errors at the software providers end either. I have set Apache and PHPs charsets to UTF-8. I have the same script working on an external centos 7 setup and the vendor says other customers use xampp with no problem. So I'm guessing this is a local character encoding problem with windows or php? How can I to narrow it down so I can decode the string correctly? Thanks.
My first guess was that a piece of the data is missing, and because of the cyclic inner structure of base64 if we'd cut off at a different offset we could get the data back.
So I've tried:
echo base64_decode(substr($payload, $offset));
for different offsets around 3400 (where the corruption starts), and got no luck! At any offset it was still gibberish.
Then I tried collecting byte statistics to see if it's coherent to the distribution usually found in text files to which JSON belongs.
$pivot = 3400;
$decodeJson = base64_decode(substr($payload, 0, $pivot));
$decodeGibberish = base64_decode(substr($payload, $pivot));
print_r(getByteDistribution($decodeJson));
print str_repeat('-', 100) . "\n";
print_r(getByteDistribution($decodeGibberish));
function getByteDistribution(string $input): array {
$distribution = [];
for ($i = 0; $i < strlen($input); ++$i) {
$ord = ord($input[$i]);
if (!isset($distribution[$ord])) {
$distribution[$ord] = 0;
}
$distribution[$ord]++;
}
arsort($distribution, SORT_NUMERIC);
return $distribution;
}
And this is what I got:
Array
(
[58] => 281
[34] => 236
[101] => 181
[115] => 132
[59] => 129
[105] => 101
[48] => 88
[49] => 83
[116] => 76
[110] => 76
[97] => 70
[100] => 69
[50] => 66
[114] => 61
[51] => 60
[99] => 55
[53] => 52
[52] => 50
[117] => 49
[56] => 47
...skipped for brevity...
)
---------------------------------------------------------------------
Array
(
[245] => 21
[222] => 19
[240] => 18
[6] => 18
[252] => 17
[55] => 16
[106] => 15
[201] => 15
[79] => 14
[133] => 14
[56] => 14
[119] => 14
[29] => 14
[117] => 14
[164] => 13
[118] => 13
[157] => 13
[104] => 13
[196] => 13
[241] => 13
...skipped for brevity...
)
I advise you to run it and see for yourself: while distribution in JSON part shows high peaks for often-repeated character, the distribution for gibberish is much more even.
Which is a strong indicator for encrypted data.
So the problem is not with the payload, but with deciphering it.
And it occurred to me that there is just the same common problem when uploading a zip file to FTP. If you happen to use text mode in your FTP client, then line ending characters which may happen in the encrypted data may be irreversibly lost due to conversion. This is most often happens with Windows because it uses different line endings than Unix/Linux.
So my suggestion is that you check the code for downloading the encrypted data and see if a binary mode may be enabled somewhere. For example, if you use fopen, then read mode should be denoted as 'rb' ('b' for binary-safe), and not just 'r'. If you use a different transport, it's up to you to inspect it.

php exec() return wrong data

When I execute php script with exec('vnstat -tr', $results);
Output:
Array ( [0] => Sampling eth0 (5 seconds average)... 0 packets sampled in 5 seconds
[1] => Traffic average for eth0
[2] =>
[3] => rx 0.00 kbit/s 0 packets/s
[4] => tx
0.00 kbit/s 0 packets/s
[5] => )
When I execute vnstat -tr in console.
Output look like this:
root#s2:~# vnstat -tr 313727 packets sampled in 5 seconds Traffic average for eth0
rx 10,42 Mbit/s 20092 packets/s
tx 488,22 Mbit/s 42653 packets/s
Someone Could tell my why PHP returned wrong data?

Unpack() delivers different results on different machines

I have some strange behavior with the unpack function. I have a packed string, stored as longblob in a mysql database. When I read that string and unpack it, it gives me an array, so far so good. But when I run this on another machine some of the values in the array are different.
When I dump the data from mysql, they are equal on both machines.
Unpacking is done this way:
$array = unpack("N*", $packed);
$array should then be like this (and it is on one machine)
Array
(
[1] => 179848175
[2] => -16214255
[3] => 179848175
[4] => -16214255
[5] => 179848175
[6] => -16214255
[7] => 179999949
[8] => -16152916
[9] => 179999277
[10] => -16168574
...
)
But on the other machine it is like this:
Array
(
[1] => 179848175
[2] => 427853622
[3] => 179848175
[4] => 427853622
[5] => 179848175
[6] => 427853622
[7] => 179999949
[8] => 427853423
[9] => 179999277
[10] => 427853341
...
)
Every second value seems to be different.
I have tested this on three different machines, on two everything was fine, but on that one machine I get that weird output.
One machine is running PHP 5.6.3 (here it is ok), two machines are running PHP 5.5.14 (on one it is ok, on the other not)
The pack format N means unsigned long, which means it can't be negative. However, you are storing negative values, and they are the ones that aren't being unpacked the way you want. PHP does not have a pack format for machine-independent signed longs; it only supports packing them in machine byte order, which may not be compatible from machine to machine. Thus you'll have to make the values signed yourself.
To convert your array items into signed values:
for ($i = 1; $i <= count($array); $i++) {
// Check for a greater-than-32-bit environment,
// and check if the number should be negative
// (i.e., if the high bit is set in 32-bit notation).
if (PHP_INT_SIZE > 4 && $array[$i] & 0x80000000) {
// A negative number was unpacked as an unsigned
// long in a greater-than-32-bit environment.
// Subtract the appropriate amount (max 32-bit
// unsigned long + 1) to convert it to negative.
$array[$i] = $array[$i] - 0x100000000;
}
}
var_dump($array);

Splitting up dynamic string in PHP

I have the following string in PHP:
System load: 0.0 Processes: 119 Usage of /: 0.8% of 226.04GB Users logged in: 1 Memory usage: 4% IP address for eth0: 192.168.0.21 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/
I'm trying to split it up into strings for each value so I can get "0.0", "119", "0.8% of 226.04GB", "1", "4%", "192.168.0.21", "0%".
I did try using set locations in the string to pick out the data but realised it was no good as the values are dynamic and could change from being 1 to 4+ characters long at any time. Is there a way I can split these up using PHP? I was unable to find anything in the string function library. Thanks.
http://www.phpliveregex.com/p/2kT
$input = 'System load: 0.0 Processes: 119 Usage of /: 0.8% of 226.04GB Users logged in: 1 Memory usage: 4% IP address for eth0: 192.168.0.21 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/';
$results = array();
preg_match_all("/\d[^\s:]*/", $input, $results);
$results will look like this:
Array
(
[0] => Array
(
[0] => 0.0
[1] => 119
[2] => 0.8%
[3] => 226.04GB
[4] => 1
[5] => 4%
[6] => 0
[7] => 192.168.0.21
[8] => 0%
)
)
A sample regular expression that just grabs groups (untested):
System load: (\d+.\d) Processes: (\d+) Usage of /: (\d+.\d)% of (\w+) Users logged in: (\d+) Memory usage: (\d+%) IP address for eth0: (\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}) Swap usage: (\d+%) Graph this data and manage this system at https://landscape.canonical.com/
It's quite vulnerable to slight changes though, like extra spaces etc. It'd be much easier to just grab this information from different places, like df. Some even are available as standard PHP functions, like sys_getloadavg().
$str = 'System load: 0.0 Processes: 119 Usage of /: 0.8% of 226.04GB Users logged in: 1 Memory usage: 4% IP address for eth0: 192.168.0.21 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/';
$regex = '/^(?:System\s+load\:\s+)(\d+\.\d+)(?:\s+Processes\:\s+)(\d+)(?:\s+Usage\s+of\s+\/\:\s+)(\d+\.\d+\%\sof\s\d+\.\d+GB)(?:\s+Users\s+logged\s+in\:\s+)(\d+)(?:\s+Memory\s+usage\:\s+)(\d+\%)(?:\s+IP\s+address\s+for\s+eth\d+\:\s+)(\d+\.\d+\.\d+\.\d+)(?:\s+Swap\s+usage\:\s+)(\d+\%)(?:\s+Graph\s+this\s+data.+)$/';
preg_match_all($regex, $str, $x);
echo '<pre>'.print_r($x, 1);
don't worry about spaces ;)

Insert into array by spaces

I have this TXT file, which each line I would to insert into array, like this:
Array ( [0] => [1] => 8100 [2] => 623 [3] => 09:04 [4] => AM [5] => 00:26 [6] => L [7] => S-ED [8] => 768 [9] => #4506856439 [10] => 00:01 [11] => )
CO USER TIME DURATION TYPE ACCOUNT_CODE CALLED_NUM RING_TIME
8100 623 09:04 AM 00:26 L S-E 250821613987
8021 8816 09:06 AM 00:20 I S-E D 768 #4506856439 00:01
8020 09:06 AM I N D 603 #45424044499 00:30
8011 09:07 AM 00:11 I S-E D 727 #7546355292 00:02
" 8817 00:11
" 00:02 H
8100 623 09:07 AM 00:01 L S-E 5542204034
8007 8818 09:08 AM 00:13 I S-E D 618 #45269021726 00:01
8013 8811 09:09 AM 00:01 I S-E D 770 #436217227 00:01
8014 09:10 AM 00:16 I S-E D 652 #4523859922 00:01
I'd like to insert it into an array with all parameters, even if empty,
but I can't get it work.
I tried this:
$fh = fopen('captures/131210.txt','r');
while ($line = fgets($fh)) {
$tempexp = preg_split('/\s+/', $line);
print_r($tempexp);
echo "<br />";
}
fclose($fh)
But it gives out weird outputs for some values, like this:
Array ( [0] => [1] => " [2] => 8812 [3] => 00:16 [4] => )
Help would be much appreciated!
If the layout of your text file is purely based on spaces you can used the exact columns to extract the data. Since the columns are not of equal width you cannot simply write it in one loop.
Use the substr function to get part of the line (first number is index, second number is length to read)
$fh = fopen('captures/131210.txt','r');
while ($line = fgets($fh)) {
$co = substr($line, 0, 7);
$user = substr($line, 7, 6);
... etc ...
echo "<br />";
}
fclose($fh)
You might need to parse the separate parts further down dependent on the content and what you want to do with it - parse as integer, date, time etc.

Categories