I am writing a wrapper library for WIM files (long story), but I have been having difficulty with the dates encoded in it. The format is:
[creationtime] => Array
(
[highpart] => 0x01CA0446
[lowpart] => 0x8E44DCAF
)
This format is inside the WIM file XML.
I have tried every date decoding technique I can think of!
Any ideas would be much appreciated.
The only things I have to go on are things related to Long Integers and WIN32 DateTime... But no luck so far.
liCreationTime is defined as LARGE_INTEGER in the WIM spec (I downloaded from MS)
This looked to me like it would be similar (if not the same) as a timestamp returned by QueryPerformanceCounter - which thankfully makes things very simple!
I did this using a calculator and command line PHP, you'll have to implement the code yourself.
Take your high and low parts and turn them into a single 64bit value.
0x01CA04468E44DCAF -> 128920240414579887
Divide that by 100000000
1289202404
Use it as the input to date()
php -r "var_dump(date('Y-m-d H:i:s', 1289202404));"
string(19) "2010-11-08 07:46:44"
Edit:
Or maybe I just got lucky.
If it is the number of nanoseconds since 1601, as other answers seem to indicate, you can use a slightly different calculation.
php -r "var_dump(date('Y-m-d H:i:s', (128920240414579887/100000000)-41651963));"
string(19) "2009-07-14 05:47:21"
I believe they might be something to do with the c/c++ FILETIME structure
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx
Related
Originally, I had the problem that, although I had the same path by optical inspection, file_exists() returned true for one and false for the other. After spending hours narrowing down my problem, I wound up with the following code... (paths redacted)
$myCorePath = $modx->getOption('my.core_path', null, $modx->getOption('core_path').'components/my/');
$pkg1 = $myCorePath.'model/';
$pkg2 = MODX_CORE_PATH . 'components/my/model/';
$pkg3 = '/path/to/modx/core/components/my/model/';
var_dump($pkg1, $pkg2, $pkg3);
...and its output:
string '/path/to/modx/core/components/my/model/' (length=37)
string '/path/to/modx/core/components/my/model/' (length=78)
string '/path/to/modx/core/components/my/model/' (length=78)
So two versions, interestingly including simply writing the string down, apparently use wide characters (these worked, file_exists()-wise), while sadly my preferred variant uses narrow characters. I tried to research this but the only thing I wound up with told me that php has no such thing as wide strings. I also verified with a hex editor that all string constants really only take one byte per character in the php file.
phpinfo() tells me I have PHP Version 5.4.9, and I run on a 64 bit linux machine, fwiw. The manual was edited a week ago; is its info not accurate, or what's going on here?
I think it is caused by multibyte coding.
Ok this relates to another question I have asked but as I have now pinpointed
the issue I thought it would be clearer on a new question.
The problem I am having relates to strtotime under PHP 4.4
I have a larger script that is failing under PHP 4.4 but works under PHP 5+
To check it was this I wrote the following and copied it to two servers one
running PHP 4.4 and the other PHP 5.3.
<?php
$my_time = '2013-03-18T21:38:58.000Z';
$my_time = strtotime($my_time);
echo $my_time;
?>
The output under PHP 4.4 was: -1
The output under PHP 5.3 was: 1363642738
Is there a way to get the same result under PHP 4.4 as 5.3??
Thanks in advance for any help!
-1 was the failure code for PHP < 5.1. This makes me think that PHP 4 can't parse that string.
This means you'll have to use a format both versions support. As a hack, you could do some string manipulation. If you can change the format of the string though, that's your best route. (Actually, your best route is to run the hell away from PHP 4.)
I don't have an installation of PHP 4 to test with, but try removing the .000Z from the end, all the examples on the strtotime page on PHP.net don't have that bit PHP 4.4 may not support it.
If that works ultimately you can parse any time stamps with a substr($my_time, 0, 19)
I'm looking for an free php library that can generate code diff HTML. Basically just like GitHub's code diffs pages.
I've been searching all around and can't find anything. Does anyone know of anything out there that does what I'm looking for?
It looks like I found what I'm looking for after doing more Google searches with different wording.
php-diff seems to do exactly what I want. Just a php function that accepts two strings and generates all the HTML do display the diff in a web page.
To add my two cents here...
Unfortunately, there are no really good diff libraries for displaying/generating diffs in PHP. That said, I recently did find a circuitous way to do this using PHP. The solution involved:
A pure JavaScript approach for rendering the Diff
Shelling out to git with PHP to generate the Diff to render
First, there is an excellent JavaScript library for rendering GitHub-style diffs called diff2html. This renders diffs very cleanly and with modern styling. However diff2html requires a true git diff to render as it is intended to literally render git diffs--just like GitHub.
If we let diff2html handle the rendering of the diff, then all we have left to do is create the git diff to have it render.
To do that in PHP, you can shell out to the local git binary running on the server. You can use git to calculate a diff on two arbitrary files using the --no-index option. You can also specify how many lines before/after the found diffs to return with the -U option.
On the server it would look something like this:
// File names to save data to diff in
$leftFile = '/tmp/fileA.txt';
$rightFile = '/tmp/fileB.txt';
file_put_contents($leftFile, $leftData);
file_put_contents($rightFile, $rightData);
// Generate git diff and save shell output
$diff = shell_exec("git diff -U1000 --no-index $leftFile $rightFile");
// Strip off first line of output
$diff = substr($diff, strpos($diff, "\n"));
// Delete the files we just created
unlink($leftFile);
unlink($rightFile);
Then you need to get $diff back to the front-end. You should review the docs for diff2html but the end result will look something like this in JavaScript (assuming you pass $diff as diffString):
function renderDiff(el, diffString) {
var diff2htmlUi = new Diff2HtmlUI({diff: diffString});
diff2htmlUi.draw(el);
}
I think what you're looking for is xdiff.
xdiff extension enables you to create and apply patch files containing differences between different revisions of files.
This extension supports two modes of operation - on strings and on files, as well as two different patch formats - unified and binary. Unified patches are excellent for text files as they are human-readable and easy to review. For binary files like archives or images, binary patches will be adequate choice as they are binary safe and handle non-printable characters well.
I'm currently successfully reading out several properties on our switches over SNMP with php. Now i'm looking at making the resulting output of snmpget and snmpwalk actually usefull for the consumers of our API's.
Problem is that the responses look like this: INTEGER: up(1) and INTEGER: 10103 ...
Is there any convention/standard on how to parse this response format or is the response vendor specific for each device we are trying to read?
Is there by any chance already a PHP library, function or extension that can cast these responses in php native variables or at least something usefull that we can work with?
UPDATE:
I've found out a few new things namely that there are indeed several libraries in php that can parse binary ASN.1 strings which basically are BER encoded strings if i'm right. Problem is that i can't seem to find a way to get the binary data from the devices with php ...
You can simply use this function at the beginning of your script :
snmp_set_quick_print(TRUE);
It will returns only the value you are searching for, without the leading "INTEGER" or so ;)
Hope this helps !
I'm not sure about your particular PHP methods, but the difference between your two INTEGER examples is likely to be whether your system has an SNMP MIB corresponding to the OID (e.g. to determine that 1 means "up").
If you only want the integers, you should be able to pass a parameter to your get or walk command. For example, net-snmp's snmpget or snmpwalk commands will take -Oe to remove symbolic labels. From the manpage:
$ snmpget -c public -v 1 localhost ipForwarding.0
IP-MIB::ipForwarding.0 = INTEGER: forwarding(1)
$ snmpget -c public -v 1 -Oe localhost ipForwarding.0
IP-MIB::ipForwarding.0 = INTEGER: 1
If you are parsing net-snmp output, I recommend reading the snmpcmd man page as it has a lot of output options that will interest you especially the display of other types such as timeticks and strings.
If you do want to retrieve SNMP in PHP you could look at how Cacti does it.
I have a PHP script that builds a binary search tree over a rather large CSV file (5MB+). This is nice and all, but it takes about 3 seconds to read/parse/index the file.
Now I thought I could use serialize() and unserialize() to quicken the process. When the CSV file has not changed in the meantime, there is no point in parsing it again.
To my horror I find that calling serialize() on my index object takes 5 seconds and produces a huge (19MB) text file, whereas unserialize() takes unbearable 27 seconds to read it back. Improvements look a bit different. ;-)
So - is there a faster mechanism to store/restore large object graphs to/from disk in PHP?
(To clarify: I'm looking for something that takes significantly less than the aforementioned 3 seconds to do the de-serialization job.)
var_export should be lots faster as PHP won't have to process the string at all:
// export the process CSV to export.php
$php_array = read_parse_and_index_csv($csv); // takes 3 seconds
$export = var_export($php_array, true);
file_put_contents('export.php', '<?php $php_array = ' . $export . '; ?>');
Then include export.php when you need it:
include 'export.php';
Depending on your web server set up, you may have to chmod export.php to make it executable first.
Try igbinary...did wonders for me:
http://pecl.php.net/package/igbinary
First you have to change the way your program works. divide CSV file to smaller chunks. This is an IP datastore i assume. .
Convert all IP addresses to integer or long.
So if a query comes you can know which part to look.
There are <?php ip2long() /* and */ long2ip(); functions to do this.
So 0 to 2^32 convert all IP addresses into 5000K/50K total 100 smaller files.
This approach brings you quicker serialization.
Think smart, code tidy ;)
It seems that the answer to your question is no.
Even if you discover a "binary serialization format" option most likely even that would be to slow for what you envisage.
So, what you may have to look into using (as others have mentioned) is a database, memcached, or on online web service.
I'd like to add the following ideas as well:
caching of requests/responses
your PHP script does not shutdown but becomes a network server to answer queries
or, dare I say it, change the data structure and method of query you are currently using
i see two options here
string serialization, in the simplest form something like
write => implode("\x01", (array) $node);
read => explode() + $node->payload = $a[0]; $node->value = $a[1] etc
binary serialization with pack()
write => pack("fnna*", $node->value, $node->le, $node->ri, $node->payload);
read => $node = (object) unpack("fvalue/nre/nli/a*payload", $data);
It would be interesting to benchmark both options and compare the results.
If you want speed, writing to or reading from the file system in less than optimal.
In most cases, a database server will be able to store and retrieve data much more efficiently than a PHP script that is reading/writing files.
Another possibility would be something like Memcached.
Object serialization is not known for its performance but for its ease of use and it's definitely not suited to handle large amounts of data.
SQLite comes with PHP, you could use that as your database. Otherwise you could try using sessions, then you don't have to serialize anything, you just saving the raw PHP object.
What about using something like JSON for a format for storing/loading the data? I have no idea how fast the JSON parser is in PHP, but it's usually a fast operation in most languages and it's a lightweight format.
http://php.net/manual/en/book.json.php