Metin düzenleyicili bir ikili dosyayı açtığınızda neden ikili kod görmüyorsunuz?

Metin düzenleyicili bir ikili dosyayı açtığınızda neden ikili kod görmüyorsunuz? Örneğin, metin düzenleyicili bir görüntü açtığımda, bazı tuhaf karakterler ve ayrıca bazı insan tarafından okunabilen karakterler görüyorum; ancak görüntü ikili olarak kodlanmalıdır.

İkili ve metin verileri birbirinden ayrılmaz: Bunlar sadece veridir . Onları bir veya diğer yapan yorumlamaya bağlıdır. İkili verileri (görüntü dosyası gibi) bir metin düzenleyicide açarsanız, çoğu sizin için bir anlam ifade etmez, çünkü seçtiğiniz yorumlamaya (metin olarak) uymaz .

Metin dediğiniz şey , olası dosya içeriğinin bir alt kümesidir : Belirli bir karakter kümesinde okunabilir karakterlere çeviren veriler .

Örneğin, ASCII'de , 128 "izinli" değerden yalnızca yarısının harf ve sayı, 30'un noktalama ve geri kalanının kontrol karakterleri olduğunu görebilirsiniz . İkinci grup sadece metin dosyalarında çok kullanılmaz ve gerçekten iyi bir metin gösterimi yoktur. Bunlardan bazıları , metin editörlerinin bunları görüntülemek için yaratıcı olması gereken Tab ve Newline karakterleridir.

Bazı metin editörleri, açıkça boşlukları görüntülemek için seçeneklere sahiptir. Daha sonra normal biçimlendirme davranışlarına ek olarak karakter olarak çizilirler (bu sadece karakterlerin yorumlanmasıdır ).

Saf ASCII sadece 128 değeri yorumlar. Bu bilgiyi saklamak için kullanılan baytların her birinin 256 olası değeri vardır, bu nedenle olası değerlerin yarısına ASCII'de izin verilmez. Bunlar, örneğin Latin 1 gibi bölgeye özgü karakter kümelerinde kullanılır, ancak ASCII'de tanımsızdırlar. Bir metin görüntüleyicide yalnızca ASCII'yi işleyebilecek yararlı bir gösterimi yoktur.

İkili veriler genellikle metin olarak yorumlanmaz. Yani bu dosyalarda, tüm olası bayt değerleri yaygın olarak bulunur. Geri kalan her şey boşa gider (ve metni çok iyi sıkıştırabilmenizin bir nedeni). Resim dosyası formatları karmaşıktır ve bunları genellikle metin olarak görmezsiniz, bu nedenle okunabilir olmaları gerekmez.

Mümkün olan tüm değerleri okunabilir karakterlerle eşleştiren ortak bir veri yorumlaması (karakter kümesi) olmadığı için ve bu zaten bir şey ifade etmeyeceğinden (okunabilir metin olmadığı için), ana parçalar anlamsız olarak gösterilir.

Bir hex editörü veri için farklı bir temsil seçer: Her baytı iki onaltılık basamak olarak görüntüler . Bu sadece farklı bir gösterimdir ve insan tarafından kolayca okunabilen bir karakter kümesi vardır: 256 olası tüm byte değeri iki onaltılık rakam olarak gösterilebilir.

İkili verilerin onaltılık ya da tam tersi (kolay bir onaltılık basamağa 4 ikili basamak) ile eşleştirilmesi kolay olduğundan ve ikili basamağın basamak başına çok az bilgi içerdiğinden, onaltılık genellikle insanlar için ikili bilgiyi okumak için tercih edilen bir yoldur. farklı bir temsil tercih etmek için nedenler.

Bazı metin editörleri bir hex editör moduna ve bir dosyanın metin mi, yoksa ikili mi olduğunu belirlemeye çalışan ve otomatik olarak bir mod veya diğerini seçmeye çalışan bazı buluşsal yöntemleri olabilir. Ancak bunun doğru olması zor olabilir ve bu dosyanın türünün bir tür olup olmadığını belirten belirli bir özelliği değildir.

Bazı FTP istemcileri, metin verileri için hangi dosya sonlarının kullanılacağını belirtmenizi ister . Ardından, bu programlar, bağlı olduğunuz makinenin işletim sistemiyle eşleşecek şekilde dosya içeriğini değiştirecektir, çünkü Windows, CR/LFLinux ve Unix'ten (Mac OS X; dahil) farklı bir satır biten karakter dizisi ( ) kullanır LF.

Çünkü onu bir metin düzenleyicide açtınız, ikili düzenleyicide değil .

Hepsi bağlam ve yorumlama ile ilgili. Bilgisayarınızdaki, yalnızca nasıl yorumlamak istediğimize karar verdiğimizde anlam kazanan, yüksek ve alçak gerilim kalıpları veya bir diskin mıknatıslanmış bölgeleridir.

Farklı şartlar altında, düşük-yüksek-düşük-düşük-düşük-düşük-düşük-düşük kalıp, 65 numara, bir müşterinin kahve sipariş ettiği, 'martın tarihi olan' A 'harfi, gök mavisi bir renk anlamına gelebilir. 6. ya da hiç bir şey, gerçekten.

