[UPHPU] encoding help....

Justin Purdie jpurdie at skyvantage.com
Wed Jul 25 09:42:12 MDT 2012


I know... I feel like I'm two steps away from coding binary :-)

Walt, Thanks for the ideas... I think you're on to something.... I'm
getting some response like  \x01\xfe\x00\x0a\x04

Let me play around with your suggestions, and I'll let you know what I turn
up.


Justin Purdie
SkyVantage Development
US Ph. +1-801-649-2925 option 305
US Fax. +1-419-828-6643
Skype (Calls only - no chat): skyvantage
Email: support at skyvantage.com
twitter:  http://twitter.com/skyvantage
facebook: http://www.facebook.com/SkyVantage

---
This message may contain confidential and/or privileged information of
SkyVantage Corporation and  its affiliated companies.  If you are not the
intended recipient, please (i) do not disclose,  copy, distribute, or use
this information, (ii) advise the sender by return e-mail, and (iii)
delete  all copies from your computer.  Your cooperation is greatly
appreciated.


On Wed, Jul 25, 2012 at 9:31 AM, Walt Haas <haas at xmission.com> wrote:

> Oops, make that:
>
> $record = '\x03\xFE\x00\x06\x03...'
>
> On 07/25/2012 09:13 AM, Walt Haas wrote:
> > How about a string of 6 or 10 hex characters, something like:
> >
> > $record = '\03\FE\00\06\03...'
> >
> > or whatever.  If you use fwrite() to output the string, it should pick
> > up the length automatically, or you can set the length as the third
> > argument of fwrite().
> >
> > Need to be careful about whether the output is big-endian or
> little-endian.
> >
> > My, this does take me back ... :-)
> >
> > -- Walt
> >
> >
> > On 07/25/2012 09:04 AM, Walt Haas wrote:
> >> Well, you could encode it as a hex integer, but that would be 8 bytes
> >> unless you use the arbitrary precision arithmetic.  Or you could
> >> represent it internally as a collection of integers.  My question is,
> >> what will you do with it after you have the 80 characters?  I haven't
> >> seen a key punch for a while :-)
> >>
> >> -- Walt
> >>
> >>
> >> On 07/25/2012 08:48 AM, Justin Purdie wrote:
> >>> I'm working on a project where I need to integrate with some older
> tech.
> >>>
> >>> I've been given a specification in which I need to build a string
> following
> >>> this format:
> >>>
> >>>
> >>>          0                   1                   2                   3
> >>>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
> >>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>         |0|0|0|0|0| Ver |1|1 1 1 1 1 1 0|            length
>   |
> >>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>         |0 0 0 0 0| C D | PROTEC| BFLAG |          Sender HLD
>   |
> >>>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>         |       Recipient HLD           |
> >>>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>       Length
> >>>       This field indicates the number of bytes of the whole command,
> header
> >>>
> >>>       included. The only possible values are equal to 6 bytes or 10
> bytes.
> >>>
> >>> Elsewhere in the docs, the "CD" field (the other fields are irrelevant
> for
> >>> my question) is mapped to :
> >>>
> >>>     CD
> >>>       This field specifies the Coding
> >>>          000 : 5 bits (padded baudot)
> >>>          010 : 6 bits (IPARS)
> >>>          100 : 7 bits (ASCII)
> >>>          110 : 8 bits (EBCDIC)
> >>>
> >>>          xx1 : R.F.U
> >>>
> >>>
> >>> My question is, what format/encoding allows that string of 80
> characters to
> >>> be 6 or 10 bytes. None of those encodings seem to give me the right
> byte
> >>> size, everything comes out to be more. Does anyone have any insight on
> this?
> >>>
> >>> Any help is appreciated (tuxtoaster I'm looking at you). Thanks in
> advance.
> >>>
> >>>
> >>> Justin Purdie
> >>> SkyVantage Development
> >>> US Ph. +1-801-649-2925 option 305
> >>> US Fax. +1-419-828-6643
> >>> Skype (Calls only - no chat): skyvantage
> >>> Email: support at skyvantage.com
> >>> twitter:  http://twitter.com/skyvantage
> >>> facebook: http://www.facebook.com/SkyVantage
> >>>
> >>> ---
> >>> This message may contain confidential and/or privileged information of
> >>> SkyVantage Corporation and  its affiliated companies.  If you are not
> the
> >>> intended recipient, please (i) do not disclose,  copy, distribute, or
> use
> >>> this information, (ii) advise the sender by return e-mail, and (iii)
> >>> delete  all copies from your computer.  Your cooperation is greatly
> >>> appreciated.
> >>>
> >>> _______________________________________________
> >>>
> >>> UPHPU mailing list
> >>> UPHPU at uphpu.org
> >>> http://uphpu.org/mailman/listinfo/uphpu
> >>> IRC: #uphpu on irc.freenode.net
> >>
> >>
> >> _______________________________________________
> >>
> >> UPHPU mailing list
> >> UPHPU at uphpu.org
> >> http://uphpu.org/mailman/listinfo/uphpu
> >> IRC: #uphpu on irc.freenode.net
> >
> >
> > _______________________________________________
> >
> > UPHPU mailing list
> > UPHPU at uphpu.org
> > http://uphpu.org/mailman/listinfo/uphpu
> > IRC: #uphpu on irc.freenode.net
>
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>


More information about the UPHPU mailing list