|Re: [pdt-dev] PDT 2.0 and use of encodings for remote debug|
My initial thoughts are
for 1: have a dual byte string representation in the variable view for example (see screen shot - if it works :-) )
and for 2, I was thinking about having a data encoding preference as a first step and the ability to change that encoding for a string using a pop up menu item in the variables view in a later step.
transfer encoding remains the same but isn't used to decode php strings into java lang strings.
pdt-dev-bounces@xxxxxxxxxxx wrote on 06/08/2008 14:10:11:
> 2008/8/6 Dave Kelsey <d_kelsey@xxxxxxxxxx>
> 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 = "" 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
> pdt-dev-bounces@xxxxxxxxxxx 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 <d_kelsey@xxxxxxxxxx>
> > 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