У старому проєкті я зіткнувся з тим, що значення параметра форми, очікуване як save, надходило з додатковими символами ¬_. Проблему помітили під час роботи з IE6, Safari та Opera. У початковій нотатці підозрювалося також передавання через POST, але окремої перевірки цього припущення не наведено.
Зайві символи в отриманому параметрі
Ілюстрація отриманого значення та порівняння з оригіналу:
$_GET['op']='save¬_'
if ($_GET['op']=='save'){'программный код'}Фрагмент вище показує задум перевірки й не є готовим виконуваним прикладом: рядок у фігурних дужках — заповнювач. Через відмінність у значенні порівняння з save не давало очікуваного результату.
Власний метод clrget у «Корпорація 2»
У «Корпорація 2» тоді використовувалася власна функція очищення:
$GLOBALS["c"]->clrget('Поле');У тексті також був наведений такий виклик:
echo 'op= '.$GLOBALS["c"]->clrget($_GET["op"])Очікуваний результат у тому випадку — op=save. Ці записи по-різному описують аргумент: спершу назву поля, потім його значення. Без реалізації методу clrget не можна вважати їх взаємозамінним або документованим API.
Що перевіряти під час діагностики форми
Пізніше я пов’язав помилку з формою, де action містив параметри URL, а методом було обрано POST. Однак саме поєднання цих елементів не доводить причини додавання символів і не є загальною властивістю браузерів. Для діагностики потрібно перевіряти HTML форми, кодування, фактичний запит і обробник параметрів; універсальне відрізання двох символів може пошкодити правильні значення.
Механізм надсилання форм описано в стандарті HTML. Наведена нотатка стосується конкретної історичної реалізації.
Немає коментарів:
Дописати коментар