Bug 144548 - I18N - local variables don't show ok if multibyte characters used as values
I18N - local variables don't show ok if multibyte characters used as values
Status: RESOLVED FIXED
Product: php
Classification: Unclassified
Component: Debugger
6.x
PC Windows XP
: P2 with 3 votes (vote)
: 7.0
Assigned To: Ondrej Brejla
issues@php
JA_COMMUNITY
: 70_HR_FIX, I18N
: 197351 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-20 10:12 UTC by luwei
Modified: 2011-07-28 11:34 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description luwei 2008-08-20 10:12:15 UTC
I new a php project default encoding set to utf-8 .when debuging a php file,all php local variable value can not display
properly for chinese charset string as the main editor can.
Is this a bug ? or i can find and change some options somewhere to display my string debuging value  properly
Comment 1 Ken Frank 2008-08-25 16:07:23 UTC
could you attach a gif of the editor showing incorrect display of the values
and also php file with the kind of code  you are using ?

also, where does the variables value not display ok - is it in the debugger window ?

finally what platform are you on and what is the locale or regional settings you are using ?

ken.frank@sun.com
Comment 2 Ken Frank 2008-08-25 22:39:59 UTC
confirming this is seen on windows.

this is not about name of the variable or other programattic/lanaguage 
types being in multibyte - this is just about the values, and that
seems to be allowed (we've already discussed in other issues that for php
use of non ascii not supported in names of variables, or project names,paths.

the value does show ok in editor and in browser when php is run.

and when project encoding property is the default encoding of the locale, in my 
case win31j, the variable values show ok in local vars window
(issue filer sees it using default utf-8 project encoding)

thus its probably related to encoding assumptions being used.

this probably should be p2 since it is about actual data.

ken.frank@sun.com
Comment 4 Quality Engineering 2009-04-15 07:48:19 UTC
Integrated into 'main-golden', will be available in build *200904150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/494788efc282
User: Radek Matous <rmatous@netbeans.org>
Log: #144548 I18N - local variables don't show ok if multibyte characters used as values
Comment 5 Masaki Katakai 2009-06-01 08:14:26 UTC
Still reproducible on 6.7 beta and latest dev build.
Set source encoding to UTF-8 and run on Windows (SJIS).

Screenshot:
http://ja.netbeans.org/servlets/GetAttachment?list=netcat67&msgId=2038060&attachId=1

NetBeans IDE 6.7 Beta (Build 200904242137)
Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02
Windows XP 5.1; MS932; ja_JP (nb)

NetBeans IDE Dev (Build 200905291401)
Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02
Windows XP 5.1; MS932; ja_JP (nb)

I have a question: in the fix 

http://hg.netbeans.org/web-main/rev/494788efc282

It seems that just using "UTF-8".

+            is.setEncoding("UTF-8");

Shouldn't we consider source encoding of project here?
Users would be able to set any encoding other than UTF-8.

Comment 6 Filip Zamboj 2010-09-15 12:26:21 UTC
batch reassigning
Comment 7 OndrejBrejla 2011-03-29 10:30:19 UTC
Fixed in web-main: http://hg.netbeans.org/web-main/rev/e5416424aa33
Comment 8 Quality Engineering 2011-03-30 08:43:45 UTC
Integrated into 'main-golden', will be available in build *201103300400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e5416424aa33
User: Ondrej Brejla <OndrejBrejla@netbeans.org>
Log: #144548 - I18N - local variables don't show ok if multibyte characters used as values
Comment 9 OndrejBrejla 2011-04-03 11:46:14 UTC
*** Bug 197351 has been marked as a duplicate of this bug. ***
Comment 10 Petr Pisl 2011-04-03 20:28:32 UTC
Ondro, do you think that the fix is safe to transplant into NB 7.0?
Comment 11 OndrejBrejla 2011-04-04 08:18:36 UTC
I think that it's safe and that there are no threats. If a problem occurs during fetching the debug session for runtime options (with a project encoding), there is a fallback to the same behaviour which worked before the fixation.
Comment 12 OndrejBrejla 2011-04-04 08:58:59 UTC
I would like to transplat the fix into 7.0. Could I ask QE for testing? Thanks.
Comment 13 Marian Mirilovic 2011-04-04 14:04:47 UTC
(In reply to comment #12)
> I would like to transplat the fix into 7.0. Could I ask QE for testing? Thanks.

Hmm, was a P3 for long time, without any escalation. I think we can release 70 without this fix and let it integrated into 7.0.1.
Comment 14 Petr Pisl 2011-04-04 14:20:21 UTC
The bug has 3 votes and at least one duplicate. If it will not be a pat of NB 7.0 it will be part of the next release.
Comment 15 Petr Pisl 2011-04-04 15:02:58 UTC
This an email that I have received a while ago from Petr Ungern:

--------------------------------------------------------------
Sorry that I comment on this bug. Its real not convenient if debug values are not readable, and as it is fixed in this present development version, it would be real good to have it in 7.0, and not in any later coming version. NB is not only used by plain English users...  
--------------------------------------------------------------



Personally I think that the fix should go to the NB 7.0, if the fix is save. There are many people who use the PHP with different encoding.
Comment 16 webfox 2011-04-04 15:42:48 UTC
I love NB, and if multibyte characters are unreadable displayed in debugging then its real not very helpful. I tested this latest development version (Ondrej recommended me to test it) extensive, and it works extremely fine. Would real appreciate if this fixed bug would be in NB 7.0, as otherwise I would have to stick to this development version, instate to use 7.0 containing still this bug, and to wait for an NB version that fix it. Debugging in different UTF encodings is important for me and I guess a lot other users. Hope that NB 7.0 will contain this fix. Thanks for your attention.
Comment 17 Masaki Katakai 2011-04-05 01:46:55 UTC
As I remember correctly, I got at least 4 questions about this issue on the local mailing list in Japan since NetBeans began to support PHP. Windows is one of the major development platforms so most PHP developers using NetBeans meet this issue.
Comment 18 Marian Mirilovic 2011-04-05 07:12:43 UTC
Ok, I see your arguments, just do not understand why this issue got fixed so late in release cycle ? 

Anyway, I agree with integration into release70 TODAY, BUT I would like to ask all participants to test the bits for potential regressions once RC2 build is out. Thanks in advance.
Comment 19 Petr Pisl 2011-04-05 14:44:27 UTC
I have just transplanted Ondra's fix into release70. 

The answer for question, why it's fixed so late, it easy. Resources. It was P3 and I don't have time even evaluate the P3 bugs. I'm still solving P1 and P2. Thanks Ondra to helping with issues.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo