exFAT-Dateisystemspezifikation

1 Einführung

Das exFAT-Dateisystem ist der Nachfolger von FAT32 in der FAT-Dateisystemfamilie. Diese Spezifikation beschreibt das exFAT-Dateisystem und stellt alle Informationen bereit, die für die Implementierung des exFAT-Dateisystems erforderlich sind.

1.1 Entwurfsziele

Das exFAT-Dateisystem hat drei zentrale Entwurfsziele (siehe Liste unten).

  1. Behalten Sie die Einfachheit fat-basierter Dateisysteme bei.

    Zwei der Stärken von FAT-basierten Dateisystemen sind ihre relative Einfachheit und einfache Implementierung. Im Rahmen seiner Vorgänger sollten Implementierer exFAT relativ einfach und einfach zu implementieren finden.

  2. Aktivieren sie sehr große Dateien und Speichergeräte.

    Das exFAT-Dateisystem verwendet 64 Bits, um die Dateigröße zu beschreiben, wodurch Anwendungen ermöglicht werden, die von sehr großen Dateien abhängen. Das exFAT-Dateisystem ermöglicht auch Cluster mit einer Breite von bis zu 32 MB, sodass sehr große Speichergeräte effektiv aktiviert werden können.

  3. Integrieren Sie Erweiterbarkeit für zukünftige Innovationen.

    Das exFAT-Dateisystem integriert Erweiterbarkeit in seinen Entwurf, sodass das Dateisystem mit Innovationen bei der Speicherung und Nutzungsänderungen Schritt halten kann.

1.2 Spezifische Terminologie

Im Kontext dieser Spezifikation haben bestimmte Begriffe (siehe Tabelle 1)eine spezifische Bedeutung für den Entwurf und die Implementierung des exFAT-Dateisystems.

Tabelle 1 Definition von Begriffen, die eine sehr spezifische Bedeutung haben

Begriff Definition
Soll In dieser Spezifikation wird der Begriff "soll" verwendet, um ein erforderliches Verhalten zu beschreiben.
Optional In dieser Spezifikation wird der Begriff "should" verwendet, um ein Verhalten zu beschreiben, das dringend empfohlen wird, aber nicht obligatorisch ist.
May In dieser Spezifikation wird der Begriff "may" verwendet, um ein optionales Verhalten zu beschreiben.
Obligatorisch. Dieser Begriff beschreibt ein Feld oder eine Struktur, das bzw. die eine Implementierung ändern soll und wie in dieser Spezifikation beschrieben interpretiert werden soll.
Optional Dieser Begriff beschreibt ein Feld oder eine Struktur, die von einer Implementierung unterstützt werden kann oder nicht. Wenn eine Implementierung ein bestimmtes optionales Feld oder eine bestimmte Struktur unterstützt, muss sie das Feld oder die Struktur wie in dieser Spezifikation beschrieben ändern und interpretieren.
Nicht definiert Dieser Begriff beschreibt feld- oder strukturbezogene Inhalte, die eine Implementierung bei Bedarf ändern kann (d. h. beim Festlegen von umgebenden Feldern oder Strukturen von klar zu null), und darf nicht interpretieren, um eine bestimmte Bedeutung zu haben.
Reserviert

Dieser Begriff beschreibt Feld- oder Strukturinhalte, die Implementierungen:

  1. Initialisiert mit 0 (null) und sollte für keinen Zweck verwendet werden.

  2. Sollte nicht interpretiert werden, außer beim Berechnen von Prüfsummen

  3. Soll vorgängeübergreifend beibehalten werden, die umgebende Felder oder Strukturen ändern

1.3 Volltext allgemeiner Akronyme

In dieser Spezifikation werden Akronyme verwendet, die in der Personalcomputerbranche häufig verwendet werden (siehe Tabelle 2).

Tabelle 2: Vollständiger Text allgemeiner Akronyme

Akronym Volltext
ASCII American Standard Code for Information Interchange
BIOS Grundlegendes Eingabeausgabesystem
CPU Zentrale Verarbeitungseinheit
exFAT Erweiterbare Dateizuordnungstabelle
FAT Dateizuordnungstabelle
FAT12 Dateizuordnungstabelle, 12-Bit-Clusterindizes
FAT16 Dateizuordnungstabelle, 16-Bit-Clusterindizes
FAT32 Dateizuordnungstabelle, 32-Bit-Clusterindizes
GPT GUID-Partitionstabelle
GUID Global eindeutiger Bezeichner (siehe Abschnitt 10.1)
INT Interrupt
MBR Master Boot Record
texFAT Transaktionssicherer ExFAT
UTC Koordinierte Weltzeit (UTC)

1.4 Standardqualifizierer für Feld und Struktur

Felder und Strukturen in dieser Spezifikation verfügen über die folgenden Qualifizierer (siehe Liste unten), sofern in der Spezifikation nichts anderes angegeben ist.

  1. Sind nicht signiert

  2. Verwenden Sie die Dezimalschreibweise, um Werte zu beschreiben, sofern nicht anders angegeben. In dieser Spezifikation wird der Postfixbuchstabe "h" verwendet, um Hexadezimalzahlen zu kennzeichnen, und GUIDs werden in geschweifte Klammern eingeschlossen.

  3. Im Little-Endian-Format

  4. Kein Zeichen mit NULL-Terminierung für Zeichenfolgen erforderlich

1.5 Windows CE und TexFAT

TexFAT ist eine Erweiterung für exFAT, die transaktionssichere Betriebssemantik über dem Basisdateisystem hinzufügt. TexFAT wird von Windows CE verwendet. TexFAT erfordert die Verwendung der beiden FATs und Zuordnungsbitmaps für die Verwendung in Transaktionen. Außerdem werden mehrere zusätzliche Strukturen definiert, einschließlich Auffüllungsdeskriptoren und Sicherheitsdeskriptoren.

2 Volumestruktur

Ein Volume ist der Satz aller Dateisystemstrukturen und des Datenspeichers, die zum Speichern und Abrufen von Benutzerdaten erforderlich sind. Alle exFAT-Volumes enthalten vier Regionen (siehe Tabelle 3).

Volumestruktur in Tabelle 3

Name der Unterregion

Offset

(Sektor)

Größe

(Sektoren)

Kommentare
Hauptstartregion
Hauptstartbranche 0 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.1 definiert ihren Inhalt.
Hauptbranches für erweiterte Starte 1 8 Diese Unterregion ist obligatorisch, und Abschnitt 3.2) definiert ihren Inhalt.
OEM-Hauptparameter 9 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.3 definiert ihren Inhalt.
Reservierter Hauptteil 10 1 Diese Unterregion ist obligatorisch, und ihr Inhalt ist reserviert.
Hauptstartprüfsumme 11 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.4 definiert ihren Inhalt.
Region für den Sicherungsstart
Sicherungsstart-Sektor 12 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.1 definiert ihren Inhalt.
Sichern erweiterter Startbranches 13 8 Diese Unterregion ist obligatorisch, und Abschnitt 3.2 definiert ihren Inhalt.
OEM-Parameter sichern 21 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.3 definiert ihren Inhalt.
Reservierte Sicherung 22 1 Diese Unterregion ist obligatorisch, und ihr Inhalt ist reserviert.
Sicherungsstartprüfsumme 23 1 Diese Unterregion ist obligatorisch, und Abschnitt 3.4 definiert ihren Inhalt.
FAT-Region
FAT-Ausrichtung 24 FatOffset – 24

Diese Unterregion ist obligatorisch, und ihre Inhalte sind ggf. nicht definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide das Feld FatOffset.

Erstes FAT FatOffset FatLength

Diese Unterregion ist obligatorisch, und Abschnitt 4.1 definiert ihren Inhalt.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide die Felder FatOffset und FatLength.

Zweites FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Diese Unterregion ist obligatorisch, und Abschnitt 4.1 definiert ggf. ihren Inhalt.

Hinweis: Die Felder Haupt- und Sicherungsstartsektor enthalten die Felder FatOffset, FatLength und NumberOfFats. Das Feld NumberOfFats darf nur die Werte 1 und 2 enthalten.

Datenbereich
Clusterheapausrichtung FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Diese Unterregion ist obligatorisch, und ihre Inhalte sind ggf. nicht definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide die Felder FatOffset, FatLength, NumberOfFats und ClusterHeapOffset. Die gültigen Werte des Felds NumberOfFats sind 1 und 2.

Clusterheap ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

Diese Unterregion ist obligatorisch, und Abschnitt 5.1 definiert ihren Inhalt.

Hinweis: Die Felder Haupt- und Sicherungsstartsektoren enthalten die Felder ClusterHeapOffset, ClusterCount und SectorsPerClusterShift.

Übermäßiger Speicherplatz ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

Diese Unterregion ist obligatorisch, und ihre Inhalte sind ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten die Felder ClusterHeapOffset, ClusterCount, SectorsPerClusterShift und VolumeLength.

3 Haupt- und Sicherungsstartregionen

Die Hauptstartregion enthält alle erforderlichen Startanweisungen, Informationen zur Identifizierung und Dateisystemparameter, damit eine Implementierung Folgendes ausführen kann:

  1. Starten Sie ein Computersystem von einem exFAT-Volume.

  2. Identifizieren Sie das Dateisystem auf dem Volume als exFAT.

  3. Ermitteln Sie den Speicherort der ExFAT-Dateisystemstrukturen.

Die Region "Sicherungsstart" ist eine Sicherung der Hauptstartregion. Sie unterstützt die Wiederherstellung des exFAT-Volumes, wenn sich die Hauptstartregion in einem inkonsistenten Zustand befindet. Außer unter seltenen Umständen, z. B. beim Aktualisieren von Startanweisungen, sollten Implementierungen den Inhalt der Sicherungsstartregion nicht ändern.

3.1 Unterregionen des Haupt- und Sicherungsstartbranches

Der Hauptstartsektor enthält Code zum Starten von einem exFAT-Volume und grundlegende exFAT-Parameter, die die Volumestruktur beschreiben (siehe Tabelle 4). BIOS, MBR oder andere Bootumreifungs-Agents können diesen Sektor untersuchen und alle darin enthaltenen Startanweisungen laden und ausführen.

Der Sicherungsstart-Sektor ist eine Sicherung des Hauptstartbranches und weist die gleiche Struktur auf (siehe Tabelle 4). Der Sicherungsstart-Sektor kann Wiederherstellungsvorgänge unterstützen. Implementierungen müssen jedoch den Inhalt der Felder VolumeFlags und PercentInUse als veraltet behandeln.

Vor der Verwendung des Inhalts des Haupt- oder Sicherungsstartbranches müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen und sicherstellen, dass sich alle felder innerhalb ihres gültigen Wertbereichs befinden.

