Hiện tượng này đã để lại cho tôi câu hỏi để hỏi.

Dưới đây là thử nghiệm chi tiết, hệ điều hành của tôi là Windows 7 x64 SP1:

• Tôi đã thay đổi tệp hình ảnh (JPG) thành TXT bằng cách thay đổi tiện ích mở rộng của nó (hoặc người ta chỉ có thể chọn mở JPG bằng notepad, điều tương tự)

Nó trông giống như thế này, các chuỗi văn bản trông kỳ quặc và một số trong số chúng (rất hiếm) thực sự có ý nghĩa, như trong ảnh chụp màn hình bên dưới "creator: dg-jpeg v1.0 ..."

• Tôi đã tắt gói và chọn tất cả văn bản bằng Ctrl + A (để đảm bảo không bỏ sót nội dung nào)
• Tôi đã dán văn bản đã sao chép vào một tệp TXT trống khác và lưu nó dưới dạng JPG, tôi so sánh kích thước tệp mới với JPG gốc. Tất cả trong số họ (những JPG gốc, các tập tin TXT chuyển đổi và file TXT mới được tạo ra) là của chính xác kích thước tương tự, để byte.

Khi tôi cố mở, Windows sẽ nói "Windows Photo Viewer không thể mở ảnh này vì tệp dường như bị hỏng, bị hỏng hoặc quá lớn" .

Tôi thậm chí đã thử kiểm tra nó bằng một phương pháp khác: Mở JPG bằng notepad, tôi cắt MỘT ký tự đã biết từ một vị trí dễ nhớ (như ký tự đầu tiên của dòng thứ 2) sau đó lưu tệp. Người xem tất nhiên sẽ hiển thị cùng một thông điệp. Sau đó, tôi mở lại và dán ký tự vào vị trí CHÍNH XÁC (Notepad nhớ trạng thái thoát của nó như vị trí cửa sổ, gói, kích thước phông chữ ... vì vậy tôi không gặp vấn đề gì khi nói đúng)

Và vẫn là lỗi tương tự. Bạn có thể thử điều này để có được ý tưởng, hãy nhớ chọn một hình ảnh nhỏ khác Notepad sẽ hoạt động như một người đàn ông rỉ sét cũ.

Điều gì có thể là nguyên nhân của hiện tượng này?

Tùy thuộc vào mã hóa được sử dụng để mở tệp, bạn có thể thấy hành vi khác nhau. Sổ ghi chép Windows 7 của tôi cho phép mở một tệp bằng ANSI, UTF-8, Unicode hoặc Unicode endian.

Tôi đã kiểm tra vấn đề này với một hình ảnh jpeg 2x2 pixel nhỏ được tạo bằng gimp và mở và lưu tệp hình ảnh bằng mã hóa ANSI. Mở cả ảnh gốc và ảnh đã lưu bằng trình chỉnh sửa hex Tôi thấy rằng tất cả 00 chuỗi (hai chữ số hex, ký tự điều khiển NUL ) đã được chuyển đổi thành 20 (ký tự khoảng trắng).

Thay thế trở lại trong trình chỉnh sửa hex tất cả 20 by 00 khôi phục định dạng hình ảnh.

Tôi đã googled nó một chút và tôi đã không tìm thấy bất kỳ tài liệu tham khảo nào giải thích tại sao nó làm điều đó. Chỉ một tài liệu tham khảo cho một bài đăng cảnh báo về nó (liên kết bộ nhớ cache của google, trang không có sẵn).

Nếu bạn lưu / mở tệp dưới dạng UTF-8, có vẻ như nó vẫn chuyển đổi các ký tự NUL thành khoảng trắng nhưng nó cũng làm tăng kích thước tệp kết quả do chuyển đổi từ các ký tự một byte thành chuỗi nhiều byte UTF-8.

Nếu bạn lưu / mở tệp dưới dạng Unicode, có vẻ như nó vẫn chuyển đổi các ký tự NUL thành khoảng trắng nhưng cũng thêm một byte vào đầu tệp, BOM .

