简体   繁体   English

将扩展的 Ascii“表”代码(例如─、┬)从 PHP 脚本打印到控制台的问题

[英]Issues with printing extended Ascii “table” codes (e.g. ─, ┬) to console from Php script

Update更新

I have added a solution to the problem in an answer below.我在下面的答案中添加了该问题的解决方案。 Also the title has been updated from the old to a more fitting one, since it seems that all characters from 128 to 255 seem to be causing an issue (the extended ASCII codes, as seen here: Ascii table ).此外,标题已从旧更新为更合适的标题,因为从 128 到 255 的所有字符似乎都引起了问题(扩展的 ASCII 代码,如下所示: Ascii 表)。

Update II更新二

The problem seems to have gone away after updating PHP to 7.1.30 (lower version might work as well).PHP 更新到 7.1.30 后问题似乎已经消失(低版本也可以)。 Worth noting is that my fix below instead caused problematic output in the newer version:值得注意的是,我在下面的修复反而在新版本中导致了有问题的输出: 问题自行修复后修复问题 Also using the helper function in the answer clearly causes problems, as it generates gibberish:同样在答案中使用辅助函数显然会导致问题,因为它会产生胡言乱语:

for($i=128; $i<256; $i++) {echo "'" . chr($i) . "', ";}
'�', '�', '�', '�', '�', '�',...

I have tested switching back and forth between 5.6.25 and 7.1.30 and the problem again re-appears in the 5.6.我测试过在 5.6.25 和 7.1.30 之间来回切换,问题再次出现在 5.6 中。 and the fix works fine in the 5.6., so it is clearly version-related.并且该修复在 5.6. 中运行良好,因此它显然与版本相关。

Conclusion结论

It seems that the problem was caused by PHP version – previously it was 5.6.25, now it is 7.1.30 and the fix is no longer needed (and not desireable, as it causes issues).似乎问题是由 PHP 版本引起的 - 以前是 5.6.25,现在是 7.1.30,不再需要修复(并且不希望,因为它会导致问题)。 So, if you run into the ÔöÇ issue and you run lower PHP version, the fix might help you.因此,如果您遇到ÔöÇ问题并且您运行较低的 PHP 版本,该修复程序可能会对您有所帮助。 But if you run into , the issue lies elsewhere.但是如果你遇到 ,问题就出在别处。


The old description:旧描述:

I am trying to output results of a gulp task run from Laravel Artisan command (I need data from PHP to compile and then export assets from multiple modules and then compile them all together in the main application).我正在尝试输出从 Laravel Artisan 命令运行的 gulp 任务的结果(我需要来自 PHP 的数据进行编译,然后从多个模块导出资产,然后在主应用程序中将它们全部编译)。

Everything works fine but for some reason, the "table" Ascii characters are output incorrectly as gibberish ( Ôöî ) instead of proper characters ( ).一切正常,但由于某种原因,“表格”Ascii 字符被错误地输出为乱码 ( Ôöî ) 而不是正确的字符 ( )。

Details细节

See this image:看这张图片: 工匠的吞咽输出 and compare it to the desired result of the same command output directly from gulp to console:并将其与直接从 gulp 到控制台的相同命令输出的所需结果进行比较: 所需的输出 . .

So I was tinkering with this and the funny part is that I get the wrong result even if I just use echo "─┬──────────────";所以我正在修补这个,有趣的是,即使我只使用echo "─┬──────────────"; ,我也会得到错误的结果echo "─┬──────────────"; inside my php file (which is run by Laravel artisan as php artisan my-command).在我的 php 文件中(由 Laravel artisan 作为 php artisan my-command 运行)。 The wrong result is ÔöÇÔöČÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇ .错误的结果是ÔöÇÔöČÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇ

I have tried to convert the encoding ( mb_convert_encoding("─┬──────────────", "UTF-8") ), detect the encoding (php states "UTF-8"), setting config values ( ini_set output_encoding, internal_encoding, ... ) and tried other various methods.我试图转换编码( mb_convert_encoding("─┬──────────────", "UTF-8") ),检测编码(php 状态为“UTF-8”),设置配置值( ini_set output_encoding, internal_encoding, ... )并尝试了其他各种方法。 Up to no avail...无济于事...

So I went deeper and tried to use ord() and chr() in my script and in command line to determine what is really going on.所以我更深入地尝试在我的脚本和命令行中使用ord()chr()来确定真正发生了什么。 So: when i run this in the command line:所以:当我在命令行中运行它时:

$php -a
Interactive mode enabled

<?php
$var = "─┬──────────────";
for($i = 0; $i < strlen($var); $i++) {    echo ord($var[$i])."<br/>"; }
?>

