This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 139480 - I18N - php standalone file does not have encoding tag
Summary: I18N - php standalone file does not have encoding tag
Status: RESOLVED INVALID
Alias: None
Product: php
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: Sun All
: P2 blocker (vote)
Assignee: Tomas Mysik
URL:
Keywords: I18N
Depends on:
Blocks:
 
Reported: 2008-07-09 20:12 UTC by Ken Frank
Modified: 2008-07-25 21:00 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2008-07-09 20:12:46 UTC
a standalone php file can be created and run; thus it seems that, just like
for standalone html or jsp or xml files, an encoding/charset kind of tag
should be part of the template and seeded with project encoding value and use feq.
(php web page is seeded with charset tag with project encoding value)
Comment 1 Ken Frank 2008-07-14 19:46:24 UTC
when add
(header ('Content-type: text/html; charset="euc-jp"');
for example, to this standalone file,
when run it, it seems to do right thing as to setting
browser encoding.

but seems it should be added for user, just as such
tags for new html, xml and jsp files are added for
user.

ken.frank@sun.com
Comment 2 Tomas Mysik 2008-07-25 10:13:16 UTC
Definitely not because

> header ('Content-type: text/html; charset="euc-jp"')

does exactly what you can read - sends a raw HTTP header. There's no relation between HTTP and script files.

Other thing is that you _cannot_ know whether this file is included in other PHP file or not.
Comment 3 Ken Frank 2008-07-25 17:41:07 UTC
I'm not clear - is the statement that php standalone files should not have en encoding
kind of tag - that perhaps the comparison used with html, jsp, xml files might not be
valid in php world ?  please clarify.

also, if so, then what is requirement for user who uses non ascii in this file and chooses
to run it - they won't see their characters ok, whereas users who use ascii only will - 
this seems discriminating to the users.  if we provide a run funtionality for standalone file
it should work for all users ?

please reopen as needed or explain why it should not be.

ken.frank@sun.com
Comment 4 Tomas Mysik 2008-07-25 18:58:11 UTC
> I'm not clear - is the statement that php standalone files should not have en encoding
> kind of tag - that perhaps the comparison used with html, jsp, xml files might not be
> valid in php world

If you have a PHP file (no HTML) then IDE cannot help much. Such PHP script is similar to shell scripts and so it is 
up to user what output the script produces, which encoding he uses in console etc.
Comment 5 Ken Frank 2008-07-25 19:57:30 UTC
but the ide or php code should help/do the right thing - since this is a php nb
functionality to run the file - and this can be done for some other file types
of other projects

will retry to see if run php file to show in ow or web page
is ok without need for any encoding tag, and will reopen if not
since php module should handle encoding to allow it to happen.

ken.frank@sun.com
Comment 6 Tomas Mysik 2008-07-25 20:24:31 UTC
Sorry, but still not clear what "the right thing" means - how can NB find out what is it? Does it mean that NB should 
e.g. connect to user's database and find out the encoding of data and then somehow change user's code? Or try to 
recognize whether the currently edited file is a script for console or just some fragment which will be included in 
some other PHP script in runtime? How?? As I said, not sure what you mean by this term.
Comment 7 Ken Frank 2008-07-25 21:00:39 UTC
good points about scope of it -

am actually just talking now about simple print of a string to the ow

since if it worked in that case, it would mean at least that the correct
encoding is being communicated - just like in a html file or jsp file,
there is just one meta charset or page encoding statement at beginning of file
and that assumption is used thruout.

the reason i had mentioned in this issue about adding
header ('Content-type: text/html; charset="euc-jp"'); (or some encoding value)
is that in some mail communication with php alias, it was mentioned to try
this in php file to see if it solved the problem of this issue as to
the print of some mbyte in standalone php file not working
but you mentioned here that is not valid approach at least for this case
(ie to seed the php file with that statement, and since also it could conflict
with such statements of encoding in other php or html files)

ken.frank@sun.com