Bu fenomen bana sormam gereken sorular bırakıyor.

İşte ayrıntılı deney, benim işletim sistemim Windows 7 x64 SP1:

• Bir resmi (JPG) dosyayı sadece uzantısını değiştirerek TXT olarak değiştirdim (veya biri JPG'yi not defteri ile açmayı seçebilir, aynı şey)

Bu, garip bir şekilde görünen metin dizileri gibi görünmelidir ve bazıları (çok nadir) aslında aşağıdaki gibi, "yaratıcısı: dg-jpeg v1.0 ..." ekran görüntüsündeki gibi anlamlıdır.

• Kaydırma işlemini devre dışı bıraktım ve Ctrl + A kullanarak tüm metni seçtim (hiçbir şeyin kaçırmadığından emin olmak için)
• Kopyalanan metni başka bir boş TXT dosyasına yapıştırdım ve JPG olarak kaydettim, yeni dosya boyutunu orijinal JPG ile karşılaştırdım. Hepsi (orijinal JPG, dönüştürülmüş TXT dosyası ve yeni oluşturulan TXT dosyası), bayt olarak tam olarak aynı boyuttadır.

Açmaya çalıştığımda, Windows "Windows Fotoğraf Görüntüleyicisi bu resmi açamıyor çünkü dosya bozuk, bozuk veya çok büyük görünüyor" diyor .

Hatta başka bir yöntem kullanarak test etmeye çalıştım: JPG'yi not defteri ile açtım, ONE bilinen karakteri hatırlaması kolay bir yerden kestim (2. satırın ilk karakteri gibi) ve sonra dosyayı kaydedin. İzleyici elbette aynı mesajı gösterirdi. Sonra tekrar açtım ve karakteri EXACT konumuna yapıştırdım (Notepad çıkış konumunu hatırlar, pencere konumu, kaydırma, yazı tipi boyutu gibi hatırlar.

Ve hala aynı hatayı. Bu fikri elde etmek için deneyebilirsiniz, küçük bir resim seçmeyi unutmayın, yoksa Notepad eski paslı bir adam gibi davranır.

Bu fenomenin nedeni ne olabilir?

Dosyayı açmak için kullanılan kodlamaya bağlı olarak, farklı davranışlar görebilirsiniz. Windows 7 not defterim, bir dosyayı ANSI, UTF-8, Unicode veya Unicode big endian'da açmaya izin veriyor.

Bu sorunu, gimp ile oluşturulan ve görüntü dosyasını ANSI kodlamasıyla açıp kaydeden küçük bir 2x2 piksel jpeg görüntüsü ile test ettim. Hem orijinali hem de kaydedilen görüntünün hex editörüyle açılması, tüm 00 dizisinin (iki onaltılık hane, NUL kontrol karakteri ) 20'ye (boşluk karakteri) dönüştürüldüğünü görüyorum .

Onaltılık düzenleyicide tekrar yerine, 20x00'ün tümü görüntü formatını geri yükler.

Bunu biraz googledim ve neden yaptığını açıklayan hiçbir referans bulamadım. Yalnızca bunun hakkında uyaran bir yayına yapılan referans (google önbellek bağlantısı, sayfa mevcut değil).

Dosyayı UTF-8 olarak kaydederseniz / açarsanız, NUL karakterlerini hala boşluklara dönüştürdüğü anlaşılıyor, ancak tek baytlık karakterlerden UTF-8 çoklu bayt sıralarına dönüşümler nedeniyle ortaya çıkan dosya boyutunu da artırıyor.

Dosyayı Unicode olarak kaydeder / açarsanız, NUL karakterlerini hala boşluklara dönüştürdüğü, ancak dosyanın başlangıcına ( BOM) bir bayt eklediği görülüyor .

Neden başarısız oluyor:

Not Defteri, NUL(ASCII code 32) gibi karakterler için boşluk karakteri oluşturur, çünkü Windows API'nin metin kutusu yalnızca boş sonlandırılmış ASCIIZ'a (karakter dizisi, işaretçi) izin verir . İlk NUL'da kesiliyor. (ASCII code 0)char *

Bunun nedeni, Windows API’nin çoğunlukla C dilinde yazılmış olması ve boş sonlandırılmış dizelerin ortak özelliklerden biri olması. Modern Windows ve Unicode aynı görüldüğünde bile boş sonlandırılmış dizeler oluşur. Böylece not defteri onları boş alanla değiştirir, böylece dosyanın tamamını görüntüleyebilirsiniz.

Yani dosyayı kaydettiğinizde bozuktur.

wikipedia-null sonlandırılmış dizeler

Daha fazla araştırma nasıl yapılır:

Karakter değiştirme etkisini görmek için karşılaştırmanın ötesindeki (ticari, deneme) benzeri bir karşılaştırıcı kullanabilirsiniz . ayrıca diğer ikili karşılaştırma araçlarına bakınız .

Not : (20) ₁₆ = (32) ₁₀

Notepad nedeni büyük dosyalar üzerinde yavaş hareket eder

Notepad.exe'ye (XP 32 bit) bakıyor

(Hala C ++ ile yazılmış veya en azından benzer bir linker kullandığını düşünüyorum )

PEiD aracını kullanıyorum (PE + / 64 exes ile geliştirme durdu)

PEiD, Universal Extractor'un bin klasöründe paketlenmiş olarak bulunabilir

Not defterini çıkarttım. Açıkçası Windows xp iso ex_ dosya. Denemek. 7z kullanarak bir taksi dosyası özüdür.

Uyarı! Virüs tarayıcınız Universal Extractor / PEiD yazılımını hack aracı veya virüs olarak algılayabilir. Güvenme İndirme !!

Windows API hakkında daha fazla bilgi

kredi: Jason C

Bu sadece metin kutusu değil; Genel olarak WM_SETTEXT , dize uzunluğunu belirtmek için bir parametre sunmaz ve dizelerin her zaman boş değerde sonlandığı varsayılır. Her zaman dize uzunluğunu belirten özel bir mesaj içeren özel bir metin kutusu oluşturabilirsiniz, ancak Not Defteri ve diğer pek çok program makul şekilde yapmaz. Ayrıca SetWindowText işlevi de bir uzunluk parametresi sağlamaz.

Not Defteri, tüm özel / genişletilmiş karakterleri olduğu gibi korumaz. Bu davranış için hemen elimde bir referans yok, ancak bunun örneğin Notepad'in CRLF'ye dönüştüreceği ve boşaltacağı null (0x00) satırının UNIX stili LF satırı sonunda olduğu gibi olduğunu buldum. JPG gibi bir ikili dosyada, Not Defteri'nin korumadığı karakter (ler) in rastgele ortaya çıkma olasılığı vardır. Denemenizi HEX uyumlu bir düzenleyici ile deneyin; sonra çalışması gerekir. İyi bir referans bulursam ve bir kez bir HEX editörünü test ettikten sonra cevabımı güncelleyeceğim.

Güncelleme: Birkaç tanınmış programcı editörünü denedim ama bunlardan sadece bir tanesi Maël Hörz tarafından yayınlanan HxD'den çıktı . HxD'yi daha önce hiç kullanmamıştım ancak Not Defteri ++ için bir Hex görüntüleyici / düzenleyici eklentisi olan bu Stack makalesinin cevabı sayesinde buldum .

Birkaç dakika süren çabadan sonra çalışmayan diğer editörler Notepad ++, Notepad2 ve UltraEdit (v17.3, eski sürüm) idi. Bunlardan birkaçı ilk birkaç baytın kopyalanması / yapıştırılmasıyla, JPEG dosya imzası sihirli numarası FF D8 FF ile ilgili problemler yaşadı . Belki şu an için zamanımdan biraz daha fazla işe yaramazlardı.

Bunu gün içerisinde Geri yazma ile yapabiliyordunuz. Windows 3.1'de standart bir programdı, ancak Windows 95'in dahil edip etmediğini hatırlayamıyorum. Yazma, açabileceği herhangi bir dosyanın güvenli bir şekilde düzenlenmesine izin verir (muhtemelen çok sınırlı dosya boyutu). Not Defteri kesinlikle ikili güvenli değildir (metin aynı kalır, ancak metin olmayan karakterlerin gerçek baytları [örneğin kontrol kodları] değişebilir) bu nedenle JPG örneğinizin çalışmaması. Yazma (ve çok eski Windows) kopyasını almayı deneyin ve denemenizi tekrar deneyin!

Göre Wikipedia'nın "Windows Write" makale yazma Windows NT 3.5 kadar dahil edildi. Daha sonra Windows 95'te Wordpad ile değiştirildi. write.exeWindows dizininde hala mevcuttu ancak Wordpad'i açmak için sadece bir sarıcıydı.

Bence bu kadar kodlama sorunu değil, karakter seti için de bir problem. JPG formatı temel olarak bir bayt akışıdır. Böylece NUL, ETX, STX, SOH, DLE, vb. Gibi yazdırılamayan karakterlere izin verilir.

Microsoft Not Defteri, yazdırılamayan karakterleri görüntüleyemiyor. Boş karakter gibi bir yer gibi yer tutucular görüntüleyebilir. Bu yüzden dosyayı Not Defteri ile açmak, asıl içeriği göstermez, seçilen kodlama tarafından çözülen içerik (utf-8, utf-16, vb.) yazdırılabilir karakterler

Tüm görüntülenen metni seçip metni panoya kopyalarken, yalnızca yer tutucuları içeren yazdırılabilir karakterleri kopyalarsınız. Böylece boş karakterleri otomatik olarak boşluklara dönüştürür ve yazdırılamayan diğer karakterleri tamamen yok sayar.

Yani temelde sadece bu şekilde yaparak içerik kaybedersiniz. Bunun yerine bir hex editörü kullanıyorsanız, tüm içeriği tamamen kopyalar.

Güncelleme: Bhathiya Pereras'ın cevabı doğru: https://superuser.com/a/782885/322784 Metin panoya kopyalanırken yazdırılamayan karakterler göz ardı edilmiyor.

JPEG dosyası, bazı alanlar dışındaki metin olmayan verileri içerir, temelde 0 ile 255 arasındaki herhangi bir bayt değeri, özellikle de neredeyse sahte veri içeren kodlanmış sıkıştırılmış görüntüyü temsil eden alanda bulunur.

Ancak Notepad, verileri varsayılan olarak ANSI metni olarak değerlendirir, bu nedenle orijinal verileri değiştiren çeşitli şeyler yapar:

• Geçerli bir ANSI metni için anlamlı olmadığı için özel / tanımsız / yasaklanmış karakterleri eşleyen baytların yerini al

• boş karakterleri, satır sonunu ve dosya dizilerinin sonunu Windows / DOS kurallarına yeniden kodlayın

Bu, verileri düzenleyip metin olarak kaydederseniz, en iyi durumda jpeg'i değiştirecek ve en kötü durumda kullanılamaz hale getirecektir.