UTF-8, milyonlarca yeni karaktere sahip geniş bir yabancı dilin kullanılmasını destekleyebilir mi?


86

Durumunda bir uzaylı istilası karakterlerin kendi muhtemelen büyük miktardaki için izin vermek için bir şekilde UTF-8 tasarlanmıştır oluştu ve biz mevcut bilgisayar sistemlerinin tümünde kendi dilleri desteklemek zorunda kaldılar?

(Elbette, uzaylıların aslında dilleri olup olmadığını, nasıl iletişim kurduklarını, nasıl iletişim kurduklarını bilmiyoruz, ancak argüman uğruna, lütfen sadece onların yaptığını hayal edin.)

Örneğin, dilleri milyonlarca yeni temel glif, sembol ve / veya birleştirme karakterinden oluşuyorsa, UTF-8 teorik olarak bu yeni glifleri içerecek ve mevcut tüm yazılımları destekleyecek şekilde genişletilebilir mi?

Gliflerin mevcut boyut sınırlamalarını çok aşması ve tek bir glifi temsil etmek için daha fazla bayt gerektirmesi durumunda daha fazla ilgileniyorum. UTF-8 olabilir durumunda değil genişletilecek, o UTF-32 üzerinde tek avantajı sadece düşük karakterlerin boyutu olduğunu kanıtlıyor?


16
dillerini destekle ” (vurgum) ... Kaç tane? Dillerin karakterlere bölünebileceğinden emin miyiz? Belki de dil mekansal ilişkilere dayanmaktadır. - bkz. Ted Chiang “Hayatının Öyküsü”, Hayatınızın ve Diğerlerinin Öyküleri . En iyi ihtimalle, bu sadece bir X-byte'lık bir soru (konu dışı). En kötüsü, spekülatif saçmalık. (ne istediğinizi belli değil)
Roger

6
@ScantRoger Kabul edilen cevap, soruyu yanıtlandığı şekilde yanıtlamak için iyi bir iş çıkarır.
Qix

11
Kabul edilen cevap, bize UTF-8, UTF-16 ve UTF-32'nin gerçeklerini söyleme konusunda iyi bir iş çıkarıyor. Bunu Wikipedia'da görebilirsin. "Yabancı istilası" na gelince, cevabın nasıl cevap verdiğini anlamıyorum.
Roger


9
Unicode, dilleri desteklemez, karakterleri destekler - anlamı yazılı olarak ifade etmek için kullanılan glifler. Birçok insan dilinin bir senaryosu yoktur ve bu nedenle unicode tarafından desteklenemez. Pek çok hayvanın iletişim kurduğundan bahsetmiyorum ama yazılı bir dili yok. Söylenen resimlerle veya sözsüz çizgi romanlarla iletişim, glifler sonlu olmadığı için unicode tarafından desteklenemez. Tanım olarak uzaylıların nasıl iletişim kurduğunu bilmiyoruz, bu nedenle sorunuzun yanıtlanması imkansız. Unicode
un

Yanıtlar:


109

Unicode standardı için boş alan vardır Unicode kod noktaları “uçaklar” ve “bloklar” halinde düzenlenmiştir. 17 toplam uçaktan, şu anda atanmamış 11 tane var . Her uçakta 65.536 karakter var, bu yüzden yabancı bir dilden ayırmak için gerçekçi olarak yarım milyon kod noktası var (hepsini ilk temastan önce daha fazla emoji ile doldurmazsak). Unicode 8.0'dan itibaren toplamda sadece 120.737 kod noktası atandı (toplam kapasitenin yaklaşık% 10'u), aynı miktar atanmamış ancak özel, uygulamaya özel kullanım için ayrılmıştır. Toplamda 974,530 kod noktası atanmamıştır.

UTF-8, Unicode'un belirli bir kodlamasıdır ve şu anda UTF-16'nın sınırlamalarıyla eşleşen kod noktası başına dört sekizli (bayt) ile sınırlıdır. Özellikle, UTF-16 sadece 17 uçağı desteklemektedir. Daha önce, UTF-8 kod noktası başına 6 okteti desteklemekteydi ve 32768 uçağı desteklemek için tasarlanmıştı. Prensipte bu 4 baytlık sınır kaldırılabilir, ancak bu Unicode'un mevcut organizasyon yapısını bozabilir ve UTF-16'nın aşamalı olarak kaldırılmasını gerektirir - bazı işletim sistemlerinde ve programlamada ne kadar sağlam olduğu düşünüldüğünde yakın gelecekte gerçekleşmesi olası değildir. Diller.

