我一直在阅读有关PHP语言环境的信息,似乎setlocale()
线程有问题。(我对线程不太熟悉 - 文档提到它不是线程安全的)
我想让我的项目能够处理某些数字格式,而 Intl 扩展似乎很有趣。
http://php.net/manual/en/book.intl.php
我应该预料到setlocale()
在使用 Intl 扩展时遇到的相同问题吗?
好吧,我自己也很好奇,所以我设计了一个测试。
首先,我用这两个文件测试了setlocale()
:
<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );
date_default_timezone_set( 'Europe/Amsterdam' );
setlocale( LC_ALL, 'dutch_nld' ); // awkward Windows locale string
sleep( 10 ); // let's sleep for a bit here
echo strftime( '%A, %B %d, %Y %X %Z', time() );
和
<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );
date_default_timezone_set( 'America/Los_Angeles' );
setlocale( LC_ALL, 'english_usa' ); // awkward Windows locale string
echo strftime( '%A, %B %d, %Y %X %Z', time() );
然后我在两个单独的选项卡中执行它们。第一个locale1.php
,在设置区域设置后休眠 10 秒,让我们有时间同时执行locale2.php
。
令我惊讶的是,locale2.php
甚至不允许正确更改区域设置。它似乎sleep( 10 )
locale1.php
劫持了Apache/PHP进程,以至于它不允许locale2.php
同时更改语言环境。但是,它确实同时回应了日期,当然,只是没有像您期望的那样本地化。
编辑:对不起,报废了。看起来locale2.php
确实改变了区域设置,然后locale1.php
睡觉后打印英语日期而不是荷兰语。因此,这似乎确实符合setlocale()
的预期行为。/编辑
然后,我用这两个文件测试了IntlDateFormatter
:
<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );
$dateFormatter = new IntlDateFormatter(
'nl_NL',
IntlDateFormatter::FULL,
IntlDateFormatter::FULL,
'Europe/Amsterdam'
);
sleep( 10 ); // let's sleep for a bit here
echo $dateFormatter->format( time() );
和
<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );
$dateFormatter = new IntlDateFormatter(
'en_US',
IntlDateFormatter::FULL,
IntlDateFormatter::FULL,
'America/Los_Angeles'
);
echo $dateFormatter->format( time() );
然后在两个单独的选项卡中再次执行它们,与第一组文件的方式相同。这确实给出了预期的结果:当locale1.php
睡觉时,locale2.php
根据美国规则很好地打印美式英语日期,之后locale1.php
根据荷兰规则很好地打印荷兰
因此,总而言之,Intl
似乎可以避免setlocale
问题。
当然也要注意金贤民的回答。由于缺乏使用Intl
的经验,我无法对此发表评论。我最近才发现Intl
.
如果您不在框架中工作,Intl 扩展是安全的,非常有用。
例如,如果您使用的是Symfony2,则在使用表单和验证器时,您的程序很可能会崩溃。