Lumaktaw sa pangunahing nilalaman

Pag-uulat ng engine

Proseso ng pagsusuri​

Ang Glasswall library ay tumatanggap ng file sa pamamagitan ng isang inilathalang API at ipinapasa ito sa ilang process cycle. Ang output mula sa bawat cycle ay nagiging input para sa kasunod, kaya napapanatili ang antas ng paghihiwalay sa pagitan ng mga proseso. Ang pagsusuri ng file ay nagaganap sa bawat cycle. Sa mga unang cycle, natutukoy ang istruktura ng file at ang mga laki ng mga bumubuong bahagi nito. Ang mga susunod na cycle ay nakatuon sa pagsasagawa ng mga syntactic at semantic na pagsusuri, na tumutukoy sa mga posibleng pinagmumulan ng panganib, mga field na wala sa saklaw, o mga maling pagkakabuo ng istruktura.

Kung ang mga elemento ng file ay naka-compress, ang mga ito ay ine-expand at ang mga resulta ay sinusuri, inaanalisa, at bineberipika. Dahil dito, ang analysis report na inilalathala sa dulo ng proseso ay makapagbibigay ng masusing pagtatasa ng nilalaman at istruktura ng file. Sa pagdaan sa mga proseso ng sanitisation at remediation, nakapagbibigay ang Glasswall ng tumpak na ulat ng mga aksyong maaaring isagawa ng regeneration functionality ng Glasswall, upang maging conformant ang file sa specification.

Sa bawat cycle, ang file na pinoproseso ay kino-convert sa sariling internal representation ng Glasswall. Pinapasimple nito ang mga proseso ng parsing at traversing at tumutulong na makapagbigay ng isolation. Habang nagna-navigate ang proseso ng pagsusuri sa mga istruktura ng Glasswall, ang mga detalyadong pagsusuri ay ginagawa hindi lamang sa mga indibidwal na component kundi pati sa mas mataas na antas ng mga ugnayan sa pagitan ng mga component ng file. Ang mga pagsusuring ito sa mas mataas na antas ay nagbibigay-daan upang maayos na maberipika ang semantic na istruktura at consistency ng file.

Mga analysis report​

Ang mga analysis report ng Embedded Engine ay nagbibigay ng detalyado at hindi nakatali sa uri ng file na paglalarawan ng data at nilo-log sa XML format. Ang istruktura ng ulat na ito ay sumusunod sa isang Analysis Report XSD, na idinisenyo upang pasimplehin ang parsing at processing. Ang analysis report XSD ay matatagpuan sa folder na /schemas/sdk_editor ng release package ng Embedded Engine.

Ang analysis report ay naglalaman ng sumusunod na impormasyon tungkol sa file:

  • Buod ng Dokumento — mataas na antas na impormasyong partikular sa file.
  • Content Management Policy — ang mga setting ng mga content management switch na inilapat sa naprosesong file.
  • Mga Content Group — ang pangunahing pagpapangkat ng content na natukoy sa naprosesong file.
  • Mga Content Item — ang mga low-level na istrukturang natukoy sa naprosesong file.
  • Mga Issue Item — ang mga natukoy na istrukturang hindi tumutugma sa specification ng manufacturer o kung saan ang mga natukoy na istruktura ay hindi pinapayagan ng policy (sa parehong kaso, nirereject ang file).
  • Mga Sanitisation Item — ang mga natukoy na istrukturang nasa ilalim ng content management na minarkahan para alisin ng policy.
  • Mga Pinapayagang Item — ang mga natukoy na istrukturang nasa ilalim ng content management na pinapahintulutan ng policy.
  • Mga Remedy Item — mga awtomatikong pagwawastong inilapat sa naprosesong file upang maiayon ang file sa specification ng manufacturer.

Mga halimbawang analysis report​

Ang seksyong ito ay naglalaman ng pinaikling Glasswall Analysis Report na may lahat ng pangunahing elemento ng isang karaniwang ulat. Ang partikular na halimbawang ito ay batay sa isang PDF file.

Buod ng dokumento​

Ang bawat XML report ay nagsisimula sa isang buod ng dokumento na ipinapakita sa ibaba:

    <gw:DocumentSummary>
        <gw:TotalSizeInBytes>2293803</gw:TotalSizeInBytes>
        <gw:FileType>pdf</gw:FileType>
        <gw:Version>PDF-1.6</gw:Version>
        <gw:FileTypeDetectionMethod>signature match</gw:FileTypeDetectionMethod>
        <gw:InputSHA256>DEE7CEB7AB57227121FF65F0D8D0878CBEDF90864069D9525698257972498099</gw:InputSHA256>
        <gw:OutputSHA256>83EE59FAB5972429CE65CBB22EBF8B592D53F47927E0FA751584875D4F80CA1E</gw:OutputSHA256>
        <gw:ProcessingTimeMilliseconds>101</gw:ProcessingTimeMilliseconds>
        <gw:ComplexityLevel>4.41</gw:ComplexityLevel>
    </gw:DocumentSummary>

  • TotalSizeInBytes - Laki ng input file
  • FileType - Uri ng file na natukoy ng Glasswall
  • Version - Bersyon ng format ng file (kapag matutukoy)
  • FileTypeDetectionMethod - Pamamaraan ng pagtukoy ng Glasswall na ginamit upang matukoy ang format ng file
  • InputSHA256 - SHA-256 ng orihinal na input file
  • OutputSHA256 - SHA-256 ng output file pagkatapos maproseso ng Glasswall (kung muling nabuo ang file)
  • ProcessingTimeMilliseconds - Oras na sinukat ng Glasswall para maproseso ang file
  • ComplexityLevel - Tantiya ng Glasswall sa antas ng pagiging kumplikado ng file, na ginawa sa pamamagitan ng pagkalkula ng log10 hanggang 2 decimal places ng bilang ng mga artefact na natukoy sa file

