📄 long filename specification.htm
字号:
<TR>
<TD align=middle>11 </TD>
<TD align=middle>byte </TD>
<TD align=left> Attribute (<CODE>00ARSHDV</CODE>) </TD></TR>
<TR>
<TD align=middle>12 </TD>
<TD align=middle>byte </TD>
<TD noWrap align=left> NT (Reserved for WindowsNT;
<BR> always 0) </TD></TR>
<TR>
<TD align=middle>13 </TD>
<TD align=middle>byte </TD>
<TD align=left> Created time; millisecond portion </TD></TR>
<TR>
<TD align=middle>14 </TD>
<TD align=middle>word </TD>
<TD align=left> Created time; hour and minute </TD></TR>
<TR>
<TD align=middle>16 </TD>
<TD align=middle>word </TD>
<TD align=left> Created date </TD></TR>
<TR>
<TD align=middle>18 </TD>
<TD align=middle>word </TD>
<TD align=left> Last accessed date </TD></TR>
<TR>
<TD align=middle>20 </TD>
<TD align=middle>word </TD>
<TD noWrap align=left> Extended Attribute
<BR> (reserved for OS/2; always 0) </TD></TR>
<TR>
<TD align=middle>22 </TD>
<TD align=middle>word </TD>
<TD align=left> Time </TD></TR>
<TR>
<TD align=middle>24 </TD>
<TD align=middle>word </TD>
<TD align=left> Date </TD></TR>
<TR>
<TD align=middle>26 </TD>
<TD align=middle>word </TD>
<TD align=left> Cluster </TD></TR>
<TR>
<TD align=middle>28 </TD>
<TD align=middle>dword </TD>
<TD align=left> File Size </TD></TR></TBODY></TABLE></CENTER></DIV>
<P>In any case, this new 8.3 filename format is the format used with the LFN. As
for the LFN format itself (seen </A><A
href="http://home.teleport.com/~brainy/lfn.htm#organization">previously</A>) is
stored "backwards", with the first entry toward the bottom and the last entry at
the top, right above the new 8.3 filename entry. </P>
<P>Each LFN entry is stored as follows: </P>
<DIV align=center>
<CENTER>
<TABLE width="80%" border=1>
<TBODY>
<TR>
<TH align=middle width="15%">Offset </TH>
<TH align=middle width="15%">Length </TH>
<TH align=left width=*> Value </TH></TR>
<TR>
<TD align=middle>0 </TD>
<TD align=middle>byte </TD>
<TD align=left> Ordinal field (desc. below) </TD></TR>
<TR>
<TD align=middle>1 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 1 (desc. below) </TD></TR>
<TR>
<TD align=middle>3 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 2 </TD></TR>
<TR>
<TD align=middle>5 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 3 </TD></TR>
<TR>
<TD align=middle>7 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 4 </TD></TR>
<TR>
<TD align=middle>9 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 5 </TD></TR>
<TR>
<TD align=middle>11 </TD>
<TD align=middle>byte </TD>
<TD align=left> Attribute </TD></TR>
<TR>
<TD align=middle>12 </TD>
<TD align=middle>byte </TD>
<TD align=left> Type (reserved; always 0) </TD></TR>
<TR>
<TD align=middle>13 </TD>
<TD align=middle>byte </TD>
<TD align=left> Checksum (desc. below) </TD></TR>
<TR>
<TD align=middle>14 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 6 </TD></TR>
<TR>
<TD align=middle>16 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 7 </TD></TR>
<TR>
<TD align=middle>18 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 8 </TD></TR>
<TR>
<TD align=middle>20 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 9 </TD></TR>
<TR>
<TD align=middle>22 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 10 </TD></TR>
<TR>
<TD align=middle>24 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 11 </TD></TR>
<TR>
<TD align=middle>26 </TD>
<TD align=middle>word </TD>
<TD align=left> Cluster (unused; always 0) </TD></TR>
<TR>
<TD align=middle>28 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 12 </TD></TR>
<TR>
<TD align=middle>30 </TD>
<TD align=middle>word </TD>
<TD align=left> Unicode character 13
</TD></TR></TBODY></TABLE></CENTER></DIV>
<P>Throughout this entry, you see "unicode characters". Unicode characters are
2-byte long characters (as opposed to ASCII characters that are 1-byte long
each) that support not only traditional latin alphabet characters and arabic
numbers but they also support the languages of the rest of the world, including
the CJK trio (Chinese, Japanese, Korean), Arabic, Hebrew, etc. Plus you have
some space left over for more math and science symbols. Unicode characters are
still going through revisions (on their second revision as I am writing, I
believe) but Windows95 has left spaces to more fully support unicodes in the
future. You can keep up with the Unicode development by visiting the Unicode
webpage at <A href="http://www.unicode.org/">http://www.unicode.org/</A>. Note
that, in the 2-byte unicode character, the first byte is always the character
and the second byte is always the blank, as opposed to having the first byte
blank and the second byte blank. There is a perfectly logical explanation for
this but it's kind of long to get into at the moment so e-mail me if you are
curious. (If you have a computer dictionary, look up "little endian" and it'll
explain everything.) For our purposes, though, just treat every other word as an
ASCII character as long as the following byte is a blank character. Anyways,
notice that, in order to maintain the compatibility with older programs, the
attribute byte and the cluster word had to be kept. Because of this, each
unicode character had to be scattered throughout the entry. </P>
<P>By now you probably noticed that there is no file information (size, date,
etc.) stored in the LFN entry. Any information about the file itself is stored
in the 8.3 filename, located below all the LFN entries (as <A
href="http://home.teleport.com/~brainy/lfn.htm#organization">mentioned
before</A>). </P>
<P>The checksum is created from the shortname data. The steps/equation used to
calculate this checksum is as follows: </P>
<DIV align=center>
<CENTER>
<TABLE width="80%" border=1>
<TBODY>
<TR>
<TH>Step # </TH>
<TH>Task </TH></TR>
<TR>
<TD align=middle>1 </TD>
<TD align=left> Take the ASCII value of the first character.
This is your first sum. </TD></TR>
<TR>
<TD align=middle>2 </TD>
<TD align=left> Rotate all the bits of the sum rightward by
one bit. </TD></TR>
<TR>
<TD align=middle>3 </TD>
<TD align=left> Add the ASCII value of the next character with
the value from above. This is your next sum. </TD></TR>
<TR>
<TD align=middle>4 </TD>
<TD align=left> Repeat steps 2 through 3 until you are all
through with the 11 characters in the 8.3 filename.
</TD></TR></TBODY></TABLE></CENTER></DIV>
<P align=center>In C/C++, the above steps look like this: </P>
<DIV align=center>
<CENTER>
<TABLE width="80%" border=0>
<TBODY>
<TR>
<TD><BR><CODE>for (sum = i = 0; i < 11; i++) {</CODE>
<BR><CODE> sum = (((sum & 1) << 7) |
((sum & 0xfe) >> 1)) + name[i];</CODE> <BR><CODE>}</CODE>
</TD></TR></TBODY></TABLE></CENTER></DIV>
<P>This resulting checksum value is stored in each of the LFN entry to ensure
that the short filename it points to indeed is the currently 8.3 entry it should
be pointing to. </P>
<P>Also, note that any file with a name that does not fill up the 8.3 spaces
completely leaves a trace of space characters (ASCII value 32) in the blank
spaces. These blank spaces do go into the calculation of the checksum and does
not get left out of the calculation. </P>
<P>I'm sure you're dying to know what the ordinal field is. This byte of
information tells the order of the LFN entries (1st LFN entry, 2nd LFN entry,
etc.) If it's out of order, something is wrong! How Windows95 would deal with
LFN when such a thing happen is a mystery to me. <BR> An example of
how ordinal field work: The first LFN entry, located at the very bottom as we
have <A href="http://home.teleport.com/~brainy/lfn.htm#organization">seen
before</A>, has an ordinal field value 1; the second entry (if any -- remember
that a LFN doesn't always have to be tens of characters long), located just
before the first entry, has an ordinal field value of 2; etc. As an added
precaution, the last entry has a marking on the ordinal field that tells that it
is the last entry. This marking is done by setting the 6th bit of the ordinal
field. </P>
<P>That is basically all there is to long filenames. But before we end this
conversation (while we're on the subject of LFN,) I think it would be
interesting to note that, since any long filename can be up to 255 bytes long
and each entry can hold up to 13 characters, there can only be up to 20 entries
of LFN per file. That means it only needs 5 bits (0th bit to 4th bit) of the
ordinal field. And with the 6th bit used to mark the last entry, two bits are
left for open usage -- the 5th and the 7th bit. Whether or not Microsoft is
going to do anything with these bits -- or why Microsoft used the 6th bit to
indicate the last entry instead of 7th or 5th bit and limited the file length to
255 bits -- remains to be a mystery only Microsoft will keep to itself. </P>
<HR>
<H3>Credit</H3>
<P><FONT size=-1>Much the information in this documentation has been gathered
from Norton Utilities for Windows95 user's manual. Detailed researches were done
using Norton Utilities Disk Edit. The checksum calculation was graciously
donated by Jacob Verhoeks to <CODE>comp.os.msdos.programmer</CODE> Newsgroup as
a reply to my request. Apparently the file Mr. Verhoeks used to get me the
checksum code, <CODE>vfat.txt</CODE>, that comes with newer Linux operating
systems have some good information on Windows95 LFN. BTW, I just (like, right
now) found out that checksum algorithm is also in Ralf Brown's Interrupt List.
</FONT></P>
<HR>
<P>Copyright ?996-1998 vinDaci </P></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -