Hello Dan,

Well, starting with the v6.8.1 version of N++, the main menu Encoding has been, slightly, changed :

Before the v6.8.1 version, the Encode lines were Encode in ANSI, Encode in UTF-8 without BOM, Encode in UTF-8, Encode in UCS-2 Big Endian and Encode in UCS-2 Little Endian. And idem, for the Convert lines.

From the v6.8.1 version, the Encode lines are Encode in ANSI, Encode in UTF-8, Encode in UTF-8-BOM, Encode in UCS-2 BE BOM and Encode in UCS-2 LE BOM. And idem, for the Convert lines.

NOTES :

The BOM, also called Byte Order MArk, is an invisible character, of Unicode code point \xFEFF, which helps the application to detect the right encoding of the current file, as well as the Most and the Least significant bytes of the characters, in that file.

So, depending of the Unicode encoding used, the representation of the hidden BOM character, beginning the file is :

The two bytes FE FF in the UCS-2 BE BOM

The two bytes FF FE in the UCS-2 LE BOM

The three bytes EF BB BF in the UTF-8 BOM encoding

REMARKS :

The UTF-8 sequence EF BB BF is just the UTF-8 transformation format of the UNICODE value of the BOM ( FE FF ) !

The N++ encoding, simply called UTF-8, means that all the characters of the file are UTF-8 encoded, but NO BOM is added, at the very beginning of the file. That’s the UNIQUE difference with the strict UTF-8-BOM encoding !

Best Regards,

guy038

Hello Boliusa bol,

I really wonder how you could find your Arabic characters with that syntax [\ufec1], or even \ufec1 !?

With the BOOST regex library, used from N++ v6.00, I think that the right syntax, to find your two characters, should be \x{fec1} and \x{fec9}.

Your characters are part of the Arabic Presentation Forms-B table, from FE70 to FEFF, at the address, below :

http://www.unicode.org/charts/PDF/UFE70.pdf

Secondly, don’t forget that, in N++, the search is oriented characters and NOT bytes. So, when you search for \x{fec1}, in a file, with an UTF-8 encoding, the regex engine looks for the three consecutive bytes efbb81, which represents the ONLY Arabic character ﻁ

Note that :

With the UCS-2 BE encoding ( Low Endian ), this character would have been encoded with the two bytes C1FE

With the UCS-2 LE encoding ( Big Endian ), this character would have been encoded with the two bytes FEC1

And it good to remind what is the difference, between the UTF-16 and USC-2 encodings :

With the UCS-2 encodings, supported by Notepad++, you can encode any character, from UNICODE code-point \x0 to \x{FFFD}

With the UTF-16 encodings, NOT supported by Notepad++, you can encode ALL UNICODE code-points, from \x0 to \x{10FFFD}, with the surrogate pairs mechanism.

BTW, in N++, the regex syntax \x{...} does NOT work, presently, for code-points over FFFF !

Now, if N++ search is “characters” oriented, how to detect the individual bytes of some characters of an UTF-8 file ? It’s normally impossible and it’s rather useless to do so ! Indeed, with the only syntax \x{fec1}, you’ll always find your ARABIC LETTER TAH ISOLATED FORM, as long as your file’s encoding is an UNICODE encoding !

If you really want to see the individual bytes of an UTF-8 file, just choose the option Encode in ANSI :

For instance, let’s suppose that you have an UTF-8 file with the ONLY ARABIC LETTER AIN ISOLATED FORM : ﻉ. Once you chose the menu option Encoding - Encode in ANSI, it will display the three-characters string ﻉ.

And, as the UTF-8 representation of this character is EF BB 89, it’s easy to verify that the simple regex search of \xEF\xBB\x89 does find the string ﻉ

By the way, here is, below, a very nice Internet tool to get the main informations for each UNICODE character. By default, you must type, on top of the page, the UNICODE hexadecimal code-point of your character ( For instance fec9 ), but you may select one of the six other proposed interpretations :

http://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?

Hope that this post will be useful to you, anyway !

Best Regards,

guy038

P.S. :

Waooh, by chance, the Windows ANSI Code Pages 1252 ( Latin 1 ) and 1256 ( Arabic ) have a same representation, for the three characters, of code \xEF, \xBB and \x89 !

To that purpose, consult the different Windows encodings, below :

https://msdn.microsoft.com/en-us/goglobal/bb964654

I’m not entirely sure what you are asking for, but perhaps if you check the “Wrap around” checkbox in the Find dialog you’ll eventually find what you are looking for…

Hi,

no such problem for me. Tested on Notepad++: v6.8.3 @ Windows 7 x64.

Maybe try also on another PC, mouse, … . Or try to be more specific about your release, programming language, …? Provide more info how to reproduce this issue.

@donho : Thank you very much! Tested, and it works perfectly.

One more question: Do you prefer to post suggestions/bugs here on community, or on GitHub? So I know what is better for you, not to complicate things.
If here, maybe it would be nice to have separated section for it? Or maybe even type of comments, so I can set it as resolved ;). Something like questions. But maybe I’m just thinking too much ;).

@dail : Sure, it would be also nice feature, to close selected text to typed delimiter.

Also one more suggestion for this feature in auto-insert for html/xml close tag. Let’s say we have any xml:

<node name="abc"/>

Then I’d like to add > as value, right after c. Or better say to “value” part. Just to use it while writing regular expression etc… I will get:

<node name="abc></node>"/>

So maybe to ignore this feature even in this case. Sure it’s not best to add non-xml-correct character as value. But I type it normal way. And after it’s done, I use plugin XML Tools -> Convert selection XML to text (). But on the other hand, maybe this is just my different approach, that is not needed globally. Still maybe also others would like to don’t auto-close xml tag while in value area?

Hi,

as far as I see it works in version v6.8.3. It is just not so nice visualized, but moving tabs can be done. Just check that you have UNchecked option Preferences -> General -> Tab Bar -> Lock (no drag and drop).