UTF-7 - UTF-7

UTF-7

Diller)	Uluslararası
Standart	RFC  2152
sınıflandırma	Unicode Dönüşüm Formatı , ASCII zırhı , değişken genişlikli kodlama , durum bilgisi olan kodlama
Dönüştürür / Kodlar	tek kod
Öncesinde	HZ-GB-2312
tarafından başarıldı	8BITMIME üzerinden UTF-8
v T e

UTF-7 (7- bit Unicode Transformation Format ), bir ASCII karakter akışı kullanarak Unicode metni temsil etmek için kullanılmayan bir değişken uzunluklu karakter kodlamasıdır . Başlangıçta, UTF-8 ile alıntı-yazdırılabilir kombinasyonundan daha verimli olan, İnternet E-posta iletilerinde kullanım için Unicode metnini kodlamanın bir yolunu sağlamayı amaçlamıştı .

UTF-7 (kendi RFC), bir "değildir Unicode Transformation Format ," tanımı olarak can sadece kodlama kod noktaları BMP (içermez ilk 65536 Unicode kod noktalarına, emojileri ve diğer birçok karakter). Bununla birlikte, bir UTF-7 tercümanı UTF-16'ya / UTF-16'dan ise, o zaman her bir vekil yarısını 16 bitlik bir kod noktasıymış gibi kodlayabilir (ve muhtemelen yapar) ve böylece tüm kod noktalarını kodlayabilir. Diğer UTF-7 yazılımlarının (UTF-32 veya UTF-8 çevirmenleri gibi) bunu destekleyip desteklemediği açık değildir.

UTF-7 hiçbir zaman Unicode Konsorsiyumu'nun resmi standardı olmadı . Güvenlik sorunları olduğu bilinmektedir, bu nedenle yazılımın kullanımını devre dışı bırakacak şekilde değiştirilmiştir. O edilir yasak içinde HTML 5 .

Motivasyon

E-posta biçiminin modern standardı olan MIME , ASCII aralığının üzerindeki bayt değerleri kullanılarak üstbilgilerin kodlanmasını yasaklar . MIME, mesaj gövdesinin çeşitli karakter kümelerinde (ASCII'den daha geniş) kodlanmasına izin verse de , temel alınan iletim altyapısının ( SMTP , ana E-posta aktarım standardı) 8 bitlik temiz olması hala garanti edilmez . Bu nedenle, şüphe durumunda önemsiz olmayan bir içerik aktarım kodlaması uygulanmalıdır. Ne yazık ki base64 , MIME olmayan istemcilerde US-ASCII karakterlerini bile okunamaz hale getirme dezavantajına sahiptir . Öte yandan, alıntı-yazdırılabilir ile birleştirilen UTF-8, BMP'den ASCII olmayan karakterler için 6-9 bayt ve BMP dışındaki karakterler için 12 bayt gerektiren boyut açısından çok verimsiz bir biçim üretir .

Kodlama sırasında belirli kurallara uyulması koşuluyla, UTF-7, temel bir MIME aktarım kodlaması kullanılmadan e-postayla gönderilebilir , ancak yine de metin karakter kümesi olarak açıkça tanımlanmalıdır. Ayrıca, "Konu:" gibi e-posta başlıklarında kullanılıyorsa , karakter kümesini tanımlayan MIME kodlu sözcüklerde UTF-7 bulunmalıdır . Kodlanmış kelimeler, alıntı-yazdırılabilir veya base64 kullanımını zorladığından , UTF-7, alıntı-yazdırılabilir (veya onun varyantı, RFC 2047/1522) ile birleştirildiğinde çift kaçmayı önlemek için bir kaçış karakteri olarak = işaretini kullanmaktan kaçınmak üzere tasarlanmıştır. ?Q?-başlıkların kodlanması).

UTF-7, işlenmesi çok zor olduğu için genellikle uygulamalarda yerel bir temsil olarak kullanılmaz. UTF-8'in kote-yazdırılabilir veya base64 ile kombinasyonuna göre boyut avantajına rağmen, şu anda feshedilmiş olan Internet Mail Consortium'un kullanılması önerilmez.

Mesaj gövdelerini 7 bit biçiminde kodlama ihtiyacını azaltan 8BITMIME de tanıtıldı.

