Điều gì chính xác xảy ra khi bạn sử dụng lệnh 'copy / b'?

Hôm nay, tôi mới phát hiện ra rằng tôi có thể hợp nhất một số tệp bằng cách sử dụng copy /blệnh. Đặc biệt, tôi nhận thấy rằng khi tôi hợp nhất hai tệp mp3, trình phát VLC thể hiện các hành vi hài hước với thời gian:

Ở đây, nó khá bình thường nhưng âm nhạc đầu tiên đã kết thúc ... sau đó là phần vui nhộn tiếp theo ....

Ở đây, thời gian tìm kiếm thực sự đang chạy như đang chơi.

Khi kết hợp hình ảnh hoặc PDF với kỹ thuật này, tôi phát hiện ra rằng sẽ có sự gia tăng chính xác về kích thước tệp nhưng chỉ có hình ảnh đầu tiên sẽ được hiển thị.

Vì vậy, câu hỏi của tôi là: chính xác copy /blệnh làm gì? Nó thực sự có nghĩa là được sử dụng để hợp nhất các tập tin hay đây là một hack?

Các /blá cờ của copyxử lý lệnh các tập tin như nhị phân (ví dụ, một luồng nguyên byte vô nghĩa), và sao chép chúng byte cho byte thay vì mặc định (hoặc /a) hành vi mà xử lý chúng như dòng văn bản (với end-of-line ký tự, cuối tập tin, v.v.)

Bạn có thể hợp nhất các tệp văn bản với hành vi văn bản mặc định hoặc chuyển đổi nhị phân, nhưng hầu như mọi tệp nhị phân sẽ không hoạt động. Bạn không thể đơn giản sao chép các byte từ hai tệp nhị phân và mong đợi chúng hoạt động vì các tệp nhị phân thường có các tiêu đề , siêu dữ liệu , cấu trúc dữ liệu, vv xác định định dạng của tập tin. Nếu bạn thực hiện một bản sao nhị phân, bạn sẽ chỉ sao chép tất cả các byte mà cuối cùng sẽ đặt các cấu trúc này ở những nơi không nên, vì vậy khi bạn mở chúng, chức năng phân tích cú pháp sẽ gặp sự cố và xem những gì về cơ bản là dữ liệu bị hỏng . Một số chương trình sẽ bỏ qua các phần không có ý nghĩa và chỉ hiển thị những gì họ có thể (cho phép lập thể hoạt động), nhưng một số sẽ ném lỗi và phàn nàn rằng tệp bị hỏng. Khả năng phát hiện tham nhũng phụ thuộc vào loại tệp.

Ví dụ: hãy phát minh ra một định dạng PDF đơn giản hóa:

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

Như bạn có thể thấy, mỗi tệp sẽ chứa một tiêu đề cấp tệp với một số thông tin chung, theo sau là các khối dữ liệu cho mỗi trang chứa dữ liệu trang. Sau đó, nếu bạn lấy hai tệp, mỗi tệp chứa một trang và hợp nhất chúng thành tệp nhị phân, bạn sẽ không tạo một tệp hai trang mà thay vào đó một tệp bị hỏng bắt đầu bằng một trang, sau đó có một bó rác (tệp tiêu đề không có ý nghĩa khi chương trình cố gắng đọc trang hai).

Điều tương tự cũng xảy ra với MP3 của bạn. Khi bạn kết hợp chúng như thế, các thẻ ID3 ở đầu và / hoặc cuối của tệp thứ hai được giữ lại và khi người chơi cố đọc khung tiếp theo, nó sẽ chờ dữ liệu âm thanh, nhưng đang tìm tiêu đề của tệp thứ hai không khớp với định dạng dự kiến ​​cho dữ liệu âm thanh, vì vậy nó không biết phải làm gì. Một số người chơi sẽ phát tiêu đề dưới dạng dữ liệu âm thanh (có thể sẽ phát dưới dạng tĩnh / tạp âm / bật / v.v.), một số người sẽ cắt âm thanh cho đến khung chính xác tiếp theo, một số có thể ngừng phát bài hát hoàn toàn và một số thậm chí có thể bị sập .

Các copylệnh không biết gì về định dạng tập tin khác so với văn bản đơn giản (và thậm chí sau đó, chỉ ASCII text), vì vậy chỉ plain-text có thể được kết hợp một cách chính xác với nó. Các tệp nhị phân phải được kết hợp bằng trình chỉnh sửa biết cách phân tích và giải thích nội dung một cách chính xác.

Trong ví dụ của bạn, với MP3, nó có thể sẽ có những hành vi kỳ lạ vì cách MP3 được mã hóa. Ví dụ: thẻ ID3v1 là 128 byte cuối cùng của MP3 (ví dụ: nghệ sĩ, album, v.v.). Thông tin này không "có thể chơi được". Khi VLC hoặc trình phát phương tiện khác mở MP3, nó (có thể) sẽ phát qua MP3 đầu tiên, hành động hài hước cho thông tin và sau đó có thể phát qua phần còn lại của tệp. Tôi không tải Windows ngay bây giờ, vì vậy tôi không thể kiểm tra chắc chắn.

Tôi sẽ cho rằng điều này giống như hình ảnh và phim ảnh; tùy thuộc vào cách các tệp được mã hóa tùy thuộc vào cách các tệp sẽ "kết hợp". Tôi tưởng tượng chức năng này xuất phát từ thời của DOS khi mọi thứ đều ở dạng văn bản đơn giản

Cách đây rất lâu, trong những ngày Win ME cũ, tôi thường sử dụng để ghép các video clip. Nó không hoạt động mọi lúc nhưng nó đã làm việc một thời gian.

Đây là một ví dụ về lệnh tôi đã sử dụng:

copy /b movie1.mpg + movie2.mpg + movie3.mpg movie4.mpg

Nếu những bộ phim không quá lớn và cùng loại, tốc độ khung hình, v.v., chúng thường được hợp nhất hoàn hảo. Gần đây đã không thử bất cứ điều gì như thế này.

Về MP3, đại khái, những gì sau tiêu đề đều có thể được đọc dưới dạng dữ liệu. Có trò chơi này, Sonic 3 trong Sega Genesis và một trò chơi khác gọi là Sonic & Knuckles. Hộp mực ban đầu của Sonic & Knuckles có một khe cắm để chèn các trò chơi khác, nhưng khi thêm Sonic 2 và đặc biệt 3, có lẽ tổng kiểm tra sẽ kích hoạt một bộ con trỏ khác, trò chơi sẽ hoạt động khác. Trong giai đoạn đầu sử dụng ROM, bất cứ khi nào chúng tôi muốn đặt hai hộp mực hoạt động giống như trong phần cứng, chúng tôi đã sử dụng copy /b sonick.bin+sonic3.bin sonic3k.bin. Bằng cách này, sự hợp nhất của chúng sẽ dẫn đến một ROM lớn trong đó sonick sẽ có tập lệnh (con trỏ) để làm cho nó sử dụng tài nguyên sonic3.