两者:
$result = iconv('UTF-8', 'UTF-16LE//IGNORE//TRANSLIT', $str);
及 mb_convert_encoding()
无法将ndash(–)转换为长减号。
结果将进入csv,因此不能将其替换为html实体。有什么想法吗?
代码:
$data = $eventHelper->getProgramForCsvExport($event);
$response = new StreamedResponse();
$response->setCharset('UTF-16LE');
$filename = 'program-' . $event->getShortName() . $event->getShortYear() . '.csv';
$utf16Data = [];
foreach ($data as $row) {
$utf16row = [];
foreach ($row as $entry) {
$utf16row[] = iconv('UTF-8', 'UTF-16LE//IGNORE//TRANSLIT', $entry);
}
$utf16Data[] = $utf16row;
}
$response->setCallback(function () use ($utf16Data) {
$output = fopen('php://output', 'w+');
foreach ($utf16Data as $row) {
fputcsv($output, $row, ';');
}
fclose($output);
});
$response->headers->set('Content-Type', 'text/csv; charset=utf-16');
$response->headers->set('Content-Disposition', 'attachment; filename="' . $filename . '"');
return $response;
编辑:这是一个伟大的office 365的导出,它不再支持utf-8,但默认为utf-16le(据我所知)。德国乌姆劳特(äöüß)很好(在皈依之前没有),但恩达什(也许还有其他一些特殊的角色)不行。NDASHE在mac上为空,在windows上为括号(左右)。
1条答案
按热度按时间lbsnaicq1#
我认为问题在于,您的代码没有在文件的开头输出utf-16le bom(字节顺序标记),因此读取它的程序不知道它使用的是什么编码,并且(显然)猜测能力很差。
utf-16le bom是字节序列
0xFF
0xFE
(按该顺序)就在文件的开头。将其作为写入输出的第一件事。有关BOM的更多信息,请参见本unicode常见问题解答。为了验证我的理论,我为一个只包含字符的utf-16le文件编写了字节序列
0–0
:这个
FF FE
是bom表,是30 00
数字是零吗13 20
是短跑,还是决赛30 00
是最后一个数字零(零就在那里,所以我可以很容易地找到破折号,尽管在这么短的文件中,这并不难。😀)我可以在windows上用office 365打开它。
然后我写了一个没有bom表的文件:
office 365确实误解了n-破折号,并将其显示为一个看起来像一对括号的字符。