← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 373 · data

KEYFİ KARAKTER KÜMELERİ

Yazar
Kurum
Tarih
14 Temmuz 1972
Durum
Network Working Group Yorum Talebi
Kanal
data/

KEYFİ KARAKTER KÜMELERİ

John McCarthy tarafından

14 Temmuz 1972

Bilgisayarlarda saklanan belgelerin keyfi karakterler içerebilmesi ve bunların herhangi bir CRT ekranda görüntülenebilmesi, herhangi bir klavye kullanılarak düzenlenebilmesi ve herhangi bir yazıcıda basılabilmesi güzel olurdu. Bu notun amacı, özellikle ARPA ağına atıfla, buradan oraya nasıl gidilebileceğini önermektir.

Şu anda neredeyiz?

  1. Hâlihazırda 96 karakterli ASCII vardır ve herkes bunun daha büyük herhangi bir kümenin içine dahil edilmesi gerektiği konusunda hemfikirdir.

  2. Birçok kurulum, küçük Latin alfabesini bile içermeyen 64 karakterli kümelere bağımlıdır.

  3. Stanford Artificial Intelligence Laboratory'de, 96 karakterli ASCII'yi içeren ve klavyelerimizde, ekranlarımızda ve satır yazıcımızda uygulanmış olan 114 karakterli bir kümemiz vardır.

  4. Karakter tasarımlarını bellekten alan yazıcılar kullanılabilir hâle gelmektedir; örneğin, Xerox XGP yazıcısı; bunlardan birini edinmekteyiz.

  5. IMLAC tipi ekran, karakter tasarımlarını ana bellekte tutar; bu nedenle görüntülenen kümenin değiştirilmesi yalnızca belleğin yeniden yüklenmesi meselesidir.

  6. Birçok ekran sistemi, karakter üretecini birçok ekran birimi arasında paylaşır. Bunların bazılarında, örneğin Datadisc'te, keyfi kümeler muhtemelen uygulanabilirdir (daha sonra açıklanacak bazı geçici çözümler kullanılarak), ancak diğer sistemlerde, örneğin bizim III'lerimizde, keyfi kümeler uygulanabilir değildir.

Genişletilmiş karakter kümeleriyle iletişim için olası bir yaklaşım, belki 8 ya da 9 bit kullanarak genişletilmiş standart bir karakter kümesi üretmek ve yeni donanımların bu kümeyi uygulamasını beklemektir. Bu yaklaşımın dezavantajı, bir sonraki adımın ne olması gerektiği konusunda anlaşmaya varmanın çok zor olacak olmasıdır; ayrıca resmi bir uzlaşı sağlansa bile, birçok grup kendi çıkarları gereği standardı göz ardı etmeyi tercih edecektir.