Während der anfängliche Formatvorgang den Inhalt des Haupt- und des Sicherungsstartsektors initialisiert, können Implementierungen diese Sektoren nach Bedarf aktualisieren (und auch ihre jeweilige Startprüfsumme aktualisieren). Implementierungen können jedoch entweder die Felder VolumeFlags oder PercentInUse aktualisieren, ohne die jeweilige Startprüfsumme zu aktualisieren (die Prüfsumme schließt diese beiden Felder ausdrücklich aus).

Tabelle 4: Struktur des Haupt- und Sicherungsstartbranches

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
JumpBoot 0 3 Dieses Feld ist obligatorisch, und Abschnitt 3.1.1 definiert seinen Inhalt.
FileSystemName 3 8 Dieses Feld ist obligatorisch, und Abschnitt 3.1.2 definiert seinen Inhalt.
MustBeZero 11 53 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.3 wird der Inhalt definiert.
PartitionOffset 64 8 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.4 wird der Inhalt definiert.
VolumeLength 72 8 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.5 wird der Inhalt definiert.
FatOffset 80 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.6 wird der Inhalt definiert.
FatLength 84 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.7 wird der Inhalt definiert.
ClusterHeapOffset 88 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.8 wird der Inhalt definiert.
ClusterCount 92 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.9 wird der Inhalt definiert.
FirstClusterOfRootDirectory 96 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.10 wird der Inhalt definiert.
VolumeSerialNumber 100 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.11 wird der Inhalt definiert.
FileSystemRevision 104 2 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.12 wird der Inhalt definiert.
VolumeFlags 106 2 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13 wird der Inhalt definiert.
BytesPerSectorShift 108 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.14 wird der Inhalt definiert.
SectorsPerClusterShift 109 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.15 wird der Inhalt definiert.
NumberOfFats 110 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.16 wird der Inhalt definiert.
DriveSelect 111 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.17 wird der Inhalt definiert.
PercentInUse 112 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.18 wird der Inhalt definiert.
Reserviert 113 7 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
BootCode 120 390 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.19 wird der Inhalt definiert.
BootSignature 510 2 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.20 wird der Inhalt definiert.
ExcessSpace 512 2BytesPerSectorShift – 512

Dieses Feld ist obligatorisch, und sein Inhalt ist ( falls erforderlich) nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das Feld BytesPerSectorShift.

3.1.1 JumpBoot-Feld

Das Feld JumpBoot muss die Sprunganweisung für CPUs enthalten, die auf PCs üblich sind, die bei der Ausführung die CPU "springen", um die Startverschnappungsanweisungen im Feld BootCode auszuführen.

Der gültige Wert für dieses Feld ist (in der Reihenfolge von low-order byte bis high-order byte) EBh 76h 90h.

3.1.2 FileSystemName-Feld

Das Feld FileSystemName muss den Namen des Dateisystems auf dem Volume enthalten.

Der gültige Wert für dieses Feld ist in ASCII-Zeichen "EXFAT", der drei nachstellende Leerzeichen enthält.

3.1.3 MustBeZero-Feld

Das MustBeZero-Feld muss direkt dem Bytebereich entsprechen, den der gepackte BIOS-Parameterblock auf FAT12/16/32-Volumes verbraucht.

Der gültige Wert für dieses Feld ist 0. Dadurch wird verhindert, dass FAT12/16/32-Implementierungen fälschlicherweise ein exFAT-Volume einbinden.

3.1.4 PartitionOffset-Feld

Das Feld PartitionOffset muss den medien relativen Sektoroffset der Partition beschreiben, die das gegebene ExFAT-Volume hostet. Dieses Feld unterstützt die Startverschnappung vom Volume mit erweiterter INT 13h auf PCs.

Alle möglichen Werte für dieses Feld sind gültig. Der Wert 0 gibt jedoch an, dass Implementierungen dieses Feld ignorieren sollen.

3.1.5 VolumeLength-Feld

Das VolumeLength-Feld muss die Größe des angegebenen exFAT-Volumes in Sektoren beschreiben.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens 220/2BytesPerSectorShift,wodurch sichergestellt wird, dass das kleinste Volume nicht kleiner als 1 MB ist

  • Mindestens 264bis 1, der größte Wert, den dieses Feld beschreiben kann

Wenn die Größe des Unterbereichs "Übermäßiger Speicherplatz" jedoch 0 ist, ist der Wert dieses Felds ClusterHeapOffset + (232- 11) * 2SectorsPerClusterShift.

3.1.6 FatOffset-Feld

Das Feld FatOffset muss den volume-relativen Sektoroffset des ersten FAT beschreiben. Mit diesem Feld können Implementierungen first FAT an den Merkmalen der zugrunde liegenden Speichermedien ausrichten.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens 24 für die Sektoren, die von den Hauptstart- und Sicherungsstartregionen verwendet werden

  • Mindestens ClusterHeapOffset ( FatLength NumberOfFats), das die Vom Clusterheap verbrauchten Sektoren * abspricht

3.1.7 FatLength-Feld

Das Feld FatLength muss die Länge jeder FAT-Tabelle in Sektoren beschreiben (das Volume kann bis zu zwei FATs enthalten).

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens (ClusterCount + 2) * 22/2BytesPerSectorShiftauf die nächste ganze Zahl aufgerundet, wodurch sichergestellt wird, dass jedes FAT über ausreichend Speicherplatz zum Beschreiben aller Cluster im Clusterheap verfügt.

  • (ClusterHeapOffset – FatOffset) /NumberOfFats wird auf die nächste ganze Zahl aufgerundet, wodurch sichergestellt wird, dass die FATs vor dem Clusterheap vorhanden sind.

Dieses Feld kann einen Wert enthalten, der über die untere Grenze hinaus (wie oben beschrieben) liegt, damit der zweite FAT(sofern vorhanden) auch an den Merkmalen der zugrunde liegenden Speichermedien ausgerichtet werden kann. Der Inhalt des Speicherplatzes, der die von FAT selbst benötigten Inhalte überschreitet, ist nicht definiert.

3.1.8 ClusterHeapOffset-Feld

Das Feld ClusterHeapOffset muss den volume-relativen Sektoroffset des Clusterheaps beschreiben. Mit diesem Feld können Implementierungen den Cluster heap an den Merkmalen der zugrunde liegenden Speichermedien ausrichten.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens FatOffset + FatLength NumberOfFats, um die Sektoren zu * berücksichtigen, die in allen vorherigen Regionen verbraucht werden

  • Mindestens 232– 1 oder VolumeLength – (ClusterCount * 2SectorsPerClusterShift), je nach berechnungs geringerer

3.1.9 ClusterCount-Feld

Das Feld ClusterCount muss die Anzahl der Cluster beschreiben, die der Cluster heap enthält.

Der gültige Wert für dieses Feld muss den kleineren der folgenden Werte haben:

  • (VolumeLength – ClusterHeapOffset) / 2SectorsPerClusterShiftwird auf die nächste ganze Zahl aufgerundet. Dies ist genau die Anzahl von Clustern, die zwischen dem Anfang des Clusterheaps und dem Ende des Volumes passen können.

  • 232bis 11, die maximale Anzahl von Clustern, die von FAT beschrieben werden können

Der Wert des Felds ClusterCount bestimmt die Mindestgröße eines FAT. Um extrem große FATs zu vermeiden, können Implementierungen die Anzahl von Clustern im Clusterheap steuern, indem sie die Clustergröße erhöhen (über das Feld "SectorsPerClusterShift"). Diese Spezifikation empfiehlt nicht mehr als 224bis 2 Cluster im Cluster heap. Implementierungen müssen jedoch Volumes mit bis zu 232bis 11 Clustern im Cluster heap verarbeiten können.

3.1.10 FirstClusterOfRootDirectory-Feld

Das Feld FirstClusterOfRootDirectory muss den Clusterindex des ersten Clusters des Stammverzeichnisses enthalten. Implementierungen sollten alle Anstrengungen unternehmen, um den ersten Cluster des Stammverzeichnisses im ersten nicht fehlerhaften Cluster nach den Clustern zu platzieren, die von der Zuordnungsbitmap und der Up-Case-Tabelle verwendet werden.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens 2: Der Index des ersten Clusters im Cluster heap

  • ClusterCount + 1 ist der Index des letzten Clusters im Cluster heap.

3.1.11 VolumeSerialNumber-Feld

Das Feld VolumeSerialNumber muss eine eindeutige Seriennummer enthalten. Dies unterstützt Implementierungen bei der Unterscheidung zwischen verschiedenen exFAT-Volumes. Implementierungen sollten die Seriennummer generieren, indem das Datum und die Uhrzeit der Formatierung des exFAT-Volumes kombiniert werden. Der Mechanismus zum Kombinieren von Datum und Uhrzeit zum Bilden einer Seriennummer ist implementierungsspezifisch.

Alle möglichen Werte für dieses Feld sind gültig.

3.1.12 FileSystemRevision-Feld

Das Feld FileSystemRevision muss die Haupt- und Nebenrevisionsnummern der exFAT-Strukturen auf dem angegebenen Volume beschreiben.

Das obere Byte ist die Hauptrevisionsnummer, und das niedrige Byte ist die kleinere Revisionsnummer. Wenn das obere Byte beispielsweise den Wert 01h enthält und das niedrige Byte den Wert 05h enthält, beschreibt das Feld FileSystemRevision die Revisionsnummer 1.05. Wenn das obere Byte den Wert 0Ah enthält und das niedrige Byte den Wert 0Fh enthält, beschreibt das Feld FileSystemRevision die Revisionsnummer 10.15.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens 0 für das niedrige Byte und 1 für das hohe Byte

  • Mindestens 99 für das niedrige Byte und 99 für das obere Byte

Die Revisionsnummer von exFAT, die in dieser Spezifikation beschrieben wird, ist 1,00. Implementierungen dieser Spezifikation sollten ein beliebiges exFAT-Volume mit der Hauptrevisionsnummer 1 und kein exFAT-Volume mit einer anderen hauptrevisionsnummer ein mounten. Implementierungen müssen die kleinere Revisionsnummer erfüllen und dürfen keine Vorgänge ausführen oder Dateisystemstrukturen erstellen, die nicht in der entsprechenden Spezifikation der angegebenen nebenrevisionsnummer beschrieben sind.

3.1.13 VolumeFlags-Feld

Das VolumeFlags-Feld muss Flags enthalten, die den Status verschiedener Dateisystemstrukturen auf dem exFAT-Volume angeben (siehe Tabelle 5).

Implementierungen dürfen dieses Feld nicht enthalten, wenn die jeweilige Hauptstart- oder Sicherungsstartbereichs-Prüfsumme abrechnt. Beim Verweis auf den Sicherungsstartsektor müssen Implementierungen dieses Feld als veraltet behandeln.

Tabelle 5: VolumeFlags-Feldstruktur

Feldname

Offset

(bit)

Größe

(Bits)

