随手写个非递归枚举所有文件的程序, 大家评评

walleeee

回复 59# 三月廿七


    这是unsigned short

walleeee

回复 56# 三月廿七


    算了。总之，你要明白A/W/T之间的区别联系，以及wchat_t和unicode的区别联系，以及中文和字符集的联系关系。这些都要明白。

walleeee

回复 58# 三月廿七


T系类型有_UNICODE宏来生效控制。所以ms在某些方面来说设计就是一塌糊涂，六朝余孽。

几个月前我跟ow这货就说了，要不就utf8，要不就干脆utf32，这2个我都能接受，前者为了存储效率，后者为了计算效率，自己选择。至于其他gbk...xxxxx等等，都是糟粕，都是造轮子，都是在给自己造城墙，把自己关起来

三月廿七

walleeee 发表于 2012-05-13 16:07
回复 56# 三月廿七

其实，我只要支持中文就行了，
反正，我就是囫囵吞枣写代码，效果出来就行

walleeee

回复 64# 三月廿七


支持中文？唉

什么叫支持中文？什么叫中文？其实计算机的字典里面根本就没有中文这个说法，甚至英文也没有，什么都没有。

中文，英文，以及其他，都是认为规定，你说叫中文就叫中文，我说叫中语，也叫中语，这是一个约定。

三月廿七

walleeee 发表于 2012-05-13 16:15
回复 64# 三月廿七

意思就是有某个汉字所对应的位图的编码，

walleeee

回复 66# 三月廿七


我们还是有很大不同。

我写程序要反复推敲很久，接口也是繁复权衡，重写那是家常便饭，有时甚至宁愿不写也不写个就交了，大概是因为我们环境不同，我没有谁逼迫，没人给我deadline。而你有，所以我也理解你。

三月廿七

回复 27# walleeee


你是觉得这种函数名太长了嘛？  gtk_color_button_new_with_color  
GTK 名称长而不乱，我比较欣赏
我以前写的函数前面还加公司名，虽然我一开始也不怎么习惯，写多了就习惯了，

OwnWaterloo

三月廿七 发表于 2012-05-13 15:52
这代码哪里不正确了？ 你唧唧歪歪什么呀？

A/W/T不分，cp936也不明白，与字符、编码相关的问题一团浆糊的人，还强力测试
真当测试是无脑的工作吗？

凡涉及"字符"串，每一步的输入需要什么、输出给的什么？如果不从每一步弄明白，只看最终结果的人，一辈子都别想搞清楚这些概念。
哥今天免费教你对待字符问题应该细致到什么程度，也免费给你几个测试用例。


代码：

1. 
   
2. #include <stdio.h>
   
3. #include <string.h>
   
4. 
   
5. #define WIN32_LEAN_AND_MEAN
   
6. #include <windows.h>
   
7. 
   
8. int main(void)
   
9. {
   
10.       int a;
    
11.       WIN32_FIND_DATA data;
    
12.       HANDLE h = FindFirstFile(TEXT(".\\*"), &data);
    
13. 
    
14.       if (h==INVALID_HANDLE_VALUE)
    
15.             return -1;
    
16.       else do {
    
17.             TCHAR const* p = data.cFileName;
    
18.             for (; *p; ++p)
    
19.                   printf("%02x ", (unsigned)*p);
    
20.             printf("\n");
    
21.       } while (FindNextFile(h,&data));
    
22.       a = GetLastError() != ERROR_NO_MORE_FILES;
    
23.       CloseHandle(h);
    
24. 
    
25.       return a;
    
26. }
    

复制代码

编译出A与W版本：

1. 
   
2. cl /W3 /O2 /FelistA.exe /UUNICODE /U_UNICODE list.c
   
3. cl /W3 /O2 /FelistW.exe /DUNICODE list.c
   

复制代码

输入有FindFirstFileA与FindFirstFileW：
1. 前者（在中文版Windows里，下同）接受cp936
TEXT(".\\*"展开为".\\*"确实是字符串.\*在cp936编码下的结果。

2. 后者接受utf16
TEXT(".\\*"展开为L".\\*"也确实是字符串.\*在utf16编码下的结果。


输出有FindFirstFileA/W与FindNextFileA/W。
为了查看输出的内容，直接按十六进制（而非字符）输出其内容。


测试用例：
1. ©
创建一个叫这个名字的文件。
listW.exe 就可以输出 a9， 这也是©在utf16编码下的结果， W版本输出utf16编码的结果。
而listA.exe 输出 3f 。知道这是什么吗？ 这是?在cp936编码下的结果。 cp936不包含©这个字符。
懂我46楼在说什么了吗？ 如果文件名不能用cp936编码， A版本的函数就没法输出， 只能替换成一个问号。

2. 其他汉字
关于©，我帮你找一个借口： 它不是中文。 问题是，如果文件名包含了©，你就不打算支持了对不对？
为了避免你用这些借口， 我还给你找了其他一些不能用cp936编码的汉字：䥺。
另外几个直接给你unicode code point，因为chrome上显示不出34c5 34cb 36b7 36a3 36b8 434f 48bc。用vim的你应该知道怎么怎么输入。

W版本会输出utf16编码，而A版本依然替换成问号。



PS：连问题都搞不明白还强力测试，你不觉得可笑吗？

三月廿七

OwnWaterloo 发表于 2012-05-13 19:04
A/W/T不分，cp936也不明白，与字符、编码相关的问题一团浆糊的人，还强力测试
真当测试是无脑的 ...

谢谢，谢谢，
反正， 我是一辈子都搞不清了