unicode UTF-8 2 bytes of meer?

[Peter Wagemans]

Ik ben aan het studeren voor mijn certificaat test volgende woensdag en wordt hier toch nog maar eens geconfronteerd met de vraag. Extract uit de het FTS leerboek:

A text field can hold about two gigabytes of information, which is the equivalent of about a billion characters, or roughly 500,000 pages of English text. FileMaker Pro stores textual data internally as Unicode values, which require up to two bytes of information per character.

Discussie tijdens de FMSummit in Brugge aan tafel 's avonds met mijn nederlands collega die ook Peter heet, waarbij Peter me verteld dat UTF-8 veel meer dan 65000 karakters bevat, omdat de chinese taal alleen al 250.000 lettertekens bevat.

Kwam ik daar even uit de lucht vallen. En nu weer. Dus Wikipedia erbij.

https://en.wikipedia.org/wiki/UTF-8#Description

Daar schrijven ze:

The original specification covered numbers up to 31 bits (the original limit of the Universal Character Set). In November 2003, UTF-8 was restricted by RFC 3629 to end at U+10FFFF, in order to match the constraints of the UTF-16 character encoding. This removed all 5- and 6-byte sequences, and 983040 4-byte sequences.

en dan dit

The first 128 characters (US-ASCII) need one byte. The next 1,920 characters need two bytes to encode. This covers the remainder of almost all Latin alphabets, and also Greek, Cyrillic, Coptic, Armenian, Hebrew, Arabic, Syriac and Tāna alphabets, as well as Combining Diacritical Marks. Three bytes are needed for characters in the rest of the Basic Multilingual Plane, which contains virtually all characters in common use[12] including most Chinese, Japanese and Korean characters. Four bytes are needed for characters in the other planes of Unicode, which include less common CJK characters, various historic scripts, mathematical symbols, and emoji (pictographic symbols).

Tot hier toe is mijn conclusie dat de FTS documentatie niet correct is, en dat een FileMaker veld MINDER karakters kan bevatten als er bijvoorbeeld gebruik wordt gemaakt van niet latijnse talen - of van CJK karakters.

Is die conclusie correct? En het FTS leerboek eigenlijk fout?

[Banach]

Unicode is wat anders dan UTF-8 of UTF-16. De laatste twee zijn 'encodings'. De basis voor deze encodings is Unicode, maar is dus niet hetzelfde.

[Peter Wagemans]

Inderdaad, ik had "omvat" ipv "bevat" moeten gebruiken.

[JeanWM]

Peter,

 

iets dat we regelmatig als vraag tegenkomen, het verschil tussen UTF-n en Unicode.

 

UTF-n is encoding, Unicode is character set.

 

Een character set is een reeks characters met unieke getallen, soms naar gerefereerd als code points.

Een voorbeeld ervan in de Unicode character set, het getal voor de letter A is 41.

 

Een encoding is een algorithm dat de reeks getallen vertaald naar binary om het saven naar disk mogelijk te maken. Alles wordt immers met eentjes en nulletjes op disk gezet.

 

Een 1 = 00000001

Een 2 = 00000010

Een 3 = 00000011

Een 4 = 00000100

 

Wat je “ziet’ als 1, 2, 3, 4 …. wordt vertaald naar binary en zo opgeslagen op schijf.

 

Een toepassing ( FileMaker ) “leest” van een schijf:

 

1101000 1100101 1101100 1101100 1101111

 

FM weet dat dit een Unicode voorstelling is van een string, vertaald (encoded) met UTF-8 en moet dit nu op scherm tonen.

 

Eerst zal het de binary code converteren naar getallen. Het gebruikt de UTF-8 algorithm om de data te decoden. Dat geeft, in dit geval:

 

104 101 108 108 111

 

FM weet dat dit een Unicode string is, en verondersteld dat elk getal een character voorsteld.

 

De Unicode character set wordt gebruikt om elk getal te vertalen naar een overeenstemmend character.

 

Het resultaat wordt dus: hello

 

Conclusie:

UTF-n en Unicode kunnen niet met elkaar vergeleken worden, UTF-n is een encoding gebruikt om getallen te vertalen naar binary data.

Unicode is een character set gebruikt om characters naar getallen te vertalen.

 

De vraag is echter: wat is de definitie van "...gigabytes of information".

 

"hello" ( 5 letters ) tegenover 104 101 108 108 111.

 

"hello" is wat je in een veld zet, 104 101 108 108 111 is wat opgeslagen wordt....

 