Kommentare
ActiveFat 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.1 wird der Inhalt definiert.
VolumeDirty 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.2 wird der Inhalt definiert.
MediaFailure 2 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.3 wird der Inhalt definiert.
ClearToZero 3 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.4 wird der Inhalt definiert.
Reserviert 4 12 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
3.1.13.1 ActiveFat-Feld

Das Feld ActiveFat muss beschreiben, welche FAT- und Zuordnungsbitmap aktiv sind (und Implementierungen verwenden sollen) wie folgt:

  • 0 bedeutet, dass die erste FAT- und die erste Zuordnungsbitmap aktiv sind.

  • 1 bedeutet, dass die zweite FAT- und zweite Zuordnungsbitmap aktiv ist und nur möglich ist, wenn das NumberOfFats-Feld den Wert 2 enthält.

Implementierungen sollten die inaktive FAT- und Allocation Bitmap als veraltet betrachten. Nur TexFAT-orientierte Implementierungen dürfen die aktiven FAT- und Allocation Bitmaps wechseln (siehe Abschnitt 7.1).

3.1.13.2 VolumeDirty-Feld

Im Feld VolumeDirty muss wie folgt beschrieben werden, ob das Volume "dirty" ist oder nicht:

  • 0, was bedeutet, dass sich das Volume wahrscheinlich in einem konsistenten Zustand befindet.

  • 1, was bedeutet, dass sich das Volume wahrscheinlich in einem inkonsistenten Zustand befindet.

Implementierungen sollten den Wert dieses Felds auf 1 festlegen, wenn Inkonsistenzen von Dateisystemmetadaten auftreten, die sie nicht auflösen. Wenn beim Einbinden eines Volumes der Wert dieses Felds 1 ist, können nur Implementierungen, die Inkonsistenzen von Dateisystemmetadaten auflösen, den Wert dieses Felds auf 0 (0) löschen. Solche Implementierungen dürfen den Wert dieses Felds nur auf 0 löschen, nachdem sichergestellt wurde, dass sich das Dateisystem in einem konsistenten Zustand befindet.

Wenn beim Einbinden eines Volumes der Wert dieses Felds 0 ist, sollten Implementierungen dieses Feld auf 1 festlegen, bevor dateisystemmetadaten aktualisiert werden, und dieses Feld anschließend auf 0 löschen, ähnlich der empfohlenen Schreib reihenfolge, die in Abschnitt 8.1 beschrieben wird.

3.1.13.3 MediaFailure-Feld

Im Feld MediaFailure muss wie folgt beschrieben werden, ob bei einer Implementierung Medienfehler festgestellt wurden:

  • 0, was bedeutet, dass das Hostmedium keine Fehler gemeldet hat oder bekannte Fehler bereits im FAT als "schlechte" Cluster aufgezeichnet wurden.

    1. Das bedeutet, dass das Hostmedium Fehler gemeldet hat (d. h. fehlgeschlagene Lese- oder Schreibvorgänge auft hat).

Eine Implementierung sollte dieses Feld auf 1 festlegen, wenn:

  1. Das Hostingmedium schlägt bei Zugriffsversuchen auf eine beliebige Region auf dem Volume fehl.

  2. Die Implementierung hat die Wiederholungsalgorithmen für den Zugriff erschöpft, falls vorhanden.

Wenn beim Einbinden eines Volumes der Wert dieses Felds 1 ist, können Implementierungen, die das gesamte Volume auf Medienfehler überprüfen und alle Fehler als "ungültige" Cluster im FAT aufzeichnen (oder medienfehler anderweitig beheben), den Wert dieses Felds auf 0 setzen.

3.1.13.4 ClearToZero-Feld

Das Feld ClearToZero hat in dieser Spezifikation keine signifikante Bedeutung.

Die gültigen Werte für dieses Feld sind:

  • 0, das keine besondere Bedeutung hat

  • 1 bedeutet, dass Implementierungen dieses Feld vor dem Ändern von Dateisystemstrukturen, -verzeichnissen oder -dateien auf 0 löschen müssen.

3.1.14 BytesPerSectorShift-Feld

Das Feld BytesPerSectorShift muss die Bytes pro Sektor beschreiben, ausgedrückt als Protokoll2(N), wobei N die Anzahl der Bytes pro Sektor ist. Für 512 Bytes pro Sektor ist der Wert dieses Felds beispielsweise 9.

Der gültige Wertebereich für dieses Feld muss:

  • Mindestens 9 (Sektorgröße 512 Byte), dies ist der kleinstmögliche Sektor für ein exFAT-Volume.

  • Höchstens 12 (Sektorgröße von 4.096 Byte), was der Arbeitsspeicherseitengröße von CPUs entspricht, die auf PCs üblich sind.

3.1.15 SectorsPerClusterShift Field

Das Feld "SectorsPerClusterShift" beschreibt die Sektoren pro Cluster, ausgedrückt als Protokoll2(N), wobei N für die Anzahl der Sektoren pro Cluster steht. Für 8 Sektoren pro Cluster ist der Wert dieses Felds beispielsweise 3.

Der gültige Wertebereich für dieses Feld muss:

  • Mindestens 0 (1 Sektor pro Cluster), der kleinstmögliche Cluster

  • Höchstens 25 : BytesPerSectorShift, das zu einer Clustergröße von 32 MB ausgewertet wird

3.1.16 NumberOfFats-Feld

Das Feld NumberOfFats muss die Anzahl der FATs und Zuordnungsbitmaps beschreiben, die das Volume enthält.

Der gültige Wertebereich für dieses Feld muss:

  • 1, das angibt, dass das Volume nur das erste FAT und die erste Zuordnungsbitmap enthält.

  • 2, das angibt, dass das Volume die erste FAT-, zweite FAT-, Erste Zuordnungsbitmap und zweite Zuordnungsbitmap enthält. Dieser Wert ist nur für TexFAT-Volumes gültig.

3.1.17 LaufwerkFeld auswählen

Das Feld DriveSelect muss die erweiterte INT 13h-Laufwerksnummer enthalten, die das Starten dieses Volumes mithilfe von erweitertem INT 13h auf PCs unterstützt.

Alle möglichen Werte für dieses Feld sind gültig. Ähnliche Felder in früheren FAT-basierten Dateisystemen enthielten häufig den Wert 80h.

3.1.18 PercentInUse-Feld

Das Feld PercentInUse muss den Prozentsatz der Cluster im Clusterheap beschreiben, die zugeordnet sind.

Der gültige Wertebereich für dieses Feld muss:

  • Zwischen 0 und 100 einschließlich, d. h. dem Prozentsatz der zugeordneten Cluster im Clusterheap, gerundet auf die nächste ganze Zahl

  • Genau FFh, was angibt, dass der Prozentsatz der zugeordneten Cluster im Clusterheap nicht verfügbar ist

Implementierungen müssen den Wert dieses Felds ändern, um Änderungen bei der Zuordnung von Clustern im Clusterheap widerzuspiegeln, oder sie müssen ihn in FFh ändern.

Implementierungen dürfen dieses Feld nicht enthalten, wenn sie die jeweilige Prüfsumme für den Hauptstart oder die Sicherungsstartregion berechnen. Beim Verweisen auf den Sicherungsstart-Sektor müssen Implementierungen dieses Feld als veraltet behandeln.

3.1.19 BootCode-Feld

Das Feld BootCode muss Anweisungen zum Starten enthalten. Implementierungen füllen dieses Feld möglicherweise mit den CPU-Anweisungen auf, die zum Starten eines Computersystems erforderlich sind. Implementierungen, die keine Startanleitungen bereitstellen, müssen jedes Byte in diesem Feld im Rahmen des Formatvorgangs mit F4h initialisieren (die Stoppanweisung für CPUs, die auf PCs üblich sind).

3.1.20 BootSignature-Feld

Das Feld BootSignature muss beschreiben, ob die Absicht eines bestimmten Sektor darin besteht, ein Boot-Sektor zu sein oder nicht.

Der gültige Wert für dieses Feld ist AA55h. Jeder andere Wert in diesem Feld macht den jeweiligen Startsektor ungültig. Implementierungen sollten den Inhalt dieses Felds vor je nach einem anderen Feld im jeweiligen Startsektor überprüfen.

3.2 Haupt- und Sicherungsregionen für erweiterte Startsektoren

Jeder Sektor der Hauptbranches für erweiterte Starte weist die gleiche Struktur auf. Jeder Sektor kann jedoch unterschiedliche Startanweisungen enthalten (siehe Tabelle 6). Bootumschnall-Agents, z. B. die Startanleitungen im Hauptstartsektor, alternative BIOS-Implementierungen oder die Firmware eines eingebetteten Systems, können diese Sektoren laden und die darin enthaltenen Anweisungen ausführen.

Der Erweiterte Startsektoren sichern ist eine Sicherung der Hauptbranches für erweiterte Starte und weist die gleiche Struktur auf (siehe Tabelle 6).

Vor der Ausführung der Anweisungen des Haupt- oder Sicherungsbranches für erweiterte Starte sollten Implementierungen ihren Inhalt überprüfen, indem sie sicherstellen, dass das Feld ExtendedBootSignature jedes Sektor seinen vorgeschriebenen Wert enthält.

Während der anfängliche Formatvorgang den Inhalt sowohl des Haupt- als auch des erweiterten Startsektors für Sicherungen initialisiert, können Implementierungen diese Sektoren nach Bedarf aktualisieren (und auch ihre jeweilige Startprüfsumme aktualisieren).

Tabelle 6: Struktur des erweiterten Startbranches

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
ExtendedBootCode 0 2BytesPerSectorShift – 4

Dieses Feld ist obligatorisch, und Abschnitt 3.2.1 definiert seinen Inhalt.

Hinweis: Sowohl der Haupt- als auch der Sicherungsstartsektor enthalten das Feld BytesPerSectorShift.

ExtendedBootSignature 2BytesPerSectorShift – 4 4

Dieses Feld ist obligatorisch, und Abschnitt 3.2.2 definiert seinen Inhalt.

Hinweis: Sowohl der Haupt- als auch der Sicherungsstartsektor enthalten das Feld BytesPerSectorShift.

3.2.1 Feld "ExtendedBootCode"

Das Feld ExtendedBootCode muss Anweisungen zum Starten enthalten. Implementierungen füllen dieses Feld möglicherweise mit den CPU-Anweisungen auf, die zum Starten eines Computersystems erforderlich sind. Implementierungen, die keine Startanweisungen bereitstellen, müssen jedes Byte in diesem Feld im Rahmen ihres Formatvorgangs mit 00h initialisieren.

3.2.2 Feld "ExtendedBootSignature"

Das Feld ExtendedBootSignature muss beschreiben, ob die Absicht eines bestimmten Sektor darin besteht, ein erweiterter Startsektor zu sein oder nicht.

