note 124655 added to faq.html

The scenario: 1. There is a php script which (possibly complemented by a direct written HTML code) consrtucts a HTML page via its echo command, based on whatever algoritmus eventually based on supplementary data from server files or databases. 2. This php script leads to data being saved into string variable(s), which (possibly) can contain arbitrary characters, including control codes (newline, tab...), HTML special characters (&,<...) and non-ASCII (international) characters. 3. These non-ASCII characters are UTF-8 encoded, as well as the HTML page (I do highly recommend) *) 4. The values of these PHP string variables have to be transferred into javascript variables for further processing by javascript (or exposing these values in HTML directly) The problem: it is not safe to PHP-echo such variables into HTML (javascript) directly, because some of characters possily contained in them cause malfunction of the HTML. These strings need some encoding/escaping in order to become strings of non-conflicting characters The solution There may be a big lot of ways of this encoding. The following one seems to me the easiest one: The PHP variable with unpredictable value can originate from some file, as an example (or from user input as well): $variable=file_get_content(...) 1. Convert all bytes of that string into hex values and prepend all hex-digit-pairs with % $variable_e=preg_replace("/(..)/","%$1",bin2hex($variable)) The new variable is now guarantied to contain only %1234567890abcdefABCDEF chracters (e.g. %61%63%0a...) and can safely be directly echoed into HTML: var variable="<?php echo $variable_e;?>" //that's NOT all folks But now the value is still encoded. To get the original value of the variable, it has te be decoded: *) var variable=decodeURIComponent("<?php echo $variable_e;?>") The value of the variable is now the same as the original value. *) I have no idea about non-UTF-8 encoded pages/data, espetially how the decodeURIComponent works in such a case, because i have no reason to use other encodings and handle them as highly deprecatad. WARNING: this approach is not (generally) safe against code injection. I highly recommend some further check (parsing) of the value depending on the particular case. P.S. For very large amount of data, I would recomment to save them into file on the PHP side (file_put_content) and read them by javascript via HTTP Request. I use this approach as it needs one line of code on server as well as client side. I do agree with arguement that not all chaeacters have to be encoded. Do not enjoy my possibly stupid solution, if you have a better idea murphy ---- Server IP: 45.112.84.4 Probable Submitter: 185.85.3.172 (proxied: 78.80.24.251) ---- Manual Page -- http://php.net/manual/en/faq.html.php Edit -- https://master.php.net/note/edit/124655 Del: integrated -- https://master.php.net/note/delete/124655/integrated Del: useless -- https://master.php.net/note/delete/124655/useless Del: bad code -- https://master.php.net/note/delete/124655/bad+code Del: spam -- https://master.php.net/note/delete/124655/spam Del: non-english -- https://master.php.net/note/delete/124655/non-english Del: in docs -- https://master.php.net/note/delete/124655/in+docs Del: other reasons-- https://master.php.net/note/delete/124655 Reject -- https://master.php.net/note/reject/124655 Search -- https://master.php.net/manage/user-notes.php