Hi,

2008/8/6 Dave Kelsey <[EMAIL PROTECTED]>

>
> Hi Michael, it looks like transfer encoding applies to things like stack
> frames as well for example. I see transfer encoding is the encoding to use
> when converting the binary wire data into java.lang.String so that is a
> fixed encoding that I would assume is agreed between the zend debugger and
> PDT when a debug session starts, and configurable by the user.
>
> The problem I see is that a PHP String can contain 2 types of data
>
> 1. Binary data - This cannot be converted to a java.lang.String so should
> have a useful representation within the eclipse variable view such as a byte
> presentation.
> 2. Character data = this should be converted to a java.lang.String based on
> the encoding this data is in. The question is what encoding is it in ? the
> php script knows and one solution could be for the user  to set the transfer
> encoding to the same as this in order to view it, but the transfer encoding
> is also used for other things so I am not sure that this encoding setting
> should be used for this purpose. Also the transfer encoding has a limited
> set of encodings allowed and what if the character data is in a Japanese
> code for example.


That's true (Eclipse limitation, I think), but the combo-box is editable and
one can enter in any encoding he likes.

>
> In the case of 1, a PHP string could have some child variables that
> represent the length and a byte array so that you can view the data as a
> byte array
> In the case of 2, there needs to be some sort of default for PHP String
> encodings and maybe the possibility of being able to override that default
> within the variables view in the small case where a php script may have
> multiple strings containing character data in different encodings.


If I understand correctly, do you propose configuration of transfer encoding
per file or even per variable? Won't it make the configuration more
difficult to user?


>
>
> I am currently looking to see how to address these problems for XDebug and
> think that the problem must also be common for the zend debugger as well and
> wondered if anything was being done in this area ? I don't think I will get
> around to solving 2, but I hope to solve 1 at least.
>
> Dave Kelsey
>
>
> [EMAIL PROTECTED] wrote on 06/08/2008 13:17:01:
>
>
> >
> > Hi,
> >
> > Output and Transfer encodings are only applied to variable and
> > output views. Besides that debug process should work as usual.
> > Is there any specific problem you see with variables containing binary
> data?
> >
> > Thanks!
>
> > 2008/8/6 Dave Kelsey <[EMAIL PROTECTED]>
> >
> > I am looking at the various areas where encoding applies and the
> > current configurable options available in PDT 2.0
> >
> > The output encoding looks like it only applies to output from the
> > php script which will be displayed in the Debug and Browser output views.
>
> >
> > The transfer encoding applies to the binary data that flows over the
> > wire (so must be in sync with the encoding used by the debug engine
> > when sending information such as stack frame names, variable names
> > etc). It also looks like the transfer encoding is used to convert
> > php string information to Java.lang.String for display in the
> > variables display.
> >
> > Is this correct ?
> >
> > One of the issues I have is that in php strings (ignoring php6 at
> > present) can contain binary or character data. The character data
> > and the encoding that correctly represents that data is known to the
> > php program and could very well be different to the transfer encoding.
> >
> > A Common problem I see for both Zend and XDebug debug environments
> > is a user may want to have a binary representation of a php string
> > in the debugger or may want to display the string based on a user
> > selected encoding.
> >
> > Is anyone looking at this issue for PDT 2.0 ? I haven't had the
> > opportunity to investigate it but it seems to me that the solution
> > should be common for any installed debugger.
> >
> > regards
> > Dave Kelsey
> >
> >
> >
> >
> >
>
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> >
> >
>
> >
> > _______________________________________________
> > pdt-dev mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
> >
> >
> >
> > --
> > Michael_______________________________________________
> > pdt-dev mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
>
>
>  ------------------------------
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
> _______________________________________________
> pdt-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/pdt-dev
>
>


-- 
Michael
_______________________________________________
pdt-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Reply via email to