Most efficient way to pass PHP variables to external JavaScript (or jQuery) file

后端 未结 2 580
温柔的废话
温柔的废话 2021-01-13 07:16

I\'ve read several posts about the question and found this to be the simplest solution, here is my code:

js inside PHP code



        
相关标签:
2条回答
  • 2021-01-13 07:44

    About question 1: use JSON_HEX_TAG in json_encode()

    • Example 1
      Consider this simple piece of code.

      <script>
          <?php $myVarValue = 'hello world'; ?>
          var myvar = <?php echo json_encode($myVarValue); ?>;
          alert(myvar);
      </script>
      

      Output:

      <script>
          var myvar = "hello world";
          alert(myvar);
      </script>
      

      It alerts hello world. Good.

    • Example 2
      Let's try having </script> as the string.

      <script>
          <?php $myVarValue = '</script>'; ?>
          var myvar = <?php echo json_encode($myVarValue); ?>;
          alert(myvar);
      </script>
      

      Output:

      <script>
          var myvar = "<\/script>";
          alert(myvar);
      </script>
      

      It alerts </script>. Good.

      As you can see, the slash (/) is correctly escaped as \/,

    • Example 3
      Now, consider this very special string: <!--<script>

      <script>
          <?php $myVarValue = '<!--<script>'; ?>
          var myvar = <?php echo json_encode($myVarValue); ?>;
          alert(myvar);
      </script>
      

      Output:

      <script>
          var myvar = "<!--<script>";
          alert(myvar);
      </script>
      

      Surprisingly, it does not alert anything, and there's nothing in the error console. What?!

      If you check JSON's spec, none of the characters in <!--<script> need to be escaped, so what went wrong?

      Image adapted from json.org

    For a complete and well explained answer, read this amazing Q & A. In short, it turns out that having <!--<script> in a <script> block confuses the HTML parser. PHP actually did its job correctly in json_encode(); you just can't have a <!--<script> there, even though it is a perfectly valid JavaScript string!

    I did a few simple tests myself. The browsers actually ignore everything after <!--<script>, so if it happens in the middle of a page, the entire second half of the page is gone! I'm not sure if someone can actually inject something malicious there to, say, execute arbitrary code, but that's bad enough.

    Also,

    • If you have not just a string in $myVarValue, but a complex object like array("key" => array("one", "and<!--<script>two", 3)), which includes <!--<script>, it's still bad.
    • If you have a plain HTML file (i.e. no PHP) and you have <!--<script> anywhere (even in a JavaScript comment) in your <script> block, it's also bad.
    • If you are using other, non-PHP, server-side programming languages, and produced <!--<script>, it's bad too.
    • If your PHP is outputting JavaScript directly (Content-type: application/javascript), it's actually ok [1].

    The solution? Use JSON_HEX_TAG to escape < and > (requires PHP 5.3.0).

    <script>
        <?php $myVarValue = '<!--<script>'; ?>
        var myvar = <?php echo json_encode($myVarValue, JSON_HEX_TAG); ?>;
        //                                            ^^^^^^^^^^^^^^
        alert(myvar);
    </script>
    

    Output:

    <script>
        var myvar = "\u003C!--\u003Cscript\u003E";
        alert(myvar);
    </script>
    

    It alerts <!--<script>. Hurray!

    It works because there's no more <!--<script> in the output, so no more HTML parsing problems.

    Note: you don't need JSON_HEX_TAG if you're not printing into a <script> block.

    [1] Here, "ok" merely means it is free from the <!--<script> issue. Dynamically generating external JavaScript files is not recommended as it has tons of disadvantages, such as those stated here, here, here.


    About question 2: initial page load time

    Actually, it's rather obvious. If the time needed to obtain the value of $myVarValue is long (e.g. you're fetching lots of data from DB), PHP will have to wait, so is the browser, and the user. That means longer initial page load time. If you load the data later with Ajax instead, they won't have to wait to see the initial result, but then, the Ajax call would be an extra HTTP request, so it means more workload to the server, and more load to the network.

    Of course, each method has its pros and cons, so you have to decide. I suggest reading this excellent Q & A.

    0 讨论(0)
  • 2021-01-13 07:52

    Pretty sure that won't break it. The whole point of json_encode is that it's safe to dump.

    </script> might break it, but PHP escapes / as \/ by default so you shouldn't have to worry about it.

    0 讨论(0)
提交回复
热议问题