问题
PHP取得json前面有乱码(去除文件头部BOM ，
php json输出有??,css样式也不正常
,去除php bom头 ，
chrome调试窗口开头多一个空格，有小红点 PHP去掉json字符串中的
简体中文，改成繁体中文，或者其他国家的文字，json错误
在PHP中，如果你想要直接输出JSON而不包含BOM（Byte Order Mark），你可以使用json_encode函数来生成JSON字符串，然后使用header函数来设置响应类型为JSON，并确保不输出BOM。
以下是一个简单的例子：
<?php
// 数据数组
$data = array('name' => 'John', 'age' => 30, 'email' => 'john@example.com');
// 设置响应类型为JSON
header('Content-Type: application/json; charset=UTF-8');
// 防止输出BOM
if (substr(PHP_SAPI, 0, 3) === 'cgi') {
// CGI模式时需要额外处理
if (function_exists('apache_setenv')) {
@apache_setenv('no-gzip', '1');
@ini_set('zlib.output_compression', 'Off');
@apache_setenv('no-chunked', '1');
}
} else {
@ini_set('zlib.output_compression', 'Off');
@ini_set('output_handler', '');
}
// 输出JSON字符串
echo json_encode($data);
?>在这个例子中，我们首先设置了响应类型为application/json，并且关闭了PHP的压缩输出设置，以确保不会输出BOM。然后，我们使用json_encode将数组转换成JSON格式，并直接输出。
请注意，关闭输出压缩对性能有轻微影响，因此在生产环境中应该根据需要进行相应的优化。
如果php程序文件本事是bom格式的。去除bom格式
//只要把此文件另存为removebom.php,放在服务器根目录，然后执行，就可以去除服务器端bom，//在chrome有小红点的开始 1 <?php
2 //remove the utf-8 boms
3 //by magicbug at gmail dot com
4 if (isset($_GET['dir'])){ //config the basedir
5 $basedir=$_GET['dir'];
6 }else{
7 $basedir = '.';
8 }
9 $auto = 1;
10 checkdir($basedir);
11 function checkdir($basedir){
12 if ($dh = opendir($basedir)) {
13 while (($file = readdir($dh)) !== false) {
14 if ($file != '.' && $file != '..'){
15 if (!is_dir($basedir."/".$file)) {
16 echo "filename: $basedir/
17 $file ".checkBOM("$basedir/$file")." <br>";
18 }else{
19 $dirname = $basedir."/".
20 $file;
21 checkdir($dirname);
22 }
23 }
24 }
25 closedir($dh);
26 }
27 }
28
29 function checkBOM ($filename) {
30 global $auto;
31 $contents = file_get_contents($filename);
32 $charset[1] = substr($contents, 0, 1);
33 $charset[2] = substr($contents, 1, 1);
34 $charset[3] = substr($contents, 2, 1);
35 if (ord($charset[1]) == 239 && ord($charset[2]) == 187 &&
36 ord($charset[3]) == 191) {
37 if ($auto == 1) {
38 $rest = substr($contents, 3);
39 rewrite ($filename, $rest);
40 return ("<font color=red>BOM found,
41 automatically removed.</font>");
42 } else {
43 return ("<font color=red>BOM found.
44 </font>");
45 }
46 }
47 else return ("BOM Not Found.");
48 }
49
50 function rewrite ($filename, $data) {
51 $filenum = fopen($filename, "w");
52 flock($filenum, LOCK_EX);
53 fwrite($filenum, $data);
54 fclose($filenum);
55 }
56 ?>源码引用自
还有 eBay Marketplace Account Deletion/Closure Notifications Workflow | eBay Developers Program
eBay Marketplace Account Deletion/Closure Notifications Workflow | eBay Developers Programhttps://developer.ebay.com/marketplace-account-deletion
mportant!我们强烈建议实现使用JSON库来创建响应体。当实现通过写出字符串值而不是创建挑战响应时,字节顺序标记(BOM)通常会预置到响应体。由于一个 BOM 被认为是无效的 JSON, 接收服务有问题解析例外, 作为一个结果, 尝试订阅到市场账户删除通知失败.
For more information, reference to:
- 第8节。字符编码,RFC8259
- Byte Order Mark (BOM) FAQ on the Unicode 网站
问:什么是BOM？
A 字节顺序标记 (月初（beginning of month的缩写））由数据流开头的字符代码U+FEFF组成，在这里它可以用作签名定义字节顺序和编码形式，主要是未标记的明文文件。在一些更高级别的协议下，在该协议中定义的Unicode数据流中可能强制（或禁止）使用BOM。[AF]
问:BOM有什么用处？
A 月初（beginning of month的缩写）在键入为文本的文件的开头很有用，但不知道这些文件是大端还是小端格式，它还可以作为一种提示，表明文件是Unicode格式的，而不是传统编码格式的。此外，它还可以作为签名具体来说编码形式二手的。[AF]
问:endian是什么意思？
长于一个字节的数据类型可以用最高有效字节（最高有效位）第一还是最后。前者被称为大端的，后者小端的。交换数据时，在发送系统上以“正确”顺序出现的字节在接收系统上可能会显得无序。在这种情况下月初（beginning of month的缩写）看起来像0xFFFE非字符允许接收系统在处理数据之前应用字节反转。UTF-8是面向字节的，因此没有这个问题。然而，最初的BOM可能有助于确定数据流为UTF-8。[AF]
问:BOM仅用于16位Unicode文本吗？
A 月初（beginning of month的缩写）可以用作签名无论Unicode文本如何转换:UTF-16, UTF-8，或者UTF-32。组成BOM的确切字节将是由该转换成的任何Unicode字符U+FEFF转换格式。在这种形式中，BOM用于指示它是一个Unicode文件，以及它采用哪种格式。示例:
字节 | 编码形式 |
00 00 FE FF | UTF-32，大端的 |
FF FE 00 00 | UTF-32，小端的 |
FE FF | UTF-16，大端 |
FF FE | UTF-16，小端字节 |
EF BB BF | UTF-8 |
问:UTF-8数据流可以包含BOM字符（UTF-8格式）吗？如果是，那么我还可以认为剩余的UTF 8字节是以大端顺序排列的吗？
是的，UTF-8可以包含一个月初（beginning of month的缩写）。然而，它使不字节流的字节序差异。UTF 8总是有相同的字节顺序。初始BOM是仅仅用作签名—表示一个未标记的文本文件在UTF 8中。请注意，一些UTF-8编码数据的接收者并不期待BOM。在使用UTF-8的地方透明地在8位环境中，使用BOM会干扰任何期望特定美国信息交换标准代码字符开头，如使用“#！”Unix shell开头的剧本. 【AF】
问:我该如何处理文件中间的U+FEFF？
如果没有协议支持将其用作月初（beginning of month的缩写）并且当不在文本流的开头时，U+FEFF通常不应该出现。向后和睦相处它应该被视为零宽度不间断空格（ZWNBSP），然后是文件或字符串内容的一部分。U+2060字的使用工匠在表达单词连接语义方面，比ZWNBSP更受青睐，因为它不会与BOM混淆。当设计一种标记语言或数据协议时，U+FEFF的使用可能仅限于字节顺序标记。在这种情况下，出现在文件中间的任何U+FEFF都可以被视为不支持的字符. [AF]
问:我使用的协议在文本开头有BOM。我如何表示一个初始的ZWNBSP？
使用U+2060 WORD工匠相反。
问:如何标记不会将U+FEFF解释为BOM的数据？
使用标签UTF-16BE来表示大端的 UTF-16文本，以及UTF-16LE来表示小端的UTF-16文本。如果您确实使用了月初（beginning of month的缩写），将文本标记为简单UTF-16. [医学博士]
问:为什么我不总是使用需要BOM的协议？
如果数据具有关联的类型，如数据库中的字段，则月初（beginning of month的缩写）没有必要。特别是，如果文本数据流被标记为UTF-16BE, UTF-16LE, UTF-32BE或者UTF-32LE，BOM既不必要也不允许。任何U+FEFF都会被解释为ZWNBSP。
不要用BOM标记数据库或字段集中的每个字符串，因为这会浪费空间并使字符串连接变得复杂。此外，这还意味着两个数据字段可能具有完全相同的内容，但不是二进制相等的（其中一个字段前面有BOM）。
问:我应该如何处理材料清单？
以下是一些需要遵循的准则:
- 特定协议（例如微软的。txt文件）可能需要使用月初（beginning of month的缩写）在某些Unicode数据流上，如文件。当你需要符合这样的协议时，使用BOM。
- 对于未标记的文本，一些协议允许可选的BOM。在这些情况下，
- 在已知文本数据流纯文本，但编码未知，BOM可用作签名。如果没有BOM，编码可以是任何东西。
- 如果已知一个文本数据流是普通Unicode文本（但不是哪种字节顺序），则BOM可以用作签名。如果没有物料清单，文本应解释为大端的.
- 一些面向字节的协议期望美国信息交换标准代码文件开头的字符。如果UTF-8与这些协议一起使用，使用BOM作为编码形式应避免签名。
- 其中数据流的精确类型是已知的（例如Unicode big-endian或Unicode小端的），不应使用BOM。特别是，每当数据流被声明为UTF-16BE, UTF-16LE, UTF-32BE或者UTF-32LE炸弹必须不被使用。(另请参见问:UCS-2和UTF-16有什么区别？.) [AF]