UTF-7'nin değiştirilmiş bir biçimi (bazen 'mUTF-7' olarak adlandırılır) şu anda posta kutusu adları için IMAP e-posta alma protokolünde kullanılmaktadır.

Açıklama

UTF-7 ilk olarak , Unicode'un Posta Güvenli Dönüşüm Formatı olan RFC 1642'de deneysel bir protokol olarak önerildi . Bu RFC , hiçbir zaman standart haline gelmeyen bilgi amaçlı bir RFC olan RFC 2152 tarafından geçersiz kılınmıştır. RFC 2152'nin açıkça belirttiği gibi, RFC "herhangi bir tür İnternet standardı belirtmez". Buna rağmen, RFC 2152, IANA'nın karakter kümeleri listesinde UTF-7'nin tanımı olarak alıntılanmıştır. UTF-7 de bir Unicode Standardı değildir. Unicode Standard 5.0 yalnızca UTF-8, UTF-16 ve UTF-32'yi listeler. Ayrıca, RFC 2060'ta belirtilen ve bazen UTF-7 olarak tanımlanan değiştirilmiş bir sürümü de vardır.

Bazı karakterler doğrudan tek ASCII bayt olarak gösterilebilir. İlk grup "doğrudan karakterler" olarak bilinir ve 62 alfanümerik karakter ve 9 sembol içerir: ' ( ) , - . / : ?. Doğrudan karakterleri tam anlamıyla dahil etmek güvenlidir. "İsteğe bağlı doğrudan karakterler" olarak bilinen diğer ana grup, ve boşluk hariç U+ 0020 –U+007E aralığındaki diğer tüm yazdırılabilir karakterleri içerir ~ \ +(karakterler \ve JIS-~ gibi "ASCII türevlerinde" yeniden tanımlanmaları nedeniyle hariç tutulurlar- Roma ). İsteğe bağlı doğrudan karakterlerin kullanılması boyutu küçültür ve insan tarafından okunabilirliği artırır, ancak aynı zamanda kötü tasarlanmış posta ağ geçitleri gibi şeyler tarafından kırılma olasılığını artırır ve başlık alanları için kodlanmış sözcüklerde kullanıldığında ekstra kaçış gerektirebilir.

Boşluk, sekme, satır başı ve satır besleme de doğrudan tek ASCII bayt olarak gösterilebilir. Ancak, kodlanmış metin e-postada kullanılacaksa, bu karakterlerin e-postaya uygun olması için daha fazla içerik aktarımı kodlaması gerektirmeyen şekillerde kullanılmasına özen gösterilmelidir. Artı işareti ( +) olabilir olarak kodlanabilir +-.

Diğer karakterler UTF-16'da kodlanmalıdır (bu nedenle U+10000 ve üstü, iki vekil olarak kodlanacaktır) ve ardından değiştirilmiş Base64'te . Bu değiştirilmiş Base64 kodlu UTF-16 bloklarının başlangıcı bir +işaret ile gösterilir . Bitiş, değiştirilen Base64 kümesinde olmayan herhangi bir karakterle belirtilir. Değiştirilen Base64'ten sonraki karakter bir -(ASCII tire-eksi ) ise, kod çözücü tarafından tüketilir ve kod çözme bir sonraki karakterle devam eder. Aksi takdirde kod çözme, base64'ten sonraki karakterle devam eder.

Örnekler

• " Hello, World!" Olarak kodlanmış " Hello, World+ACE-"
• " 1 + 1 = 2" Olarak kodlanmış " 1 +- 1 +AD0- 2"
• " £1", " " olarak kodlanmıştır +AKM-1. Pound işareti için Unicode kod noktası, aşağıdaki tabloda olduğu gibi değiştirilmiş Base64'e dönüşen U+00A3'tür . 0'a doldurulan iki bit kaldı.

altıgen hane	0				0				A				3
İkili sistem örüntüsü	0	0	0	0	0	0	0	0	1	0	1	0	0	0	1	1	0	0
dizin	0						10						12
Base64-Kodlanmış	A						K						m

Kodlama ve kod çözme için algoritma

kodlama