Görüntü dosyanızı bir grafik programında açtığınızda, bir görüntü olarak yorumlanmasını bilir, hangi desenlerin görüntü biçimini, hangi desenlerin görüntü boyutunu ve benzerlerini gösterdiğini bilir.

Görüntü dosyanızı bir metin düzenleyicide açtığınızda, metin olarak kabul edilir. Bu, bilgisayarda gerçekten olup bitenlere çok daha yakın olan çok basit bir formattır, ancak hala bazı yorumlar devam etmektedir. Spesifik olarak, hemen hemen her model, bazıları AZ gibi normal, ancak bazı garip karakterler olarak, belirli bir karakter olarak yorumlanır. Birkaç desen karakter olarak görünmüyor, bunun yerine temel biçimlendirme olarak kabul ediliyor: newline, tab.

(Unicode gibi şeyler ve UTF-8 gibi metin kodlamaları ile durum biraz karışık ama burada basitlik adına bunlarla ilgilenmeyeceğim.)

Bir metin düzenleyicide açık bir ikili dosyanız olduğunda, değişiklik yapmamaya dikkat edin, çünkü yaptığınız herhangi bir değişiklik, dosya içeriğinin normal yorumunu tamamen bozacak, yani dosyayı bozacak ve kullanılamaz hale getirecektir.

Basitleştirilmiş bir örnek olarak, bir metin düzenleyiciyle açılan bir görüntü dosyasını düşünün.

Görüntü, 3 piksel genişliğinde kareler ve her kare arasında 1 piksellik gri bir kenarlıkla basit bir satranç şeklidir. - üç siyah piksel, gri kenarlık pikseli, üç beyaz piksel, gri kenarlık pikseli, tekrarlayın.

Bu görüntüdeki ilk satır dört kez aşağıdaki değere sahip olacaktır:

Black    Black    Black    Gray     White    White    White    Gray
0x000000 0x000000 0x000000 0x7F7F7F 0xFFFFFF 0xFFFFFF 0xFFFFFF 0c7F7F7F

(Hex'de, Binary yerine - Binary'deki dize dört kat daha uzun olur - 0x7F, 0b01111111 ile değiştirilir)

Bu veri dizisini bir metin düzenleyiciye yüklerseniz aşağıdaki metni alırsınız:

[Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Del] [Del] [Del] [Boş] [Boş] [Boş] [Boş] [Boş ] [Boş] [Boş] [Boş] [Boş] [Sil] [Del] [Del]

Bunun nedeni, 0x00'ün Null değerinin ASCII kodudur ve siyah bir pikselin değerini almak için bu 3 kez yazmanız gerekir (yine de 24bit BMP'de) ve 3 siyah pikseliniz var. O zaman 0x7F, Delete için ASCII kodudur ve gri bir piksel elde etmek için üç kez BU'ya ihtiyacınız vardır. 0xFF, belirli bir şey için geçerli ASCII kodunu değil - genişletilmiş ASCII setinde bile - ve 3 beyaz piksel elde etmek için 9 kez yazmanız gerekir. Tamamladıktan sonra, gri bir piksel yazmak için üç Silme daha elde edersiniz.

Daha faydalı bir şekilde açıklayıcı olabilecek, göstermenin farklı bir yolu bunun tam tersi bir örnektir - bir metin editöründe açıldığında sıfır olanları almak için bir dosyaya ne yazmanız gerekir?

ASCII elbette sıfır ve bir kodlar! Bir metin düzenleyicisindeki sıfır, 0 değerine sahip tek bir bit olarak değil, 0b00110000 değerine sahip 8 bit olarak veya onaltılık 0x30 değerinde depolanır.

'0' için ASCII kodu 0x30 ve '1' için ASCII kodu 0x31'dir, yani bir satranç desenini sıfırlar ve olanlar olarak saklamak istiyorsanız, dosyanız şöyle görünecektir:

text editor:
10101010
01010101
10101010
01010101

Stored data (ASCII values for '1', '0' and 'new line'):
0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x0D 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x0D 0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x0D  0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x31

Bundan daha fazlası var - dosyalar başlamış, durmuş, meta veriler ve diğer her türlü şeyden bahsetmişler, ancak aldatma dersi ve sorunuza cevap:

Dosyanızın ilk 8 biti 0b00110000 değilse, metin editörünüz '0' yazmaz çünkü bu '0' karakterinin ASCII kodudur. Dosyanız ilk 8 bit olmadıkça, dosya 0b00110001'dir, metin editörünüz '1' yazmaz çünkü bu '1' karakterinin ASCII kodudur.

Editör, bazı metnin mantıklı olup olmadığını anlamak için yeterince akıllı değildir; bu nedenle, bu özelliğe sahip olması halinde, özellikle aksi belirtilmedikçe, herhangi bir dosyayı metin olarak görüntüler. Diğerlerinin de belirttiği gibi, bazı editörler hex gösterme özelliğine sahiptir.