Menu

UTF-16 support in N++

2009-04-19
2012-11-13
  • Piotr Dobrogost

    Piotr Dobrogost - 2009-04-19

    Hi

    Thanks for this great app.

    It seems there's no support for UTF-16 in N++. Is it right?

    I found only one (!) topic (over 1 year old) on this subject
    https://sourceforge.net/forum/message.php?msg_id=4640239
    and I'm observing the same (wrong) behavior from N++.

    Regards
    Piotr Dobrogost

     
    • cchris

      cchris - 2009-04-27

      You have a point. My choice of ANSI vs UTF-8 was probably hiding this issue.

      Another attempt:
      The commands in the upper part of the menu could be renamed "Translate to ...", while those on the lower part would show as "Encode using ..." .

      Rationale:
      - Encoding is something that is meant to modify a file, like changing the line endings.
      - Translating only means showing by other means, with some possibility of distortion in the binary contents (BOM or not, etc). Exactly like between two natural languages.

      CChris

       
    • cchris

      cchris - 2009-04-20

      Doesn't Format -> Encode as UCS2 Little Endian help?

      CChris

       
    • Piotr Dobrogost

      Piotr Dobrogost - 2009-04-22

      Thanks for your replay.

      No. After I choose "Encode as UCS2 Little Endian" whole text gets deleted.

      Right after opening i see for instance [NUL]H[NUL]T[NUL]T[NUL]P instead of HTTP. I guess it's not UTF-16 (UCS2) but UTF-8 written in a strange way where each character is written as [NUL][CHARACTER].
      What do you think?

       
    • mlippert

      mlippert - 2009-04-22

      Um, I just tested this w/ N++ ver 5.3.1 (Unicode) and it works fine.

      I created a new file, typed in some text, went to the Format menu and selected "Encode in UCS-2 Little Endian"

      saved the file.

      closed it in N++.

      opened it from N++. (Text looked fine)

      used the Hex-Editor plugin to verify that the file was indeed UFT-16LE. Saw that it also had a BOM (1st 2 bytes were FF FE).

      What behavior are you seeing that makes you think something is wrong and what version of Notepad++ are you using?

       
    • mlippert

      mlippert - 2009-04-22

      Oops. Sorry didn't read the linked message, so I missed that the issue is UTF-16 files that don't have a BOM.

      This is a more difficult case recognize automatically, but I agree that Notepad++ should have some way to manually tell that a particular file has a particular encoding when you open it.

      It does seem from the help that selecting "Encode in UCS-2 LE" is supposed to be how you do this, and it is definitely not working.

      I assume the "Convert to..." options are supposed to convert from the selected "Encode in..." to a new encoding, changing the bytes in memory and changing the "Encode in..." selected to the converted to target?

      BTW there is also a small error in the help's Encoding page, when it talks about the BOM added for the UTF-16 LE & BE encodings it says it is a 4-byte BOM when actually it is a 2-byte BOM. (the 4-byte BOM is only for UTF-32).

       
    • Piotr Dobrogost

      Piotr Dobrogost - 2009-04-23

      mlippert255, thanks for your help.
      I added LE BOM at the beginning and that solved the problem.

      "It does seem from the help that selecting "Encode in UCS-2 LE" is supposed to be how you do this, and it is definitely not working.

      I assume the "Convert to..." options are supposed to convert from the selected "Encode in..." to a new encoding, changing the bytes in memory and changing the "Encode in..." selected to the converted to target?"

      I'm not sure. I was looking for any help on this but couldn't find any. Does someone know where is any information on Format menu of N++?

      "BTW there is also a small error in the help's Encoding page,(...)"

      Agree. You can submit this bug using Tracker - https://sourceforge.net/tracker/?group_id=95717&atid=612382

       
    • cchris

      cchris - 2009-04-24

      While some more detailed help could be welcome, experimenting helps (and the HexEditor plugin as well).

      I created a new file, ANSI encoded, and typed a couple accented letters. In Hex view, I end up with: e0 e7 e8 e9.

      Format -> Encode to UTF8. Instead of accented letters, I get E0, E7 E8 E9 printed as control characters. Correct, these are not valid UTF8 codes.

      Format -> Convert to UTF8: the accented letters came back, but now the contents are : ef bb bf c3 a0 c3 a7 c3 a8 c3 a9

      Format -> Encode as ANSI: display now is àçèé, and the 8 bytes didn't change.

      To be honest, if I had designed it, I'd have renamed Encode as... to View as... and Convert to... as Encode with... But I didn't design it.

      CChris

       
      • Don HO

        Don HO - 2009-04-24

        > To be honest, if I had designed it, I'd have renamed Encode as... to View as...
        > and Convert to... as Encode with... But I didn't design it. 

        I have thought about these naming issues : "Encode as" should be "Interpret as". The problem is for some case, applying different interpretation make buffer dirty, then BOM is added or removed to/from the file while saving file. So the term "View" or "Interpret" may make more confuse.

        If you have a better term, I'll take it.

        Don

         
  • Florin C Bodin

    Florin C Bodin - 2011-06-14

    Hello,

    I made two paralel instalations of N++ and N++(u), so that if I cant export a file direct in UTF-8 format from another file that uses special fonts that are embeded on wikipedia (i.e. encoded in phoenician, akadian or aramaic/syriac special unicode fonts), so that I can save the file first in N++ Unicode and after I can open it in N++ and make use of all older plugins that allows me to trasform the tines of text. ;-)

    Ory. 

     
MongoDB Logo MongoDB