Kijk ook eens even naar de omvang op schijf van een bestand waar er veel velden geindexeerd zijn, t.o.v. hetzelfde bestand zonder indexatie.

De "hoeveelheid" tekst zal hetzelfde zijn voor alle velden, de opgeslagen "hoeveelheid" echter niet....

[Peter Wagemans]

Bedankt voor deze "UTF-n 101" (pun intended) uiteenzetting. En Banach, jij ook bedankt om mij erop te wijzen dat ik moet oppassen wat ik zomaar schrijf.

 

Maar beide antwoorden lijken mij te gaan over "UTF-n is geen Unicode".

 

Wat eigenlijk niet mijn vraag is. Mijn vraag is of we minder karakters kunnen stockeren in een tekst veld, als we gebruik maken van bepaalde talen. Waarmee ik bedoel dat het me lijkt dat FileMaker niet genuanceerd genoeg is met hun statement die ik in de eerste post vermeld heb. het ljikt me dat er in bepaalde talen behoorlijk wat minder karakters (interpreteer:leesbare tekens) in een veld geraken, omdat ze meer dan 2 bytes nodig hebben in the UTF-8 encoding die FileMaker gebruikt.

Dit is natuurlijk een zuiver academische vraag, ik moet de eerste klant nog tegen komen die op zulke beperkingen botsts. Maar een FTS manual die developers voorbereid voor certificatie moet 100% correct ziijn, en niet zomaar een onvolledige defintie geven vind ik.

 

Puur op "binary" niveau veronderstel ik dat een text veld 4GB aankan, waarvan FileMaker 2GB reserveert voor controle code bytes ( stijl, font, marges ), maar dat is ook maar een veronderstelling, misschien krijg je pas problemen als de som van alle bytes die 4GB overschreidt. Wie zich geroepen voelt om dit "eventjes" te testen, be my guest... Hoe dan ook, deze post is een poging om mijn - onze - kennis te verdiepen over de limieten van een tekst veld.

 

Dus nogmaals bedankt voor de reakties, maar toch graag ook reaktie op de eigenlijke vraag.

[Banach]

Een must read artikel over Unicode en encodings is dit: http://www.joelonsoftware.com/articles/Unicode.html van Joel Spolsky. Ook zijn andere artikelen zijn trouwens het lezen meer dan waard.

 

Hij geeft aan dat UTF-8 uit 1 tot wel 6 bytes kan bestaan. UTF-8 is zodanig geconstrueerd om in de eerste 127 codepoints exact de ASCII tekens te bevatten. UTF-8 heeft dan maar één byte nodig.

 

Dit houdt dus in dat wanneer je tekst hebt die niet voornamelijk uit ASCII tekens bestaat je vaak meer bytes nodig hebt om het juiste Unicode teken weer te geven. Heb je alleen Engelstalige tekst dan zult je in 4GB meer tekst kunnen opslaan dan tekst in een Europese taal. De Aziatische talen hebben in een UTF-8 representatie nog meer ruimte nodig zodat je in 4GB nog minder tekst in zo'n taal kwijt kunt.

 

Aan de andere kant is 4GB aan tekst in FM verre van praktisch. Al bij enkele tientallen MB's heb je seconden lang die vervelende strandbal in beeld, simpelweg voor de presentatie van de eerste paar regels van een dergelijk veld.

Edited October 18, 2015 by Guest

[JeanWM]

FTS zegt:

A text field can hold about two gigabytes of information, which is the equivalent of about a billion characters, or roughly 500,000 pages of English text. FileMaker Pro stores textual data internally as Unicode values, which require up to two bytes of information per character.

 

Vandaar ook mijn vraag: wat bedoelen ze met "informatie"....

 

Er is sprake van "about" en "a billion characters" en "English text".

 

Dat interpreteer ik als: indien je een "andere" taal gebruikt dat meer characters nodig heeft voor hetzelfde in het Engels, dat je nog altijd beperkt blijft tot de "about" en "two gigabytes".

Dus...minder tekst.

 

Wat we in dit geval niet getest hebben, maar wat ik wel vrees, is dat FM de bestaande tekst gaat overschrijven indien de limiet overschreden wordt.

Een beetje zoals indertijd met FM 4 etc. waar de file size zowat 2 GB was en FM zonder waarschuwing de file begon te overschrijven.

Er was wel ergens in een KB "If you ever reach the file size limit, the file will begin to overwrite itself,"

 

Mijn dos centavos sin IVA

[Banach]

FileMaker Pro stores textual data internally as Unicode values, which require up to two bytes of information per character.