Pamamahala ng nilalaman​

Pagkatapos ay inililista ang mga policy sa pamamahala ng nilalaman na ginamit sa file.

Tandaan: Lahat ng policy para sa lahat ng uri ng file ay nakalista sa bawat ulat. Kung saan ang policy ay hindi na-configure ngunit available, ang mga default na setting ng policy na inilapat ay ililista rin.

Ang ilan sa mga setting ng switch para sa pamamahala ng nilalaman ng PDF ay ipinapakita sa ibaba:

    <gw:ContentManagementPolicy>
        <gw:Camera cameraName="pdfConfig">
            <gw:ContentSwitch>
                <gw:ContentName>javascript</gw:ContentName>
                <gw:ContentValue>sanitise</gw:ContentValue>
            </gw:ContentSwitch>
            <gw:ContentSwitch>
                <gw:ContentName>acroform</gw:ContentName>
                <gw:ContentValue>sanitise</gw:ContentValue>
            </gw:ContentSwitch>
            <gw:ContentSwitch>
                <gw:ContentName>embedded_files</gw:ContentName>
                <gw:ContentValue>sanitise</gw:ContentValue>
            </gw:ContentSwitch>
        </gw:Camera>
    </gw:ContentManagementPolicy>

Mga content group at item​

Ang bilang ng iba’t ibang content group na nakita sa file (16), kasama ang isang halimbawa ng content item mula sa unang group, ay ipinapakita sa ibaba:

    <gw:ContentGroups groupCount="16">
        <gw:ContentGroup>
            <gw:BriefDescription>PDF document has Basic File Section structure instances</gw:BriefDescription>
            <gw:ContentItems itemCount="5">
                <gw:ContentItem>
                    <gw:TechnicalDescription>PDF Header Instances</gw:TechnicalDescription>
                    <gw:InstanceCount>1</gw:InstanceCount>
                    <gw:TotalSizeInBytes>15</gw:TotalSizeInBytes>
                    <gw:AverageSizeInBytes>15</gw:AverageSizeInBytes>
                    <gw:MinSizeInBytes>15</gw:MinSizeInBytes>
                    <gw:MaxSizeInBytes>15</gw:MaxSizeInBytes>
                </gw:ContentItem>
            </gw:ContentItems>>
        </gw:ContentGroup>
    ...
    </gw:ContentGroups>

Mga item ng sanitisation​

Sa halimbawang ito, dahil ang switch na metadata ay itinakda sa sanitise, ipinapakita ang isang dictionary structure bilang naka-tag para alisin.

    <gw:SanitisationItems itemCount="1">
        <gw:SanitisationItem>
            <gw:TechnicalDescription>Document information dictionary detected in a document trailer dictionary.</gw:TechnicalDescription>
            <gw:SanitisationId>16872998749</gw:SanitisationId>
            <gw:InstanceCount>1</gw:InstanceCount>
            <gw:TotalSizeInBytes>0</gw:TotalSizeInBytes>
        </gw:SanitisationItem>
    </gw:SanitisationItems>

Mga pinayagang item​

Sa halimbawang ito, dahil ang switch na metadata ay itinakda sa allow, kaya nananatili ang isang dictionary structure.

    <gw:AllowedItems itemCount="1">
        <gw:AllowedItem>
            <gw:TechnicalDescription>Document information dictionary detected in a document trailer dictionary.</gw:TechnicalDescription>
            <gw:AllowedId>16872998749</gw:AllowedId>
            <gw:InstanceCount>1</gw:InstanceCount>
            <gw:TotalSizeInBytes>0</gw:TotalSizeInBytes>
        </gw:AllowedItem>

Mga Remedy Item​

Hindi lahat ng XML report ay may kasamang Remedies, dahil ang mga ito ay mga awtomatikong pagwawasto na ginagawa upang maiayon ang anumang regenerated file sa file specification. Sa halimbawang ito, may naiulat na remedy item sa file.

    <gw:RemedyItems itemCount="1">
        <gw:RemedyItem>
            <gw:TechnicalDescription>
                PDF Stream is missing an End-Of-Line before the &apos;EndStream&apos; marker.
            </w:TechnicalDescription>
            <gw:RemedyId>1605893787</gw:RemedyId>
            <gw:InstanceCount>7</gw:InstanceCount>
        </gw:RemedyItem>
    </gw:RemedyItems>

Mga Issue Item​

Napakakaunting file ang may issue, dahil nangangahulugan ito na hindi lamang sila hindi umaayon sa file specification, kundi hindi rin na-Remedy ng Glasswall ang issue pabalik sa mga pamantayang itinakda sa specification. Ang file na may issue item ay hindi maaaring ma-regenerate.

    <gw:IssueItems itemCount="1">
        <gw:IssueItem>
            <gw:TechnicalDescription>
                /Info dictionary contained an unexpected key (/GTS_PDFXConformance).
            </gw:TechnicalDescription>
            <gw:IssueId>1670998746</gw:IssueId>
            <gw:InstanceCount>1</gw:InstanceCount>
        </gw:IssueItem>
    </gw:IssueItems>

Iniuulat din ang mga issue item kapag natukoy na ang isang file ay hindi sumusunod dahil sa content management policy (kung saan ginamit ang setting na disallow).

Ang bawat Sanitisation item, Allowed Item, Remedy item o Issue item ay may kaugnay na natatanging numerikong ID, upang ang item ay natatanging matukoy ng ibang mga application na maaaring gustong magproseso ng mga XML report.

Huling na-update noong