2
当PDO OCI通过PDO :: fetch（）返回我的行时，我的CLOB列已经是PHP流。对于长字符的多字节UTF-8字符的情况下，当我读这个流，它被截断。PDO OCI截断大型多字节CLOB
实例
- 我CLOB是8193个英镑符号（“£”）... 16386个字节的串
- 我的返回的行阵列示出了列称为“资源类型=‘流’”
- 我执行stream_get_contents（）来获得串出流的
- 我的字符串为8,192个字符... 16,384字节
- 因此，我已经失去了一个字符
另：
- 我CLOB是10万个英镑符号串...... 200000个字节
- 按照上述步骤
- 我的字符串是50848个字符... 101696个字节
- 从而我输了49,152个字符
我可以看到使用三字节字符（“の”）的类似结果，其中工作的最大长度是正确的ly是2730个字符（8192个字节）。
我不得不使用原始OCI，在这里我用的是LOB对象本身的读取循环同样的问题：
while !lob->eof() then lob->read(8192)
我能够得到的全尺寸来解决这个问题整个CLOB（lob->size()），并将其用作我的LOB读取大小，从而将它全部放在一个大的阅读中。
我没有办法在PDO OCI中做到这一点。
我的预感是PDO OCI中的内部代码可能会执行相同类型的读取循环来将LOB转换为PHP流。
看起来，在原始OCI中分块读取LOB> 8192字节可能会被破坏，并且也许PDO OCI具有相同的错误。在我的一些测试中，我的直觉认为读取可能在多字节字符的中间结束，如果它试图下一次恢复所看到的无效的UTF-8字节，就会失败。
有没有人遇到过这种行为？任何PDO OCI的解决方法？
我的环境：
- 在RHEL6 PHP 5.5.24，OCI8 v1.4.10 - Win7上PHP 5.5.11，OCI8 v1.4.10
因为PDO OCI似乎正在返回已经被截断的流，所以我没有任何事情可以在这一点之前做，以防止它被阻止。 – ashnazg
嗯，我以前的搜索没有发现这个bug - https://bugs.php.net/bug.php？编号= 60994 – ashnazg
是的，我已经提到，要使用原始OCI工作，我必须显式传递给LOB-> read（）长度大于实际CLOB值的值，从而迫使读取发生在一个大块而不是“LOB-> eof（）然后LOB-> read（）”loopl – ashnazg