UTF-16'nın hala yaygın kullanımda olmasının tek nedeni, sadece tek bir Unicode düzlemini destekleyen hatalı UCS-2 kodlamasına bir uzantısı olmasıdır. Aksi takdirde hem UTF-8 (sabit genişlikte değil) hem de UTF-32'den (ASCII uyumlu değil, ortak veriler için yer israfı) istenmeyen özellikleri miras alır ve endianness'i bildirmek için bayt sipariş işaretleri gerektirir. Bu sorunlara rağmen UTF-16'nın hala popüler olduğu göz önüne alındığında, bunun çok yakında kendiliğinden değişeceği konusunda pek iyimser değilim. Umarım, yeni Alien Overlord'larımız bu engelini kendi Kurallarına uygulayacaklardır ve onların bilgeliği UTF-16'yı yeryüzünden uzaklaştıracaktır .


7
Aslında, UTF-8, UTF-16 ile eşleşmesi için 4 byte limitinin sadece bir kısmıyla sınırlıdır. Spesifik olarak, bunun 17/32'sine, yarıdan biraz daha fazla.
Deduplicator

5
Windows dışında, işletim sisteminin veya işletim sistemindeki programların çoğunun UTF16 kullandığı başka bir işletim sistemi bilmiyorum. OSX programları tipik olarak UTF8, Android programları tipik olarak UTF8, Linux tipik olarak UTF8'dir. Yani ihtiyacımız olan tek şey Windows'un ölmesi (mobil alanda zaten bir çeşit ölü)
slebetman

23
İlk temastan önce bunların hepsini daha fazla emoji ile doldurmadığımız sürece . Uzaylılarla barışçıl etkileşime en önemli tehdit emoji'dir. Mahvolduk.
rickster

13
@slebetman Gerçekten değil. JVM tabanlı herhangi bir şey UTF-16'yı kullanır (Android, neden söylemediğinizden emin değildir), JavaScript UTF-16'yı kullanır ve Java ve JavaScript'in en popüler diller olduğu göz önüne alındığında, UTF-16 hiçbir yere gitmiyor yakında.
Malcolm

5
@Kaiserludi "Çoğu Linux kodu unicode için UTF32 kullanır", evet, hayır. Cidden bu fikri nereden buldun? Hatta bir wfopen sistem çağrısı veya başka bir şey yok, UTF8. Cehennem Python ve Java - her ikisi de dizeleri tarihsel nedenlerden dolayı UTF-16 olarak tanımlayan - gerektiğinde durumlar dışında UTF-16 olarak saklamıyor. hafızası pahalıdır, CPU ucuzdur). Aynısı Android için de geçerli - NDK’nın JString’i UTF8’dir, çünkü Google mühendisleri delirmez.
Voo

30

Eğer UTF-8 gerçekte uzatılacaksa, temsil edebileceği maksimum değere bakmalıyız. UTF-8 şöyle yapılandırılmıştır:

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

(utanmadan kopyalanan RFC dan .) Biz ilk bayt her zaman çok takip byte akım karakteri oluşturan nasıl kontrol ettiğini görüyoruz.

8 bayta izin verecek kadar genişletirsek, Unicode olmayan ek gösterimler elde ederiz.

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Bu tekniğin bize ulaşabileceği mümkün olan en fazla gösterimi hesaplamak

  10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7

veya 10 tabanında:

  128
+  32 * 64
+  16 * 64^2
+   8 * 64^3
+   4 * 64^4
+   2 * 64^5
+   1 * 64^6
+   1 * 64^7

bize 4.468.982.745.216 adedinde azami beyan tutarı veriyor.

Öyleyse, eğer bu 4 milyar ( veya trilyon, istediğiniz gibi ) karakterleri yabancı dilleri temsil etmek için yeterliyse, asgari çabayla, yeni UTF-8'i yeni yabancı hırsızlarımızı memnun edecek kadar uzatabiliriz ;-)


8
Şu anda UTF-8, 0x10FFFF'a kadar yalnızca kod noktaları ile sınırlıdır - ancak bu yalnızca UTF-16 ile uyumluluk içindir. Uzatmaya ihtiyaç duyulursa, 0x7FFFFFFF (2³¹-1) olana kadar kod noktaları ile genişletme konusunda belirsizlik yoktur. Ancak bunun ötesinde çelişkili tanımlar gördüm. Gördüğüm bir tanım, 111111xxilk 2 bayt, ardından maksimum 2³² kod noktası için beş uzatma baytı izliyor. Ancak bu yalnızca ilk 2³¹ kod noktası için belirttiğiniz tanımla uyumludur.
kasperd