İlk olarak, bir kodlayıcı hangi karakterlerin doğrudan ASCII biçiminde temsil +edileceğine , hangilerinin öncelenmesi gerektiğine +-ve hangilerinin Unicode karakter bloklarına yerleştirileceğine karar vermelidir . Basit bir kodlayıcı, doğrudan kodlama için güvenli olduğunu düşündüğü tüm karakterleri doğrudan kodlayabilir. Ancak bir Unicode dizisini sonlandırmanın, doğrudan ASCII'de tek bir karakter çıktısı almanın ve ardından başka bir Unicode dizisi başlatmanın maliyeti 3 ila 3'tür.+2 ⁄ 3 bayt. Bu 2'den fazla+Karakteri bir Unicode dizisinin parçası olarak temsil etmek için 2 ⁄ 3 bayt gerekir. Her Unicode dizisi aşağıdaki prosedür kullanılarak kodlanmalı ve ardından uygun sınırlayıcılarla çevrelenmelidir.

Örnek olarak £† (U+00A3 U+2020) karakter dizisini kullanarak:

kod çözme

İlk olarak, kodlanmış bir veri , açıklama bölümünde belirtildiği gibi düz ASCII metin parçalarına ( + es ve ardından bir tire dahil) ve boş olmayan Unicode bloklarına ayrılmalıdır . Bu yapıldıktan sonra, her Unicode bloğunun kodu aşağıdaki prosedürle çözülmelidir (örneğimiz olarak yukarıdaki kodlama örneğinin sonucu kullanılarak)

1. Her Base64 kodunu temsil ettiği bit dizisi olarak ifade edin:
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. İkili dosyayı soldan başlayarak on altı bitlik gruplar halinde yeniden gruplandırın:
   000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
3. Sonunda yalnızca sıfır içeren tamamlanmamış bir grup varsa, onu atın (eksik grup bunlardan herhangi birini içeriyorsa, kod geçersizdir):
   0000000010100011 0010000000100000
4. 16 bitlik her grup bir karakterin Unicode (UTF-16) numarasıdır ve başka şekillerde ifade edilebilir:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

Bayt sipariş işareti

Bir bayt sıra işareti (BOM), bir akışın veya dosyanın en başındaki isteğe bağlı özel bir bayt dizisidir ve verinin kendisi olmadan aşağıdaki veriler için kullanılan kodlamayı belirtir; kodlamayı belirten meta verinin yokluğunda kullanılabilir. Belirli bir kodlama şeması için, bu şemanın Unicode kod noktası temsilidir U+FEFF.

Tipik olarak tek, sabit bir bayt dizisi olsa da, UTF-7'de dört varyasyon görünebilir, çünkü UTF-7 kodlamasının 4. baytının son 2 biti aşağıdaki karaktere U+FEFFaittir , bu da 4 olası bit modeliyle sonuçlanır ve bu nedenle 4 4. konumda farklı olası baytlar. Unicode bayt sıra işaretleri tablosundaki UTF-7 girişine bakın .

Güvenlik

UTF-7, aynı kaynak dizenin birden çok temsiline izin verir. Özellikle, ASCII karakterleri Unicode bloklarının bir parçası olarak gösterilebilir. Bu nedenle, daha sonra UTF-7 olarak yorumlanabilecek dizelerde standart ASCII tabanlı kaçış veya doğrulama işlemleri kullanılıyorsa, kötü amaçlı dizeleri bunları geçmek için Unicode blokları kullanılabilir. Bu sorunu azaltmak için sistemlerin doğrulamadan önce kod çözme gerçekleştirmesi ve UTF-7'yi otomatik algılama girişiminden kaçınması gerekir.

Internet Explorer'ın eski sürümleri , sayfayı UTF-7 olarak yorumlamak için kandırılabilir. Bu, siteler arası komut dosyası çalıştırma saldırısı için kullanılabilir, çünkü <ve >işaretleri çoğu doğrulayıcının basit metin olarak geçmesine izin verdiği UTF-7 olarak +ADw-ve +AD4-UTF-7'de kodlanabilir .

UTF-7, en azından Microsoft yazılımı (.NET) için, 2020'de .NET 5'te daha önce kasıtlı olarak (güvenlik sorunlarını önlemek için) destekleyen kod yolları ile eski olarak kabul edilir.

Referanslar

Ayrıca bakınız

• Unicode kodlamalarının karşılaştırılması