Der gültige Wert für dieses Feld ist AA550000h. Jeder andere Wert in diesem Feld macht den jeweiligen Main- oder Backup Extended Boot Sector ungültig. Implementierungen sollten den Inhalt dieses Felds vor je nach einem anderen Feld im jeweiligen erweiterten Startbereich überprüfen.

3.3 Oem-Parameter-Unterregionen für Haupt- und Sicherungsdaten

Die Unterregion OEM-Hauptparameter enthält zehn Parameterstrukturen, die herstellerspezifische Informationen enthalten können (siehe Tabelle 7). Jede der zehn Parameterstrukturen wird von der Vorlage für generische Parameter abgeleitet (siehe Abschnitt 3.3.2). Hersteller können ihre eigenen benutzerdefinierten Parameterstrukturen aus der Vorlage generische Parameter ableiten. Diese Spezifikation selbst definiert zwei Parameterstrukturen: NULL-Parameter (siehe Abschnitt 3.3.3)und Flashparameter (siehe Abschnitt 3.3.4).

Die OEM-Sicherungsparameter sind eine Sicherung der OEM-Hauptparameter und haben die gleiche Struktur (siehe Tabelle 7).

Vor der Verwendung der Inhalte der OEM-Parameter Main oder Backup müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen.

Hersteller sollten die OEM-Haupt- und Sicherungsparameter mit ihren eigenen benutzerdefinierten Parameterstrukturen (falls vorhanden) und beliebigen anderen Parameterstrukturen auffüllen. Bei nachfolgenden Formatvorgängen muss der Inhalt der OEM-Parameter Main und Backup beibehalten werden.

Implementierungen können die OEM-Haupt- und Sicherungsparameter nach Bedarf aktualisieren (und müssen auch ihre jeweilige Startprüfsumme aktualisieren).

Oem-Parameterstruktur in Tabelle 7

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
Parameter[0] 0 48 Dieses Feld ist obligatorisch, und Abschnitt 3.3.1 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.

Parameter[9] 432 48 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.1 wird der Inhalt definiert.
Reserviert 480 2BytesPerSectorShift – 480

Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das Feld BytesPerSectorShift.

3.3.1 Parameter [ 0 ] ... Parameter [ 9]

Jedes Parameterfeld in diesem Array enthält eine Parameterstruktur, die von der Vorlage Generische Parameter (siehe Abschnitt 3.3.2) ableitung. Jedes nicht verwendete Parameterfeld muss so beschrieben werden, dass es eine NULL-Parameterstruktur enthält (siehe Abschnitt 3.3.3).

3.3.2 Vorlage für generische Parameter

Die Vorlage Generische Parameter stellt die Basisdefinition einer Parameterstruktur (siehe Tabelle 8) zur Alle Parameterstrukturen werden von dieser Vorlage ableiten. Die Unterstützung für diese Vorlage für generische Parameter ist obligatorisch.

Vorlage für generische Parameter in Tabelle 8

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.2.1 wird der Inhalt definiert.
CustomDefined 16 32 Dieses Feld ist obligatorisch, und die Strukturen, die von dieser Vorlage ableiten, definieren ihren Inhalt.
3.3.2.1 ParametersGuid-Feld

Das Feld ParametersGuid muss eine GUID beschreiben, die das Layout des Rests der angegebenen Parameterstruktur bestimmt.

Alle möglichen Werte für dieses Feld sind gültig. Hersteller sollten jedoch ein GUID-generierende Tool wie GuidGen.exe verwenden, um eine GUID auszuwählen, wenn benutzerdefinierte Parameterstrukturen von dieser Vorlage ableiten werden.

3.3.3 NULL-Parameter

Die NULL-Parameterstruktur wird von der Vorlage Generische Parameter (siehe Abschnitt 3.3.2) und beschreibt ein nicht verwendetes Parameterfeld (siehe Tabelle 9). Beim Erstellen oder Aktualisieren der OEM-Parameterstruktur müssen Implementierungen nicht verwendete Parameterfelder mit der Struktur NULL-Parameter auffüllen. Außerdem sollten Implementierungen beim Erstellen oder Aktualisieren der OEM-Parameterstruktur NULL-Parameterstrukturen am Ende des Arrays konsolidieren, wodurch alle anderen Parameterstrukturen am Anfang der OEM-Parameterstruktur belässt werden.

Unterstützung für die Nullparameterstruktur ist obligatorisch.

Struktur von NULL-Parametern in Tabelle 9

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.3.1 wird der Inhalt definiert.
Reserviert 16 32 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
3.3.3.1 ParametersGuid-Feld

Das Feld ParametersGuid muss der Definition entsprechen, die von der Vorlage generische Parameter bereitgestellt wird (siehe Abschnitt 3.3.2.1).

Der gültige Wert für dieses Feld in GUID-Notation ist {00000000-0000-0000-0000-000000000000} .

3.3.4 Flashparameter

Die FlashParameter-Struktur wird von der Vorlage Generische Parameter (siehe Abschnitt 3.3.2) und enthält Parameter für Flashmedien (siehe Tabelle 10). Hersteller flashbasierter Speichergeräte können ein Parameterfeld (vorzugsweise das Feld Parameter [ 0) mit ] dieser Parameterstruktur auffüllen. Implementierungen können die Informationen in der FlashParameter-Struktur verwenden, um Zugriffsvorgänge während Lese-/Schreibvorgängen und für die Ausrichtung von Dateisystemstrukturen zu optimieren, die die Formatierung der Medien erhingen.

Die Unterstützung für die Flashparameterstruktur ist optional.

Struktur der Flashparameter in Tabelle 10

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.1 wird der Inhalt definiert.
EraseBlockSize 16 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.2 wird der Inhalt definiert.
PageSize 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.3 wird der Inhalt definiert.
SpareSectors 24 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.4 wird der Inhalt definiert.
RandomAccessTime 28 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.5 wird der Inhalt definiert.
ProgrammingTime 32 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.6 wird der Inhalt definiert.
ReadCycle 36 4 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.4.7 wird der Inhalt definiert.
WriteCycle 40 4 Dieses Feld ist obligatorisch, und Abschnitt 3.3.4.8 definiert seinen Inhalt.
Reserviert 44 4 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.

Alle möglichen Werte für alle Flash-Parameterfelder, mit Ausnahme des ParametersGuid-Felds, sind gültig. Der Wert 0 gibt jedoch an, dass das Feld tatsächlich bedeutungslos ist (Implementierungen müssen das angegebene Feld ignorieren).

3.3.4.1 ParametersGuid-Feld

Das Feld ParametersGuid muss der Definition in der Vorlage für generische Parameter entsprechen (siehe Abschnitt 3.3.2.1).

Der gültige Wert für dieses Feld in GUID-Notation ist {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

3.3.4.2 Feld "EraseBlockSize"

Das Feld EraseBlockSize muss die Größe des Löschblocks des Flashmediums in Bytes beschreiben.

3.3.4.3 PageSize-Feld

Das Feld PageSize muss die Größe der Seite des Flashmediums in Bytes beschreiben.

3.3.4.4 Feld "SpareSectors"

Das Feld SpareSectors muss die Anzahl der Sektoren beschreiben, die das Flashmedium für seine internen Sparingvorgänge zur Verfügung hat.

3.3.4.5 RandomAccessTime-Feld

Das Feld RandomAccessTime muss die durchschnittliche zufällige Zugriffszeit des Flashmediums in Nanosekunden beschreiben.

3.3.4.6 ProgrammingTime-Feld

Im Feld ProgrammingTime muss die durchschnittliche Programmierzeit des Flashmediums in Nanosekunden beschrieben werden.

3.3.4.7 ReadCycle-Feld

Das Feld ReadCycle muss die durchschnittliche Lesezykluszeit des Flashmediums in Nanosekunden beschreiben.

3.3.4.8 WriteCycle-Feld

Das Feld WriteCycle muss die durchschnittliche Schreibzykluszeit in Nanosekunden beschreiben.

3.4 Haupt- und Sicherungsstartprüfsummen-Unterregionen

Die Haupt- und Sicherungsstartprüfsummen enthalten jeweils ein sich wiederholendes Muster der Vier-Byte-Prüfsumme des Inhalts aller anderen Unterregionen in den jeweiligen Startregionen. Die Prüfsummenberechnung darf die Felder VolumeFlags und PercentInUse nicht in ihrem jeweiligen Startsektor enthalten (siehe Abbildung 1). Das sich wiederholende Muster der 4-Byte-Prüfsumme füllt die jeweilige Startprüfsummenunterregion vom Anfang bis zum Ende des Unterbereichs aus.

Vor der Verwendung des Inhalts einer der anderen Unterregionen in den Haupt- oder Sicherungsstartregionen müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen.

Während der anfängliche Formatvorgang sowohl die Haupt- als auch die Sicherungsstartprüfsumme mit dem sich wiederholenden Prüfsummenmuster auffüllt, müssen implementierungen diese Sektoren aktualisieren, wenn sich der Inhalt der anderen Sektoren in ihren jeweiligen Startregionen ändert.

Abbildung 1 Startprüfsummenberechnung

UInt32 BootChecksum
(
    UCHAR  * Sectors,        // points to an in-memory copy of the 11 sectors
    USHORT   BytesPerSector
)
{
    UInt32 NumberOfBytes = (UInt32)BytesPerSector * 11;
    UInt32 Checksum = 0;
    UInt32 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 106) || (Index == 107) || (Index == 112))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Sectors[Index];
    }

    return Checksum;
}

4 Dateizuordnungstabellenbereich

Die FAT-Region (File Allocation Table) kann bis zu zwei FATs enthalten: eine in der ersten FAT-Unterregion und eine in der zweiten FAT-Unterregion. Im Feld NumberOfFats wird beschrieben, wie viele FATs diese Region enthält. Die gültigen Werte für das Feld NumberOfFats sind 1 und 2. Daher enthält die erste FAT-Unterregion immer ein FAT. Wenn das Feld NumberOfFats zwei ist, enthält die zweite FAT-Unterregion auch ein FAT.

Im Feld ActiveFat des Felds VolumeFlags wird beschrieben, welches FAT aktiv ist. Nur das Feld VolumeFlags im Hauptstartsektor ist aktuell. Implementierungen müssen das FAT, das nicht aktiv ist, als veraltet behandeln. Die Verwendung des inaktiven FAT und das Wechseln zwischen FATs ist implementierungsspezifisch.

4.1 Erste und zweite FAT-Unterregionen

Ein FAT muss Clusterketten im Clusterheap beschreiben (siehe Tabelle 11). Eine Clusterkette ist eine Reihe von Clustern, die Platz zum Aufzeichnen des Inhalts von Dateien, Verzeichnissen und anderen Dateisystemstrukturen bietet. Ein FAT stellt eine Clusterkette als einfach verknüpfte Liste von Clusterindizes dar. Mit Ausnahme der ersten beiden Einträge stellt jeder Eintrag in einem FAT genau einen Cluster dar.

