MAX_PATH？？

[danny1221]

先看看MSDN上的说法：
In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters.

（1）这里的characters，应该是指Unicode字符吧？
（2）如果某一个程序用VS2008编译（OS是简体中文），那么如果我用char数组接收一个路径，这个char数组最大的长度应该是
char szPath[MAX_PATH*2]吧，因为简体中文的操作系统locale的缺省非Unicode编码是用GBK，GBK编码一个中文用两个byte。

请问大家，我这两点有没有问题？？

[danny1221]

to LS：
我是想问，在一般的情况下，不考虑"Long File Names"，如果我要用char数组接收一个路径，那么这个char数组要开多大？
比如我在C盘根目录下建了一个文件，名字是：
C:\这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很长的文件名这是一个很长很长很长很.txt

这里中文有251个，非中文有7个。如果还想加长，Explorer不干。
对于这么长的文件名，显然用char szPath[MAX_PATH]是放不下的，只能装一半。。。

[LuciferStar]

这种情况真的很麻烦。你这个例子，还是在根目录，如果在其他路径下，会崩溃。
CFileDialog获取的文件名应该不存在这个问题，预先判断一下长度，然后临时new一个数组。
其他情况，真的比较头痛了。

[wltg2001]

对于这么长的文件名，显然用char szPath[MAX_PATH]是放不下的，只能装一半。。。
============
为什么放不下呢，windows下最长的路径应该不会超过260个字符啊。如果要考虑中文的话，你用WCHAR[MAX_PATH]不就行了。

[LuciferStar]

[Quote=引用 6 楼 wltg2001 的回复:]
对于这么长的文件名，显然用char szPath[MAX_PATH]是放不下的，只能装一半。。。
============
为什么放不下呢，windows下最长的路径应该不会超过260个字符啊。如果要考虑中文的话，你用WCHAR[MAX_PATH]不就行了。
[/Quote]

其实应该是单个文件最长260个字符。

[danny1221]

to LS,
我当然知道wchar_t[MAX_PATH]能装下一个一般的文件名，我只是想和大家确认下，如果用char装一个文件名，那么这个数组最大的大小应该是MAX_PATH*2。

在我的代码中，我显式地调用FindFirstFileA, FindNextFileA，我贴出来；

void GenFileList(PCSTR pszDir, PCSTR pszPrefix, std::vector<std::string> &vecFileList, std::vector<std::string> &vecLongFN)
{
	char szFileName[MAX_PATH*2];
	char szFindDir[MAX_PATH*2];
	strcpy_s(szFindDir, pszDir);
	strcat_s(szFindDir, "*");
	WIN32_FIND_DATAA wfd;
	HANDLE hFind = hFind = FindFirstFileA(szFindDir, &wfd);
	if (hFind != INVALID_HANDLE_VALUE)
	{
		do
		{
			if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
			{
				if (wfd.cFileName[0] == '.')
				{
					if (wfd.cFileName[1] == '\0' || (wfd.cFileName[1] == '.' && wfd.cFileName[2] == '\0'))
					{
						continue;
					}
				}
				else
				{
					sprintf_s(szFileName, "%s%s\\", pszPrefix, wfd.cFileName);
					char szChildDir[MAX_PATH*2];
					sprintf_s(szChildDir, "%s%s\\", pszDir, wfd.cFileName);
					GenFileList(szChildDir, szFileName, vecFileList, vecLongFN);
				}
			}
			else
			{
				char* dot = strrchr(wfd.cFileName, '.');
				if (dot && std::binary_search(pMainDlg->m_vecAcceptExts.begin(), pMainDlg->m_vecAcceptExts.end(), dot+1, compare_without_case()))
				{
					sprintf_s(szFileName, "%s%s", pszPrefix, wfd.cFileName);
					if (strlen(szFileName) > MAX_FI_PATH-1)
					{
						vecLongFN.push_back(szFileName);
					}
					else
					{
						vecFileList.push_back(szFileName);
					}
				}
			} 
		} while (FindNextFileA(hFind, &wfd));

		FindClose(hFind);
	}
}

