Terminal shows non-ascii? characters in UTF-16 hex codes

Multi tool use
Multi tool use

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












todoroki@todoroki-VJZ13B ~>printf "än"
echo "ä"
ä
ä
ä
udcc3udca4: u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093


according to a UTF-16 decode tool, u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093 is コマンドが見つかりません (= "command not found"), which is the correct Japanese output I expect.



From the printf and echo result, UTF-8 seems working correctly.



This happens in all shell outputs, such as ls (Japanese characters in filenames shows up in UTF-16 hex format)



less vi nano behaves more strange; a file (a.txt, created with gedit) like below



あ
い
う
ä


will show as



in less (it complains "a.txt" may be a binary file. See it anyway?):



<E3><81><82>
<E3><81><84>
<E3><81><86>
<C3><A4>


in vi:



�~A~B
�~A~D
�~A~F
ä


and in nano:



 ^a^b
^a^d
^a^f


I don't remember what I had done, but it was correctly showing Japanese letters at least two days ago (and for more than 6 months).



What could be the problem and the way to recover from this?









share







New contributor




Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.























    up vote
    0
    down vote

    favorite












    todoroki@todoroki-VJZ13B ~>printf "än"
    echo "ä"
    ä
    ä
    ä
    udcc3udca4: u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093


    according to a UTF-16 decode tool, u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093 is コマンドが見つかりません (= "command not found"), which is the correct Japanese output I expect.



    From the printf and echo result, UTF-8 seems working correctly.



    This happens in all shell outputs, such as ls (Japanese characters in filenames shows up in UTF-16 hex format)



    less vi nano behaves more strange; a file (a.txt, created with gedit) like below



    あ
    い
    う
    ä


    will show as



    in less (it complains "a.txt" may be a binary file. See it anyway?):



    <E3><81><82>
    <E3><81><84>
    <E3><81><86>
    <C3><A4>


    in vi:



    �~A~B
    �~A~D
    �~A~F
    ä


    and in nano:



     ^a^b
    ^a^d
    ^a^f


    I don't remember what I had done, but it was correctly showing Japanese letters at least two days ago (and for more than 6 months).



    What could be the problem and the way to recover from this?









    share







    New contributor




    Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      todoroki@todoroki-VJZ13B ~>printf "än"
      echo "ä"
      ä
      ä
      ä
      udcc3udca4: u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093


      according to a UTF-16 decode tool, u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093 is コマンドが見つかりません (= "command not found"), which is the correct Japanese output I expect.



      From the printf and echo result, UTF-8 seems working correctly.



      This happens in all shell outputs, such as ls (Japanese characters in filenames shows up in UTF-16 hex format)



      less vi nano behaves more strange; a file (a.txt, created with gedit) like below



      あ
      い
      う
      ä


      will show as



      in less (it complains "a.txt" may be a binary file. See it anyway?):



      <E3><81><82>
      <E3><81><84>
      <E3><81><86>
      <C3><A4>


      in vi:



      �~A~B
      �~A~D
      �~A~F
      ä


      and in nano:



       ^a^b
      ^a^d
      ^a^f


      I don't remember what I had done, but it was correctly showing Japanese letters at least two days ago (and for more than 6 months).



      What could be the problem and the way to recover from this?









      share







      New contributor




      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      todoroki@todoroki-VJZ13B ~>printf "än"
      echo "ä"
      ä
      ä
      ä
      udcc3udca4: u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093


      according to a UTF-16 decode tool, u30b3u30deu30f3u30c9u304cu898bu3064u304bu308au307eu305bu3093 is コマンドが見つかりません (= "command not found"), which is the correct Japanese output I expect.



      From the printf and echo result, UTF-8 seems working correctly.



      This happens in all shell outputs, such as ls (Japanese characters in filenames shows up in UTF-16 hex format)



      less vi nano behaves more strange; a file (a.txt, created with gedit) like below



      あ
      い
      う
      ä


      will show as



      in less (it complains "a.txt" may be a binary file. See it anyway?):



      <E3><81><82>
      <E3><81><84>
      <E3><81><86>
      <C3><A4>


      in vi:



      �~A~B
      �~A~D
      �~A~F
      ä


      and in nano:



       ^a^b
      ^a^d
      ^a^f


      I don't remember what I had done, but it was correctly showing Japanese letters at least two days ago (and for more than 6 months).



      What could be the problem and the way to recover from this?







      terminal unicode





      share







      New contributor




      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.










      share







      New contributor




      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      share



      share






      New contributor




      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 5 mins ago









      Todoroki

      1




      1




      New contributor




      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Todoroki is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.

























          active

          oldest

          votes











          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          Todoroki is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f474695%2fterminal-shows-non-ascii-characters-in-utf-16-hex-codes%23new-answer', 'question_page');

          );

          Post as a guest



































          active

          oldest

          votes













          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          Todoroki is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          Todoroki is a new contributor. Be nice, and check out our Code of Conduct.












          Todoroki is a new contributor. Be nice, and check out our Code of Conduct.











          Todoroki is a new contributor. Be nice, and check out our Code of Conduct.













           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f474695%2fterminal-shows-non-ascii-characters-in-utf-16-hex-codes%23new-answer', 'question_page');

          );

          Post as a guest













































































          2HhmP2p5A5dY7t9RJzuG6VNw
          5,xgZdF7NV,vJzHx3X,e3 Ohv3rt4v,5wk7 q1Ygiq1zEiWbOjfHgyR dF0GVS 2b

          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          How many registers does an x86_64 CPU actually have?

          Displaying single band from multi-band raster using QGIS