我已经阅读了下一篇文章:
但可能错过了一些BASIC积分.
使用
use open(:utf8);
影响cpan模块呢？例如,当某个CPAN模块打开任何文件时,它将打开:utf8？这个陈述是真的吗？(或者open pragma只是词法范围？)AFAIK - 它也影响模块,但是以"不一致"的方式...(可能是模块的问题).
有open pragma效果opendir吗？- 我已经尝试过的 - 不 - 我仍然需要额外decode的所有文件名来源readdir(除了NFC).所以,IO :: Dir是不同的东西 - open pragma不包含什么？
影响开放的pragma sockets,管道呢？(例如什么是IO :: Handle？)
所有(或大多数)CPAN模块都知道何时进行i/o他们需要怎么做(utf8或lattin1或raw？)(可能不是,因为一个简单的autodie不适用于openpragma ...... :()
在许多地方,我可以阅读类似的规则:记住Unicode的规范规则:始终在应用程序的边缘编码/解码.这是一个很好的规则 - 但应用程序边缘意味着:我自己的源代码.CPAN模块(通常)也在边缘之后 - 不仅仅是"外部世界",如系统或网络......
根据我的经验,我的短脚本(大量使用CPAN)的内容的3/4包含:顶级声明,以及几乎所有的几十种编码/解码/ NFC ......
例如:即使是日志记录工具,也需要显式编码
use Log::Any qw($log);
use Log::Any::Adapter ('File', 'file.log');
$log->error( encode('utf-8', "tökös"));
甚至,当想要添加tie到我的代码时,需要$key $value用编码版本替换每一个.
这是真的,还是我错过了上述doccu中的一些基本观点？
一些CPAN模块处理utf8(内部),如JSON :: XS,YAML :: XS,File :: Slurp ..(从未成功从YAML :: XS获得正确的"事物",纯YAML和JSON :: XS无需工作任何问题...
对于某些模块存在的"黑客" -样DBIx::Class::ForceUTF8,Template::Stash::ForceUTF8,HTML::FillInForm::ForceUTF8-等等, -什么不允许写"既" UTF和非UTF世界正确的应用程序...(
许多CPAN模块不会在内部调用上面的"黑客变种" - (例如HTML::FillInForm::ForceUTF8)但只是简单的一个,所以用utf8正确使用它们......其他人,默默地失败..;(
Plack应用程序不处理utf8 记录消息而没有烦人的"宽字符......";(/现代perl :( /并且可以继续;(
从上面我"扣除"(可能是错误的) - 比我必须知道和记住每个CPAN模块如何处理utf8编码的字符串,因为没有一些"注册表" - 主要是基于试验/错误.
所以主要的问题是:
虽然我记得:这里没有灵丹妙药,但是这里有一些很好的方法可以检测并知道" utf8 ready CPAN模块 "在使用它们之前不需要特殊的编码/解码吗？
如果有人需要知道,我正在使用我的每个脚本中的下一个:
use 5.014;
use warnings;
use utf8;
use feature qw(unicode_strings);
use charnames qw(:full);
use open(:utf8); #this sometimes is bad, so using only open qw(:std :utf8);
use Encode qw(encode decode);
use Unicode::Normalize qw(NFD NFC);
嗯..只是"发现" utf8:allperl模块取代了readdir解码的版本.
Empahsis矿:
该
openpragma用作为所有I/O声明默认"层"(也称为"规则")的接口之一.任何两个参数open,readpipe(又名qx//)和类似的运营中发现的词汇范围,这个编译的将使用默认声明.open当它们没有指定IO层时,即使是三个参数也可能受到该pragma的影响MODE.
所以不,它不会影响任何不存在pragma的代码.但是,如果传递给pragma范围之外的代码,则在这种pragma范围内打开的句柄不会丢失其层.
测试以查看模块所期望的内容:
utf8::downgrade($_);.utf8::uprade($_);.| 归档时间： |
|
| 查看次数： |
553 次 |
| 最近记录： |