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

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

Но здесь 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?
  • здесь некоторые Test :: что-то уже сделано для тестирования utf8?
  • здесь что-то вроде Perl :: Critic для utf8 - что будет проверять исходный код модуля на предмет возможной некорректности utf8? (потому что ручная проверка источников на наличие 7 + 24 + 52 вещей, которые я не могу классифицировать как «простой способ программирования»)
  • или каким-либо другим способом? :)

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

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

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

Edit:

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

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

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

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

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

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

13
задан Community 23 May 2017 в 12:12
поделиться