命令如何查找有中文字符的行

yjqd

命令如何查找有中文字符的行

test.txt内容如下：

Meng said the commission will step
one 129 ok
two78kl
three99 88 ui
thre99 88 ui6
bk高兴oewp
89爵士io
12听99

szwp

bjay2008xmy 发表于 2022-5-23 11:24
%u4e00是UTF-8编码，如果用这个编码判断的话，样本的编码也应该要使用UTF-8编码

等你发示例教程教大家。

szwp

bjay2008xmy 发表于 2022-5-22 20:40
你这种方法应该是把样本和TXT里面的汉子逐一对比吧，看符不符合TXT里面的。如果样本有200个字符的话，不 ...

这个计算是错误的。学习正则重要的是自己尝试，别人常用的，是他们的环境。findstr需要/R选项才能使用正则表达式，这种说法是错误的，东西要靠自己尝试结果，转发未经核实的太浪费屏幕空间，也会误导。
你还需要补充中文的编码知识，\u4e00 明显不是GB码。GB2312的中文范围俺已经在47楼说了，仔细往下看贴。

初学者能掌握findstr的正则就能满足常用需求了，findstr /?里有 [x-y]    范围: 在指定范围内的任何字符
本题实际是一个xy的求解。上面发的findstr "[^'-Z]" ，你试了没有，这就是没有/R的正则表达式。

dos时代菜鸟

nttwqz 发表于 2022-5-22 11:50
那就用goto跳出for循环。
你觉得用了call貌似觉得提高了效率，很可能效率反而更低。实际使用中，谁也不 ...

确实如此，因为 call 本身就是一个耗时的指令，他相当于 变相调用 了一次 cmd 。
我用 call 并不是因为效率，只是  书写上的习惯，习惯 模块化 函数化 了。容易 模块化的 修改和 理解。

当然，对于这样单一目的的，确实没必要 搞一个函数来调用。

szwp

nttwqz 发表于 2022-5-22 13:22
还是我以前想的方法简单

pushd %~dp0

只考虑常用汉字的话，gb2312够了。
主要看实际样本范围有多大。

szwp

正则史比WIN史长。

szwp

bjay2008xmy 发表于 2022-5-22 10:49
找个对正则匹配完全支持的命令行程序

不可能有完全支持的，就像要将win98或更前的exe放到11里运行，东西在发展，没结束前，哪有完全。
微软自家不同产品里的正则互相也不完全兼容。各种正则的原理不一样，查找的方式也不一样。

nttwqz

还是我以前想的方法简单

pushd %~dp0
findstr /i /g:GBK汉字.txt a.txt

GBK汉字.txt从网上搜集并整理，2万+汉字，删除了部分变成英文？并且英文？能匹配的“汉字”，有精力和条件的或者需要结果特别严禁精确的可以进一步整理，不过个人感觉，一般用途足够了，毕竟常用汉字才几千个。


GBK汉字.txt下载
GBK汉字_findstr匹配适用_GBK.7z (10.48 KB, 下载次数: 1)

2022-5-22 13:11 上传

点击文件名下载附件
下载积分: 无忧币 -2

nttwqz

dos时代菜鸟 发表于 2022-5-22 10:04
用call 主要用到 exit /b
如果 直接用 for ，就得用 goto

那就用goto跳出for循环。
你觉得用了call貌似觉得提高了效率，很可能效率反而更低。实际使用中，谁也不可能每次都测试不同写法的执行效率，所以还是少用为好。而且，你这也没到了需要权衡利弊到底用不用call的时候，完全可以不用。

1000时，不用call用时60毫秒，用call用时2120毫秒，是不用call的35倍。

1. 10:59:54.53
   
2. 10:59:54.59
   
3. 10:59:56.71
   
4. 请按任意键继续. . .

复制代码

1. @echo off
   
2. 
   
3. echo;%time%
   
4. for /l %%a in (1 1 1000) do (
   
5.     echo;%%a
   
6. )>nul
   
7. echo;%time%
   
