Re: Routines for review: Hex <-> String
Re: Routines for review: Hex <-> String
- Subject: Re: Routines for review: Hex <-> String
- From: has <email@hidden>
- Date: Sun, 19 Jan 2003 22:48:00 +0000
Philip Aker wrote:
> StringToHex still has limits. It can't deal with >32k of text.
Somewhere in the execution of the do shell script. So if you need to
hex your logs you're going to have to tweek it.
Way cool guys.
</lurk>
Yes. Very promising.
Several points to add:
1. Always use 'quoted form' property of strings and unicode text:
on stringToHex(str)
do shell script ("echo -n " & (quoted form of str) & " |
hexdump -ve '1/1 \"X\"'")
end stringToHex
2. Bugs I've found in hexToString's perl script:
- currently it errors on anything in the 80-FF range
- invalid chars currently end up in result (these should be caught,
and a suitable error message raised)
3. Needs further testing (I only spent a couple of minutes and was
hardly thorough). e.g. What happens with values that are unicode
text/international text, especially ones containing extended
characters? Right now, these will be crunched to strings during
concatenation - what are the possible consequences of that? Any other
exciting ways these handlers could be broken?
4. Is 32K limit a shell thing, or a limitation of the 'do shell
script' command? (Anyone know?) If the latter, should really be filed
as an AS bug. Either way, not too hard to work around.
5. Proper parameter checking and sensible error reporting would be
very nice (yes it's pedantic, but a little extra work is worth it if
it means you can sleep safe at night).
Fix, test, debug; repeat until bombproof. Stick in a library,
document and release = very cool indeed.
Notes:
Quick test shows vanilla AS [1] is faster on strings up to ~150
characters/hex words (presumably due to initial overhead of using the
shell?). Could retain vanilla option for handling short strings - is
it worth it?
Anyone know if string<->integer and integer<->hex conversions can be
done in a similar way? (Given that the result of conversion to
integers would probably have to be in form of a string containing one
integer per line, rather than as a list of true integer values, to be
practical.)
<lurk>
has
[1] table lookup-based algorithms
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.