Path: csiph.com!news.mixmin.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups: comp.lang.javascript
Subject: Re: How to pass a php variable to a javascript file (function)?
Date: Fri, 02 Oct 2015 21:37:50 +0200
Organization: PointedEars Software (PES)
Lines: 106
Message-ID: <1739227.XXYPReGQTy@PointedEars.de>
References: <r6jPx.32747$nl4.14152@fx02.am4> <XnsA5276328DD4DEeejj99@194.109.6.166> <mulldu$lli$1@news.albasani.net>
Reply-To: Thomas 'PointedEars' Lahn <cljs@PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
X-Trace: solani.org 1443814672 31066 eJwNwoERACEIA7CVACnqOHyv7D+CfwlWeXFnoRLzoyDC5jKljoZrceGiT4S186ht/HB/HqYHLpgRfA== (2 Oct 2015 19:37:52 GMT)
X-Complaints-To: abuse@news.solani.org
NNTP-Posting-Date: Fri, 2 Oct 2015 19:37:52 +0000 (UTC)
User-Agent: KNode/4.14.2
X-User-ID: eJwFwQERADEIAzBLz61AkTMG9S/hEz9h8RLhAZeLQk61Nm5DS26d/mBPhPytvqPutUlN3gVtqA45abVWP4v5FuA=
Cancel-Lock: sha1:13P2yibewUPzv/3pn/m6SqQwwsU=
X-NNTP-Posting-Host: eJwFwQERADEIAzBLHVBG5ezg8S/hE3qe7BvJDC5XwbJ4ektgoKkLbenAQGRL4/X5HOvnjP0B/bQQHA==
Xref: csiph.com comp.lang.javascript:28795

Stefan Weiss wrote:

> On 2015-10-02 09:44, Evertjan. wrote:
>>>              var some_string = <?php echo json_encode($sometext); ?>;
>> 
>> This is totally errorprone, you need to enclose the litteral string in
>> '-s or "-s, ensuring that the ones used do not appear in the inner text.
> 
> No, json_encode() already takes care of quoting and character escaping;
> adding extra quotes around the result would be a syntax error.

ACK.
 
> That doesn't mean that json_encode() by itself is enough to safely
> escape strings as JavaScript literals. What if $sometext contains
> "</script>"?

Not a problem in HTML5 or XHTML(5), but in HTML < 5.
 
> What actually has to be escaped - in addition to characters like quotes,
> newlines, etc - depends on which HTML version is used.
> For HTML5, the process and some pitfalls are described here:
> http://www.w3.org/TR/html5/scripting-1.html#restrictions-for-contents-of-script-elements
> 
> Short version:
> 
> | Note: The easiest and safest way to avoid the rather strange
> | restrictions described in this section is to always escape "<!--" as
> | "<\!--", "<script" as "<\script", and "</script" as "<\/script"  […]

And it is wrong *again* (see below).  For example, if you had a RegExp 
literal in your ECMAScript or Perl code to match “<script” (which as for 
ECMAScript code can be useful for retrieving embedded data), which would 
likely be /<script…/, then changing that to /<\script…/ would attempt to 
match “<”, followed by ECMAScript/Perl whitespace, followed by “cript…” 
instead.

For another example, as can be seen further below that note, the HTML5 
Specification (fortunately) does not even define syntax that would require 
“</script>” in a “script” element to be escaped in any way:

| script        = outer *( comment-open inner comment-close outer )
| 
| outer         = < any string that doesn't contain a substring that matches 
| not-in-outer >
| not-in-outer  = comment-open
| inner         = < any string that doesn't contain a substring that matches 
| not-in-inner >
| not-in-inner  = comment-close / script-open

(No “script-close” there.)

Presumably, this part of the note incorporates escape recommendations for 
HTML < 5, where the CDATA content of a SCRIPT element would end when the SGL 
parser encountered “</” (ETAGO) as it claims that “for historical reasons, 
parsing of script blocks in HTML is a strange and exotic practice that acts 
unintuitively in the face of these sequences.”

Which *actually* means: The authors of this paragraph did not know what the 
hell they were doing back then [when they wrote or read the HTML 4.01 
Specification], they still do not know, and they are projecting that on 
their unfortunate readership.  The record shows that one cannot trust the 
authors of HTML Specifications regarding advice relevant to Web programming 
languages, in particular ECMAScript implementations.  (Fortunately, as 
always, Notes are not normative.)

In fact, the easiest and safest way to avoid the issue is to put the script 
code in a separate file, and use the “src” attribute of the “script” element 
to include the corresponding resource.  Yes, that means another request, but 
you can’t have everything.

>>> So in doSomething I want to be able to use this some_string created in
>>> php file. How can I do it?
>> So you cannot.
>> 
>> Why don't you create that string on the "index.html" PAGE,
>> that you probably will have to rename to "index.php".
> 
> Thats one way to do it. Unfortunately, we don't know enough about OP's
> project to give any meaningful advice. For example, if we knew that
> `some_string` is relatively short, we could suggest passing it along to
> index.html in the query string.
> 
>   location.href = "index.html?s=" + encodeURIComponent(some_string);
> 
> The script included from index.html could then read it back from the
> query string.

It is important to emphasize “relatively short”, because this approach is 
subject to IE URL length limits which can be easily exceeded if the argument 
to encodeURIComponent() contains Unicode characters with code points beyond 
the US-ASCII range (as URI percent-encoding is UTF-8 based).
 
> In general, mixing dynamic and static files (PHP and plain HTML) like
> this tends to get messy.

It depends on the application.  There is no good reason that PHP should 
parse files in which there are no proper PHP sections, and every reason to 
avoid that.  But doing things client-side that can be done server-side is 
often not the correct approach.

-- 
PointedEars (Zend Certified PHP Engineer)
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.