我的意思是我开的这些char buffer，最大的长度应该是MAX_PATH*2，如果用MAX_PATH，碰到一个变态长的文件名，显然是不够。。

[danny1221]

代码编译时用的字符集是Unicode

[ARPGGAMEDVP]

如果你要接收一个文件名，可以用MAX_PATH
但是路径的话，还是用类似string对象吧。
除非你可以保证，你不会用很长的路径。

[LuciferStar]

哦，那只需要MAX_PATH。
char和wchar，只是表现在存储上，长度的计数，在使用的时候，没差别。

[woxoxow]

如果文件路径很长的话，
操作系统的工作就会不正常，
我遇过这样的问题，
在删除一个目录时，
操作系统报告有一个文件删不了，
原因是这个文件的路径太长了，
然后我把它的某一个父目录剪裁到根目录，
剪裁出的目录可以删除，
原来删除不了的目录也可以删除了。
由此可见WinXP的API无法处理太长的路径。

[LuciferStar]

试试用//?/前缀。

[LuciferStar]

打错了，是\\?\

http://hi.baidu.com/singlestudio/blog/item/9a8bf954bc6523193a2935f2.html

[na2650945]

[Quote=引用 2 楼 wltg2001 的回复:]
你弄错了，MAX_PATH只不过是一个常量而已，相当于
#define MAX_PATH 260
与UNICODE与ANSI并没有太多的关系。
[/Quote]
恩。
恩。
可以是char path[MAX_PATH];
或者wchar_t path[MAX_PATH];

[muzizongheng]

你只要TCHAR szTemp[MAX_PATH]就可以了。 不是长度的常量不对， 而是你申请的内存不对。

[luckysym]

只能说楼主看书只看一半。

WinAPI CreateFile函数中，对于第一个参数lpFileName明确指出：
In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path.

翻译就是，在ANSI版本的CreateFile函数（即CreateFileA），则文件全路径最长是MAX_PATH个字符。而对于UNICODE版本的CreateFile函数(即CreateFileW)，则可以支持32K字符长度。
那么即说明Windows本身支持的文件路径全长为32K，只是为了向下兼容，ANSI版本的只支持MAX_PATH（260）个字符。

[luckysym]

所以，既然MAX_PATH只对ANSI版本有效，那么所谓的characters，就无所谓单字节双字节。因为ANSI版本是采用多字节编码，那么，在分配空间时，只需要分配MAX_PATH个字节即可，无需考虑双字节问题。

[蠓虫带着秤砣飞]

汗，我一直自己认为MAX_PATH是255...没细看过MSDN。

[bulerain]

char szPath[MAX_PATH*2] ??
你Y的是在偷换概念还是真的不知道
你看看 char str[MAX_PATH]和 WCHAR wstr[MAX_PATH] 是不是装一样多的字符？

但是，一个char的sizeof确实是1，一个WCHAR是2，
说到动态分配内存 如果从 char* ps= new char[260]; 一样的，WCHAR* ps= new WCHAR[260];
也是一样，
如果是用malloc alloc heapalloc之类，也一样

如果从char 转wchar ，或是wchar转char 就需要考虑了

[lwbeyond]

MAX_PATH 就是个数字 260 , 与UNICODE与ANSI并没有太多的关系.

如果你怕不够, 你可以自己定义长度 char szPath[1000] 无所谓.

[ddc]

曾经为这个问题改了不少代码,260不够,需要520.驱动送上来的路径转成char会超过.原因不祥,回头我去问问.
如果是3环调API,260够了,定义如此.

[danny1221]

恩，谢谢大家，自己试验过明白了。。
比如在C盘下建一个很长名字的文件（转换成char后的长度远大于MAX_PATH个bytes）
零一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十.txt
使用FindFirstFileA无法找到这个名字过长的文件。
最后GetLastError() = 234(ERROR_MORE_DATA).
原因嘛应该就是
WIN32_FIND_DATAA的CHAR cFileName[ MAX_PATH ];成员装不下这个长家伙。。。