要使用UTF-16通过Unicode代码点进行搜索,您可以使用(\x{FEC1}
),无论文件是使用UTF-8还是UTF-16进行编码,它都能正常工作。
请记住,您不需要使用UTF-8代码进行搜索,因为您可以使用UTF-16代码进行搜索。但是要解决你的问题的一部分,询问你如何通过UTF-8代码搜索该字符...
你不能。嗯,你可以,但这是一个可怕的黑客,你真的不应该。
尝试的显而易见的事情是\xef\xbb\x81
在您的UTF-8编码文档中搜索,但这不起作用。(注意这里没有{}
:Notepad ++ \xNN
要求2个十六进制数字或\x{NNNN}
4个十六进制数字)。这是因为Notepad ++实际上并不搜索字节值,而是搜索Unicode代码点。因此,您可以搜索代码点U + FEC1,但不能搜索UTF-8字节0xEF 0xBB 0x81,因为Notepad ++会“隐藏”您的编码详细信息。(因为在几乎每种情况下,编辑文本文件的人都会更关心查找实际字符而不是查找UTF-8字节。)
你可能会尝试另一种技巧,即采用UTF-8编码文件并选择Encoding → Encode in ANSI
菜单选项,此时该选项ﻁﻁﻉﻁﻉﻁﻉ
似乎成了ï»ï»ï»‰ï»ï»‰ï»ï»‰
。(我说“似乎变成”而不是“成为”因为......好吧,请继续阅读。)这是因为它已经采用了你的文件的UTF-8文本,并将其重新解释为“ANSI”(这是一个可怕的编码名称,因为它完全错误,应该真的称为“Windows-1252”,但这是一个不同的问题)。(顺便说一句,ﻁﻁﻉﻁﻉﻁﻉ
在我的文本中向后看的原因比在屏幕截图中看起来那样:那是因为Notepad ++并不关心阿拉伯语是从右到左书写的,所以它按照粘贴到文件中的顺序从左到右显示字符。但是你的浏览器我们非常关心以正确的从右到左的顺序呈现阿拉伯语,该字符串的前两个字母(ﻁﻁ
)出现在字符串的右侧,而不是在左侧,就像它们在Notepad ++中所示。抛开弃儿,这就是为什么这会有所帮助。在“ANSI”(实际上是Windows-1252)编码中,每个字节都是单个字符,因此现在您将能够按单个字节进行搜索。现在,如果你搜索\xef\xbb\x81
(不需要是正则表达式,只是一个“扩展”搜索),它将找到字符。有点。它看起来像它突出了两个字符ï»
,但它确实突出3个字符:ï
,»
,和一个“看不见”0x81
不存在的角色。(因为在Windows-1252编码中没有任何字符0x81
:请亲自看看。)现在你明白为什么我说“似乎变成了” - 因为你的UTF-8编码文本确实变成了ï»_ï»_ﻉï»_ﻉï»_ﻉ
,其中_
代表了一种“看不见的” “Windows-1252代码页中未正式存在的字符。无论如何,既然您已经在Windows-1252中找到了三个字符的序列,其字节值为0xEF,0xBB和0x81,而Notepad ++已经突出显示它们,您可以选择Encoding → Encode in UTF-8
菜单选项,您的文本将自身转换回UTF -8,而Notepad ++将突出显示在同一个地方 - 因此,你'ﻁ
那么为什么我说你真的不应该这样做呢?因为它工作的唯一原因是当你切换代码页时,Notepad ++ 没有做正确的事情。找到丢失字符时正确的做法是抱怨,或者插入像Unicode替换字符这样的字符�
(或者?
如果你在遗留的代码页中没有插入一个简单字符�
),或者做一些事情以便用户将知道他们的文本中有无效字符。永远不应忽略错误,并且0x81
在Windows-1252文本中具有值是错误的。这个技巧起作用的唯一原因是因为Notepad ++对无效字符做错了(也就是说,它忽略了它们)。所以你真的不应该依赖这个技巧:随着Notepad ++的任何更新,它可能会改变其未记录的(和错误的)行为,并开始在错误编码的文本中放置正确的替换字符,此时此技巧将失败。坚持搜索真正的Unicode代码点,你会好得多。
顺便说一句,你原来的尝试([\uFEC1]
)失败的原因是因为,根据Notepad ++的正则表达式语法,\u
意思是“大写字母”。(请记住,在正则表达式中,括号代表“任何这些字符”)。文档进一步说,“请参阅关于小写字母[sic]字母的注释”,并且关于小写字母的注释说“如果”匹配大小写“搜索选项关闭,则”将会回到“单词字符”。就像在截图中一样。因此,正则表达式[\uFEC1]
正在搜索“任何单词字符,或F,或E,或C,或1” - 它匹配示例文本中的每个单个字符。
Phew,对我所说的“非常简单”来说,这是一个很长的答案。我希望这有助于你更好地理解Unicode; 如果是这样的话,那我打字的时间就是值得的。