8. for /l %%a in (1 1 1000) do (
   
9.     call :echoecho %%a
   
10. )>nul
    
11. echo;%time%
    
12. pause
    
13. 
    
14. exit
    
15. 
    
16. :echoecho
    
17.     echo;%~1
    
18. goto :eof

复制代码

szwp

在中文全集中找太慢了吧

dos时代菜鸟

nttwqz 发表于 2022-5-22 09:55
尽量少在for中使用call，遍历内容较少时没什么，多的时候很影响效率，你用for /l直接echo和call方式echo ...

用call 主要用到 exit /b
如果 直接用 for ，就得用 goto

窄口牛

英文没有一个占两个或者两个字节以上的哇，这是不是个突破点？

nttwqz

dos时代菜鸟 发表于 2022-5-21 22:05
这也是个思路

尽量少在for中使用call，遍历内容较少时没什么，多的时候很影响效率，你用for /l直接echo和call方式echo一试便知。

szwp

dos时代菜鸟 发表于 2022-5-21 22:05
这也是个思路

当集合较大时，还是判断范围方便。这样可将16区前的全角符号制表符也排除了。

dos时代菜鸟

szwp 发表于 2022-5-21 20:45
也可试下非排除法，判断字符是否 >=啊

这也是个思路

1.     @echo off
   
2.     setlocal ENABLEDELAYEDEXPANSION
   
3.     set file1=test.txt
   
4.     for /f "delims=" %%c in ('type !file1!') do (
   
5.         call :str_x "%%c"
   
6.         if !found0! EQU 1 ECHO [%%c]
   
7.     )
   
8. 
   
9.     pause
   
10.     goto :eof
    
11. 
    
12.     :str_x
    
13.         set "str1=%~1"
    
14.         SET found0=0
    
15.         set n=0
    
16.         :loop1
    
17.         for %%i in (!n!) do (
    
18.             set ch=!str1:~%%i,1!
    
19.             if "!ch!"=="" exit /b
    
20.             if not "!ch!"=="" (
    
21.                 if "!ch!" GEQ "啊" ( if "!ch!" LEQ "齄" (
    
22.                     set found0=1
    
23.                     exit /b
    
24.                 ))
    
25.             )
    
26.         )
    
27.         set /a n +=1
    
28.         goto loop1
    
29.     exit /b

复制代码

szwp

dos时代菜鸟 发表于 2022-5-21 10:08
还是要搞个 非中文的 字符集，做排除用。 比如英文的字符集

也可试下非排除法，判断字符是否 >=啊 <=齄

窄口牛

简体转繁体就是吧，常用字对应。

nttwqz

dos时代菜鸟 发表于 2022-5-21 10:08
还是要搞个 非中文的 字符集，做排除用。 比如英文的字符集

我曾经就有个奇葩的想法，把GBK中的所有中文相关字符都弄到一个记事本中用来匹配。。。

dos时代菜鸟

还是要搞个 非中文的 字符集，做排除用。 比如英文的字符集

szwp

bjay2008xmy 发表于 2022-5-20 21:51
这确实是个好办法，解决问题的思路要比方法更重要

findstr "[^'-Z]"

findstr里字符的顺序不是标准的ascii，你可以搞个脚本将顺序搞出来比较。

以前叫纯中文，现在叫全角的，里面也包含数字英文符号制表符等，是否认为是中文得看你的需求，东西得靠自己调试。

窄口牛

能搞定吗？需要整理直播列表用。

szwp

bjay2008xmy 发表于 2022-5-20 13:59
没有通用的吗，我还以为有通用的不仅限于此例样本的正则表达式

findstr /rc:"[^'-Z]"

任何东西都离不了环境。

szwp

bjay2008xmy 发表于 2022-5-20 13:50
那有没有应用在此例中专门识别中文的正则表达式

中文数量显然远大于英文，用排除法省事。按3楼提示操作方便。
你要提供原始数据和结果数据以附件形式发上来试，因为已经变动过样本数据，不方便确定，他要大写还是小写了。