Question

我一直在阅读PHP中的语言环境，看起来setlocale()有线程问题。（我对线程不太熟悉 - 文档提到它不是线程安全的）

我想让我的项目能够处理某些数字格式，而Intl扩展看起来很有趣。

http://php.net/manual/en/book.intl.php

我是否应该期待setlocale()使用Intl扩展程序的相同问题？

Answer 1

好吧，我自己也很好奇，所以我设计了一个测试。

首先，我使用这两个文件测试了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问题似乎是安全的。{/ p>

但当然也要记住Hyunmin Kim's。由于缺乏使用setlocale的经验，我无法对此发表评论。我最近才发现Intl。

Answer 2

如果您不在框架内工作，Intl扩展是安全且非常有用的。

例如，如果您使用的是Symfony2，那么在使用表单和验证器时，您的程序很可能会崩溃。

PHP Intl扩展线程安全吗？

2 个答案: