Вот отличный вопрос и замечательный tchrist * ответ с 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 безопасными / готовыми / правильными?
- вот какой-нибудь тест:: что-то уже сделано для тестирования utf8?
- здесь что-то вроде Perl :: Critic для utf8 - что будет проверять источник модуля на возможную некорректность utf8? (потому что вручную проверять источники на 7 + 24 + 52 вещей я не могуклассифицировать как «простой способ программирования»)
- или любым другим способом? :))
Я понимаю, что большинству модулей CPAN просто не нужно знать о utf8.Но вот что нужно другим.
Пожалуйста, не поймите меня неправильно. Я люблю язык Perl .Я знаю, что Perl обладает чрезвычайно мощными возможностями utf8.(особенно 5.14).Вышесказанное не имело значения как критика perl - но мне (и, возможно, некоторым другим тоже) нужно знать, какие модули CPAN в порядке, и как их классифицировать ...)
При разработке с использованием нескольких CPANмодулей, и изначально все идет хорошо, но в финальном тестировании вы обнаружите, что некоторые модули не поддерживают utf8, и, следовательно, часть вашей работы бесполезна - это действительно может вызвать некоторое разочарование.: (
Редактировать:
Я понимаю, что все сложные вещи, связанные с юникодом, имеют два корня:
- сам юникод - поскольку Чрист превосходно проанализировал некоторые изпроблемные моменты
- perl - просто не может сломать все рабочие модули, работающие серверы и т. д. - поэтому необходимо поддерживать обратную совместимость.
Моя единственная надежда: perl6. Is - это совершенно новый идругой язык. Не нужно поддерживать обратную совместимость. Поэтому я надеюсь, что в perl6 будет по умолчанию некоторые вещи, которые невозможно сделать в perl5, и все вещи utf8 будут намного более интуитивными.
Но вернемся к модулям: @daxim сказал: «Авторы даже не раскрывают, является ли их модуль безопасным от заражения, и эта функция существует десятилетиями!» - и это катастрофа. Может быть (может быть, и, честно говоря, понятия не имею, как это сделать), но, может быть, мы подошли к тому времени, когда нужно наложить гораздо более жесткие ограничения на представления CPAN.
С одной стороны, я действительно оченьppy с волонтерскими работами авторов CPAN.С другой стороны, публикация исходного кода не только похожа на свободу слова «правильно», но и должна подчиняться некоторым правилам.
Я понимаю, что почти невозможно совершить «революцию», но нам, вероятно, нужнонекоторая «эволюция».Может быть, пометить любой модуль CPAN, что не является безопасным utf8.Отметьте все, что не является безопасным.Отметьте (как здесь, в SO), какой модуль не соответствует минимальным стандартам кодирования, и удалите их.Может быть, я идеалист и / или наивный.:)