I'm afraid you already found the answer by yourself - it's bad news in that there is no better answer that I know of.
The BOM should not be there, and it's the sender's responsibility to not send it along.
But I can reassure you, the BOM is either there or there is not, and if it is, it's those three bytes you know.
You can have a slightly faster and handle another N BOMs with a small alteration:
$__BOM = pack('CCC', 239, 187, 191);
// Careful about the three ='s -- they're all needed.
while(0 === strpos($data, $__BOM))
$data = substr($data, 3);
A third-party BOM detector wouldn't do any different. This way you're covered even if at a later time cURL began stripping unneeded BOMs.
Possible causes
Some JSON optimizers and filters may decide the output requires a BOM. Also, perhaps more simply, whoever wrote the script generating the JSON inadvertently included a BOM before the opening PHP tag. Apache, not caring what the BOM is, sees there is data before the opening tag, so sends it along and hides it from the PHP stream itself. This can occasionally also cause the "Cannot add headers: output already started" error.
Content detection
You can verify the JSON is valid UTF-8, BOM or not BOM, but need mb_string
support and you must use strict mode to get some edge cases:
if (false === mb_detect_encoding($data, 'UTF-8', true)) {
// JSON contains invalid sequences (erroneously NOT JSON encoded)
}
I would advise against trying to correct a possible encoding error; you risk breaking your own code, and also having to maintain someone else's work.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…