Tabellen-11-Dateizuordnungstabellenstruktur

Feldname

Offset

(Byte)

Größe

(Bytes)

Kommentare
FatEntry[0] 0 4 Dieses Feld ist obligatorisch, und Abschnitt 4.1.1 definiert seinen Inhalt.
FatEntry[1] 4 4 Dieses Feld ist obligatorisch, und Abschnitt 4.1.2 definiert seinen Inhalt.
FatEntry[2] 8 4 Dieses Feld ist obligatorisch, und Abschnitt 4.1.3 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.

FatEntry[ClusterCount+1] (ClusterCount + 1) * 4 4

Dieses Feld ist obligatorisch, und Abschnitt 4.1.3 definiert seinen Inhalt.

ClusterCount + 1 darf FFFFFFF6h nie überschreiten.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das Feld ClusterCount.

ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

Dieses Feld ist obligatorisch, und sein Inhalt ist ggf. nicht definiert.

Hinweis: Die Felder Haupt- und Sicherungsstartsektor enthalten die Felder ClusterCount, FatLength und BytesPerSectorShift.

4.1.1 FatEntry [ ] 0-Feld

Das Feld FatEntry [ 0 ] muss den Medientyp im ersten Byte (das byte der niedrigsten Reihenfolge) beschreiben und FFh in den verbleibenden drei Bytes enthalten.

Der Medientyp (das erste Byte) sollte F8h sein.

4.1.2 FatEntry [ ] 1-Feld

Das Feld FatEntry [ 1 ] ist nur aufgrund der historischen Rangfolge vorhanden und beschreibt keine interessanten Informationen.

Der gültige Wert für dieses Feld ist FFFFFFFFh. Implementierungen müssen dieses Feld mit dem vorgeschriebenen Wert initialisieren und sollten dieses Feld für keinen Zweck verwenden. Implementierungen sollten dieses Feld nicht interpretieren und seinen Inhalt über Vorgänge hinweg beibehalten, die umgebende Felder ändern.

4.1.3 FatEntry [ 2 ] ... FatEntry [ ClusterCount+1 ] Fields

Jedes FatEntry-Feld in diesem Array muss einen Cluster im Clusterheap darstellen. FatEntry [ 2 ] stellt den ersten Cluster im Clusterheap und FatEntry [ ClusterCount+1 ] den letzten Cluster im Clusterheap dar.

Der gültige Wertebereich für diese Felder muss folgendermaßen sein:

  • Zwischen 2 und ClusterCount + 1 (einschließlich), was auf den nächsten FatEntry-Vorgang in der angegebenen Clusterkette verweist; der angegebene FatEntry darf nicht auf FatEntry verweisen, der in der angegebenen Clusterkette vorangestellt ist.

  • Genau FFFFFFF7h, wodurch der entsprechende FatEntry-Cluster als "schlecht" markiert wird

  • Genau FFFFFFFFh, das den entsprechenden FatEntry-Cluster als letzten Cluster einer Clusterkette markiert; Dies ist der einzige gültige Wert für den letzten FatEntry-Wert einer bestimmten Clusterkette.

5 Datenbereich

Der Datenbereich enthält den Clusterheap, der verwalteten Speicherplatz für Dateisystemstrukturen, Verzeichnisse und Dateien bereitstellt.

5.1 Clusterheap-Unterregion

Die Struktur des Clusterheaps ist sehr einfach (siehe Tabelle 12); jede aufeinander folgende Reihe von Sektoren beschreibt einen Cluster, wie im Feld "SectorsPerClusterShift" definiert. Wichtig: Der erste Cluster des Clusterheaps verfügt über Index 2, der direkt dem Index von FatEntry [ 2 ] entspricht.

In einem exFAT-Volume verwaltet eine Zuordnungsbitmap (siehe Abschnitt 7.1.5)den Datensatz des Zuordnungsstatus aller Cluster. Dies ist ein wesentlicher Unterschied zu den Vorgängern von exFAT (FAT12, FAT16 und FAT32), bei denen ein FAT einen Datensatz des Zuordnungsstatus aller Cluster im Clusterheap verwaltet hat.

Clusterheapstruktur in Tabelle 12

Feldname

Offset

(Sektor)

Größe

(Sektoren)

Kommentare
Cluster[2] ClusterHeapOffset 2SectorsPerClusterShift

Dieses Feld ist obligatorisch, und in Abschnitt 5.1.1 wird der Inhalt definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder ClusterHeapOffset und SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

.

Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2SectorsPerClusterShift 2SectorsPerClusterShift

Dieses Feld ist obligatorisch, und in Abschnitt 5.1.1 wird der Inhalt definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder ClusterCount, ClusterHeapOffset und SectorsPerClusterShift.

5.1.1 Cluster [ 2 ] ... [ClusterclusterCount+1-Felder ]

Jedes Clusterfeld in diesem Array besteht aus einer Reihe zusammenhängender Sektoren, deren Größe durch das Feld "SectorsPerClusterShift" definiert wird.

6 Verzeichnisstruktur

Das ExFAT-Dateisystem verwendet einen Verzeichnisstrukturansatz, um die Dateisystemstrukturen und -dateien zu verwalten, die im Cluster heap vorhanden sind. Verzeichnisse verfügen in der Verzeichnisstruktur über eine 1:n-Beziehung zwischen übergeordnetem und untergeordnetem Element.

Das Verzeichnis, auf das das Feld FirstClusterOfRootDirectory verweist, ist der Stamm der Verzeichnisstruktur. Alle anderen Verzeichnisse stammen aus dem Stammverzeichnis auf singly-linked-Weise ab.

Jedes Verzeichnis besteht aus einer Reihe von Verzeichniseinträgen (siehe Tabelle 13).

Ein oder mehrere Verzeichniseinträge werden zu einem Verzeichniseintragssatz kombiniert, der etwas von Interesse beschreibt, z. B. eine Dateisystemstruktur, ein Unterverzeichnis oder eine Datei.

Tabelle 13: Verzeichnisstruktur

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
DirectoryEntry[0] 0 32 Dieses Feld ist obligatorisch, und in Abschnitt 6.1 wird der Inhalt definiert.

.

.

.

.

.

.

.

.

.

.

.

.

DirectoryEntry[N-1] (N – 1) * 32 32

Dieses Feld ist obligatorisch, und in Abschnitt 6.1 wird der Inhalt definiert.

N, die Anzahl der DirectoryEntry-Felder, ist die Größe der Clusterkette in Bytes, die das gegebene Verzeichnis enthält, dividiert durch die Größe eines DirectoryEntry-Felds, 32 Byte.

6.1 DirectoryEntry [ 0 ] ... DirectoryEntry [ N--1]

Jedes DirectoryEntry-Feld in diesem Array wird von der Generischen DirectoryEntry-Vorlage (siehe Abschnitt 6.2 ) ableiten.

6.2 Generische DirectoryEntry-Vorlage

Die Vorlage "Generic DirectoryEntry" stellt die Basisdefinition für Verzeichniseinträge (siehe Tabelle 14) zur Alle Verzeichniseintragsstrukturen leiten sich von dieser Vorlage ab, und nur von Microsoft definierte Verzeichniseintragsstrukturen sind gültig (exFAT verfügt nicht über Bestimmungen für vom Hersteller definierte Verzeichniseintragsstrukturen, außer wie in Abschnitt 7.8 und Abschnitt 7.9 definiert). Die Interpretation der Vorlage "Generic DirectoryEntry" ist obligatorisch.

Tabelle 14: Generische DirectoryEntry-Vorlage

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1 wird der Inhalt definiert.
CustomDefined 1 19 Dieses Feld ist obligatorisch, und Strukturen, die von dieser Vorlage ableiten, können ihren Inhalt definieren.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.2 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.3 wird der Inhalt definiert.

6.2.1 EntryType-Feld

Das Feld EntryType verfügt über drei Verwendungsmodi, die durch den Wert des Felds definiert werden (siehe Liste unten).

  • 00h, eine End-of-Directory-Markierung, und die folgenden Bedingungen gelten:

    • Alle anderen Felder in der angegebenen DirectoryEntry sind tatsächlich reserviert.

    • Alle nachfolgenden Verzeichniseinträge im angegebenen Verzeichnis sind ebenfalls End-of-Directory-Marker.

    • End-of-Directory-Marker sind nur außerhalb von Verzeichniseintragssätzen gültig.

    • Implementierungen können End-of-Directory-Marker nach Bedarf überschreiben.

  • Zwischen 01h und 7Fh einschließlich . Dies ist ein nicht verwendeter Verzeichniseintragsmarker, und die folgenden Bedingungen gelten:

    • Alle anderen Felder in der angegebenen DirectoryEntry sind eigentlich nicht definiert.

    • Nicht verwendete Verzeichniseinträge sind nur außerhalb von Verzeichniseintragssätzen gültig.

    • Implementierungen können nicht verwendete Verzeichniseinträge bei Bedarf überschreiben.

    • Dieser Wertebereich entspricht dem Feld InUse (siehe Abschnitt 6.2.1.4),das den Wert 0 enthält.

  • Zwischen 81h und FFh einschließlich . Dies ist ein regulärer Verzeichniseintrag, und die folgenden Bedingungen gelten:

    • Der Inhalt des EntryType-Felds (siehe Tabelle 15) bestimmt das Layout des Rests der DirectoryEntry-Struktur.

    • Dieser Wertebereich und nur dieser Wertebereich sind innerhalb eines Verzeichniseintragssets gültig.

    • Dieser Wertebereich entspricht direkt dem Feld InUse (siehe Abschnitt 6.2.1.4), das den Wert 1 enthält.

Um Änderungen am Feld "InUse" (siehe Abschnitt 6.2.1.4)zu verhindern, die fälschlicherweise zu einem Verzeichnisendemarker führen, ist der Wert 80h ungültig.

Tabelle 15: Generische EntryType-Feldstruktur

Feldname

Offset

(bit)

Größe

(Bits)

Kommentare
TypeCode 0 5 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1.1 wird der Inhalt definiert.
TypeImportance 5 1 Dieses Feld ist obligatorisch, und abschnitt 6.2.1.2 definiert seinen Inhalt.
TypeCategory 6 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1.3 wird der Inhalt definiert.
InUse 7 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1.4 wird der Inhalt definiert.
6.2.1.1 TypeCode-Feld

Das Feld TypeCode beschreibt teilweise den spezifischen Typ des angegebenen Verzeichniseintrags. In diesem Feld sowie den Feldern TypeImportance und TypeCategory (siehe Abschnitt 6.2.1.2 bzw. Abschnitt 6.2.1.3)wird der Typ des angegebenen Verzeichniseintrags eindeutig identifiziert.

Alle möglichen Werte dieses Felds sind gültig, es sei denn, die Felder TypeImportance und TypeCategory enthalten beide den Wert 0. In diesem Fall ist der Wert 0 für dieses Feld ungültig.

