Hi dazappa,

I'm not sure whether this is an HTML5 issue or an HTTP protocol issue. Either way, the pack('N' function performs a binary pack of a 32bit integer in big endian order.

If you know you're never going to deal with negative numbers then you can do this:-

Code:
result:=chr(data div 16777216)+chr(data div 65536)+chr(data div 256)+chr (data mod 256)
However, a safer alternative is this:-

Code:
result:=chr(data and $ff);
data:=data shr 8;
result:=chr(data and $ff)+result;
data:=data shr 8;
result:=chr(data and $ff)+result;
data:=data shr 8;
result:=chr(data and $ff)+result;
This should handle the packing of negative as the negative bit (2's compliment integers) will be shifted down to become just another character.

Using the example you gave, 259970620, this becomes $F7ED63C in hex. $7E = ~, $D6 = the O with umlaut (although exact representation seems to depend on character set), $3c becomes <. The leading $0f is obviously not visible as it's an ASCII control code.

The only other thing I'll say is to reiterate my opening... is this an HTTP protocol issue (in which case I'd use a ready made server such as the one that is supplied with Indy - I use it commercially and it's pretty dam good in terms of stability. When it gets a request you just get an event that provides the request and response objects and from there you can do pretty much anything) or is this an HTML5 issue (if so, I'm suprised they are wanting binary packed data like this... as I understand HTML it's meant to be plain text, certainly I've never had to handle binary data like this, then again, I haven't tinkered with HTML5, but I have tinkered at length with HTTP and previous HTML versions).

Hope this helps.