Gambar ini. Pasukan kewangan telah mengarkibkan penyata pelanggan dan rekod transaksi sebagai PDF/A untuk enam tahun yang lalu. Setiap fail membawa tag metadata yang betul. Setiap pekerja percaya kerja itu selesai sebaik sahaja fail disimpan. Kemudian pengawal selia muncul untuk semakan rutin, menjalankan segelintir fail tersebut melalui pengesah, dan separuh daripadanya gagal.
Tiada dokumen yang pernah disentuh, tiada yang dilakukan secara berbeza. Dokumen ini tidak pernah mematuhi pada mulanya, mereka hanya mendakwa pematuhan. Dan perbezaan antara "mendakwa sebagai PDF/A" dan "menjadi PDF/A" adalah salah satu titik buta yang paling kerap dan mahal dalam pengarkiban dokumen hari ini.
Jadi, jika usaha mengarkib anda gagal dan/atau jika anda mahu kekal di sebelah kanan proses, berikut ialah perkara yang salah dan cara mewujudkan aliran kerja yang mantap untuk Pematuhan PDF/A.
Mengapa pematuhan PDF/A lebih penting daripada yang disedari oleh kebanyakan pasukan
PDF/A bukan sekadar "PDF dengan arkib." Ia adalah format yang ditakrifkan oleh piawaian ISO untuk memastikan bahawa dokumen akan dibuka dan kelihatan dengan cara yang sama sekarang, dalam sepuluh tahun, dan dalam lima puluh tahun, tidak kira apa perisian atau fon telah dipasang untuk membacanya pada ketika itu.
Itu mengambil banyak kepentingan dalam hal peraturan. Peraturan seperti GDPR memberi mandat bahawa syarikat mesti mengekalkan integriti, kerahsiaan dan ketersediaan data peribadinya. Peraturan seperti MiFID II mewajibkan firma menyimpan data komunikasi dan transaksi daripada pelanggan selama bertahun-tahun dalam format yang tidak boleh diubah secara rahsia. Lakukan sesuatu yang salah di sini, dan anda boleh berdepan denda yang diukur dalam peratusan satu digit hasil tahunan anda, yang merupakan jumlah yang besar untuk syarikat utama.
Sebab itu bila Pematuhan PDF/A kekurangan dalam arkib, ia tidak dianggap sebagai masalah dengan teknologi. Ia dianggap sebagai isu pematuhan peraturan, dan tanggungjawab terletak pada firma berkenaan.
Sebab yang paling biasa fail PDF/A gagal pengesahan
Kebanyakan kegagalan PDF/A menjejak kembali kepada senarai pendek isu berulang. Di sinilah perkara biasa berlaku.
Fon yang tidak dibenamkan sepenuhnya
Tidak dinafikan, ia adalah punca masalah yang paling biasa. Untuk fail PDF/A, semua fon yang digunakan dalam dokumen mesti dibenamkan dalam fail supaya penonton tidak perlu memasang fon pada mesinnya. Dalam banyak keadaan, hanya subset fon yang dibenamkan dalam fail PDF, yang biasanya gagal dalam proses pengesahan. Daripada kajian lepas yang dilakukan pada fail PDF/A kehidupan sebenar, telah diperhatikan bahawa lebih separuh daripada kejadian tidak akur timbul daripada fon.
Ruang warna bebas peranti
Mengikut keperluan PDF/A, warna perlu diterangkan melalui profil ICC bebas peranti untuk memastikan pemaparan yang konsisten tidak kira apa monitor paparan, pencetak atau perisian aplikasi yang anda gunakan untuk melihat dokumen. Menariknya, salah satu ralat yang paling kerap dilakukan dalam penciptaan PDF/A melibatkan dokumen berdasarkan beberapa ruang warna (seperti sRGB biasa) yang tidak mempunyai profil ICC yang diperlukan.
Metadata yang tidak sepadan dengan realiti
Setiap dokumen PDF/A mesti mengandungi metadata XMP yang menyatakan versi PDF/A yang dipatuhi (PDF/A-1, -2 atau -3) dan pada tahap pematuhan mana (A, B atau U). Kegagalan untuk menyediakan metadata sedemikian atau menyediakannya dengan cara yang salah atau mengelirukan bermakna kegagalan serta-merta sebelum pengauditan pun bermula.
Sejarah kemas kini tambahan yang tidak kemas
Kemas kini tambahan menambahkan data tambahan pada dokumen PDF sedia ada tanpa menulis semula keseluruhan dokumen dari awal. Ia adalah pilihan yang mudah dalam fail PDF standard, tetapi untuk Fail PDF/A, ia dilakukan dengan berhati-hati:
- •PDF/A-1 tidak membenarkan kemas kini tambahan sama sekali. Sebarang suntingan perlu menghasilkan penulisan semula penuh fail.
- •Dalam PDF/A-2 dan PDF/A-3, kemas kini tambahan dibenarkan; walau bagaimanapun, data yang dilampirkan mestilah selaras dengan dokumen yang lain. Penambahan semakan menggunakan fon tidak terbenam, sebagai contoh, menjadikan keseluruhan fail tidak sah.
- •Nombor versi dalam pengepala fail juga perlu sepadan dengan versi yang diisytiharkan dalam katalog dalaman dokumen. Ketidakpadanan di sini adalah perkara yang mudah untuk terlepas dan cara mudah untuk gagal pengesahan.
Penukaran dokumen kepada PDF/A tidak bersamaan dengan pengesahan PDF/A
Ia adalah kawasan di mana banyak syarikat tersandung; dan ia harus dinyatakan dengan jelas.
Penukaran mengambil dokumen, tanpa mengira format asalnya (sama ada dokumen Word, halaman HTML atau PDF) dan menukarnya kepada Fail PDF/A. Dengan berbuat demikian, perisian menambah metadata yang memperakui fail yang baru dibuat sebagai fail yang mematuhi PDF/A.
Pengesahan ialah proses yang berbeza sama sekali di mana program khas mengesahkan bahawa fail benar-benar memenuhi semua keperluan untuk disahkan.
Tetapi inilah kelainannya: Metadata yang dimasukkan pada peringkat penukaran ialah tuntutan, bukan bukti. Fail mungkin mengandungi maklumat dalam metadatanya bahawa ia mematuhi PDF/A-2b, namun gagal lulus pengesahan PDF/A-2b.
Menjadikan ini lebih teruk, banyak sumber percuma dan terbuka Pengesah PDF/A gunakan heuristik dan bukan perbandingan baris demi baris terhadap keseluruhan spesifikasi. Ini bermakna bahawa mereka selalunya akan mendakwa bahawa dokumen itu "mungkin" sah, yang mungkin kelihatan seperti berita baik pada mulanya, tetapi pastinya tidak. Cara lain untuk mengesahkan pematuhan adalah secara visual, di mana seseorang hanya membuka dokumen dan melihat sama ada ia kelihatan betul.
Sekurang-kurangnya, setiap fail PDF/A perlu:
- •Benamkan semua fon, imej dan kandungan secara langsung, tanpa sebarang rujukan luaran
- •Elakkan borang audio, video, JavaScript dan XFA sepenuhnya
- •Langkau mampatan LZW, penyulitan dan perlindungan kata laluan
- •Berikan setiap medan borang interaktif kamus penampilan yang betul
- •Simpan metadata menggunakan standard XMP
Langkau pengesahan dan anda percaya bahawa setiap satu daripada kotak ini telah disemak dengan betul, tanpa benar-benar mengesahkannya.
Tahap pematuhan tidak boleh ditukar ganti
Satu lagi sumber senyap bagi audit yang gagal ialah ketidakpadanan tahap pematuhan, di mana fail menuntut tahap pematuhan yang sebenarnya tidak dipenuhi.
Dua perkara yang patut difahami di sini:
Piawaian itu sendiri berbeza antara satu sama lain. PDF/A-1, PDF/A-2, dan PDF/A-3 diterbitkan berselang tahun dan tidak mempunyai peraturan yang sama. PDF/A-1, misalnya, tidak menyokong ketelusan atau lapisan dan hanya menawarkan tahap pematuhan A dan B. PDF/A-2 menambah sokongan untuk ketelusan, lapisan dan juga membenamkan fail PDF/A lain, bersama-sama dengan tahap baharu, U.
Tahap pematuhan membina antara satu sama lain. Tahap U termasuk semua yang diperlukan untuk tahap B, dan tahap A termasuk semua yang diperlukan untuk tahap U, serta banyak lagi. Memilih tahap yang betul bukan sekadar perincian teknikal, ia adalah keputusan yang mempunyai akibat sebenar tentang bagaimana arkib anda boleh digunakan bertahun-tahun ke depan. Arkib tuntutan di mana dokumen perlu kekal boleh dicari dan boleh diekstrak teks, contohnya, memerlukan sekurang-kurangnya tahap U. Tahap B sahaja tidak akan menjaminnya.
Tahap U secara khusus adalah mengenai integriti teks. Ia memastikan teks Unicode yang mendasari dalam dokumen boleh diekstrak atau dicari dengan pasti kemudian, yang amat penting untuk mana-mana arkib yang mungkin perlu disemak atau dicari bertahun-tahun selepas pemfailan.
Seperti apa sebenarnya saluran paip PDF/A kalis audit
Proses pengarkiban yang boleh dipertahankan biasanya mengikut bentuk ini:
Normalkan dokumen sumber → Tukar kepada PDF/A → Sahkan secara bebas → Arkibkan fail
Ini adalah langkah yang biasanya dilangkau oleh kebanyakan organisasi, tetapi ia adalah langkah yang paling penting. Sekiranya perisian yang menukar fail kepada bentuk lain ialah perisian yang mengesahkan proses penukaran, semua yang anda lakukan ialah mengesahkan output yang dijana oleh perisian berdasarkan spesifikasi yang difahami oleh perisian. Tafsiran yang salah mengenai spesifikasi yang dilakukan oleh perisian tidak akan dikesan sehingga fail disahkan oleh pengesah bebas.
Jejak audit yang kukuh hendaklah termasuk:
- •Rekod siapa yang menukar setiap fail dan bila
- •Nama dan versi alat yang digunakan
- •Laporan pengesahan bebas yang mengesahkan tahap pematuhan yang dituntut, dicap masa yang ideal dan disimpan bersama dokumen itu sendiri
Penjanaan dan pengesahan dijangka dilakukan oleh sistem yang berbeza; laporan pengesahan perlu boleh dibaca mesin dan disimpan sebagai bukti audit; dan konsistensi antara kandungan yang dituntut dan sebenar perlu nyata. Menurut GDPR dan MiFID II, akauntabiliti untuk memastikan bukti integriti terletak sepenuhnya pada pemegang arkib, bukan penyedia perisian.
Kesimpulan
PDF/Fail yang belum disahkan secara bebas sebenarnya hanyalah fail yang berharap ia mematuhi. Itu mungkin baik selama bertahun-tahun, sehingga pengawal selia meminta untuk melihat arkib. Bangunan Pengesahan PDF/A ke dalam perancangan sebagai langkah yang berasingan dan bebas inilah yang menjadikan arkib yang penuh harapan menjadi arkib yang boleh dipertahankan, dan ia merupakan tabiat yang jauh lebih murah untuk dibina sekarang daripada denda yang perlu dibayar kemudian.
Ambil Langkah Seterusnya Ke Arah Pematuhan PDF/A
Tukar kepada PDF/ASelamat di tangan kita
AziPDF memandang serius privasi anda. Ingat tu...