2
Evet, Wikipedia gerçekten Unicode veya ISO 10646 (bağlama göre) anlamına geldiğinde UTF-16 hakkında bir şeyler söylüyor. Aslında, RFC 3629'dan bu yana UTF-8 , U + 10FFFF'nin (veya F4 8F BF BFUTF-8 baytların) ötesinde tanımsızdır . Bu yüzden burada bahsettiğim her şey saf spekülasyon. Tabii ki, birisi yüksek bir ilk baytın aşağıdaki başka bir yapıya işaret ettiği (ve bu süreçte kendiliğinden senkronizasyonu yok etmeyeceğinin) başka uzantıları düşünebilir. Yine de byte şemasını gerçek UTF-8'e mümkün olduğunca yakın olmaya çalıştım.
Boldewyn

4
Bu 4 trilyon, katrilyon değil.
Ypnypn

1
Aşağıdaki bayt sayısının her zaman birinci bayttaki öncekilerin sayısından daha az olması kesinlikle gerekli değildir. Perl aslında (2000'den beri) 5, 6 ve 7 byte formlarının bu cevapla aynı olduğu UTF-8'in bir varyantını destekliyor, ancak FF72 bit saklayabilen 13 baytlık bir kod birimi getiriyor. 2 ^ 36 üzerindeki herhangi bir şey üniform bir şekilde çok pahalıdır, ancak 64 bitlik bir int ve daha sonra bazılarını kodlamaya izin verir.
Hobiler

7

RFC3629, UTF-8'i karakter başına maksimum dört bayt ile sınırlar, maksimum değeri 0x10FFFF olup, maksimum 1.112.064 kod noktasına izin verir. Açıkçası, bu kısıtlama kaldırılabilir ve standart genişletilebilir, ancak bu, bu limite kadar çalışan mevcut kod için bir değişiklik olduğunu kanıtlar.

Bir veri dosyası bakış açısına göre, standart, her bir baytın en önemli biti (MSB) ayarlanmışsa, bir sonraki baytın kodlamanın bir parçası olması esasına göre çalıştığından, bir değişiklik olmaz. RFC3629'dan önce bile, standart dördüncü baytın MSB'sini ayarsız bırakarak 31 bit ile sınırlıydı.

Standardı 0x10FFFF ötesine genişletmek UTF-8'in UTF-16 ile kısmi veri uyumluluğunu da bozar.


5
Yani teoride, veriler geriye dönük olarak uyumlu olurdu, fakat kod kendiliğinden standarttaki değişiklikle uyumlu olmaz mıydı?
Qix 24/15

2
@ Qix, Bu geçerli bir nokta. Mevcut herhangi bir UTF-8 dosyası doğal olarak, örneğin milyonlarca daha fazla kod noktasını barındırmak için maksimum 6 byte ile uyumlu olacaktı, ancak UTF-8'i idare etmek için tasarlanan birçok kütüphane muhtemelen bu uzantıyı kullanmayacaktı.
David Arno

4
UTF-16 ölümcül bir şekilde kırılır. Doğal olarak yalnızca 0x10FFFF kod noktalarını destekleyebilir.
gnasher729

1
@ gnasher729: Sandığınız kadar büyük bir sorun değil. Unicode bunu, vardiya değerleri ile çözmüştür (Japonca için Shift JIS). Basitçe ayrılmış / kullanılmamış bir karakteri (0xFFFD?) Kodlamayı daha geniş bir forma kaydıran bir "vardiya karakteri" olarak işaretlerlerdi. Muhtemelen UTF32.
Mooing Duck

4

Gerçekten, sadece 2 Unicode kod noktası kodu, karakterleri birleştiriyorlarsa, sonsuz sayıda glif için kullanılır.

Örneğin, Unicode'un Kore Hangul alfabesi için kodladığı iki yolu karşılaştırın: Hangul Heceleri ve Hangul Jamo . Karakter 웃 Hangul Syllabelstek bir kod-nokta C6C3oysa Hangul Jamobu üç kod noktası 110B(ㅇ) 116E(ㅜ) 11B9(ㅅ). Açıkçası, birleştirme karakterlerini kullanmak çok daha az kod noktası alır, ancak her karakter için daha fazla bayt gerektiğinden yazma için daha az etkilidir.

Bu numara ile UTF-8 veya UTF-16'da kodlanabilecek kod noktası sayısının ötesine geçmeye gerek yoktur.

Sanırım dilleri dünyevi dilden ziyade mesaj başına daha fazla bayt gerektiriyorsa, uzaylıların ne kadar kırılgan olacağına bağlı. Sakıncası yoksa, her biri milyonlarca karakterin, 100k karakter birleştiren bir karmakarışık kullanarak temsil edilmesi, o zaman sorun olmaz; Öte yandan, topraklardan daha fazla bayt kullanmaya zorlanırsa, kendilerini ikinci sınıf vatandaş gibi hissettirirse, bazı çatışmalar içinde olabiliriz ( UTF-8 ile gözlemlediklerimizin aksine değil ).


Bu, sadece yabancı dildeki karakterler aslında daha sınırlı bir grafik dizisinden oluşuyorsa geçerlidir. Bu böyle olmayabilir.
JacquesB

1
Bildiğim kadarıyla, karakterleri birleştirmenin tek tek grafiklerle ilişkilendirilmesi gerekmiyor. Unicode SSS bu konuda sessiz, ancak benim izlenimim, her iki durumda da önceden oluşturulmuş bir glif gerekli olacağından, yerleşim motoru için grafik dizileri olmayan tarak dizilerini desteklemenin daha zor olmayacağı yönünde.
Owen

Bu uzaylılar ne kadar süreyle yaşıyorlar ve çocukluk döneminde grafilere ayrıştırılamayan kaç karakter öğrenebiliyorlar? Ve önceden oluşturulmuş Hangul, gzip'ten sonra bile, ayrıştırılmış Hangul'a göre bayt avantajını koruyor mu?
Damian Yerrick

-2

Düzenleme: Şimdi soru "milyonlarca yeni karakter" yazıyor. Bu cevap vermeyi kolaylaştırır:

Hayır . Utf-8 bir Unicode kodlamasıdır. Unicode, 1.114.112 farklı kod noktalarına izin veren bir kod alanına sahiptir ve şu anda bir milyondan daha azının atanmamış olması gerekmektedir. Bu nedenle Unicode'da milyonlarca yeni karakteri desteklemek mümkün değildir. Tanım olarak, Unicode kodlaması yok, Unicode tarafından tanımlanandan daha fazla karakter destekleyemez. (Elbette daha ileri bir seviyeyi kodlayarak hile yapabilirsiniz - her tür veri, sonuçta sadece iki karakterle gösterilebilir.)


Asıl soruya cevap vermek için:

Unicode, dilleri desteklememektedir; karakterleri - dili yazılı olarak temsil etmek için kullanılan sembolleri - desteklemektedir.

Tüm insan dillerinin yazılı bir temsili yoktur, dolayısıyla tüm insan dilleri Unicode tarafından desteklenemez. Ayrıca birçok hayvan iletişim kurar, ancak yazılı bir dili yoktur. Örneğin balinalar, bir dili çağıracak kadar karmaşık, ancak herhangi bir yazılı forma sahip olmayan (ya da mevcut fonetik gösterimlerle yakalanamayan) bir iletişim biçimine sahiptir. Bu yüzden dünyadaki bütün diller bile Unicode tarafından desteklenemez.

Daha da kötüsü, arıların dili gibi bir şey. Sadece yazılı bir forma sahip olmakla kalmaz, yazılı olarak anlamlı bir şekilde temsil edilemez. Dil, temelde bir yöne işaret eden ancak güneşin şu anki konumuna dayanan bir dans türüdür. Bu nedenle, dans sadece gerçekleştiği yerde ve zamanda bilgi değerine sahiptir. Sembolik veya metinsel bir temsil, arı dilinin şu anda ifade edemediği bilgileri (güneşin konumu, konumu) içermelidir.

Unicode'da yazılı veya sembolik bir iletişim şekli bile temsil etmek mümkün olmayabilir. Örneğin, şekiller veya sözsüz çizgi romanlar Unicode tarafından desteklenemez, çünkü glif kümesi sınırlı değildir. Bir havaalanı gibi uluslararası ortamlarda çok sayıda resimli iletişim olduğunu fark edeceksiniz; bu nedenle, uzayda yolculuk eden bir uzaylı ırkının resimli bir dil kullanmak için geliştiği düşünülemez.

Yabancı bir ırkın sınırlı bir sembol setine sahip bir yazı sistemi olan bir dili olsa bile, bu sistem Unicode'da desteklenemeyebilir. Unicode, yazının doğrusal bir sembol dizisi olmasını bekler. Müzik notasyonu, Unicode'da tamamen temsil edilemeyen bir yazı sistemi örneğidir, çünkü anlam hem sembol seçiminde hem de dikey ve yatay yerleştirmede kodlanmıştır. (Unicode bireysel müzik sembollerini desteklemektedir, ancak bir skoru kodlayamaz.) Çok sesli müzik (nadir olmayan) veya benzer karmaşıklığa sahip bir iletişim kanalı kullanılarak iletilen yabancı bir ırk, orkestra puanı gibi görünen bir yazı sistemine sahip olabilir. Unicode bunu destekleyemez.

Ancak, argüman uğruna, tüm dillerin, yabancı dillerin bile, sonlu bir kümeden seçilen doğrusal bir sembol dizisi olarak ifade edilebileceğini varsayalım. Unicode, uzaylı istilası için yeterince büyük mü? Unicode'un şu anda bir milyondan az atanmış kod noktası var. Çince, en kapsamlı Çince sözlüğe göre yüz binlerce karakter içermektedir (şu anda hepsi Unicode tarafından farklı karakterler olarak desteklenmemektedir). Bu nedenle, Çince'nin karmaşıklığına sahip on dil yalnızca Unicode'un tamamını kullanacaktır. Dünyada yüzlerce farklı yazı sistemimiz var, ama neyse ki çoğu ideografik değil alfabetiktir ve bu nedenle az sayıda karakter içerir. Tüm yazılı diller Çince gibi ideogramlar kullanıyorsa, Unicode dünya için yeterince büyük olmazdı. Alfabelerin kullanımı, yalnızca sınırlı sayıda fonem kullanan, ancak insan fizyolojisi için özel olan konuşmadan kaynaklanmaktadır. Dolayısıyla, sadece bir düzine ideografik yazı sistemine sahip tek bir yabancı gezegen bile Unicode'un destekleyebileceğini aşabilir. Şimdi, bu uzaylıların dünyadan önce başka gezegenleri istila etmiş ve yazı sistemlerini desteklenmesi gereken karakter kümesine dahil edip etmediğini düşünün.

Geçerli kodlamaların genişletilmesi veya değiştirilmesi veya yeni kodlamaların tanıtılması bunu çözmez, çünkü sınırlama Unicode tarafından desteklenen kod noktalarının sayısındadır.

Yani cevap büyük olasılıkla hayır.


5
Hayal gücünden yoksunsun. Dans koreografları, sahne aktörlerinin yapacağı dansları tanımlamak ve öğretmek için kullanabilecekleri birçok dil ve terminolojiye sahiptir. Eğer arıların ne iletişim kurduğunu öğrenseydik, kesinlikle bunun için yazılı bir terminoloji tasarlayabilirdik. Ne de olsa bugün yazılı dillerimizin çoğu bir ses kodlamasıdır. Kodlama hareketi kodlama sesinden tamamen farklı değildir.
whatsisname,

3
Bu cevabın bazı kısımları iyidir ancak "Sadece yazılı bir forma sahip değildir, muhtemelen yazılı olarak da temsil edilemez" demek sadece yanlıştır. Bilgi ileten her şey, bitlere indirgenebilir ve bitlere indirgenmiş herhangi bir şey, hemen hemen istediğiniz herhangi bir karakter akışına dönüştürülebilir.
Steven Burnap

2
@StevenBurnap Doğru, ancak Unicode bir bit dizisinden daha fazlasıdır. Bu bitleri yorumlamanın bir yolu, bu oldukça katı. Evet, Unicode karakter kümesi resimlerden CNC talimatlarına kadar herhangi bir şeyi temsil edecek şekilde genişletilebilir, ancak bu çok farklı bir yaratıktır.
Owen

4
Unicode sembollerinin tanımladığı şeyin (çoğu dilde) hava basıncı varyasyonundaki kalıplar olduğunu ve çoğu dil için aslında bu kalıplarla eşleşen oldukça berbat bir iş yaptığını unutmayın.
Steven Burnap

3
Yani cümle demek "Güneş ile 45 saniye uçur, soldan 15 derece sağa, sonra 10 saniye sağa 10 derece uçar" imkansız mı? Elbette güneşin bağlam olarak konumunu bağlam olarak gerektirir.
Steven Burnap
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.