6.2.1.2 TypeImportance-Feld

Das Feld TypeImportance muss die Wichtigkeit des angegebenen Verzeichniseintrags beschreiben.

Die gültigen Werte für dieses Feld sind:

  • 0 bedeutet, dass der jeweilige Verzeichniseintrag kritisch ist (siehe Abschnitt 6.3.1.2.1 und Abschnitt 6.4.1.2.1 für kritische primäre bzw. kritische sekundäre Verzeichniseinträge).

  • 1, was bedeutet, dass der jeweilige Verzeichniseintrag unbedenklich ist (siehe Abschnitt 6.3.1.2.2 bzw. Abschnitt 6.4.1.2.2 für unbedenkliche Einträge in primären bzw. unbedenklichen sekundären Verzeichnissen)

6.2.1.3 TypeCategory-Feld

Das Feld TypeCategory muss die Kategorie des angegebenen Verzeichniseintrags beschreiben.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der gegebene Verzeichniseintrag primär ist (siehe Abschnitt 6.3).

  • 1, was bedeutet, dass der gegebene Verzeichniseintrag sekundär ist (siehe Abschnitt 6.4).

6.2.1.4 InUse-Feld

Das Feld InUse muss beschreiben, ob der bestimmte Verzeichniseintrag verwendet wird oder nicht.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der gegebene Verzeichniseintrag nicht verwendet wird. Dies bedeutet, dass die gegebene Struktur tatsächlich ein nicht verwendeter Verzeichniseintrag ist.

  • 1, was bedeutet, dass der gegebene Verzeichniseintrag verwendet wird; Dies bedeutet, dass die gegebene Struktur ein regulärer Verzeichniseintrag ist.

6.2.2 FirstCluster-Feld

Das Feld FirstCluster muss den Index des ersten Clusters einer Zuordnung im Cluster heap enthalten, der dem angegebenen Verzeichniseintrag zugeordnet ist.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Genau 0, was bedeutet, dass keine Clusterzuordnung vorhanden ist.

  • Zwischen 2 und ClusterCount + 1, dem Bereich gültiger Clusterindizes

Strukturen, die von dieser Vorlage abgeleitet werden, definieren möglicherweise sowohl die Felder FirstCluster als auch DataLength neu, wenn eine Clusterzuordnung nicht mit der abgeleiteten Struktur kompatibel ist.

6.2.3 DataLength-Feld

Das Feld DataLength beschreibt die Größe der Daten in Byte, die in der zugeordneten Clusterzuordnung enthalten sind.

Der gültige Wertbereich für dieses Feld ist:

  • Mindestens 0; Wenn das Feld FirstCluster den Wert 0 enthält, ist der einzige gültige Wert dieses Felds 0.

  • ClusterCount * 2SectorsPerClusterShift * 2BytesPerSectorShift

Strukturen, die von dieser Vorlage abgeleitet werden, können sowohl die Felder FirstCluster als auch DataLength neu definieren, wenn eine Clusterzuordnung für die abgeleitete Struktur nicht möglich ist.

6.3 Generische Primäre DirectoryEntry-Vorlage

Der erste Verzeichniseintrag in einem Verzeichniseintragssatz muss ein primärer Verzeichniseintrag sein. Alle nachfolgenden Verzeichniseinträge im Verzeichniseintragssatz müssen sekundäre Verzeichniseinträge sein (siehe Abschnitt 6.4).

Die Interpretation der Vorlage Generic Primary DirectoryEntry ist obligatorisch.

Alle primären Verzeichniseintragsstrukturen werden von der Vorlage Generic Primary DirectoryEntry (siehe Tabelle 16)ableiten, die von der Vorlage Generic DirectoryEntry (siehe Abschnitt 6.2)stammt.

Tabelle 16 Generic Primary DirectoryEntry Template

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.1 wird der Inhalt definiert.
SecondaryCount 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.2 wird der Inhalt definiert.
SetChecksum 2 2 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.3 wird der Inhalt definiert.
GeneralPrimaryFlags 4 2 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4 wird der Inhalt definiert.
CustomDefined 6 14 Dieses Feld ist obligatorisch, und Strukturen, die von dieser Vorlage ableiten, definieren ihren Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.5 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.6 wird der Inhalt definiert.

6.3.1 EntryType-Feld

Das EntryType-Feld muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry angegeben ist (siehe Abschnitt 6.2.1).

6.3.1.1 TypeCode-Feld

Das TypeCode-Feld muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.1).

6.3.1.2 TypeImportance-Feld

Das Feld TypeImportance muss der Definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1.2).

6.3.1.2.1 Kritische primäre Verzeichniseinträge

Kritische primäre Verzeichniseinträge enthalten Informationen, die für die ordnungsgemäße Verwaltung eines exFAT-Volumes von entscheidender Bedeutung sind. Nur das Stammverzeichnis enthält wichtige primäre Verzeichniseinträge (Dateiverzeichniseinträge sind eine Ausnahme, siehe Abschnitt 7.4).

Die Definition kritischer primärer Verzeichniseinträge entspricht der Hauptrevisionsnummer exFAT. Implementierungen müssen alle kritischen primären Verzeichniseinträge unterstützen und nur die kritischen primären Verzeichniseintragsstrukturen aufzeichnen, die diese Spezifikation definiert.

6.3.1.2.2 Unbedenkliche primäre Verzeichniseinträge

Unbedenkliche primäre Verzeichniseinträge enthalten zusätzliche Informationen, die für die Verwaltung eines exFAT-Volumes nützlich sein können. Jedes Verzeichnis kann unbedenkliche primäre Verzeichniseinträge enthalten.

Die Definition unbedenklicher primärer Verzeichniseinträge korreliert mit der kleineren ExFAT-Revisionsnummer. Die Unterstützung für jeden unbedenklichen primären Verzeichniseintrag, den diese Spezifikation definiert, oder jede nachfolgende Spezifikation, die definiert wird, ist optional. Ein unbekannter, unbedenklicher primärer Verzeichniseintrag rendert den gesamten Verzeichniseintragssatz als nicht unbekannt (über die Definition der anwendbaren Verzeichniseintragsvorlagen hinaus).

6.3.1.3 TypeCategory-Feld

Das Feld TypeCategory muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.3).

Für diese Vorlage muss der gültige Wert für dieses Feld 0 sein.

6.3.1.4 InUse-Feld

Das Feld InUse muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.4).

6.3.2 SecondaryCount-Feld

Das Feld SecondaryCount muss die Anzahl sekundärer Verzeichniseinträge beschreiben, die unmittelbar auf den angegebenen eintrag des primären Verzeichnisses folgen. Diese sekundären Verzeichniseinträge bilden zusammen mit dem angegebenen primären Verzeichniseintrag den Verzeichniseintragssatz.

Der gültige Wertebereich für dieses Feld muss wie hier angegeben sein:

  • Mindestens 0. Dies bedeutet, dass dieser primäre Verzeichniseintrag der einzige Eintrag im Verzeichniseintragssatz ist.

  • Mindestens 255, was bedeutet, dass die nächsten 255 Verzeichniseinträge und dieser primäre Verzeichniseintrag den Verzeichniseintragssatz umfassen.

Kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, können die Felder SecondaryCount und SetChecksum neu definieren.

6.3.3 SetChecksum-Feld

Das Feld SetChecksum muss die Prüfsumme aller Verzeichniseinträge im angegebenen Verzeichniseintragssatz enthalten. Die Prüfsumme schließt dieses Feld jedoch aus (siehe Abbildung 2). Implementierungen müssen überprüfen, ob der Inhalt dieses Felds gültig ist, bevor ein anderer Verzeichniseintrag im angegebenen Verzeichniseintragssatz verwendet wird.

Kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, können die Felder SecondaryCount und SetChecksum neu definieren.

Abbildung 2 EntrySetChecksum-Berechnung

UInt16 EntrySetChecksum
(
    UCHAR * Entries,       // points to an in-memory copy of the directory entry set
    UCHAR   SecondaryCount
)
{
    UInt16 NumberOfBytes = ((UInt16)SecondaryCount + 1) * 32;
    UInt16 Checksum = 0;
    UInt16 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 2) || (Index == 3))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x8000 : 0) + (Checksum>>1) +  (UInt16)Entries[Index];
    }
    return Checksum;
}

6.3.4 GeneralPrimaryFlags-Feld

Das Feld GeneralPrimaryFlags enthält Flags (siehe Tabelle 17).

Kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, können dieses Feld neu definieren.

Tabelle 17: Generische GeneralPrimaryFlags-Feldstruktur

Feldname

Offset

(bit)

Größe

(Bits)

Kommentare
AllocationPossible 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4.1 wird der Inhalt definiert.
NoFatChain 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4.2 wird der Inhalt definiert.
CustomDefined 2 14 Dieses Feld ist obligatorisch, und Strukturen, die von dieser Vorlage ableiten, können dieses Feld definieren.
6.3.4.1 ZuordnungPossible-Feld

Das Feld AllocationPossible muss beschreiben, ob eine Zuordnung im Cluster heap für den angegebenen Verzeichniseintrag möglich ist.

Die gültigen Werte für dieses Feld sind:

  • 0 bedeutet, dass eine zugeordnete Zuordnung von Clustern nicht möglich ist und die Felder FirstCluster und DataLength tatsächlich nicht definiert sind (Strukturen, die von dieser Vorlage ableiten, können diese Felder neu definieren).

    1. Dies bedeutet, dass eine zugeordnete Zuordnung von Clustern möglich ist und die Felder FirstCluster und DataLength wie definiert sind.
6.3.4.2 NoFatChain-Feld

Das Feld NoFatChain muss angeben, ob das aktive FAT die Clusterkette der angegebenen Zuordnung beschreibt.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass die entsprechenden FAT-Einträge für die Clusterkette der Zuordnung gültig sind und von Implementierungen interpretiert werden müssen. Wenn das Feld AllocationPossible den Wert 0 enthält, oder wenn das Feld AllocationPossible den Wert 1 enthält und das Feld FirstCluster den Wert 0 enthält, ist der einzige gültige Wert dieses Felds 0.

  • 1, was bedeutet, dass die zugeordnete Zuordnung eine zusammenhängende Reihe von Clustern ist. Die entsprechenden FAT-Einträge für die Cluster sind ungültig, und Implementierungen dürfen sie nicht interpretieren. -Implementierungen können die folgende Gleichung verwenden, um die Größe der zugeordneten Zuordnung zu berechnen: DataLength / (2SectorsPerClusterShift * 2BytesPerSectorShift) aufgerundet auf die nächste ganze Zahl

Wenn kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, das Feld GeneralPrimaryFlags neu definieren, sind die entsprechenden FAT-Einträge für die Clusterkette der zugeordneten Zuordnung gültig.

6.3.5 FirstCluster-Feld

Das FirstCluster-Feld muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.2).

