Wat is de CF-bestandsextensie? De configuratie instellen vanuit een CF-bestand. Keten van vrije blokken.
De interne structuur van het configuratiebestand (*.cf) is al lang geen geheim meer, maar er is vrijwel geen gedetailleerde documentatie hiervoor op internet. Dit artikel is een poging om deze leemte op te vullen.
De interne structuur van het configuratiebestand (*.cf) is geen geheim. Goede mensen hebben het lang geleden uit elkaar gehaald en veel interessante hulpprogramma's gemaakt waarmee je met dit formaat kunt werken. Op Infostart staan een flink aantal (zo niet meer) interessante publicaties die op de een of andere manier de inhoud van *.cf-bestanden lezen, dus dit onderwerp is helemaal niet nieuw.
Helaas is er echter zeer weinig goede documentatie van hoge kwaliteit voor dit formaat. Voor het schrijven van dit artikel werd ik geïnspireerd door de publicatie van de gerespecteerde awa, die in detail de structuur van het 1C:Enterprise besta(*.1CD) beschreef.
Het lijkt mij dat dat artikel een katalysator werd voor een aantal ontwikkelingen die door andere auteurs waren gecreëerd. De openheid en toegankelijkheid van informatie stimuleerde de creatieve activiteit van de auteurs en de hele gemeenschap ontving een aantal uitstekende hulpmiddelen voor het werken met 1C-bestandsdatabases.
Het lijkt mij dat een gedetailleerde beschrijving van het CF-formaat ook voor veel auteurs interessant zal zijn, en misschien krijgen we de kans om veel nieuwe interessante ontwikkelingen te zien op het gebied van configuratiebestanden.
Achtergrond
Zoals hierboven vermeld, is de structuur van het formaat al lang bekend en is er informatie over de structuur op internet (zij het nogal schaars). Ik had deze informatie nodig bij het ontwikkelen van het V8Viewer-programma, waarbij ik me baseerde op de volgende materialen:
Terminologie
Laten we direct naar het onderwerp van onze discussie gaan.
Laten we, om de puntjes op de i te zetten, de naam van het formaat zelf bepalen.
In dit formaat worden allereerst niet alleen configuratiebestanden aangemaakt, maar ook externe rapportage- en verwerkingsbestanden. Op internet kwam ik de naam Samengesteld bestand tegen. Misschien is het al ingeburgerd onder 1C-oldtimers, maar ik vind het niet echt leuk.
Voor de doeleinden van dit artikel stel ik voor om dit formaat een “container” te noemen. Als het lieve publiek de juiste naam in de reacties suggereert, zal ik heel blij zijn.
Laten we naar binnen kijken
De logische eenheid voor gegevensopslag binnen een container is een document. Een document is een betekenisvolle, complete set gegevens die op de een of andere manier kan worden gelezen en geïnterpreteerd. Ik gebruik de term 'bestand' specifiek niet, omdat ik deze naam zal reserveren voor een andere entiteit, waar ik het later over zal hebben.
Over het algemeen is een CF (EPF/ERF)-bestand dus een container waarin documenten worden opgeslagen.
Elk document in een container kan in blokken worden verdeeld. De minimale fysieke eenheid voor gegevensopslag is een blok, maar de betekenisvolle logische eenheid is een document. Met andere woorden, documenten in een container kunnen in de vorm van verspreide stukjes (blokken) liggen en om de inhoud van het document te kunnen lezen, moeten alle stukjes worden verzameld en gecombineerd.
Containerstructuur
De container bevat de volgende onderdelen (in volgorde):
Container header Adres van het eerste lege blok waarin u gegevens kunt toevoegen Standaard blokgrootte Aantal bestanden in de container Container inhoudsopgave document De daadwerkelijke gegevens die in de inhoudsopgave staan vermeld
Blokstructuur
Een blok bestaat uit een header en een body. De header geeft de totale grootte van het gehele document aan, de grootte van het huidige blok en het adres (positie in het bestand) van het volgende blok. Direct na de header komt de body van het blok - in feite de gegevens die we nodig hebben. De body van het blok heeft precies de lengte (in bytes) die in de header is opgegeven.
In de container bevindt zich hier en daar een magische constante die een bepaalde "leegte" aangeeft - dit is het getal 0x7fffffff.
Wanneer we een document uit blokken samenstellen, kijken we in de header naar het adres van het volgende blok. Als het gelijk is aan 0x7fffffff, dan is er geen “volgend” blok, dit is het laatste.
De constante 0x7fffffff is de waarde van INT_MAX, d.w.z. de maximale waarde van een geheel getal van 4 bytes met teken.
Logische "bestanden"
Ik zei dat ik de term ‘bestand’ zou bewaren voor betere tijden. Die tijden zijn aangebroken :)
Alle configuratie wordt als bestanden in de container opgeslagen. Als we ons onze cursus computerwetenschappen herinneren, zullen we ons herinneren dat een ‘bestand’, zo werd ons verteld, een document met een naam is.
Een bestand verschilt van een “document” doordat het een naam heeft en er met die naam naar verwezen kan worden. Als we de inhoud van de configuratie ontleden en metagegevens opbouwen, zullen we in de bestanden veel verwijzingen naar andere bestanden vinden. De configuratieleesprocedure werkt op bestandsnamen en verwijst er bij naam naar.
Samenvattend kunnen we het volgende zeggen: de container bevat verschillende documenten, maar sommige hebben een naam. Dergelijke documenten worden “bestanden” genoemd en zijn niet van dienstgerichte aard, maar van direct toegepaste aard. Het zijn de bestanden die informatie over configuratiemetagegevens opslaan.
Bestandscomponenten
Elk dossier bestaat uit twee documenten:
Attributendocument, dat de bestandsnaam en aanmaak-/wijzigingsdatums bevat. Inhoudsdocument, dat de daadwerkelijke bestandstekst bevat. Inhoud van de container
Nu alle componenten zijn aangekondigd, moeten we nog kijken naar misschien wel het belangrijkste document van de container: het inhoudsopgavedocument, dat de locatie van alle containerbestanden aangeeft. Zoals hierboven vermeld, is het inhoudsopgavedocument het allereerste document van de container en komt het onmiddellijk na de containertitel.
Adres (bestandsverschuiving) van het attribuutdocument Adres (bestandsverschuiving) van het inhoudsdocument Nummer 0x7fffffff (einde-recordmarkering).
Ik wil u eraan herinneren dat elk document in blokken kan worden verdeeld (gefragmenteerd). Het algoritme voor het samenstellen van een document uit blokken zal hieronder worden besproken.
De inhoudsopgave is een 2 significant getal INT32. Het eerste nummer is het adres van het document met bestandskenmerken. Dit adres brengt ons naar het begin van het eerste blok van het attributendocument. Uit het attributendocument kunnen we de bestandsnaam achterhalen. Het tweede nummer is het documentadres van de inhoud van het bestand. Op dit adres worden we naar het begin van het 1e blok van het inhoudsdocument gebracht, vanwaar we de bestandsgegevens direct zullen lezen.
Kenmerken van datacompressie.
Een container kan een grote verscheidenheid aan bestanden bevatten. In de regel zijn dit tekstbestanden gecodeerd in UTF-8. Tussen de containerbestanden kunnen zich echter ook andere containerbestanden bevinden. De eenvoudigste analogie is met een bestandssysteem. Een container is en de bestanden in de container zijn de inhoud ervan. Een map kan andere mappen bevatten.
De hoofdmap van dit "bestandssysteem" is het *.CF-bestand zelf. Daarin kunnen zich andere containerbestanden bevinden, in wezen geneste mappen, die met exact hetzelfde algoritme worden gelezen en exact dezelfde structuur hebben.
Er is echter één bijzonderheid in de hoofdmap. Alle documentinhoud van bestanden in de hoofdmap wordt gecomprimeerd met behulp van het Deflate-algoritme. De inhoud van bestanden in geneste mappen wordt niet langer gecomprimeerd. Simpel gezegd: op het hoogste niveau van een containerbestand worden de hoofdteksten van alle bestanden gecomprimeerd, maar als het bestand in de container zelf een container is, zullen de bestanden daarin al in hun pure vorm zijn geschreven (zonder compressie).
Keten van gratis blokken
Als u gegevens uit een container verwijdert, kunnen er lege ruimtes ontstaan. Deze vrije ruimtes zijn in een keten met elkaar verbonden en vormen een soort ‘document’ waarvan de gegevens ontbreken. Met andere woorden, vrije blokken worden met elkaar verbonden volgens hetzelfde principe waarmee documentblokken met elkaar worden verbonden. Het adres van het eerste vrije blok wordt helemaal aan het begin van de containerheader aangegeven. Als het adres van een vrij blok INT_MAX is, betekent dit dat er geen vrije (lege) blokken in het midden van de container staan.
Korte samenvatting van het theoretische gedeelte Het CF(EPF/ERF)-bestand is geschreven in het “container”-formaat De container begint met een header Alle inhoud van de container, met uitzondering van de header, is geschreven in de vorm van “documenten” Het document kan in blokken worden verdeeld. Het document begint met de blokkop, waarin u kunt zien hoe u het hele document kunt lezen. Direct na de containertitel staat een inhoudsopgave. De inhoudsopgave is een reeks vermeldingen die verwijzen naar de “bestanden” in de container. Elk bestand bestaat uit twee documenten: een attributendocument, waarin de naam van dit bestand wordt gespecificeerd, en een inhoudsdocument, waar feitelijk de bestandsgegevens zich bevinden.
Elke inhoudsopgave bevat 2 adressen. De eerste is het adres van het document met bestandskenmerken, de tweede is het adres van het inhoudsdocument.
Een container kan geneste containers bevatten (zoals geneste mappen in de hoofdcontainer worden gecomprimeerd met behulp van het Deflate-algoritme, terwijl bestanden in geneste containers zonder compressie worden geschreven).
Laten we de bytes al voelen
Het is dus tijd om na te denken over hoe alle bovengenoemde entiteiten precies zijn gestructureerd.
De belangrijkste manier om gegevens uit een container te lezen, is door de reeks blokken te lezen waaruit bepaalde documenten bestaan. Het lijkt erop dat de juiste plaats om te beginnen het principe van het lezen van blokdocumenten is.
Een document in blokken lezen
CRLF - standaard Windows-regelinvoer, tekenpaar rn (0x0D,0x0A) Grootte van het gehele document - de totale lengte van het document in bytes. Geschreven als een tekenreeksweergave van een hexadecimaal getal. Lengte - 8 bytes.
Ruimte - ruimte. Teken 0x20 De grootte van het huidige blok is de lengte van de bloktekst in bytes. Het is ook geschreven als een tekenreeksrepresentatie van een INT32-nummer in hexadecimaal formaat. Als een document uit één enkel blok bestaat, dan is de grootte van het gehele document kleiner of gelijk aan de grootte van het huidige blok (wat logisch is). Adres van het volgende blok is het adres waarop het volgende blok van het document bevindt. Als het adres van het volgende blok INT_MAX is, betekent dit dat er geen volgend blok is. Het adres van het volgende blok wordt ook geschreven als een stringrepresentatie van een getal.
Direct na de blokkop staat de bloktekst, die de lengte heeft die is opgegeven in het veld 'Huidige blokgrootte'.
Laten we naar de afbeelding kijken: de lengte van het hele document is 0x54 bytes, deze 0x54 bytes worden gemarkeerd met een rood kader. Dit zijn documentgegevens. De bloklengte is 0x200 bytes, d.w.z. langer dan de lengte van het document zelf. Om deze reden vormen de resterende gegevens in het blok "nullen" ongebruikte ruimte. Significante bytes zijn die gemarkeerd met een rood kader.
Als de lengte van het document groter is dan de lengte van het blok, moet het volgende blok worden gelezen. Als er een andere waarde dan 0x7fffffff in het veld "Volgend blokadres" wordt geschreven, moet u het huidige blok lezen, vervolgens naar dit adres gaan en een ander blok lezen. Als dit blok ook het adres van het volgende blok bevat, dan moet je daar ook heen. Zo wordt een “keten” van blokken gevormd waaruit het document bestaat.
Het lezen moet doorgaan totdat de waarde 0x7fffffff wordt aangetroffen in het veld “Adres van het volgende blok” of totdat het aantal bytes dat is opgegeven in het veld “Grootte van het gehele document” is gelezen.
Het veld “Gehele documentgrootte” heeft alleen betekenis voor het eerste blok. In alle volgende blokken van het document heeft het de waarde 0x00000000.
Indeling containerheader
De containerheader is 16 bytes lang en bestaat uit de volgende velden: |
||
Uitleg |
Adres van het eerste vrije blok |
INT32 (4 bytes) |
De offset waarop de keten van vrije blokken begint |
Adres van het eerste vrije blok |
Standaard blokgrootte |
Een blok kan elke lengte hebben, maar de standaard kan worden gebruikt om bijvoorbeeld nieuwe blokken toe te voegen. |
Adres van het eerste vrije blok |
Een getal dat een bepaalde waarde weergeeft, meestal samenvallend met het aantal bestanden in de container, maar collega's in de commentaren zijn van mening dat dit niet helemaal waar is. Dit getal heeft op geen enkele manier invloed op het containerinterpretatiealgoritme; het kan worden genegeerd. |
Gereserveerd veld |
Adres van het eerste vrije blok |
Altijd gelijk aan 0 (is dat altijd?) |
Het attributendocument beschrijft de bestandsnaam en de datums waarop het is gemaakt/gewijzigd.
De containerheader is 16 bytes lang en bestaat uit de volgende velden: |
||
Tijd voor het maken van bestanden |
UINT64 (8 bytes) |
Tijd voor het maken van bestanden, uitgedrukt in intervallen van 100 microseconden sinds het begin van onze jaartelling (01/01/0001 00:00:00) |
Tijd voor bestandswijziging |
UINT64 (8 bytes) |
Insgelijks |
Gereserveerd veld |
Adres van het eerste vrije blok |
Altijd 0. Misschien zijn dit attribuutvlaggen, zoiets als alleen-lezen, verborgen, enz. Ik ben echter geen bestanden tegengekomen waarin dit veld afwijkt van nul. |
Bestandsnaam |
Tekenreeks in UTF-16-indeling |
Beslaat de gehele resterende hoofdtekst van het document (minus 2 datums en een reserveveld) |
Een inhoudsopgave lezen Stel een inhoudsopgavedocument samen uit blokken en lees het Doorloop alle vermeldingen in het inhoudsopgavedocument en lees attribuutdocumenten (namen) van containerbestanden Match elke ontvangen naam met het adres van een inhoudsdocument De uitvoer is een correspondentie “Bestandsnaam” -> “Inhoudsadres” Bestanden lezen Haal het adres van het inhoudsdocument op basis van de bestandsnaam uit de inhoudsopgave. Stel het inhoudsdocument samen uit blokken. Als dit de rootcontainer is, pak dan het inhoudsdocument uit (het is gecomprimeerd) Klaar. Het resulterende resultaat zijn de gegevens van het gezochte bestand.
Update van 25/02/2014
Tot slot
Dit artikel is niet de ultieme waarheid; er staan waarschijnlijk zelfs fouten in. Als dit onderwerp u echter interesseert, hoop ik dat dit artikel u zal helpen bij het implementeren van uw projecten. Succes! Klik eerst in het venster dat verschijnt na het starten van het programma op de knop Toevoegen . Selecteer in het volgende venster.
Het creëren van een nieuwe informatiebasis
In het volgende venster moet u het item Een infobase maken zonder configuratie selecteren om een nieuwe configuratie te ontwikkelen of een eerder verwijderde infobase te laden.
Geef in het volgende venster de naam van de database op. Na het voltooien van de bovenstaande stappen verschijnt er een nieuwe lege database in de lijst met infobases. Nu moet je het selecteren en op de knop klikken Configureer
R. Het configuratorvenster wordt geopend (Fig. 12).
Rijst. 12. Configuratorvenster Voer de menuopdracht uit. Het programmavenster verandert - de configuratieboom wordt links geopend. Nu kunt u de opdracht uitvoeren Configuratie > Configuratie laden uit bestand. Met deze opdracht kunt u de bestaande (in ons geval lege) configuratie volledig vervangen door de configuratie die is opgeslagen in het CF-bestand. In het venster dat verschijnt, Fig. 13, moet u het pad opgeven naar het bestand waarin de configuratie is opgeslagen die u wilt laden.
Nu moet je op de knop drukken Open en wacht tot het programma de configuratie heeft geladen. Dit kan behoorlijk lang duren. Als het systeem vragen stelt (in het bijzonder over het bijwerken van de databaseconfiguratie, over het accepteren van wijzigingen in de structuur van configuratie-informatie), moet u deze bevestigend beantwoorden.
In de linkerbenedenhoek van het programmavenster worden serviceberichten over de voortgang van de configuratie-update weergegeven. Nadat de update is voltooid (servicemeldingen over het laden van de database stoppen), kunt u het configuratorvenster sluiten en het programma in de gebruikersmodus starten. In de praktijk beperkt het installeren van een informatiebank met behulp van een van de bovenstaande methoden echter meestal niet de dingen die moeten worden gedaan vóór de eerste lancering van de configuratie. We mogen vooral updates niet vergeten.
Configuratie-update
Updates worden gedistribueerd als bestanden met de .CFU-extensie. Een dergelijk bestand wordt tijdens de installatie van de update gekopieerd naar een map die, in overeenstemming met de programma-instellingen, configuratie- en updatesjabloonbestanden bevat. In veruit de meeste gevallen is dit bijvoorbeeld de map C:\Program Files\1cv81\tmplts\1c.
Als u over een configuratie-updatebestand beschikt, moet u controleren of dit kan worden gebruikt om de bestaande configuratie bij te werken. Normaal gesproken kunt u in de bestanden bij updates gedetailleerde informatie vinden over welke configuratiereleases ze moeten bijwerken.
Voordat u de configuratie bijwerkt, moet u een back-up van de infobase maken. Als u een nieuw aangemaakte informatiebank bijwerkt, kunt u deze stap achterwege laten, maar om u te verzekeren tegen de negatieve gevolgen van mogelijke fouten bij het bijwerken van een “live” database, kunt u het beste een back-up maken. Om dit te doen, kunt u verschillende technieken gebruiken. In het bijzonder kunt u, wanneer u de bestandsversie van de infobase gebruikt, eenvoudigweg de map kopiëren die de infobase bevat. U kunt de configurator met de gewenste database openen en de opdracht uitvoeren Beheer > Infobase downloaden. Infobase-downloadbestanden hebben de extensie .DT. Om de informatiebank te laden, kunt u de opdracht gebruiken Beheer > Infobase laden.
Om de configuratie bij te werken, moet u deze openen in de configuratormodus en vervolgens de volgende reeks acties uitvoeren.
1. Voer de menuopdracht uit Voer de menuopdracht uit;
2. Voer de opdracht uit Configuratie > Ondersteuning > Configuratie bijwerken;
3. Er verschijnt een venster Configuratie-update(Afb. 14).
Rijst. 14. Venster voor configuratie-update
In dit venster moet u een positie selecteren Vind beschikbare updates voor het geval u het systeem nodig heeft om automatisch bepaalde mappen te scannen op zoek naar beschikbare updates. Dit is bijvoorbeeld aan te raden als u zojuist nieuwe updates hebt geïnstalleerd die naar de bovengenoemde map tmplts zijn gedownload.
Als u over het benodigde .CFU-bestand beschikt en u wilt niet dat het systeem dit zelf zoekt, kunt u de schakelaar in de stand zetten Een updatebestand selecteren;
4. Nadat u in de volgende stap het gewenste updatebestand hebt geselecteerd, start u het updateproces. Dit kan behoorlijk lang duren.
Wanneer er een informatiebank aanwezig is met een configuratie die volledig aan alle eisen voldoet, kunt u 1C:Enterprise starten door in het startvenster de gewenste database te selecteren en op de knop 1C:Enterprise te klikken. Meestal duurt de eerste lancering van een programma met een nieuwe configuratie enige tijd: het systeem voert voorbereidende acties uit.
De interne structuur van het configuratiebestand (*.cf) is geen geheim. Goede mensen hebben het lang geleden uit elkaar gehaald en veel interessante hulpprogramma's gemaakt waarmee je met dit formaat kunt werken. Op Infostart staan een flink aantal (zo niet meer) interessante publicaties die op de een of andere manier de inhoud van *.cf-bestanden lezen, dus dit onderwerp is helemaal niet nieuw.
Helaas is er echter zeer weinig goede documentatie van hoge kwaliteit voor dit formaat. Ik werd voor het schrijven van dit artikel geïnspireerd door mijn dierbare vriend, die in detail de structuur van het 1C:Enterprise besta(*.1CD) beschreef.
Het lijkt mij dat dat artikel een katalysator werd voor een aantal ontwikkelingen die door andere auteurs waren gecreëerd. De openheid en toegankelijkheid van informatie stimuleerde de creatieve activiteit van de auteurs en de hele gemeenschap ontving een aantal uitstekende hulpmiddelen voor het werken met 1C-bestandsdatabases.
Het lijkt mij dat een gedetailleerde beschrijving van het CF-formaat ook voor veel auteurs interessant zal zijn, en misschien krijgen we de kans om veel nieuwe interessante ontwikkelingen te zien op het gebied van configuratiebestanden.
Achtergrond
Zoals hierboven vermeld, is de structuur van het formaat al lang bekend en is er informatie over de structuur op internet (zij het nogal schaars). Ik had deze informatie nodig Bij het ontwikkelen van het programma, waaraan ik werkte, vertrouwde ik op de volgende materialen:
- , auteur
- http://www.richmedia.us/post/2011/01/18/cf-file-format-1c-8-compatibel.aspx, als ik me niet vergis, is de auteur
- , auteur
Terminologie
Laten we direct naar het onderwerp van onze discussie gaan.
Laten we, om de puntjes op de i te zetten, de naam van het formaat zelf bepalen.
In dit formaat worden allereerst niet alleen configuratiebestanden aangemaakt, maar ook externe rapportage- en verwerkingsbestanden. Op internet kwam ik de naam Samengesteld bestand tegen. Misschien is het al ingeburgerd onder 1C-oldtimers, maar ik vind het niet echt leuk.
In het kader van dit artikel stel ik voor om dit formaat “ houder" Als het gerespecteerde publiek de juiste naam in de reacties suggereert, zal ik heel blij zijn.
Laten we naar binnen kijken
Logische eenheid voor gegevensopslag binnenin houder is document . Een document is een betekenisvolle, complete set gegevens die op de een of andere manier kan worden gelezen en geïnterpreteerd. Ik gebruik niet specifiek de term " bestand", omdat ik deze naam zal reserveren voor een andere entiteit, waarover later.
In algemene termen is dit dus een CF (EPF/ERF)-bestand houder , waarin ze zijn opgeslagen documenten .
Elk document in een container kan worden onderverdeeld in blokken . De minimale fysieke eenheid voor gegevensopslag is blok, maar een betekenisvolle logische eenheid is dat wel document. Met andere woorden: documenten in de container kunnen in de vorm van verspreide stukken liggen ( blokken) en om de inhoud van het document te kunnen lezen, moeten alle delen ervan worden verzameld en gecombineerd.
Containerstructuur
De container bevat de volgende onderdelen (in volgorde):
- Containerkop
- Adres van het eerste lege blok waarin gegevens kunnen worden toegevoegd
- De offset waarop de keten van vrije blokken begint
- Aantal bestanden in container
- Document met containerinhoud
- De feitelijke gegevens die in de inhoudsopgave worden vermeld
Om de inhoud van de container te kunnen lezen, moet u het inhoudsopgavedocument lezen. Echter, sinds document bestaat uit blokken, dan moet je eerst leren hoe je uit dezelfde blokken een compleet document kunt samenstellen.
Blokstructuur
Een blok bestaat uit een header en een body. De header geeft de totale grootte van het gehele document aan, de grootte van het huidige blok en het adres (positie in het bestand) van het volgende blok. Direct na de header komt de body van het blok - in feite de gegevens die we nodig hebben. De body van het blok heeft precies de lengte (in bytes) die in de header is opgegeven.
In de container bevindt zich hier en daar een magische constante die een bepaalde "leegte" aangeeft - dit is het getal 0x7fffffff.
Wanneer we een document uit blokken samenstellen, kijken we in de header naar het adres van het volgende blok. Als het gelijk is aan 0x7fffffff, dan is er geen “volgend” blok, dit is het laatste.
De constante 0x7fffffff is de waarde van INT_MAX, d.w.z. de maximale waarde van een geheel getal van 4 bytes met teken.
Logische "bestanden"
Ik zei dat de term " bestand‘Ik bewaar het voor betere tijden. Die tijden zijn aangebroken :)
De gehele configuratie wordt in een container in het formulier opgeslagen bestanden. Als we ons de cursus computerwetenschappen op school herinneren, zullen we ons herinneren dat een “bestand”, zo werd ons verteld, een naam heeft document.
Een bestand verschilt van een “document” doordat het een naam heeft en er met die naam naar verwezen kan worden. Als we de inhoud van de configuratie ontleden en een metagegevensboom bouwen, zullen we in de bestanden veel verwijzingen naar andere bestanden vinden. De configuratieleesprocedure werkt op basis van namen bestanden en verwijst ernaar bij naam.
Samenvattend kunnen we het volgende zeggen: de container bevat verschillende documenten, maar sommige hebben een naam. Dergelijke documenten worden " bestanden“En ze zijn niet van dienstverlenende aard, maar van direct toegepaste aard. Precies bestanden configuratie-metadata-informatie opslaan.
Bestandscomponenten
Elk bestand bestaat uit twee documenten:
- Attributendocument dat de bestandsnaam en aanmaak-/wijzigingsdatums bevat
- Het inhoudsdocument dat de daadwerkelijke hoofdtekst van het bestand bevat
Nu alle componenten zijn aangekondigd, moeten we nog kijken naar misschien wel het belangrijkste document van de container: het inhoudsopgavedocument, dat de locatie van alle containerbestanden aangeeft. Zoals hierboven vermeld, is het inhoudsopgavedocument het allereerste document van de container en komt het onmiddellijk na de containertitel.
- Adres (bestandsverschuiving) van het attribuutdocument
- Adres (bestandsverschuiving) van het inhoudsdocument
- Nummer 0x7fffffff (einde van recordmarkering).
Ik wil u eraan herinneren dat elk document in blokken kan worden verdeeld (gefragmenteerd). Het algoritme voor het samenstellen van een document uit blokken zal hieronder worden besproken.
De inhoudsopgave is een 2 significant getal INT32. Het eerste nummer is het adres van het document met bestandskenmerken. Dit adres brengt ons naar het begin van het eerste blok van het attributendocument. Uit het attributendocument kunnen we de bestandsnaam achterhalen. Het tweede nummer is het documentadres van de inhoud van het bestand. Op dit adres worden we naar het begin van het 1e blok van het inhoudsdocument gebracht, vanwaar we de bestandsgegevens direct zullen lezen.
Kenmerken van datacompressie.
Een container kan een grote verscheidenheid aan bestanden bevatten. In de regel zijn dit tekstbestanden gecodeerd in UTF-8. Tussen de containerbestanden kunnen zich echter ook andere containerbestanden bevinden. De eenvoudigste analogie is met een bestandssysteem. Een container is een map en de bestanden in de container vormen de inhoud ervan. Een map kan andere mappen bevatten.
De hoofdmap van dit "bestandssysteem" is het *.CF-bestand zelf. Daarin kunnen zich andere containerbestanden bevinden, in wezen geneste mappen, die met exact hetzelfde algoritme worden gelezen en exact dezelfde structuur hebben.
Er is echter één bijzonderheid in de hoofdmap. Alle inhoud documenten bestanden in de hoofdmap worden gecomprimeerd met behulp van het Deflate-algoritme. De inhoud van bestanden in geneste mappen wordt niet langer gecomprimeerd. Simpel gezegd: op het hoogste niveau van een containerbestand worden de hoofdteksten van alle bestanden gecomprimeerd, maar als het bestand in de container zelf een container is, zullen de bestanden daarin al in hun pure vorm zijn geschreven (zonder compressie).
Keten van gratis blokken
Als u gegevens uit een container verwijdert, kunnen er lege ruimtes ontstaan. Deze vrije ruimtes zijn in een keten met elkaar verbonden en vormen een soort ‘document’ waarvan de gegevens ontbreken. Met andere woorden, vrije blokken worden met elkaar verbonden volgens hetzelfde principe waarmee documentblokken met elkaar worden verbonden. Het adres van het eerste vrije blok wordt helemaal aan het begin van de containerheader aangegeven. Als het adres van een vrij blok INT_MAX is, betekent dit dat er geen vrije (lege) blokken in het midden van de container staan.
Korte samenvatting van het theoretische gedeelte
- Het CF(EPF/ERF)-bestand is geschreven in het “container”-formaat
- De container begint met een header
- Alle inhoud van de container, met uitzondering van de header, wordt geschreven als “documenten”
- Het document kan in blokken worden verdeeld
- Het document begint met een bloktitel, die aangeeft hoe u het gehele document moet lezen
- Direct na de containertitel staat een inhoudsopgave.
- Een inhoudsopgave is een verzameling vermeldingen die verwijzen naar " bestanden» in de container
- Elk bestand bestaat uit twee documenten: een attributendocument, waarin de naam van dit bestand wordt aangegeven, en een inhoudsdocument, waar de bestandsgegevens zich daadwerkelijk bevinden.
- Elke inhoudsopgave bevat 2 adressen. De eerste is het adres van het document met bestandskenmerken, de tweede is het adres van het inhoudsdocument.
- Een container kan geneste containers bevatten (zoals geneste mappen)
- Bestanden in de rootcontainer worden gecomprimeerd met behulp van het Deflate-algoritme, bestanden in geneste containers worden zonder compressie geschreven.
Laten we de bytes al voelen
Elke inhoudsopgave bevat 2 adressen. De eerste is het adres van het document met bestandskenmerken, de tweede is het adres van het inhoudsdocument.
Een container kan geneste containers bevatten (zoals geneste mappen in de hoofdcontainer worden gecomprimeerd met behulp van het Deflate-algoritme, terwijl bestanden in geneste containers zonder compressie worden geschreven).
Een document in blokken lezen
Het is dus tijd om na te denken over hoe alle bovengenoemde entiteiten precies zijn gestructureerd.
De belangrijkste manier om gegevens uit een container te lezen, is door de reeks blokken te lezen waaruit bepaalde documenten bestaan. Het lijkt erop dat de juiste plaats om te beginnen het principe van het lezen van blokdocumenten is.
[Grootte van het gehele document][Spatie][Grootte van het huidige blok][Spatie][Adres van het volgende blok][Spatie] , waarbij:
- CRLF - standaard Windows-regelinvoer, tekenpaar \r\n (0x0D,0x0A)
- Volledige documentgrootte - de totale lengte van het document in bytes. Geschreven als een tekenreeksweergave van een hexadecimaal getal. Lengte - 8 bytes.
- Ruimte - ruimte. Symbool 0x20
- De grootte van het huidige blok is de lengte van de bloktekst in bytes. Het is ook geschreven als een tekenreeksrepresentatie van een INT32-nummer in hexadecimaal formaat. Als het document uit één enkel blok bestaat, is de grootte van het gehele document kleiner of gelijk aan de grootte van het huidige blok (wat logisch is)
- Volgend blokadres - het adres waarop het volgende blok van het document zich bevindt. Als het adres van het volgende blok INT_MAX is, betekent dit dat er geen volgend blok is. Het adres van het volgende blok wordt ook geschreven als een stringrepresentatie van een getal.
Ruimte - ruimte. Teken 0x20 De grootte van het huidige blok is de lengte van de bloktekst in bytes. Het is ook geschreven als een tekenreeksrepresentatie van een INT32-nummer in hexadecimaal formaat. Als een document uit één enkel blok bestaat, dan is de grootte van het gehele document kleiner of gelijk aan de grootte van het huidige blok (wat logisch is). Adres van het volgende blok is het adres waarop het volgende blok van het document bevindt. Als het adres van het volgende blok INT_MAX is, betekent dit dat er geen volgend blok is. Het adres van het volgende blok wordt ook geschreven als een stringrepresentatie van een getal.
Direct na de blokkop staat de bloktekst, die de lengte heeft die is opgegeven in het veld 'Huidige blokgrootte'.
Laten we naar de afbeelding kijken: de lengte van het hele document is 0x54 bytes, deze 0x54 bytes worden gemarkeerd met een rood kader. Dit zijn documentgegevens. De bloklengte is 0x200 bytes, d.w.z. langer dan de lengte van het document zelf. Om deze reden vormen de resterende gegevens in het blok "nullen" ongebruikte ruimte. Significante bytes zijn die gemarkeerd met een rood kader.
Als de lengte van het document groter is dan de lengte van het blok, moet het volgende blok worden gelezen. Als er een andere waarde dan 0x7fffffff in het veld "Volgend blokadres" wordt geschreven, moet u het huidige blok lezen, vervolgens naar dit adres gaan en een ander blok lezen. Als dit blok ook het adres van het volgende blok bevat, dan moet je daar ook heen. Zo wordt een “keten” van blokken gevormd waaruit het document bestaat.
Het lezen moet doorgaan totdat de waarde 0x7fffffff wordt aangetroffen in het veld “Adres van het volgende blok” of totdat het aantal bytes dat is opgegeven in het veld “Grootte van het gehele document” is gelezen.
Indeling containerheader
Indeling containerheader
Veld |
Uitleg |
|
Uitleg |
Adres van het eerste vrije blok |
INT32 (4 bytes) |
De offset waarop de keten van vrije blokken begint |
Adres van het eerste vrije blok |
Standaard blokgrootte |
Een blok kan elke lengte hebben, maar de standaard kan worden gebruikt om bijvoorbeeld nieuwe blokken toe te voegen. |
Adres van het eerste vrije blok |
Een getal dat een bepaalde waarde weergeeft, meestal samenvallend met het aantal bestanden in de container, maar collega's in de commentaren zijn van mening dat dit niet helemaal waar is. Dit getal heeft op geen enkele manier invloed op het containerinterpretatiealgoritme; het kan worden genegeerd. |
Gereserveerd veld |
Adres van het eerste vrije blok |
Altijd gelijk aan 0 (is dat altijd?) |
Inhoudsopgave Documentrecordformaat
Bestandskenmerken Documentformaat
Het attributendocument beschrijft de bestandsnaam en de datums waarop het is gemaakt/gewijzigd.
Veld |
Uitleg |
|
Tijd voor het maken van bestanden |
UINT64 (8 bytes) |
Tijd voor het maken van bestanden, uitgedrukt in intervallen van 100 microseconden sinds het begin van onze jaartelling (01/01/0001 00:00:00) |
Tijd voor bestandswijziging |
UINT64 (8 bytes) |
Insgelijks |
Gereserveerd veld |
Adres van het eerste vrije blok |
Altijd 0. Misschien zijn dit attribuutvlaggen, zoiets als alleen-lezen, verborgen, enz. Ik ben echter geen bestanden tegengekomen waarin dit veld afwijkt van nul. |
Bestandsnaam |
Tekenreeks in UTF-16-indeling |
Beslaat de gehele resterende hoofdtekst van het document (minus 2 datums en een reserveveld) |
Principe van het lezen van containers
- Stel een inhoudsopgavedocument samen uit blokken en lees het
- Doorloop alle vermeldingen in het inhoudsopgavedocument en lees de documentkenmerken (namen) van de containerbestanden
- Wijs elke ontvangen naam toe aan het adres van het inhoudsdocument
- De uitvoer is de correspondentie “Bestandsnaam” -> “Inhoudsadres”
Bestanden lezen
- Haal op bestandsnaam het adres van het inhoudsdocument op uit de inhoudsopgave
- Stel een inhoudsdocument samen uit blokken
- Als dit de rootcontainer is, decomprimeer dan het inhoudsdocument (het is gecomprimeerd)
- Klaar. Het resulterende resultaat zijn de gegevens van het gezochte bestand.
Update van 25/02/2014
Tot slot
Tot slot
*.cf- het bestand bevat alleen de configuratie (code en structuur) zonder gebruikersgegevens. Gemaakt vanuit de 1C 8.x-configurator: “Configuratie -> Configuratie opslaan in bestand” of “Configuratie -> Leveringsconfiguratie -> Leveringsbestand aanmaken en configuratie bijwerken -> attribuut “Opleveringsbestand maken””.
*.cfu- het bestand bevat alleen een configuratie-update. Bijvoorbeeld bestand 1cv8.cfu.
Het is onmogelijk om vanuit dit bestand een configuratie aan te maken, omdat het alleen verschillen bevat tussen de nieuwe configuratie en de vorige. Gemaakt vanuit de 1C 8.x-configurator: “Configuratie -> Configuratie-levering -> Maak leveringsbestand en configuratie-update -> vlag “Creëer configuratie-updatebestand””.*.dt
- het bestand bevat de configuratie samen met de gebruikersdatabase. Dit is een gespecialiseerd 1C 8-archiefformaat. Het is gemaakt op basis van de 1C 8.x-configurator: "Beheer -> Infobase uploaden". (*.epf*.erf
) – bestand voor externe verwerking (rapport). Eventuele verwerkingen (rapporten) uit de configuratie kunnen extern worden opgeslagen. Gemaakt vanuit de 1C 8.x configurator: “Configuratie -> Open configuratie -> ga naar de gewenste verwerking (rapport) -> selecteer met de rechtermuisknop -> Opslaan als externe verwerking, rapporteer...”.*.1cd
– een volwaardig databasebestand. Standaardnaamweergave: 1Cv8.1CD. Inclusief configuratie, database, gebruikersinstellingen. Opent met het 1C 8.x-platform. Het is gemaakt om automatisch een nieuwe configuratie te ontwikkelen door op de knop “Toevoegen” te klikken wanneer u het item “Een nieuwe informatiebank aanmaken” selecteert.- logbestanden die informatie verzamelen (gegevens registreren) in 1C 8.0 8.1, 8.2, 8.3.
*. cdn- bestand met deze extensie ( 1Cv8.cdn) wordt gebruikt voor het handmatig of automatisch blokkeren van de 1C Enterprise-database achtste versie.
*.mxl- Er wordt gebruik gemaakt van bestanden met gedrukte formulieren, ook in 1C. Het zijn beide gedrukte vormen van documenten, naslagwerken, rapporten en verschillende gegevensopslagapparaten voor verschillende classificaties. Opent via de Configurator of in 1C:Enterprise-modus via “bestand -> openen”. Het wordt op precies dezelfde manier aangemaakt: in de Configurator-modus of in 1C:Enterprise via “bestand -> nieuw”. Bestanden met dergelijke extensies kunnen ook dienen als overdrachtsregels, bijvoorbeeld van 1C 7.7 tot 8.2 (acc77_82.xml en hulpverwerking exp77_82.ert) - deze bevinden zich meestal in de map ExtForms.
*.efd- dit is een 1C-archiefbestand dat wordt gebruikt om de configuratie te installeren. Bevat de 1C-configuratie of een update ervan. Het wordt gestart met behulp van het hulpprogramma setup.exe (moet zich in dezelfde map bevinden).
*.mft– hulpbestand voor het maken van een configuratie op basis van een sjabloon. Bevat configuratie-informatie, beschrijving, pad, naam. Het wordt rechtstreeks door het platform zelf gebruikt bij het maken van een 1C-informatiebasis op basis van een sjabloon.
*.grs- bestanden met grafische diagrammen in een gespecialiseerd 1C-formaat. Opent via de Configurator of in 1C:Enterprise-modus via “bestand -> openen”. Het wordt op precies dezelfde manier aangemaakt: in de Configurator-modus of in 1C:Enterprise via “bestand -> nieuw”.
*.geo- bestanden met geografische diagrammen in een gespecialiseerd 1C-formaat. Opent via de Configurator of in 1C:Enterprise-modus via “bestand -> openen”. Het wordt op dezelfde manier aangemaakt: in de Configurator-modus of in 1C:Enterprise via “bestand -> nieuw”.
*.st- tekstsjabloonbestanden. Wordt voornamelijk gebruikt door 1C-ontwikkelaars.
*.pff- een bestand met opgeslagen prestatiemetingen. Gebruikt door systeembeheerders en 1C-specialisten.
Dit zijn gedetailleerde instructies voor 1C-configuratie installeren en het creëren van een 1C-database (vanuit de geïnstalleerde configuratie). Vergeet niet eerst wat je nodig hebt.
Als je in een organisatie werkt en het gebruikt, dan heb je het ook nodig. Daarnaast is hier informatie te vinden.
1C-configuratie op een computer installeren. Een 1C-database maken op basis van de configuratie. Een 1C-database maken vanuit CF. Een 1C-database maken vanuit DT.
Wat moet er gebeuren om de 1C-configuratie te installeren?
1C-configuratie is een sjabloon. Op basis van dit sjabloon wordt een 1C-database gemaakt. Het aantal 1C-databases op basis van één 1C-configuratiesjabloon is onbeperkt.
De essentie van het opzetten van een 1C-configuratie is dus het creëren van een database.
U kunt op de volgende manieren een database maken:
- Installeer een configuratie (sjabloon) op uw computer en maak er een aan op basis daarvan
- Maak een lege database en laad CF daarin
- Maak een lege database en laad DT daarin
- Herstel de 1C SQL-databaseback-up naar een andere database en verbind deze met de 1C-server.
- Configuratienaam/versie
- Configuratienaam (demo)/versie
De 1C-configuratie installeren vanuit de distributiekit op de computer
De configuratiedistributie wordt op schijf gedistribueerd (selecteer het menu-item Installeren om te installeren) of als een zelfuitpakkend archief via internet (pak het ergens uit en klik op setup.exe).
Bij het installeren van een 1C-configuratiedistributiekit wordt slechts één vraag gesteld: de installatiemap. Standaard wordt de 1C-configuratie geïnstalleerd in de sjablonenmap.
Dit is een standaardmap. Voor 8.1 bevindt het zich meestal in “C:\Program Files\1cv81\tmplts\”, voor 8.2 in “C:\Users\UserName\AppData\Roaming\1C\1Cv82\tmplts\”.
Als gevolg van de installatie verschijnt er een map met de geïnstalleerde configuratie in de map tmplts. In deze map bevinden zich mappen met geïnstalleerde configuratiesjablonen. Ze bevatten documentatie en “aanvullende zaken”.
Zie het einde van het artikel voor de structuur van de map tmplts en een beschrijving van de bestanden in de configuratiedistributie.
Een 1C-database maken op basis van de geïnstalleerde configuratie (bestandsversie)
De configuratie wordt opgeslagen in een map op schijf (de bestandsversie, wat we overwegen).
Het is noodzakelijk om een locatie op de schijf te selecteren waar we de configuratie zullen aanmaken, bijvoorbeeld “C:\1C Database\”. Laten we deze map gaan maken of er een databasemap in maken, bijvoorbeeld: "C:\1C Databases\Trading Management Training Base".
Laten we 1C lanceren. Klik in het databaseselectievenster op de knop Toevoegen.
Selecteer “Een nieuwe informatiebank maken” en klik op “Volgende”.
Als u een configuratie (een of meer) uit de distributiekit hebt geïnstalleerd, ziet u nu een lijst met geïnstalleerde configuraties. In elke configuratie zijn de volgende opties beschikbaar:
De eerste optie is een schone, lege database. De tweede optie is een database met demogegevens voor trainingen. We kiezen voor de tweede optie (plaats de cursor op het versienummer).
Voer de naam van de database in. Dit kan alles zijn wat u begrijpt. Dit is de naam die wordt weergegeven in de lijst met databases bij het inloggen op 1C. Bijvoorbeeld 'Trainingsconfiguratie 1'.
U moet een databaselocatie selecteren. We installeren de bestandsoptie, dus selecteren we "Op deze computer....". Wanneer u de client-server-optie installeert, selecteert u 'Op de 1C-server'.
Het is noodzakelijk om dezelfde map te selecteren die we voor de database hebben voorbereid.
Een 1C-database maken van CF of DT
CF en DT downloaden een configuratie uit een bestaande database. Ze verschillen van elkaar doordat DT gegevens bevat, terwijl CF dat niet doet (bevat alleen configuratie-informatie).
Nadat u een lege database hebt gemaakt, wordt .
Om CF te uploaden of downloaden, selecteert u de volgende menu-items van de configurator.
Om ODC te uploaden of downloaden, selecteert u de volgende menupunten van de configurator.
tmplts mapstructuur
1) map “1C” – 1C-bedrijfsconfiguratiesjablonen
2) map “Configuration name” – de Engelse naam van de configuratie (Accounting-Accounting, Trade-Trade Management, Hrm-Salaries en Personnel Management)
3) Map “Versie” – configuratieversie
4) Mappen en bestanden voor configuratiesjablonen.
Het pad naar de configuratiesjabloon “Trade Management” versie 10.3.9.4:
C:\Program Files\1cv81\tmplts\1c\trade\10_3_9_4\
Configuratiesjabloonbestanden
1) Readme.txt – inhoud van de map, wat is waar
2) HTML-bestanden – verschillende beschrijvingen en hulp bij het gebruik van configuraties
3) 1cv8.cf - in dit bestand wordt de 1C-configuratie opgeslagen
4) 1Cv8.dt – dit bestand slaat een databasearchief op gebaseerd op deze configuratie, meestal een demodatabase; het bestand bevat zowel configuratie als gegevens
5) 1cv8.cfu – configuratie-updatebestand, gebruikt om van de ene configuratieversie naar de andere te migreren
6) TTF-bestanden – lettertypebestanden, die bijvoorbeeld worden gebruikt voor het afdrukken van streepjescodes. Houd er rekening mee dat deze lettertypen aan het systeem moeten worden toegevoegd als ze zich in de configuratiedistributie bevinden
7) XML-bestanden – vaak worden er verschillende classifiers bij de configuratie geleverd. We zullen overwegen om deze in toekomstige releases in de database te laden. Houd er rekening mee dat deze bestanden ook in de database moeten worden geladen nadat deze is gestopt (bijvoorbeeld okp.xml)
8) ExtReps-catalogus – externe rapporten en verwerkingen die worden gebruikt voor de boekhouding, vaak worden op deze manier rapporten aangeleverd die regelmatig veranderen, bijvoorbeeld verschillende gedrukte formulieren
9) TradeWareEpf-catalogus - verwerking die wordt gebruikt om apparatuur aan te sluiten. We zullen de aansluiting in toekomstige uitgaven bespreken
10) Conv_ХХХ-mappen – dergelijke mappen slaan “conversieregels” op, de regels waarmee u gegevens van de ene database naar de andere kunt uploaden
Overdracht 1C