I get 196<br/>194<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/> ( <br/> was copy-pasted from another thread and it is an OK visual separator in this case) .我得到196<br/>194<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/>196<br/> <br/>是从另一个线程复制粘贴的,这是一个不错的视觉效果在这种情况下是分隔符)

But when I run the exact same code from a file (run via the php artisan command), I get 226<br/>148<br/>128<br/>226<br/>148<br/>172<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>但是当我从文件中运行完全相同的代码(通过 php artisan 命令运行)时,我得到226<br/>148<br/>128<br/>226<br/>148<br/>172<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>226<br/>148<br/>128<br/>

So I get 226 148 128 (incorrect) instead of the desired 196 .所以我得到226 148 128 (不正确)而不是所需的196 And when I try echo chr(196), it prints the correct char, even from the script file run via Artisan (it prints the ).当我尝试 echo chr(196) 时,它会打印正确的字符,即使是通过 Artisan 运行的脚本文件(它会打印 )。

Also, when logging the output from php script file to a log file (via Laravel's \\Log::info() ) I do get the correct result.此外,当将 php 脚本文件的输出记录到日志文件(通过 Laravel 的\\Log::info() )时,我确实得到了正确的结果。

Only when running the script from a file and printing to console the issues do occur.只有在从文件运行脚本并打印到控制台时才会出现问题。

Conclusion结论

Do you have any idea what is going on?你知道发生了什么吗?

Why do all other characters get printed out correctly and even the wrong ones do get printed correctly in the log, but incorrectly into console?为什么所有其他字符都能正确打印出来,甚至错误的字符也能正确打印在日志中,但错误地打印到控制台?

I beleive that the issue is not related to Gulp and most probably not related to Artisan.我相信这个问题与 Gulp 无关,而且很可能与 Artisan 无关。 It is most probably some kind of encoding issue.这很可能是某种编码问题。

Any help would be much appreciated.任何帮助将非常感激。

I am out of ideas...我没有想法...

More info更多信息

The file with the script is encoded in UTF-8.带有脚本的文件以 UTF-8 编码。

I use the following code to run the gulp task, but I am fairly certain that is of no relevance to the real issue:我使用以下代码运行 gulp 任务,但我很确定这与实际问题无关:

    $proc = popen($command, 'r');
    while (!feof($proc))
    {
        $fread = mb_convert_encoding(fread($proc, 4096), 'utf-8');

        \Log::info($fread);

        print($fread);
        @ flush();
    }

    pclose($proc);

I use cmder as a console emulator on Windows 10 OS.我在 Windows 10 操作系统上使用 cmder 作为控制台模拟器。

Edit I:编辑我:

I got the codes from ord() in terminal.我从终端的 ord() 得到了代码。

Ie ord("─") returns 196 if run in the terminal via:如果通过以下方式在终端中运行,即ord("─")返回196

php -a
Interactive mode enabled

<?php
echo (ord("─"));
?>
^Z
196

I can output the correct characted by explicitly using echo chr(196) in the script file, but echo "─" prints garbage.我可以通过在脚本文件中显式使用 echo chr(196) 输出正确的字符,但是 echo "─" 打印垃圾。

Edit II:编辑二:

If I run chcp , I get Active code page: 852 .如果我运行chcp ,我会得到Active code page: 852

If I use如果我使用

    $string = "─┬──────────────";
    $string = mb_convert_encoding($string, "windows-1252");

I get ????????????????我明白了???????????????? as an output of the script.作为脚本的输出。

And I get the same result if I use $string = mb_convert_encoding($string, "ISO-8859-1");如果我使用$string = mb_convert_encoding($string, "ISO-8859-1"); ,我会得到相同的结果$string = mb_convert_encoding($string, "ISO-8859-1"); . .

Why are all the other characters printed correctly?为什么所有其他字符都打印正确? (See my first image above ↑). (见我上面的第一张图片↑)。 All letters, all colors, all formating is OK except for those few special characters.除了少数特殊字符外,所有字母、所有颜色、所有格式都可以。


I am considering either running str_replace() on each line that I am printing to replace what I get with what I want.我正在考虑在我打印的每一行上运行str_replace()以替换我想要的东西。

Or just ignoring the output's formating.或者只是忽略输出的格式。 It is ugly but it is readable...它很丑,但它是可读的......

In case anyone runs into the same issue, this function fixes the issue:如果有人遇到同样的问题,这个功能可以解决这个问题:

 /**
 * Fixes the extended ASCII characters incorrectly displayed into console.
 *
 * @param string $text
 *
 * @return string
 */
function convertExtendedAsciiCharacters($text)
{
    return str_replace(
        ['Ç', 'ü', 'é', 'â', 'ä', 'ů', 'ć', 'ç', 'ł', 'ë', 'Ő', 'ő', 'î', 'Ź', 'Ä', 'Ć', 'É', 'Ĺ', 'ĺ', 'ô', 'ö', 'Ľ', 'ľ', 'Ś', 'ś', 'Ö', 'Ü', 'Ť', 'ť', 'Ł', '×', 'č', 'á', 'í', 'ó', 'ú', 'Ą', 'ą', 'Ž', 'ž', 'Ę', 'ę', '¬', 'ź', 'Č', 'ş', '«', '»', '░', '▒', '▓', '│', '┤', 'Á', 'Â', 'Ě', 'Ş', '╣', '║', '╗', '╝', 'Ż', 'ż', '┐', '└', '┴', '┬', '├', '─', '┼', 'Ă', 'ă', '╚', '╔', '╩', '╦', '╠', '═', '╬', '¤', 'đ', 'Đ', 'Ď', 'Ë', 'ď', 'Ň', 'Í', 'Î', 'ě', '┘', '┌', '█', '▄', 'Ţ', 'Ů', '▀', 'Ó', 'ß', 'Ô', 'Ń', 'ń', 'ň', 'Š', 'š', 'Ŕ', 'Ú', 'ŕ', 'Ű', 'ý', 'Ý', 'ţ', '´', '­', '˝', '˛', 'ˇ', '˘', '§', '÷', '¸', '°', '¨', '˙', 'ű', 'Ř', 'ř', '■', ' '],
        [chr(128), chr(129), chr(130), chr(131), chr(132), chr(133), chr(134), chr(135), chr(136), chr(137), chr(138), chr(139), chr(140), chr(141), chr(142), chr(143), chr(144), chr(145), chr(146), chr(147), chr(148), chr(149), chr(150), chr(151), chr(152), chr(153), chr(154), chr(155), chr(156), chr(157), chr(158), chr(159), chr(160), chr(161), chr(162), chr(163), chr(164), chr(165), chr(166), chr(167), chr(168), chr(169), chr(170), chr(171), chr(172), chr(173), chr(174), chr(175), chr(176), chr(177), chr(178), chr(179), chr(180), chr(181), chr(182), chr(183), chr(184), chr(185), chr(186), chr(187), chr(188), chr(189), chr(190), chr(191), chr(192), chr(193), chr(194), chr(195), chr(196), chr(197), chr(198), chr(199), chr(200), chr(201), chr(202), chr(203), chr(204), chr(205), chr(206), chr(207), chr(208), chr(209), chr(210), chr(211), chr(212), chr(213), chr(214), chr(215), chr(216), chr(217), chr(218), chr(219), chr(220), chr(221), chr(222), chr(223), chr(224), chr(225), chr(226), chr(227), chr(228), chr(229), chr(230), chr(231), chr(232), chr(233), chr(234), chr(235), chr(236), chr(237), chr(238), chr(239), chr(240), chr(241), chr(242), chr(243), chr(244), chr(245), chr(246), chr(247), chr(248), chr(249), chr(250), chr(251), chr(252), chr(253), chr(254), chr(255)],
        $text);
}

The function was generated using the following commands:该函数是使用以下命令生成的:

for($i=128; $i<256; $i++) {echo "'" . chr($i) . "', ";}
for($i=128; $i<256; $i++) {echo "chr($i), ";}

You might have to generate your own one if some characters are missing for you.如果您缺少某些字符,您可能需要生成自己的字符。 (See the end of the answer). (见答案末尾)。

Conclusion:结论:

This seems to be an acceptable solution to me as it should be reasonably fast and it fixes the issue.这对我来说似乎是一个可以接受的解决方案,因为它应该相当快并且可以解决问题。

More details:更多细节:

Since the issue was annoying me, I have been tinkering with the output and with my development setup some more.由于这个问题让我很恼火,我一直在修改输出和我的开发设置。 And it seems that the issue is somewhere between PHP output and the console.似乎问题出在 PHP 输出和控制台之间。 No characters from the extended ASCII table seem to work ( Ascii table ).扩展 ASCII 表中的字符似乎不起作用( Ascii 表)。 Therefore I have changed the name of the question to better describe the issue.因此,我更改了问题的名称以更好地描述问题。

No changes in php.ini helped, so I resolved to this simple and quick replace. php.ini 中的任何更改都没有帮助,所以我决定使用这个简单快速的替换。

In case anyone has a better idea how to fix the issue, I would be interested in hearing it.如果有人对如何解决这个问题有更好的想法,我很想听听。

It is worth noticing that some of the characters printed by my command line are different than those in the aforementioned Ascii table.值得注意的是,我的命令行打印的某些字符与上述 Ascii 表中的字符不同 That might be raleted to the issue, but still gives me no clue on how to solve it.这可能与问题有关,但仍然不知道如何解决它。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM