Il /bflag del copycomando tratta i file come binari (ovvero un flusso non elaborato di byte senza senso) e li copia byte per byte anziché il /acomportamento predefinito (o il ) che li tratta come righe di testo (con fine riga caratteri, fine file, ecc.)
È possibile unire i file di testo con il comportamento del testo predefinito o l'interruttore binario, ma praticamente qualsiasi file binario non funzionerà. Non puoi semplicemente copiare i byte da due file binari e aspettarti che funzionino perché i file binari di solito hanno intestazioni , metadati , strutture di dati, ecc. che definiscono il formato del file. Se fai una copia binaria, copierai semplicemente tutti i byte così com'è che finisce per mettere queste strutture in luoghi che non dovrebbero essere, quindi quando li apri, la funzione di analisi avrà problemi e vedrai quali sono essenzialmente i dati corrotti . Alcuni programmi ignoreranno le parti che non hanno senso e mostreranno semplicemente ciò che possono (il che consente alla stereografia di funzionare), ma alcuni genereranno un errore e si lamenteranno che il file è corrotto. La capacità di rilevare la corruzione dipende dal tipo di file.
Ad esempio, inventiamo un formato PDF semplificato:
Byte(s) Meaning
---------------------
File header:
0-1 # of Pages
2-3 Language
4-5 Font
6-EOF Data (each page encoded separately)
Page data:
0-1 Page number
2-3 # of characters on page
4-#chars Letters contained on the page
Come puoi vedere, ogni file conterrà un'intestazione a livello di file con alcune informazioni generali, seguita da blocchi di dati per ogni pagina contenente i dati della pagina. Se poi prendi due file, ognuno contenente una pagina e li unisci come file binari, non creerai un file di due pagine, ma invece un file corrotto che inizia con una pagina, quindi ha un mucchio di spazzatura (il file header non ha senso quando il programma tenta di leggere la seconda pagina).
La stessa cosa accade per i tuoi MP3. Quando li combini in questo modo, i tag ID3 all'inizio e / o alla fine del secondo file vengono mantenuti e quando il lettore tenta di leggere il fotogramma successivo, si aspetta dati audio, ma trova l'intestazione del secondo file che non corrisponde al formato previsto per i dati audio, quindi non sa cosa fare. Alcuni giocatori riprodurranno l'intestazione come dati audio (che probabilmente suonerà come statico / rumore / pop / ecc.), Alcuni taglieranno il suono fino al prossimo fotogramma corretto, altri potrebbero interrompere la riproduzione del brano e alcuni potrebbero persino andare in crash .
Il copycomando non è a conoscenza di tipi di file diversi dal testo normale (e anche solo dal testo ASCII), quindi solo il testo normale può essere combinato correttamente con esso. I file binari devono essere combinati utilizzando un editor in grado di analizzare e interpretare correttamente i contenuti.