Bu nedenle, bir sonraki adımın keyfi karakter kümeleri olmasını önermek istiyorum. Bunun aşağıdaki şekilde uygulanmasını öneriyorum:

  1. Bir karakter sicili oluşturulsun. Herkes yeni bir karakter kaydedebilsin. Her karakterin benzersiz bir numarası olsun; Çinceyi bile kapsamak için 17 bit yeterli olmalıdır. Buna ek olarak, her karakterin ASCII içinde, genellikle anımsatıcı bir adı bulunsun. Son olarak, karakterin 50’ye 50 nokta matrisinde bir resim olan bir tasarımı olsun.

  2. Karakter siciline ek olarak, farklı grupların farklı belge sınıfları için kullandığı karakter kümelerinin bir sicili bulunsun. Kayıtlı bir karakter kümesi, bir sicil numarasına ve karakter kodlarının bit dizileri olarak kayıtlı karakter numaralarıyla olan karşılıklarını veren bir tabloya sahip olsun.

  3. Bir belgeyle ilişkili olarak, içinde kullanılan karakter koduna dair bir bildirim bulunsun. Bu, kayıtlı kodlardan biri olabilir ya da buna ek olarak, kayıtlı karakter numaralarıyla kod karşılıklarını veren yardımcı bir tabloyla tanımlanan değişiklikler içerebilir. Bir karakter kodu, bir sonraki karakterin sicil numarasıyla tanımlandığını söyleyen bir kaçış karakterine sahip olabilir. Karakter kodu bildirimi belgenin başlığında yer alabilir ya da alıcının bunu başka yollarla öğrenmesi gerekebilir; örneğin, kütüphane katalog kaydının bu bilgiyi içermesi nedeniyle.

  4. Yazıcılar ve ekranlar gibi aygıtlar karakterleri farklı şekillerde çizer ve şu anda standardizasyon mümkün görünmemektedir. Bu nedenle, 50’ye 50 nokta matrisi kullanan standart bir karakter tanımından aygıtın kullandığı yönteme geçiş sağlayacak bir yol sunmak gereklidir. Bu, aygıtı destekleyen programcıların sorumluluğundadır. Bazıları, kayıtlı karakterlerin nasıl uygulandığını tanımlayan dosyaları elle oluşturmayı seçebilir. Tüm karakterler için destek sağlamak ve yeni karakterler kaydedildiğinde dosyalarını güncellemek onlara fazla iş gibi görünebilir. Diğerleri, kayıtlı tanımlardan kendi uygulamalarıyla uyumlu tanımlara geçiş sağlayan programlar sunacaktır. Muhtemelen çoğu, en sık kullanılan karakterleri elle uyarlayacak ve geri kalanlar için bir program sağlayacaktır.

  5. Ele alınması en kolay aygıt satır yazıcısıdır, çünkü yavaştır. Baskı işinin başında, SPOOL programı karakter kümesini bulacak ve yazıcının belleğini ilgili belgede kullanılan karakter tasarımlarıyla yükleyecektir. Bazen, ne yapılacağını öğrenmek için sicili saklayan bilgisayarlardan birine ağ üzerinden gitmek zorunda kalabilir.

  6. Her ekran birimi için ayrı bir karakter belleğine sahip ekran sistemleri yaklaşık aynı şekilde ele alınabilir. Kullanıcılar, ekran programları alışılmadık karakterlerle karşılaştığında zaman zaman gecikmeler yaşayacaktır.

  7. Karakter belleklerini paylaşan ekran sistemleri daha karmaşık bir işlem gerektirir. Amaç, belleği, mevcut kullanıcı kümesinin kullandığı tüm karakterleri tutabilecek kadar büyük tutmak ve farklı karakter kodlarından gereken tablo bakmalarını düzgün bir şekilde ele almaktır. Aynı anda kullanılabilecek karakter kümelerinin çeşitliliği konusunda sınırlamalar olacaktır. Datadisc gibi, karaktere yalnızca ilk yazıldığında bakan sistemler büyük kümelerle çalışacak şekilde genişletilebilir. Görüntüyü sürdürmek için her karakter koduna saniyede 30 kez bakmak zorunda olan sistemler ise o kadar iyi çalışmayacaktır.

Klavye­lerin keyfi kümelere uyarlanmasını nasıl sağlayacağımıza dair özel fikirlerim yok. Her kullanıcı kendi başının çaresine bakmak zorunda kalabilir.

Bu notta şimdiye kadar tipografiyi, yani basılı belgelerde aynı harfin birçok yazı tipinde basılabilmesi gerçeğini göz ardı ettim. Belki de her yazı tipindeki her karakter için ayrı bir kayıtlı tanım gerekecektir; ancak farklı yazı tiplerindeki aynı karakterin numaraları arasında sabit bir fark bulunacaktır. Kurulumlar, hangi yazı tipi ayrımlarını uygulayacaklarına yine kendileri karar vermek zorunda kalacaktır.

Dikkate alınabilecek diğer bazı konular, metinlerin farklı aygıtların satır ve sayfa uzunluklarına otomatik olarak uyarlanmasını sağlayacak araçların sunulup sunulamayacağıdır.

Bana öyle geliyor ki, tipografik sorunların şu anda çözülebilmesi pek olası değildir ve bu aşamada karakter tasarımlarının kaydedilmesi için kurallar benimsemek, tipografiyi ise daha sonraya bırakmak en iyisi olacaktır.

Benim görüşüme göre, ARPA ağında sicili şimdi kurmanın, standartlar kuruluşunu çalışmaya başlatmanın ve çeşitli kurulumlar yazıcıları ve ekran aygıtlarını edinebildikçe genişletilmiş karakter kümelerinde belge alışverişi yapabilmenin önünde gerçek bir engel yoktur.

Stanford Artificial Intelligence Laboratory'nin mevcut politikası, sabit karakter kümelerine bağımlı başka hiçbir aygıt edinmemektir.


Bu RFC, çevrimiçi RFC arşivlerine girmek üzere, Alex McKenzie'nin yönetimi altında BBN Corp. tarafından makine tarafından okunabilir biçime dönüştürülmüştür. 1/97