title: Issues with printing extended Ascii "table" codes (e.g. ─, ┬) to console from Php script
body: <h1>Update</h1>
  <p>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: <a href="http://www.asciitable.com/" rel="nofollow noreferrer">Ascii table</a>).</p>
  <h1>Update II</h1>
  <p>The problem seems to have <strong>gone away after updating PHP to 7.1.30</strong> (lower version might work as well).
  Worth noting is that my fix below instead caused problematic output in the newer version:
  <a href="https://i.stack.imgur.com/07Cmx.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/07Cmx.png" alt="Issue with fix after problem fixed itself" /></a>
  Also using the helper function in the answer clearly causes problems, as it generates gibberish:</p>
  <pre><code>for($i=128; $i&lt;256; $i++) {echo &quot;'&quot; . chr($i) . &quot;', &quot;;}
  '�', '�', '�', '�', '�', '�',...
  </code></pre>
  <p>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. and the fix works fine in the 5.6., so it is clearly version-related.</p>
  <h2>Conclusion</h2>
  <p>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).
  So, if you run into the <code>ÔöÇ</code> issue and you run lower PHP version, the fix might help you. But if you run into <code>�</code>, the issue lies elsewhere.</p>
  <hr />
  <h1>The old description:</h1>
  <p>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).</p>
  <p>Everything works fine but for some reason, the &quot;table&quot; Ascii characters are output incorrectly as gibberish (<code>Ôöî</code>) instead of proper characters (<code>─</code>).</p>
  <h1>Details</h1>
  <p>See this image: <a href="https://i.stack.imgur.com/TdM15.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/TdM15.png" alt="Gulp output from artisan" /></a> and compare it to the desired result of the same command output directly from gulp to console: <a href="https://i.stack.imgur.com/FC0f4.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/FC0f4.png" alt="The desired output" /></a> .</p>
  <p>So I was tinkering with this and the funny part is that I get the wrong result even if I just use <code>echo &quot;─┬──────────────&quot;;</code> inside my php file (which is run by Laravel artisan as php artisan my-command). The wrong result is <code>ÔöÇÔöČÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇ</code>.</p>
  <p>I have tried to convert the encoding (<code>mb_convert_encoding(&quot;─┬──────────────&quot;, &quot;UTF-8&quot;)</code>), detect the encoding (php states &quot;UTF-8&quot;), setting config values ( ini_set output_encoding, internal_encoding, ... ) and tried other various methods. Up to no avail...</p>
  <p>So I went deeper and tried to use <code>ord()</code> and <code>chr()</code> in my script and in command line to determine what is really going on. So: when i run this in the command line:</p>
  <pre><code>$php -a
  Interactive mode enabled
  
  &lt;?php
  $var = &quot;─┬──────────────&quot;;
  for($i = 0; $i &lt; strlen($var); $i++) {    echo ord($var[$i]).&quot;&lt;br/&gt;&quot;; }
  ?&gt;
  </code></pre>
  <p>I get <code>196&lt;br/&gt;194&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;196&lt;br/&gt;</code>
  <em>(<code>&lt;br/&gt;</code> was copy-pasted from another thread and it is an OK visual separator in this case)</em>.</p>
  <p>But when I run the exact same code from a file (run via the php artisan command), I get <code>226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;172&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;226&lt;br/&gt;148&lt;br/&gt;128&lt;br/&gt;</code></p>
  <p>So I get <code>226 148 128</code> (incorrect) instead of the desired <code>196</code>. And when I try echo chr(196), it prints the correct char, even from the script file run via Artisan (it prints the <code>─</code>).</p>
  <p>Also, when logging the output from php script file to a log file (via Laravel's <code>\Log::info()</code> ) I do get the correct result.</p>
  <p>Only when running the script from a file and printing to console the issues do occur.</p>
  <h1>Conclusion</h1>
  <p>Do you have any idea what is going on?</p>
  <p>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?</p>
  <p>I beleive that the issue is not related to Gulp and most probably not related to Artisan. It is most probably some kind of encoding issue.</p>
  <p>Any help would be much appreciated.</p>
  <p>I am out of ideas...</p>
  <h1>More info</h1>
  <p>The file with the script is encoded in UTF-8.</p>
  <p>I use the following code to run the gulp task, but I am fairly certain that is of no relevance to the real issue:</p>
  <pre><code>    $proc = popen($command, 'r');
      while (!feof($proc))
      {
          $fread = mb_convert_encoding(fread($proc, 4096), 'utf-8');
  
          \Log::info($fread);
  
          print($fread);
          @ flush();
      }
  
      pclose($proc);
  </code></pre>
  <p>I use cmder as a console emulator on Windows 10 OS.</p>
  <h1>Edit I:</h1>
  <p>I got the codes from ord() in terminal.</p>
  <p>I.e. <code>ord(&quot;─&quot;)</code> returns <code>196</code> if run in the terminal via:</p>
  <pre><code>php -a
  Interactive mode enabled
  
  &lt;?php
  echo (ord(&quot;─&quot;));
  ?&gt;
  ^Z
  196
  </code></pre>
  <p>I can output the correct characted by explicitly using echo chr(196) in the script file, but echo &quot;─&quot; prints garbage.</p>
  <h1>Edit II:</h1>
  <p>If I run <code>chcp</code>, I get <code>Active code page: 852</code>.</p>
  <p>If I use</p>
  <pre><code>    $string = &quot;─┬──────────────&quot;;
      $string = mb_convert_encoding($string, &quot;windows-1252&quot;);
  </code></pre>
  <p>I get <code>????????????????</code> as an output of the script.</p>
  <p>And I get the same result if I use <code>$string = mb_convert_encoding($string, &quot;ISO-8859-1&quot;);</code>.</p>
  <p>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.</p>
  <hr />
  <p>I am considering either running <code>str_replace()</code> on each line that I am printing to replace what I get with what I want.</p>
  <p>Or just ignoring the output's formating. It is ugly but it is readable...</p>