Wenn das NoFatChain-Bit 1 ist, muss FirstCluster auf einen gültigen Cluster im Clusterhap verweisen.

Kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, können die Felder FirstCluster und DataLength neu definieren. Andere Strukturen, die von dieser Vorlage ableiten, können die Felder FirstCluster und DataLength nur dann neu definieren, wenn das Feld AllocationPossible den Wert 0 enthält.

6.3.6 DataLength-Feld

Das DataLength-Feld muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.3).

Wenn das NoFatChain-Bit 1 ist, darf DataLength nicht 0 (null) sein. Wenn das FirstCluster-Feld 0 (null) ist, muss DataLength ebenfalls 0 (null) sein.

Kritische primäre Verzeichniseintragsstrukturen, die von dieser Vorlage ableiten, können die Felder FirstCluster und DataLength neu definieren. Andere Strukturen, die von dieser Vorlage ableiten, können die Felder FirstCluster und DataLength nur dann neu definieren, wenn das Feld AllocationPossible den Wert 0 enthält.

6.4 Generische sekundäre DirectoryEntry-Vorlage

Der zentrale Zweck von sekundären Verzeichniseinträgen besteht in der Bereitstellung zusätzlicher Informationen zu einem Verzeichniseintragssatz. Die Interpretation der Vorlage Generic Secondary DirectoryEntry ist obligatorisch.

Die Definition von kritischen und unbedenklichen sekundären Verzeichniseinträgen korreliert mit der kleineren ExFAT-Revisionsnummer. Die Unterstützung für alle kritischen oder unbedenklichen sekundären Verzeichniseintrage, die diese Spezifikation oder nachfolgende Spezifikationen definiert, ist optional.

Alle sekundären Verzeichniseintragsstrukturen werden von der Vorlage Generic Secondary DirectoryEntry (siehe Tabelle 18)ableiten, die von der Vorlage Generic DirectoryEntry (siehe Abschnitt 6.2)stammt.

Tabelle 18: Generische sekundäre DirectoryEntry-Vorlage

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.1 wird der Inhalt definiert.
GeneralSecondaryFlags 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.2 wird der Inhalt definiert.
CustomDefined 2 18 Dieses Feld ist obligatorisch, und Strukturen, die von dieser Vorlage ableiten, definieren ihren Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.3 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.4 wird der Inhalt definiert.

6.4.1 EntryType-Feld

Das EntryType-Feld muss der Definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1).

6.4.1.1 TypeCode-Feld

Das TypeCode-Feld muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.1).

6.4.1.2 TypeImportance-Feld

Das Feld TypeImportance muss der Definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1.2).

6.4.1.2.1 Kritische sekundäre Verzeichniseinträge

Kritische sekundäre Verzeichniseinträge enthalten Informationen, die für die ordnungsgemäße Verwaltung des enthaltenden Verzeichniseintragssets von entscheidender Bedeutung sind. Die Unterstützung für bestimmte kritische sekundäre Verzeichniseinträge ist optional, aber ein unbekannter Eintrag für kritisches Verzeichnis rendert den gesamten Verzeichniseintragssatz als nicht erkannt (über die Definition der entsprechenden Verzeichniseintragsvorlagen hinaus).

Wenn ein Verzeichniseintragssatz jedoch mindestens einen kritischen sekundären Verzeichniseintrag enthält, den eine Implementierung nicht erkennt, muss die Implementierung höchstens die Vorlagen der Verzeichniseinträge im Verzeichniseintragssatz interpretieren und nicht die Daten, die einer Zuordnung eines Verzeichniseintrags im Verzeichniseintragssatz zugeordnet sind ( Dateiverzeichniseinträge stellen eine Ausnahme dar. siehe Abschnitt 7.4).

6.4.1.2.2 Unbedenkliche sekundäre Verzeichniseinträge

Unbedenkliche sekundäre Verzeichniseinträge enthalten zusätzliche Informationen, die für die Verwaltung des enthaltenden Verzeichniseintragssatzes nützlich sein können. Die Unterstützung für einen bestimmten unbedenklichen sekundären Verzeichniseintrag ist optional. Nicht erkannte unbedenkliche sekundäre Verzeichniseinträge rendern nicht den gesamten Verzeichniseintragssatz als nicht erkannt.

Implementierungen ignorieren möglicherweise jeden nicht erkannten unbedenklichen sekundären Eintrag.

6.4.1.3 TypeCategory-Feld

Das Feld TypeCategory muss der Definition in der Vorlage Generic DirectoryEntry entsprechen (siehe Abschnitt 6.2.1.3).

Für diese Vorlage ist der gültige Wert für dieses Feld 1.

6.4.1.4 Feld "InUse"

Das Feld InUse muss der Definition in der Vorlage Generic DirectoryEntry entsprechen (siehe Abschnitt 6.2.1.4).

6.4.2 GeneralSecondaryFlags-Feld

Das Feld GeneralSecondaryFlags enthält Flags (siehe Tabelle 19).

Tabelle 19 Generische AllgemeineSecondaryFlags-Feldstruktur

Feldname

Offset

(Bit)

Größe

(Bits)

Kommentare
AllocationPossible 0 1 Dieses Feld ist obligatorisch, und Abschnitt 6.4.2.1 definiert seinen Inhalt.
NoFatChain 1 1 Dieses Feld ist obligatorisch, und Abschnitt 6.4.2.2 definiert seinen Inhalt.
CustomDefined 2 6 Dieses Feld ist obligatorisch, und Strukturen, die von dieser Vorlage abgeleitet werden, können dieses Feld definieren.
6.4.2.1 AllocationPossible-Feld

Das Feld AllocationPossible muss die gleiche Definition wie das gleiche benannte Feld in der generischen primären DirectoryEntry-Vorlage aufweisen (siehe Abschnitt 6.3.4.1).

6.4.2.2 NoFatChain-Feld

Das NoFatChain-Feld muss die gleiche Definition wie das gleiche benannte Feld in der generischen primären DirectoryEntry-Vorlage aufweisen (siehe Abschnitt 6.3.4.2).

6.4.3 FirstCluster-Feld

Das Feld FirstCluster muss der Definition in der Vorlage Generic DirectoryEntry entsprechen (siehe Abschnitt 6.2.2).

Wenn das NoFatChain-Bit 1 ist, muss FirstCluster auf einen gültigen Cluster im Clusterheap verweisen.

6.4.4 DataLength-Feld

Das DataLength-Feld muss der Definition in der Generischen DirectoryEntry-Vorlage entsprechen (siehe Abschnitt 6.2.3).

Wenn das NoFatChain-Bit 1 ist, darf DataLength nicht 0 (null) sein. Wenn das FirstCluster-Feld 0 (null) ist, muss DataLength ebenfalls 0 (null) sein.

7 Verzeichniseintragsdefinitionen

Revision 1.00 des exFAT-Dateisystems definiert die folgenden Verzeichniseinträge:

7.1 Zuordnungsbitmap-Verzeichniseintrag

Im exFAT-Dateisystem beschreibt ein FAT nicht den Zuordnungsstatus von Clustern. stattdessen eine Zuordnungsbitmap. Zuordnungsbitmaps sind im Clusterheap vorhanden (siehe Abschnitt 7.1.5)und weisen entsprechende kritische primäre Verzeichniseinträge im Stammverzeichnis auf (siehe Tabelle 20).

Das Feld NumberOfFats bestimmt die Anzahl gültiger Zuordnungsbitmap-Verzeichniseinträge im Stammverzeichnis. Wenn das Feld NumberOfFats den Wert 1 enthält, ist die einzige gültige Anzahl von Zuordnungsbitmap-Verzeichniseinträgen 1. Darüber hinaus ist der ein Eintrag für das Zuordnungsbitmap-Verzeichnis nur gültig, wenn er die erste Zuordnungsbitmap beschreibt (siehe Abschnitt 7.1.2.1). Wenn das Feld NumberOfFats den Wert 2 enthält, ist die einzige gültige Anzahl von Zuordnungsbitmap-Verzeichniseinträgen 2. Darüber hinaus sind die beiden Zuordnungsbitmap-Verzeichniseinträge nur gültig, wenn einer die erste Zuordnungsbitmap und der andere die zweite Zuordnungsbitmap beschreibt.

Table 20 Allocation Bitmap DirectoryEntry Structure

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und Abschnitt 7.1.1 definiert seinen Inhalt.
BitmapFlags 1 1 Dieses Feld ist obligatorisch, und Abschnitt 7.1.2 definiert seinen Inhalt.
Reserviert 2 18 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und Abschnitt 7.1.3 definiert seinen Inhalt.
DataLength 24 8 Dieses Feld ist obligatorisch, und Abschnitt 7.1.4 definiert seinen Inhalt.

7.1.1 EntryType-Feld

Das Feld EntryType muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (siehe Abschnitt 6.3.1)angegeben ist.

7.1.1.1 TypCodefeld

Das TypeCode-Feld muss der Definition entsprechen, die in der Generischen primären DirectoryEntry-Vorlage angegeben ist (siehe Abschnitt 6.3.1.1).

Für einen Zuordnungsbitmap-Verzeichniseintrag ist der gültige Wert für dieses Feld 1.

7.1.1.2 TypeImportance-Feld

Das Feld TypeImportance muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.2).

Für einen Zuordnungsbitmap-Verzeichniseintrag ist der gültige Wert für dieses Feld 0.

7.1.1.3 TypeCategory-Feld

Das Feld TypeCategory muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.3).

7.1.1.4 InUse-Feld

Das Feld InUse muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.4).

7.1.2 BitmapFlags-Feld

Das Feld BitmapFlags enthält Flags (siehe Tabelle 21).

BitmapFlags-Feldstruktur in Tabelle 21

Feldname

Offset

(bit)

Größe

(Bits)

Kommentare
BitmapIdentifier 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 7.1.2.1 wird der Inhalt definiert.
Reserviert 1 7 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
7.1.2.1 BitmapIdentifier-Feld

Das Feld BitmapIdentifier muss angeben, welche Zuordnungsbitmap der angegebenen Verzeichniseintrag beschreibt. Implementierungen müssen die erste Zuordnungsbitmap in Verbindung mit dem ersten FAT verwenden und die zweite Zuordnungsbitmap in Verbindung mit der zweiten FAT-Datei verwenden. Das Feld ActiveFat beschreibt, welche FAT- und Zuordnungsbitmap aktiv sind.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der gegebene Verzeichniseintrag die erste Zuordnungsbitmap beschreibt.

  • 1, was bedeutet, dass der gegebene Verzeichniseintrag die zweite Zuordnungsbitmap beschreibt und nur möglich ist, wenn NumberOfFats den Wert 2 enthält.

7.1.3 FirstCluster-Feld

Das FirstCluster-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.5).

Dieses Feld enthält den Index des ersten Clusters der Clusterkette, wie von FAT beschrieben, der die Zuordnungsbitmap hostet.