Academisch gezien zal je bovenstaande als onzin moeten kwalificeren. Men gaat hier voorbij aan het verschil tussen een tekenset en een encoding. Ook de bewering dat dit 'up to two bytes of information per character' nodig heeft is 100% onjuist. Daarmee zou je immers slechts zo'n 65.000 tekens kunnen vastleggen. De huidige Unicode standaard bevat zo'n 113.000 tekens, dus dat red je niet met 2 bytes.

 

Ook ga je, academisch gezien, twijfelen aan andere informatie in FTS (waar staat dat voor?) wanneer men in 1 zin al tweemaal onzin schrijft. Of is men bij Filemaker blijven steken bij Unicode versie 1.1 van meer dan 20 jaar geleden (1993)?

 

Ik ben het met Peter eens dat een leerboek voor specialisten 100% juist moet zijn, dat lijkt hier niet het geval.

[Peter Wagemans]

Bedankt voor jullie waardevolle input. FileMaker heeft de neiging om sommige zaken te eenvoudig voor te stellen. Zo eenvoudig dat ze vervallen in onzinnige uitspraken.

[Peter Bouma]

Ik heb eens ergens opgevangen (maar weet niet meer waar) dat FM zijn tekst intern opslaat als UTF-16, d.w.z. niet 'up to' 2 bytes, maar gewoon altijd (groepjes van) twee bytes per teken (2 voor verreweg de meeste tekens van de moderne talen, en 4 voor zeer exotische tekens — en Emoji). Dan is de FTS dus redelijk correct met de bewering dat 1G aan tekens (in doorsnee) 2GB aan bytes zal innemen. Maar toegegeven, ze zijn er een beetje vaag over, en ik heb bij het leren ook een beetje zitten twijfelen wat er nou bedoeld werd.

Op http://help.filemaker.com/app/answers/detail/a_id/14164 staat iets heel anders (<10.000.000 tekens "per herhaling"), maar dat zal toch echt fout zijn.

 

En er moet inderdaad onderscheid worden gemaakt tussen Unicode, wat gewoon een lijst is waarin lettertekens/karakters uit een waslijst aan talen en schriftsoorten (en een heleboel meer) ieder een standaardnummer hebben gekregen, en de binaire encodings, zoals UTF-8 en UTF-16.

Bij UTF-8 kan een teken (een Unicode codepoint) door 1, 2, 3 of 4 (vroeger ook 5 of 6) bytes worden gerepresenteerd. Waar het bij deze encodings om draait is dat aan iedere byte uit een stream bytes te zien is of die op zichzelf staat, of deel uitmaakt van een groepje dat samen een karakter vertegenwoordigt. Als de hoogste bit 0 is, hebben we te maken met single-byte, en dat komt 100% overeen met de oude low-ASCII (t/m nummer 127). Is voldoende voor Engels en een bescheiden groepje andere talen met Latijns schrift zonder accenten.

Zodra de hoogste bit van een byte aanstaat, hoort een UTF-8-byte tot een groepje dat samen één karakter definieert. De op één na hoogste bit bepaalt dan of een willekeurige byte de eerste of de volgende is van een groepje van 2 of meer. Voorbij codepoint 127 zijn de bits die het Unicode-getal representeren over de 2 (of meer) bytes verdeeld, met overslaan van de bits die aangeven wat voor type byte het is. De binaire rekensom die de Unicode-waarde geeft is dus niet opgebouwd uit aaneengesloten bits, maar bijv. 5 bits van de ene byte en 6 bits van de andere. Vanaf codepoint 2^11 (2048) moet je al naar meer dan 2 bytes.

In UTF-16 past alles tot codepoint 65535 in 2 bytes. Dat is genoeg voor de meeste moderne talen, ook voor het meeste Japans en Chinees voor dagelijks gebruik. Allerlei antieke schriften (bijv. spijkerschrift), reeksen zeldzamere Chinese tekens, muzieksymbolen en Emoji hebben hogere nummers, die krijgen in UTF-16 een encoding van 4 bytes lang.

 

Ik heb even zitten proberen, maar Filemaker accepteert zonder enig probleem ook die 'zeer hoge' Unicode-tekens (dus codepoints > 0xFFFF). Je kunt in een FM-veld dus gerust Emoji invoegen, een pak van mijn hart. Maar mocht je een hele roman in Emoji willen schrijven (iemand gaat dat doen), dan zul je dus waarschijnlijk minder karakters in 1 tekstveld kwijt kunnen dan de 1 miljard die FM je belooft. Ik ga dat vanavond niet meer uitproberen.