|HTTP Content Coding Token||gzip||deflate||compress|
|An encoding format produced by the file compression program "gzip" (GNU zip)||The "zlib" format as described in RFC 1950.||The encoding format produced by the common UNIX file compression program "compress".|
|Data Format||GZIP file format||ZLIB Compressed Data Format||The compress program's file format|
|Compression Method||Deflate compression method||LZW|
|Deflate consists of LZ77 and Huffman coding|
Compress doesn't seem to be supported by popular current browsers, possibly due to its past with patents.
Deflate isn't done correctly all the time. Some servers would send the deflate data format instead of the zlib data format and at least some versions of Internet Explorer expect deflate data format instead of zlib data format.
I built timestamp.exe, a Windows command line tool to convert between computer and human readable date/time formats mostly for working on the first run wizard for IE8. We commonly write out our dates in binary form to the registry and in order to test and debug my work it became useful to be able to determine to what date the binary value of a FILETIME or SYSTEMTIME corresponded or to produce my own binary value of a FILETIME and insert it into the registry.
For instance, to convert to a binary value:
[PS C:\] timestamp -inString 2009/08/28:10:18 -outHexValue -convert filetime 2009/08/28:10:18 as FILETIME: 00 7c c8 d1 c8 27 ca 01
Converting in the other direction, if you don't know what format the bytes are in, just feed them in and timestamp will try all conversions and list only the valid ones:
(it also supports OLE Dates, and SYSTEMTIME which aren't listed there because the hex value isn't valid for those types). Or use the guess option to get timestamp's best guess:
[PS C:\] timestamp -inHexValue "40 52 1c 3b" 40 52 1c 3b as FILETIME: 1601-01-01:00:01:39.171 40 52 1c 3b as Unix Time: 2001-06-05:03:30:08.000 40 52 1c 3b as DOS Time: 2009-08-28:10:18:00.000
[PS C:\] timestamp -inHexValue "40 52 1c 3b" -convert guess 40 52 1c 3b as DOS Time: 2009-08-28:10:18:00.000
When I first wrote this I had a bug in my function that parses the date-time value string in which I could parse 2009-07-02:10:18 just fine, but I wouldn't be able to parse 2009-09-02:10:18 correctly. This was my code:
See the problem?
success = swscanf_s(timeString, L"%hi%*[\\/- ,]%hi%*[\\/- ,]%hi%*[\\/- ,Tt:.]%hi%*[:.]%hi%*[:.]%hi%*[:.]%hi", &systemTime->wYear, &systemTime->wMonth, &systemTime->wDay, &systemTime->wHour, &systemTime->wMinute, &systemTime->wSecond, &systemTime->wMilliseconds) > 1;
This post is about creating a server side z-code interpreter that represents game progress in the URI. Try it with the game Lost Pig.
I enjoy working on URIs and have the mug to prove it. Along those lines I've combined thoughts on URIs with interactive fiction. I have a limited amount of experience with Inform which generates Z-Code so I'll focus on pieces written in that. Of course we can already have URIs identifying the Z-Code files themselves, but I want URIs to identify my place in a piece of interactive fiction. The proper way to do this would be to give Z-Code its own mimetype and associate with that mimetype the format of a fragment that would contain the save state of user's interactive fiction session. A user would install a browser plugin that would generate URIs containing the appropriate fragment while you play the IF piece and be able to load URIs identifying Z-Code files and load the save state that appears in the fragment.
But all of that would be a lot of work, so I made a server side version that approximates this. On the Web Frotz Interpreter page, enter the URI of a Z-Code file to start a game. Enter your commands into the input text box at the bottom and you get a new URI after every command. For example, here's the beginning of Zork. I'm running a slightly modified version of the Unix version of Frotz. Baf's Guide to the IF Archive has lists of IF games to try out.
There are two issues with this thought, the first being the security issues with running arbitrary z-code and the second is the practical URI length limit of about 2K in IE. From the Z-Code standard and the Frotz source it looks like 'save' and 'restore' are the only commands that could do anything interesting outside of the Z-Code virtual machine. As for the length-limit on URIs I'm not sure that much can be done about that. I'm using a base64 encoded copy of the compressed input stream in the URI now. Switching to the actual save state might be smaller after enough user input.
"Don't Tase Me, Bro!" (UF Student Tasered Remix)
Remix of the 'Don't tase me, bro!' guy getting tasered.At this point I'm already not going to use this file because its in HTML but I'm even more disgusted by those date time values. Raymond Chen of the Old New Thing posted about recognizing timestamps and timestamp sentinel values. From the first blog post and with the use of a calculator for base conversion one can tell that those are UNIX style timestamps counting the number of seconds since 1970.
Thu, 27 Sep 2007 20:50:00 -0800