facebook的开发者声明页面表中的page_id是整数。
但由于许多脸书页面，它的数量增加了更大的最大int值
http://developers.facebook.com/docs/reference/fql/page/
所以fql的select给了像这样的smth e+123213
这似乎是page表文档中的一个错误。在图形API中，page对象的文档将此字段称为string。
实际上，最好将Facebook返回的任何id保存/使用为string，因为在许多情况下，id的值会导致integer边界溢出。对于某些对象，id可能包含数字以外的字符（下划线）。
更新：澄清一些事情。问题不仅在于文档，还在于返回数据。API将响应返回为JSON（或者如果使用旧的REST API，也可以指定XML格式）string。因此，响应确实包含完整且正确的page_id，但在JSON解析阶段，由于它被解析为integer，所以您会丢失它。
在PHP 5.4中，json_decode函数有额外的options参数，可能是JSON_BIGINT_AS_STRING来克服这个问题。您应该检查您使用的解析方法是否支持这样的东西。
Facebook上为这个问题打开了几个bug（这不是针对page表中的page_id，而是针对其他表上的uid字段的相同行为）：
- UID在PHP SDK中被视为FQL查询的整数，在32位系统上超过PHP_INT_MAX
- 通过GRAPH api使用FQL获取FQL page_fan表时，uid格式无效
事实上，你可以做一些事情来克服这个问题：
- 如果您使用PHP，您可以：
- 使用64位版本的运行时，由于
PHP_INT_MAX较大，因此没有此问题 - 使用PHP 5.4并将
JSON_BIGINT_AS_STRING选项传递给json_decode
- 使用64位版本的运行时，由于
- 如果您使用PHP或任何其他技术：
- 使用替代的JSON解析器（我不知道PHP中有任何JSON解析器能够处理此问题）
- 使用快速且肮脏的重新查询表达式将所有数字用引号
$response = preg_replace('/(bd+b)/', '"$1"', $response)括起来（这是针对PHP的，但您会明白的）
此外，我建议在Facebook上提交额外的Bug并更新您的问题，以便我们也可以订阅。