我正在尝试使用 erlang 端口通过 erlang 评估 php 代码。问题是当要评估的数据更大时，我会从 php 中得到 parse error。但是，如果数据较小，那么我将得到正确的输出。我认为当数据长度较大时，erlang 会在将数据发送到 php 进行评估之前截断数据。在 erlang 端口上可以发送或接收的数据长度是否有任何限制。还是其他原因造成的这个错误？
我正在使用 open_port(PortName, PortSettings) 打开一个新端口，并在 PortSettings 中将 [{packet,4},exit_status] 设置为我的端口选项.
【问题讨论】：
{packet, 4} 元组表示为处理端口另一端而启动的程序需要 4 字节长度前缀形式的数据。我在php(1) 程序的文档中没有看到任何说明它知道如何处理此类数据的内容。可能它适用于短输入的唯一原因是，如果您眯着眼睛，长度前缀看起来有点像 ASCII，只要您发送的数据小于 127 个字节。一旦你仔细检查，PHP 可能会遇到 UTF-8 解码错误。
我很确定你想在这里说spawn。这为您提供了标准的类 Unix 管道交互：通过端口发送的数据在启动的进程上进入标准输入，而它发送到标准输出的任何内容都返回到您的 Erlang 进程。
这样做的唯一问题是它在每个事务上重新启动php(1)。这可能看起来很昂贵，但由于fork(2) 系统调用的相对效率，它在任何Unix 类型系统上都不算太糟糕。如果您使用的是 Windows，或者您已经对此进行了基准测试并发现您确实需要构建类似 FastCGI 的系统，那么您可能会不走运。似乎没有libphp 可以将PHP 嵌入到您编写的用于处理分组输入的程序中，也没有办法运行php(1) 以使其在端口的另一端保持活动状态。切换到原生 Erlang 模板系统可能会更好。
另外，请注意，传递给 open_port() 的 exit_status 原子不会执行任何操作，除非您使用 spawn。
【讨论】：
php(1) 在其标准输入上获得 EOF 之前不会返回已处理的输出（至少，不是全部），直到您的 Erlang 程序调用才会发生这种情况port_close()。然后您必须打开一个新的 PHP 端口来处理另一个文档。如果您可以保持 PHP 进程运行会更有效，这就是打开端口时所有数据包和行分隔符的内容：一种区分一个事务与下一个事务的方法。由于独立的 PHP 解释器不支持，所以每次都必须重新启动它。