php - PHP Intl 扩展线程安全吗？

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 甚至不允许正确更改语言环境。 locale1.php 中的 sleep( 10 ) 以不允许 locale2.php 的方式劫持 Apache/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 正在 sleep 时 locale2.php 根据美国规则很好地打印美式英语日期，之后 locale1.php 根据荷兰语规则用荷兰语很好地打印了一个日期。

因此，总而言之，Intl 似乎没有 setlocale 问题。

还介意Hyunmin Kim's当然回答。由于缺乏使用 Intl 的经验，我无法对此发表评论。我最近才发现 Intl。