Tại sao nó thất bại:

Notepad tạo (ASCII code 32)ký tự khoảng trắng cho các ký tự như NUL (ASCII code 0) vì hộp văn bản của API Windows chỉ cho phép char * nullI kết thúc (mảng ký tự, con trỏ). Nó bị cắt ở NUL đầu tiên.

Điều đó xảy ra vì API Windows chủ yếu được viết bằng ngôn ngữ C và các chuỗi kết thúc null là một trong những tính năng phổ biến. Ngay cả khi Windows và Unicode hiện đại được coi là cùng một chuỗi kết thúc null. Vì vậy, notepad chỉ cần thay thế chúng bằng không gian để bạn có thể xem tập tin hoàn chỉnh.

Vì vậy, khi bạn lưu tập tin, nó bị hỏng.

chuỗi kết thúc wikipedia-null

Làm thế nào để nghiên cứu thêm:

Bạn có thể sử dụng một bộ so sánh như ngoài so sánh (thương mại, dùng thử) để xem hiệu ứng thay thế nhân vật. cũng thấy các công cụ so sánh nhị phân khác .

Lưu ý : (20) ₁₆ = (32) ₁₀

Lý do cho notepad hoạt động chậm trên các tệp lớn

Nhìn vào Notepad.exe (XP 32 bit)

(Tôi giả sử nó vẫn được viết bằng C ++ hoặc ít nhất là sử dụng một trình liên kết tương tự tương tự )

Tôi đang sử dụng công cụ PEiD (đã ngừng phát triển với việc giới thiệu PE + / 64 exes)

Có thể tìm thấy PEiD trong gói thư mục bin của Universal Extractor

Tôi trích xuất notepad. tập tin ex_ từ Windows xp iso rõ ràng. Hãy thử nó. Đó là một trích xuất tập tin taxi sử dụng 7z.

Cảnh báo ! Trình quét vi-rút của bạn có thể phát hiện Universal Extractor / PEiD dưới dạng các công cụ hack hoặc vi-rút. Đừng tin nó đừng tải nó !!

Thông tin thêm về API windows

tín dụng: Jason C

Nó không chỉ là hộp văn bản; Nói chung, WM_SETTEXT không cung cấp tham số nào để chỉ định độ dài chuỗi và các chuỗi luôn được giả định là chấm dứt ở mức null. Bạn luôn có thể tạo một hộp văn bản tùy chỉnh với một thông báo tùy chỉnh chỉ định độ dài chuỗi, nhưng Notepad và hầu hết các chương trình khác thì không. Ngoài ra, hàm SetWindowText cũng không cung cấp tham số độ dài.

Notepad không bảo tồn tất cả các ký tự đặc biệt / mở rộng chính xác như bản chất của chúng. Tôi không có tài liệu tham khảo cho hành vi này ngay lập tức nhưng đã phát hiện ra đây là trường hợp ví dụ với dòng cuối kiểu UNIX mà Notepad sẽ chuyển đổi thành CRLF và null (0x00) mà nó sẽ bỏ qua. Trong tệp nhị phân như JPG có thể xuất hiện ngẫu nhiên các ký tự mà Notepad không lưu giữ. Hãy thử trải nghiệm với trình soạn thảo nhận biết HEX và nó sẽ hoạt động sau đó. Tôi sẽ cập nhật câu trả lời của mình nếu tôi tìm thấy một tài liệu tham khảo tốt và một khi tôi đã thử trình soạn thảo HEX.

Cập nhật: Tôi đã thử một vài biên tập viên lập trình nổi tiếng nhưng chỉ một trong số họ làm việc ngay lập tức, HxD của Maël Hörz . Tôi chưa bao giờ sử dụng HxD trước đây nhưng tìm thấy nó nhờ vào câu trả lời cho bài viết Stack này, Trình cắm / trình chỉnh sửa hex cho Notepad ++ .

