Почему CGI.pm по-прежнему использует "\ 0" в качестве нулевого символа, когда он рассматривается как обычный символ в Perl? - PullRequest
2 голосов
/ 06 сентября 2011

Цитируется из в CGI.pm документах :

При использовании этого, вы должны остерегаться многозначных CGI параметры. Потому что хеш не может различить скаляр и список контекст, многозначные параметры будут возвращены в виде упакованной строки, разделены символом \ 0 (ноль).

Однако, как выясняется, \0 не является чем-то особенным в Perl:

print length("test\0hi");

Вывод:

7

, тогда как в C это должно быть 4.

Почему CGI.pm по-прежнему использует \0 в качестве нулевого символа, когда он рассматривается как обычный символ (больше не знак конца строки) в Perl?

Ответы [ 2 ]

7 голосов
/ 06 сентября 2011

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

Редактировать : Люди обычно избегают вставлять NUL в свои данные именно потому, что это приводит к поломке в программах на C, поэтому это делает этот символ несколько более удобным в качестве разделителя.

Редактировать2 : Хоббс комментирует , что он восходит к Perl 4, поэтому ошибка не в оригинальном дизайне, а в переносе, а затем в недостаточно усердной попытке отказаться от возможности.

Ну, задним числом всегда идеально. Hash :: MultiValue - это более разумная структура данных, о которой вы думали.

2 голосов
/ 06 сентября 2011

Это функция безопасности.

Пользователи ->Vars ожидают хэш ключей-значений, где значения являются строками. Если одно из значений является ссылкой на массив, оно нарушает это ожидание и может привести к плохому поведению программы.

Если вы хотите поддерживать аргументы с несколькими значениями, используйте ->param в контексте списка. Вы можете использовать его для создания собственного хэша, если хотите.

my %hash;
for ($cgi->params) {
   $hash{$_} = [ $cgi->param($_) ];
}

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...