Как тестировать/классифицировать модули CPAN для корректности utf8

Вот отличный вопрос и замечательный tchrist answer с рекомендациями 7 + 24 + 52 и комментариями, как сделать программу perl-программы perl безопасной.

Но вот 19K CPAN модулей. Что можно сделать для дифференциации "хороших" и "плохих"? (с точки зрения utf8)

Например: File::Slurp, если вы прочитаете файл с помощью

#use strict encoding warnings utf8 autodie... etc....
my $str = read_file($file, binmode => ':utf8');

вы получите разные результаты на основе ключей командной строки, а perl -CSDA не будет работать. Грустный. (Да, я знаю, чем Encode:: decode ( "utf8", read_file ($ file, binmode = > ': raw')), поможет, но SAD в любом случае.

Мои вопросы:

  • здесь какой-либо предпочтительный способ, как тестировать/классифицировать, какие модули CPAN являются utf8 безопасными/готовыми/правильными?
  • вот какой-то тест:: что-то уже сделано для тестирования utf8?
  • вот что-то вроде Perl:: Critic for utf8 - что будет проверять источник модуля на возможную ошибку utf8? (потому что вручную проверять источники для 7 + 24 + 52 вещей, которые я не могу классифицировать как "простой способ программирования" )
  • или любым другим способом?:)

Насколько я понимаю, большинство модулей CPAN просто не нужно знать о utf8. Но вот zilion другие, что должно.

Пожалуйста, не поймите меня неправильно. Я люблю язык Perl. Я знаю, что Perl обладает чрезвычайно мощной возможностью utf8. (особенно 5.14). Вышеприведенное не было в виду критической критикой, но мне (и, вероятно, некоторым другим тоже) нужно знать, какие модули CPAN в порядке, и как их классифицировать...)

При разработке с использованием нескольких модулей CPAN и изначально все идет хорошо, но в финальном тестировании вы обнаружите, что некоторые модули не поддерживают utf8, и поэтому часть вашей работы бесполезна - это действительно может вызвать некоторое разочарование.: (

Edit:

Я понимаю, что все сложные вещи вокруг юникода имеют два корня:

  • сам юникод - поскольку tchrist отлично проанализировал некоторые проблемные точки
  • perl - простой не может сломать все рабочие модули, живые серверы и т.д., поэтому необходимо поддерживать обратную совместимость.

Моя единственная надежда: perl6. Является совершенно новым и другим языком. Не нужно поддерживать обратную совместимость. Поэтому я надеюсь, что в perl6 будет default некоторые вещи, которые невозможно сделать в perl5, и все вещи utf8 будут намного более интуитивными.

Но вернемся к модулям: @daxim сказал: "Авторы не смогут даже определить, является ли их модуль безопасным, и эта функция существует на протяжении десятилетий!" - и это катастрофа. Может быть (возможно, большой, и, честно говоря, не знаю, как это сделать), но, возможно, мы пришли к тому времени, когда в предложения CPAN возникли гораздо более жесткие ограничения.

С одной стороны, я действительно очень доволен работой добровольцев авторов CPAN. С другой стороны, публикация исходного кода не только как "свободная" речь, но также должна подчиняться некоторым правилам.

Я понимаю, что почти невозможно совершить любую "революцию", но нам, вероятно, нужна какая-то "эволюция". Возможно, флаг любого модуля CPAN, который не является безопасным utf8. Отметьте все, что не является безопасным. Флаг (как здесь, в SO), какой модуль не соответствует минимальным стандартам кодирования и удаляет их. Может быть, я идеалист и/или наивный.:)

Ответы

Ответ 1

Холод, ситуация менее ужасная, чем вы думаете. Никто, кроме tchrist, не работает на этом уровне правильности Юникода, также см. недавний комментарий Аристотеля. Как и во всех случаях, вы получаете 80% пути с 20% усилий. Это базовое усилие, а именно получение темы кодирования символов, хорошо документировано; и jrockway повторяет это в своем ответе в этой теме.

Отвечает на ваши конкретные вопросы:

  • Нет, нет. Нет никаких согласованных усилий для сбора этой информации в центральном месте. Вики Perl 5 могут использоваться для документирования проблемных модулей, Юрд уже обсуждает некоторые из uniadvice. Мне бы очень хотелось увидеть выражение каждого автора модуля в своей документации, что "этот модуль DTRT w.r.t. enc.", но я не вижу, чтобы это происходило. Авторы не могут даже определить, является ли их модуль безопасным, и эта функция существует на протяжении десятилетий!

  • encoding::warnings можно использовать для выключения непреднамеренных обновлений. Я упоминаю об этом в рабочем потоке Контрольного списка для перехода в Unicode с помощью Perl

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