Các trình soạn thảo khác không hoạt động sau vài phút nỗ lực là Notepad ++, Notepad2 và UltraEdit (v17.3, phiên bản cũ hơn). Một vài trong số này có vấn đề với việc sao chép / dán một vài byte đầu tiên, số ma thuật chữ ký tệp JPEG FF D8 FF. Có lẽ họ sẽ làm việc với một chút khó khăn hơn tôi có thời gian hiện tại.

Bạn đã từng có thể làm điều này với Viết lại trong ngày. Đó là một chương trình tiêu chuẩn trong Windows 3.1 nhưng tôi không thể nhớ nếu Windows 95 bao gồm nó. Viết sẽ cho phép chỉnh sửa an toàn nhị phân bất kỳ tệp nào nó có thể mở (có thể kích thước tệp rất hạn chế). Notepad chắc chắn không an toàn nhị phân (văn bản vẫn giữ nguyên nhưng các byte thực tế của các ký tự không phải văn bản [ví dụ: mã điều khiển] có thể thay đổi), đó là lý do tại sao ví dụ JPG của bạn không hoạt động. Hãy thử lấy một bản sao của Write (và Windows rất cũ) và thử lại lần nữa!

Theo bài viết "Windows Write" của Wikipedia, Write đã được đưa vào Windows NT 3.5. Nó đã được thay thế bởi Wordpad trong Windows 95 trở đi. write.exevẫn còn hiện diện trong thư mục Windows nhưng chỉ đơn giản là một trình bao bọc để mở Wordpad.

Tôi nghĩ đó không phải là vấn đề về mã hóa mà còn về bộ ký tự. Định dạng JPG về cơ bản là một luồng byte. Do đó, cho phép các ký tự không in được như NUL, ETX, STX, SOH, DLE, v.v.

Microsoft Notepad không thể hiển thị các ký tự không in được. Nó có thể hiển thị giữ chỗ của một số loại như khoảng trắng cho ký tự null. Vì vậy, mở tệp bằng Notepad không hiển thị nội dung thực tế nhưng nội dung được giải mã bằng mã hóa đã chọn (utf-8, utf-16, v.v.) và được hiển thị bởi một bộ ký tự nhất định (unicode, ascii, v.v.) ngoại trừ không phải ký tự có thể in.

Khi chọn tất cả văn bản được hiển thị và sao chép văn bản vào bảng tạm, bạn chỉ sao chép các ký tự có thể in được bao gồm cả phần giữ chỗ. Do đó, tự động chuyển đổi các ký tự null thành khoảng trắng và bỏ qua hoàn toàn các ký tự không in được khác.

Vì vậy, về cơ bản bạn chỉ mất nội dung làm theo cách này. Nếu bạn sử dụng trình soạn thảo hex thay thế, nó sẽ sao chép toàn bộ nội dung.

Cập nhật: Câu trả lời của Bhathiya Pereras là đúng: https://superuser.com/a/782885/322784 Các ký tự không in được không bị bỏ qua khi sao chép văn bản vào clipboard.

Tệp JPEG chứa dữ liệu không phải văn bản ngoại trừ một số trường, về cơ bản, bất kỳ giá trị byte nào trong khoảng từ 0 đến 255 sẽ được tìm thấy, đặc biệt là trong khu vực đại diện cho hình ảnh nén được mã hóa chứa dữ liệu gần như giả ngẫu nhiên.

Nhưng Notepad sẽ coi dữ liệu là văn bản ANSI theo mặc định, do đó, nó sẽ thực hiện nhiều việc khác nhau sẽ thay đổi dữ liệu gốc, như:

• thay thế byte ánh xạ các ký tự đặc biệt / không xác định / bị cấm vì chúng không có ý nghĩa đối với văn bản ANSI hợp lệ

• mã hóa lại các ký tự null, kết thúc dòng và kết thúc chuỗi tệp theo các quy ước của Windows / DOS

Điều đó có nghĩa là nếu bạn chỉnh sửa và lưu dữ liệu dưới dạng văn bản, nó sẽ thay đổi jpeg trong trường hợp tốt nhất và làm cho nó không sử dụng được trong trường hợp xấu nhất.