Javascript-форум (https://javascript.ru/forum/)
-   Общие вопросы Javascript (https://javascript.ru/forum/misc/)
-   -   Почему при передаче php переменной в скрипт данные шифруются? (https://javascript.ru/forum/misc/76282-pochemu-pri-peredache-php-peremennojj-v-skript-dannye-shifruyutsya.html)

giwuf 21.12.2018 13:24

Почему при передаче php переменной в скрипт данные кодируются в uft-8?
 
Добрый день. Вопрос не из простых.

Касается он настройки платежной системы в интернет-магазине woocommerce. Проблема заключается в следующем: данные переменной php (почтовый адрес) передаются в скрипт почему-то закодированными.

Для начала получаю данные поля email введенные пользователем. С помощью var_dump проверяю, что в переменной содержится верная информация (email o4137889@nwytg.net), но при передаче переменной внутрь скрипта
accountId: '<?=$order->billing_email?>'


получаю вот такую закодированную строку в **utf-8**
accountId: '&#x6f;4&#x31;&#x33;7&#x38;&#x38;9&#x40;&#x6e;w&#x79;&#x74;g&#x2e;&#x6e;e&#x74;',


Причем, не важно выводится ли она через сокращенные <?= ?> или <?php ?> и echo
accountId: '<?php echo $billing_email ?>',

, через переменную или напрямую - результат каждый раз идентичен.

С чем это может быть связано и как исправить?

Код:
global $woocommerce;			
$order = new WC_Order( $order_id );
var_dump($order->billing_email); //o4137889@nwytg.net

<script src="https://widget.cloudpayments.ru/bundles/cloudpayments"></script>
<script>
	var widget = new cp.CloudPayments();
        widget.<?=$widget_f?>({ // options              <!-- /////////////???????????????  -->
        publicId: '<?=$this->public_id?>',  //id из личного кабинета
        description: 'Оплата заказа <?=$order_id?>', //назначение
        amount: <?=$order->get_total()?>, //сумма
        currency: '<?=$this->currency?>', //валюта
        invoiceId: <?=$order_id?>, //номер заказа 
        accountId: '<?=$order->billing_email?>', //идентификатор плательщика
        data: <?php echo (($this->kassa_enabled == 'yes') ? json_encode($kassa_array) : "{}") ?>
		            },
	function (options) { // success
		window.location.replace('<?=$this->get_return_url($order)?>');
	},
	function (reason, options) { // fail
		window.location.replace('<?=$order->get_cancel_order_url()?>');
        }
);
</script>


Сервер находится на unix под управлением vesta cp с php версией 7.2

laimas 21.12.2018 13:50

Цитата:

Сообщение от giwuf
такую закодированную строку в **utf-8**

Это не UTF, а html сущности. И косяк искать надо не в var_dump, а в том где она хранится, а хранится она как раз как &#x6f;4&#x31;&#x33;7&#x38;&#x38;9&#x40;&#x6e;w&#x7 9;&#x74;g&#x2e;&#x6e;e&#x74;, функция же на экране покажет текст.

PS. Вернее в браузере будет текст, после выполнения функции, смотрите не на текст, а на длину строки в этой функции.

giwuf 21.12.2018 14:29

Цитата:

Сообщение от laimas (Сообщение 500892)
Это не UTF, а html сущности. И косяк искать надо не в var_dump, а в том где она хранится, а хранится она как раз как &#x6f;4&#x31;&#x33;7&#x38;&#x38;9&#x40;&#x6e;w&#x7 9;&#x74;g&#x2e;&#x6e;e&#x74;, функция же на экране покажет текст.

PS. Вернее в браузере будет текст, после выполнения функции, смотрите не на текст, а на длину строки в этой функции.

Понял вас, но хранится она в $order_id и интересно, что сам он выводится без проблем, как и другие значения
invoiceId: <?=$order_id?>, //номер заказа


проверил c помощью функции count(), но он выводит 1. А есть ли в природе дешифраторы этих html функций? Или в настройках сервера нужно что-то прописывать?

laimas 21.12.2018 14:41

Цитата:

Сообщение от giwuf
нтересно, что сам он выводится без проблем

А их и не будет, ибо html сущности в браузере будут отображаться тем, что они представляют: &#x6f, это o, далее идет 4 как есть, затем &#x31;,это 1 и т.д.

Цитата:

Сообщение от giwuf
проверил c помощью функции count()

А причем тут count()? Функция var_dump выводит на экран тип переменой и ее значение, если тип строка, то в скобках будет указана длина строки. Бьюсь об заклад, что у вас показывает 78. Посчитайте длину символов адреса и длину строки сущностей.

Цитата:

Сообщение от giwuf
А есть ли в природе дешифраторы

Есть в РНР функция декодирования, но наверное же не декодировать надо, а выяснять почему такой бардак в данных. А такой бардак происходит тогда, когда не понимая когда нужно применять htmlspecialchars(), втыкают ее куда угодно, а если еще и htmlentities() с перепугу при сохранении в базу, то тут и получаем подобный бардак.

Разбирайтесь.

<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
</head>
<body><h3>Не верь глазам своим</h3>
<p>&#x6f;4&#x31;&#x33;7&#x38;&#x38;9&#x40;&#x6e;w&#x79;&#x74;g&#x2e;&#x6e;e&#x74;</p>
</body>
</html>

giwuf 21.12.2018 15:03

Цитата:

Сообщение от laimas (Сообщение 500894)
А причем тут count()? Функция var_dump выводит на экран тип переменой и ее значение, если тип строка, то в скобках будет указана длина строки. Бьюсь об заклад, что у вас показывает 78. Посчитайте длину символов адреса и длину строки сущностей.

laimas здесь на самом деле вы ошиблись..
string(18) “o4137889@nwytg.net”


Цитата:

Есть в РНР функция декодирования, но наверное же не декодировать надо, а выяснять почему такой бардак в данных. А такой бардак происходит тогда, когда не понимая когда нужно применять htmlspecialchars(), втыкают ее куда угодно, а если еще и htmlentities() с перепугу при сохранении в базу, то тут и получаем подобный бардак.
Понял вас, будем искать, т.к. загвоздка в том, что сайт собран исключительно на темах и плагинах без вмешательства собственного кода.

laimas 21.12.2018 15:21

Цитата:

Сообщение от giwuf
здесь на самом деле вы ошиблись

А другой причины бить не может, английские символы и цифры не будут иметь проблем при выводе в любой объявленной кодировке, а в коде вашем не видно никаких преобразований и если этой пакостью не занимается класс CloudPayments, то вывод может быть только один - сам источник данных такой.

giwuf 23.12.2018 15:59

Цитата:

Сообщение от laimas
А другой причины бить не может, английские символы и цифры не будут иметь проблем при выводе в любой объявленной кодировке, а в коде вашем не видно никаких преобразований и если этой пакостью не занимается класс CloudPayments, то вывод может быть только один - сам источник данных такой.

Здравствуйте, laimas!
С большим трудом, но удалось отыскать причину - поделюсь с вами. Есть такая зараза плагин Email Address Encoder
(A lightweight plugin that protects email addresses from email-harvesting robots by encoding them into decimal and hexadecimal entities.)
Вот он как раз и виноват во всем! Отключил - и все заработало!
Спасибо за помощь и подсказки!

laimas 23.12.2018 17:17

Я не в курсе того, что кроме этой пакости делает этот плагин, но учтите, что адреса мыла сервером должны обязательно проверятся.


Часовой пояс GMT +3, время: 08:18.