7.1.4 DataLength-Feld

Das DataCluster-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.6).

7.1.5 Zuordnungsbitmap

Eine Zuordnungsbitmap zeichnet den Zuordnungsstatus der Cluster im Cluster heap auf. Jedes Bit in einer Zuordnungsbitmap gibt an, ob der entsprechende Cluster für die Zuordnung verfügbar ist.

Eine Zuordnungsbitmap stellt Cluster vom niedrigsten bis zum höchsten Index dar (siehe Tabelle 22). Aus historischen Gründen verfügt der erste Cluster über Index 2. Hinweis: Das erste Bit in der Bitmap ist das niedrigste Bit des ersten Byte.

Tabelle 22: Zuordnungsbitmapstruktur

Feldname

Offset

(bit)

Größe

(Bits)

Kommentare
BitmapEntry[2] 0 1 Dieses Feld ist obligatorisch, und abschnitt 7.1.5.1 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.

BitmapEntry[ClusterCount+1] ClusterCount – 1 1

Dieses Feld ist obligatorisch, und in Abschnitt 7.1.5.1 wird der Inhalt definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das Feld ClusterCount.

Reserviert ClusterCount (DataLength * 8) – ClusterCount

Dieses Feld ist obligatorisch, und sein Inhalt ist (falls erforderlich) reserviert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das Feld ClusterCount.

7.1.5.1 BitmapEntry [ 2 ] ... BitmapEntry [ ClusterCount+1-Felder ]

Jedes BitmapEntry-Feld in diesem Array stellt einen Cluster im Cluster heap dar. BitmapEntry 2 stellt den ersten Cluster [ ] im Cluster heap dar, und BitmapEntry ClusterCount+1 stellt den letzten Cluster [ ] im Cluster heap dar.

Die gültigen Werte für diese Felder sind:

  • 0, der den entsprechenden Cluster als für die Zuordnung verfügbar beschreibt.

  • 1, in dem der entsprechende Cluster als nicht für die Zuordnung verfügbar beschrieben wird (eine Clusterzuordnung kann den entsprechenden Cluster möglicherweise bereits nutzen, oder die aktive FAT-Datei beschreibt den entsprechenden Cluster möglicherweise als schlecht)

7.2 Tabellenverzeichniseintrag im Up-Case-Fall

Die Up-case-Tabelle definiert die Konvertierung von Klein- in Groß-/Kleinzeichen. Dies ist wichtig, da beim Verzeichniseintrag Dateiname (siehe Abschnitt 7.7) Unicode-Zeichen verwendet werden und beim ExFAT-Dateisystem die Groß-/Kleinschreibung nicht beachtet und die Groß-/Kleinschreibung beibehalten wird. Die Up-case-Tabelle ist im Cluster heap vorhanden (siehe Abschnitt 7.2.5) und verfügt über einen entsprechenden kritischen primären Verzeichniseintrag im Stammverzeichnis (siehe Tabelle 23). Die gültige Anzahl von Up-case-Tabellenverzeichniseinträgen ist 1.

Aufgrund der Beziehung zwischen der Up-Case-Tabelle und den Dateinamen sollten Implementierungen die Up-Case-Tabelle nur aufgrund von Formatvorgängen ändern.

Tabelle 23: TabellenverzeichnisIntry-Struktur mit Up-Case-Fall

Feldname

Offset

(Byte)

Größe

(Byte)

Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.1 wird der Inhalt definiert.
Reserved1 1 3 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
TableChecksum 4 4 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.2 wird der Inhalt definiert.
Reserved2 8 12 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.3 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.4 wird der Inhalt definiert.

7.2.1 EntryType-Feld

Das EntryType-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1).

7.2.1.1 TypeCode-Feld

Das TypeCode-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.1).

Für den Verzeichniseintrag Up-case Table ist der gültige Wert für dieses Feld. 2.

7.2.1.2 TypeImportance-Feld

Das Feld TypeImportance muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.2).

Für den Verzeichniseintrag Up-case Table ist der gültige Wert für dieses Feld. 0.

7.2.1.3 TypeCategory-Feld

Das Feld TypeCategory muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.3).

7.2.1.4 InUse-Feld

Das Feld InUse muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.1.4).

7.2.2 TableChecksum-Feld

Das Feld TableChecksum enthält die Prüfsumme der Up-case-Tabelle (die in den Feldern FirstCluster und DataLength beschrieben wird). Implementierungen müssen überprüfen, ob der Inhalt dieses Felds gültig ist, bevor die Up-case-Tabelle verwendet wird.

Abbildung 3 TableChecksum-Berechnung

UInt32 TableChecksum
(
    UCHAR  * Table,    // points to an in-memory copy of the up-case table
    UInt64   DataLength
)
{
    UInt32 Checksum = 0;
    UInt64 Index;

    for (Index = 0; Index < DataLength; Index++)
    {
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Table[Index];
    }

    return Checksum;
}

7.2.3 FirstCluster-Feld

Das FirstCluster-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.5).

Dieses Feld enthält den Index des ersten Clusters der Clusterkette, wie von FAT beschrieben, der die Up-case-Tabelle hostet.

7.2.4 DataLength-Feld

Das DataCluster-Feld muss der Definition entsprechen, die in der Vorlage Generic Primary DirectoryEntry (Generisches primäres Verzeichnis) angegeben ist (siehe Abschnitt 6.3.6).

7.2.5 Up-Case-Tabelle

Eine Up-Case-Tabelle ist eine Reihe von Unicode-Zeichenzuordnungen. Eine Zeichenzuordnung besteht aus einem 2-Byte-Feld, bei dem der Index des Felds in der Up-Case-Tabelle das Unicode-Zeichen darstellt, für das die 2-Byte-Case-Zeichenfolge verwendet werden soll, und das 2-Byte-Feld, das das Unicode-Zeichen mit voraufgekannten Zeichen darstellt.

Die ersten 128 Unicode-Zeichen verfügen über obligatorische Zuordnungen (siehe Tabelle 24). Eine Up-Case-Tabelle mit einer anderen Zeichenzuordnung für eines der ersten 128 Unicode-Zeichen ist ungültig.

Implementierungen, die nur Zeichen aus dem obligatorischen Zuordnungsbereich unterstützen, ignorieren möglicherweise die Zuordnungen der restlichen Up-Case-Tabelle. Solche Implementierungen dürfen beim Erstellen oder Umbenennen von Dateien nur Zeichen aus dem obligatorischen Zuordnungsbereich verwenden (siehe Abschnitt 7.7). Wenn sie vorhandene Dateinamen in eine neue Schreib schreibe, dürfen solche Implementierungen keine Zeichen aus dem nicht obligatorischen Zuordnungsbereich verwenden, sondern sie im resultierenden Dateinamen mit vorgeänderten Schreibfehlern intakt lassen (dies ist eine partielle Auf-Schreib-/Schreibmaschierung). Beim Vergleichen von Dateinamen müssen solche Implementierungen Dateinamen, die sich vom verglichenen Namen unterscheiden, nur durch Unicode-Zeichen aus dem nicht obligatorischen Zuordnungsbereich als gleichwertig behandeln. Obwohl solche Dateinamen nur potenziell äquivalent sind, können solche Implementierungen nicht sicherstellen, dass der Dateiname mit der vollständigen Hoch-/Hochsparung nicht mit dem zu vergleichenden Namen in Zusammenhang steht.

Tabelle 24 Erforderliche erste 128 Einträge in einer Up-Case-Tabelle

Tabellenindex + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7
0000h 0000h 0001h 0002h 0003h 0004h 0005h 0006h 0007h
0008h 0008h 0009h 000Ah 000Bh 000Ch 000Dh 000Eh 000Fh
0010h 0010h 0011h 0012h 0013h 0014h 0015h 0016h 0017h
0018h 0018h 0019h 001Ah 001Bh 001Ch 001Dh 001Eh 001Fh
0020h 0020h 0021h 0022h 0023h 0024h 0025h 0026h 0027h
0028h 0028h 0029h 002Ah 002Bh 002Ch 002Dh 002Eh 002Fh
0030h 0030h 0031h 0032h 0033h 0034h 0035h 0036h 0037h
0038h 0038h 0039h 003Ah 003Bh 003Ch 003Dh 003Eh 003Fh
0040h 0040h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0048h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0050h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0058h 0058h 0059h 005Ah 005Bh 005Ch 005Dh 005Eh 005Fh
0060h 0060h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0068h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0070h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0078h 0058h 0059h 005Ah 007Bh 007Ch 007Dh 007Eh 007Fh

(Hinweis: Einträge mit Nichtidentitäts-Up-Case-Zuordnungen sind fett formatiert.)

Beim Formatieren eines Volumes können Implementierungen eine Groß-/Kleinschreibungstabelle in einem komprimierten Format mithilfe der Identitätszuordnungskomprimierung generieren, da ein großer Teil des Unicode-Zeichenraums kein Groß-/Kleinschreibungskonzept aufgibt (was bedeutet, dass die Zeichen "Kleinbuchstaben" und "Großbuchstaben" gleichwertig sind). Implementierungen komprimieren eine Up-Case-Tabelle, indem sie eine Reihe von Identitätszuordnungen mit dem Wert FFFFh gefolgt von der Anzahl der Identitätszuordnungen darstellen.

Eine Implementierung kann beispielsweise die ersten 100 Zeichenzuordnungen (64h) mit den folgenden acht Einträgen einer komprimierten Up-Case-Tabelle darstellen:

FFFFh, 0061h, 0041h, 0042h, 0043h

Die ersten beiden Einträge geben an, dass die ersten 97 (61h) Zeichen (von 0000h bis 0060h) Identitätszuordnungen aufweisen. Die nachfolgenden Zeichen (0061h bis 0063h) werden den Zeichen 0041h bis 0043h zugeordnet.

Die Möglichkeit, beim Formatieren eines Volumes eine komprimierte Up-Case-Tabelle bereitzustellen, ist optional. Die Möglichkeit, sowohl eine nicht komprimierte als auch eine komprimierte Up-Case-Tabelle zu interpretieren, ist jedoch obligatorisch. Der Wert des TableChecksum-Felds entspricht immer der Art und Weise, wie die Up-Case-Tabelle auf dem Volume vorhanden ist, die entweder im komprimierten oder unkomprimierten Format vorliegen kann.

Beim Formatieren eines Volumes sollten Implementierungen die empfohlene Up-Case-Tabelle im komprimierten Format aufzeichnen (siehe Tabelle 25), für die der Wert des TableChecksum-Felds E619D30Dh ist.

Wenn eine Implementierung eine eigene Up-Case-Tabelle definiert , entweder komprimiert oder unkomprimiert, muss diese Tabelle den gesamten Unicode-Zeichenbereich abdecken (von zeichencodes 0000h bis einschließlich FFFFh).