UTF-8

Από τη Βικιπαίδεια, την ελεύθερη εγκυκλοπαίδεια

Αυτό το άρθρο χρειάζεται μετάφραση.

Αν θέλετε να συμμετάσχετε, μπορείτε να επεξεργαστείτε το άρθρο μεταφράζοντάς το ή προσθέτοντας δικό σας υλικό και να αφαιρέσετε το {{μετάφραση}} μόλις το ολοκληρώσετε.

Το UTF-8 (8-bit Unicode Transformation Format) είναι ένα μη-απωλεστικό, σχήμα κωδικοποίησης χαρακτήρων μεταβλητού μήκους για το πρότυπο Unicode που δημιουργήθηκε από τους Ken Thompson και Rob Pike. Χρησιμοποιεί ομάδες από bytes για να αναπαραστήσει τα κωδικά σημεία του Unicode.Είναι ιδιαίτερα χρήσιμο για μετάδοση δεδομένων σε 8bit συστήματα ηλεκτρονικού ταχυδρομείου.

Συγκεκριμένα χρησιμοποιεί ένα μέχρι τέσσερα bytes ανά χαρακτήρα ανάλογα με το σύμβολο και το κωδικό του σημείο.Για παράδειγμα μόνο ένα UTF-8 byte χρειάζεται για την κωδικοποίηση των 128 ASCII χαρακτήρες στο διάστημα του Unicode U+0000 μέχρι U+007F.

Τέσσερα bytes μπορεί να φαίνονται πολλά για έναν χαρακτήρα(κωδικό σημείο),παρόλαυτά αυτό αφορά μόνο κωδικά σημεία εκτός του Βασικού πολυγλωσσικού επιπέδου,τα οποία σπάνια χρησιμοποιούνται. Επίσης το UTF-16 (το κύριο εναλλακτικό σχήμα στο UTF-8) επίσης χρειάζεται τέσσερα bytes για αυτά τα κωδικά σημεία. Το ποιό είναι ποιό αποδοτικό το UTF-8 ή το UTF-16, εξαρτάται από το εύρος των κωδικών σημείων που θα χρησιμοποιηθούν. Οι διαφορές των δυο σχημάτων μπορούν όμως να γίνουν αμελητέες με την χρήση παραδοσιακών συστημάτων συμπίεσης όπως DEFLATE. Για μικρά κομμάτια κειμένου όπου οι παραδοσιακοί αλγόριθμοι δεν αποδίδουν καλά και όπου το μέγεθος του αρχείου μετράει μπορεί να χρησιμοποιηθεί και το Πρότυπο Σχήμα Συμπίεσης για Unicode

Η IETF (Internet Engineering Task Force) απαιτεί όλα τα πρωτόκολα διαδικτύου να αναγνωρίζουν και να υποστηρίζουν τουλάχιστον σαν σχήμα κωδικοποίησης χαρακτήρων τουλάχιστον το UTF-8

Πίνακας περιεχομένων

1 Περιγραφή
2 Τροποποιημένο UTF-8
3 Σκεπτικό πίσω από UTF-8
4 Μακρείς φόρμες , μη-έγκυρη είδοδος,και θέματα ασφάλειας
5 Πλεονεκτήματα και μειονεκτήματα
6 Ιστορία
7 Δες επίσης
8 Εξωτερικοί σύνδεσμοι

[Επεξεργασία] Περιγραφή

Το UTF-8 έχει γίνει το πρότυπο γνωστό σαν RFC 3629 (UTF-8, ένα φορμάτ μετασχηματισμού του καθολικού συνόλου χαρακτήρων ISO 10646).

Συνοπτικά,τα bits ενός χαρακτήρα Unicode διαιρούνται σε ομάδες οι οποίες κατόπιν διαιρούνται ανάμεσα στα χαμηλότερης αξίας bits μέσα σε UTF-8 bytes.

Ένας χαρακτήρας που το κωδικό του σημείο είναι μικρότερο του U+0080 κωδικοποιείται με ένα μόνο byte που περιέχει το κωδικό σημείο: αυτό το σύνολο χαρακτήρων αντιστοιχεί στους 128 χαρακτήρες του 7-bit ASCII.

Σε άλλες περιπτώσεις απαιτούνται μέχρι και τέσσερα bytes. Το πιο σημαντικό bit αυτών των bytes είναι 1, για να αποφευχθεί η σύγχυση με τους 7-bit ASCII χαρακτήρες, και συγκεκριμένα με χαρακτήρες με κωδικά σημεία μικρότερα του U+0020, που παραδοσιακά καλούνται χαρακτήρες ελέγχου, όπως ο carriage return.

Code range hexadecimal	UTF-16	UTF-8 binary	Notes
000000 - 00007F	00000000 0xxxxxxx	0xxxxxxx	ASCII equivalence range; byte begins with zero
000000 - 00007F	seven x	seven x	ASCII equivalence range; byte begins with zero
000080 - 0007FF	00000xxx xxxxxxxx	110xxxxx 10xxxxxx	first byte begins with 110 or 1110, the following byte(s) begin with 10
000080 - 0007FF	three x, eight x	five x, six x
000800 - 00FFFF	xxxxxxxx xxxxxxxx	1110xxxx 10xxxxxx 10xxxxxx
000800 - 00FFFF	eight x, eight x	four x, six x, six x
010000 - 10FFFF	110110xx xxxxxxxx 110111xx xxxxxxxx	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx	UTF-16 requires surrogates; an offset of 0x10000 is subtracted, so the bit pattern is not identical with UTF-8
010000 - 10FFFF	two x, eight x, two x, eight x	three x, six x, six x, six x

Για παράδειγμα ο χαρακτήρας άλεφ (א), που είναι ο χαρακτήρας Unicode με κωδικό σημείο U+05D0, μέσω του σχήματος UTF-8 κωδικοποιείται ώς εξής:

Βρίσκεται στο διάστημα U+0080 - U+07FF. Ο πίνακας δείχνει ότι θα κωδικοποιηθεί χρησιμοποιόντας δύο bytes 110xxxxx 10xxxxxx.
Ο δεκαεξαδικός 0x05D0 είναι ισοδύναμος στον δυαδικό 101-1101-0000.
Τα έντεκα μπιτς τοποθετούνται με την σειρά που έχουν στις θέσεις που σημειώνονται με "x" : 11010111 10010000.
Το τελικό αποτέλεσμα είναι δύο μπάιτς, που για οικονομία τα εκφράζουμε σαν δύο μπάιτς στο δεκαεξαδικό 0xD7 0x90. Αυτό είναι το γράμμα άλεφ στο σχήμα UTF-8.

Έτσι οι πρώτοι 128 χαρακτήρες χρειάζονται ένα μπάϊτ. Οι επόμενοι 1920 χαρακτήρες χρειάζονται δύο μπάϊτς. Αυτοί περιλαμβάνουν Latin alphabet characters with diacritics, Greek, Cyrillic, Coptic, Armenian, Hebrew, και Arabic χαρακτήρες. Οι επόμενοι από τους BMP χαρακτήρες χρησιμοποιούν τρια μπάϊτς και οι υπόλοιποι χαρακτήρες κωδικοποιούνται με τέσσερα μπάϊτς.

Συνεχίζοντας παρόμοια είναι δυνατό να χειριστούμε πολύ μεγάλους αριθμούς. Αρχικά το πρότυπο επέτρεπε ακολουθίες μέχρι έξι μπάϊτς καλύπτοντας το διάστημα U+0000 - U+7FFFFFFF (31 μπίτς). Όμως τελικά το UTF-8 περιορίστηκε από το RFC 3629 να χρησιμοποιεί μόνο το διάστημα που καλύπτει τυπικά το Unicode, από U+0000 ως U+10FFFF, το Νοέμβριο του 2003. Πριν συμβεί αυτό μόνο τα bytes 0xFE και 0xFF δεν εμφανίζονταν σε UTF-8 κωδικοποιημένο κείμενο. Μετά την εισαγωγή αυτού του ορίου ο αριθμός των αχρησιμοποιήτων μπάϊτς σε UTF-8 κείμενο αυξήθηκε σε 13 bytes: 0xC0, 0xC1, και 0xF5 μέχρι 0xFF.

[Επεξεργασία] Τροποποιημένο UTF-8

Η Γλώσσα προγραμματισμού Java, που χρησιμοποιεί UTF-16 για την εσωτερική αναπαράσταση κειμένου υποστηρίζει μια μη-τυποποιημένη τροποποίηση του UTF-8 για σειριοποίηση συμβολοσειρών. Αυτή η κωδικοποίηση λέγεται modified UTF-8.

[Επεξεργασία] Σκεπτικό πίσω από UTF-8

Σαν συνέπεια της λειτουργίας του UTF-8, ισχύουν οι ακόλουθες ιδιότητες για ακολουθίες πολλών μπάϊτς:

Το Πιο σημαντικό μπιτ ενός χαρακτήτα ενός μπάϊτ είναι πάντα 0.
Τα πιο σημαντικά μπιτς του πρώτου μπάιτ μιας ακολουθίας πολλών μπάϊτ καθορίζει το μήκος της ακολουθίας. Αυτά τα πιο σημαντικά μπιτς είναι τα 110 για ακολουθίες δύο μπάϊτ; 1110 για ακολουθίες τριών μπάϊτ κτλ.
Τα ακόλουθα μπάιτς μιας ακολουθίας πολλών μπάϊτ έχουν 10 σαν τα δύο ποιό σημαντικά μπιτς.

Το UTF-8 σχεδιάστηκε με αυτές τις ιδιότητες προκειμένου να εγγυηθεί ότι δεν θα είναι δυνατό μια ακολουθία μπάϊτ ενός χαρακτήρα να περιέχεται μέσα σε μια μεγαλύτερη ακολουθία μπάϊτς ενός άλλου χαρακτήρα.Αυτό μας εξασφαλίζει ότι μπορούμε να εφαρμόσουμε μπάϊτ-προσανατολισμένο ταίριασμα υπό-συμβολοσειρών για αναζήτηση λέξεων και φράσεων μέσα σε κείμενο. Μερικά παλίότερα 8-μπιτ σχήματα κωδικοποίησης (όπως το Shift-JIS) δεν είχαν αυτήν την ιδιότητα κάνοντας τους αλγόριθμους ταιριάσματος συμβολοσειρών πολύ πολύπλοκους. Παρόλο που αυτή η ιδιότητα προσθέτει πλεονασμό σε UTF-8-κωδικοποιημένο κέιμενο τα πλεονεκτήματα ξεπερνούν τα μειονεκτήματα και, εξάλλου, η συμπίεση δεδομένων δεν είναι στόχος του Unicode και πρέπει να εξεταστεί ξεχωριστά. Ακόμα αυτές οι ιδιότητες επιτρέπουν επανασυγχρονισμό στον επόμενο χαρακτήρα ενός ρεύματος κειμένου που μεταδίδεται από ένα σημείο σε κάποιο άλλο σε περίπτωση που χαθούν κάποια μπάϊτς λόγω βλάβης.

Επίσης λόγω του σχεδιασμού των ακολουθιών μπάϊτς, αν μια ακολουθία που υποθέτουμε ότι αναπαριστά κείμενο επαληθευτεί σαν UTF-8 τότε με μεγάλη σιγουριά μπορούμε να υποθέσουμε ότι είναι UTF-8. Η οικογένεια προτύπων ISO-8859 χρησιμοποιεί 100xxxxx για εξαιρετικά σπάνιους κωδικούς ελέγχου. Και κάποιες άλλες παραδοσιακές κωδικοποιήσεις χρησιμοποιούν μπάιτς σε αυτό το διάστημα αλλά μόνο για σπάνιους χαρακτήρες.

Μπορούν να χρησιμοποιηθούν σχήματα μπιτ προκειμένου να αναγνωρίστούν UTF-8 χαρακτήρες. Αν το πρώτο μπάιτ στο δεκαεξαδικό αρχίζει με 0-7 είναι χαρακτήρας ASCII. Αν αρχίζει με C ή D, είναι χαρακτήρας 11 μπιτ (εκφρασμένος με δυο μπάϊτ). Αν αρχίζει με E είναι 16 μπιτ (εκφρασμένος σε 3 μπάϊτς) και αν αρχίζει με F, είναι 21 μπιτς εκφρασμένος σε 4 μπάϊτς). 8 μέχρι B δεν μπορούν να είναι αρχικά ψηφία, αλλά όλα τα ακόλουθα μπάϊτς πρέπει να αρχίζουν με ψηφίο ανάμεσα στο 8 και το B. Έτσι με μια ματιά μπορείς να πεις ότι ο "0xA9" δεν είναι έγκυρος UTF-8 χαρακτήρας, αλλά ότι οι "0x54", "0xE3 0xB4 ή 0xB1" είναι έγκυροι UTF-8 χαρακτήρες.

[Επεξεργασία] Μακρείς φόρμες , μη-έγκυρη είδοδος,και θέματα ασφάλειας

Η ακριβή απόκριση ενός αποκωδικοποιητή σε μη-έγκυρη είδοσο είναι ακαθόριστη σε εκτεταμένο βαθμό. Υπάρχουν πολλοί τρόποι με τους οποίους ένας αποκωδικοποιητής μπορεί να αποκριθεί σε μη-έγκυρη είσοδο:

Εισαγωγή χαρακτήρα αντικατάστασης (πχ. '?', '�')
Να προσπεράσει τον χαρακτήρα
Να μεταφράσει τον χαρακτήρα σαν να ήταν από άλλο σύνολο χαρακτήρων (συχνά Latin-1)
Να μεταφράσει όλο το κείμενο σαν να ήταν από άλλο σύνολο χαρακτήρων

(συχνά Latin-1 ή το τοπικό σύνολο χαρακτήρων), κάτι που συμβαίνει σε εφαρμογές όπως IRC όπου το UTF-8 δεν είναι καθολικά αποδεκτό και δεν υπάρχει ενσωματομένος στο πρόγραμμα τρόπος για να καθοριστεί το σύνολο χαρακτήρων.

Να αδιαφορήσει και να αποκωδικοποιήσει σαν ο χαρακτήρας να ήταν κάποιος παραπλίσιος του UTF-8
Να αναφέρει λάθος

Decoders may of course behave in different ways for different types of invalid input.

All possibilities have their advantages and disadvantages but care must be taken to avoid security issues if validation is performed before conversion from UTF-8.

Overlong forms (where a character is encoded in more bytes than needed but still following the forms above) are one of the most troublesome types of data. The current RFC says they must not be decoded but older specifications for UTF-8 only gave a warning and many simpler decoders will happily decode them. Overlong forms have been used to bypass security validations in high profile products including Microsoft's IIS web server.

To maintain security in the case of invalid input there are two options. The first is to decode the UTF-8 before doing any input validation checks. The second is to use a strict decoder that, in the event of invalid input, returns either an error or text that the application considers to be harmless.

[Επεξεργασία] Πλεονεκτήματα και μειονεκτήματα

Γενικά
- Πλεονεκτήματα
  - Sorting of UTF-8 strings using standard byte-oriented sorting routines will produce the same results as sorting them based on Unicode code points, but this is unlikely to be considered a culturally acceptable sort order.
  - UTF-8 and UTF-16 are the standard encodings for XML documents. All other encodings must be specified explicitly either externally or through a text declaration. [1]
- Μειονεκτήματα
  - A badly-written (and not compliant with current versions of the standard) UTF-8 parser could accept a number of different pseudo-UTF-8 representations and convert them to the same Unicode output. This provides a way for information to leak past validation routines designed to process data in its eight-bit representation. See the W3 FAQ: Multilingual Forms for a Perl regular expression to validate a UTF-8 string

Compared to legacy encodings
- Advantages
  - UTF-8 can encode any Unicode character.
  - UTF-8 guarantees resynchronisation is possible with only the character that was cut in the middle lost. Many legacy multibyte encodings are much harder to resynchronise.
  - A byte sequence for one character never occurs as part of a longer sequence for another character as it did in older variable-length encodings like Shift-JIS (see the previous section on this).
  - The first byte of a multibyte sequence is enough to determine the length of the multibyte sequence (just count the number of leading set bits). This makes it extremely simple to extract a substring from a given string without elaborate parsing. This was often not the case in legacy multibyte encodings.
- Disadvantages
  - UTF-8 is generally larger than the appropriate legacy encoding for everything except diacritic-free, Latin-alphabet text. Most alphabetic scripts had only a single byte per character in legacy encodings but their letters take at least two bytes in UTF-8. Ideographic scripts generally had two bytes per character in their legacy encodings yet take three bytes per character in UTF-8.
  - Legacy encodings for almost all non-ideographic scripts use a single byte per character making string cutting and joining easy.

Compared to UTF-7
- Advantages
  - UTF-8 uses significantly fewer bytes per character for all non-ASCII characters.
  - UTF-8 encodes "+" as itself UTF-7 encodes it as "+-"
- Disadvantages
  - UTF-8 requires the transmission system to be eight-bit clean. In the case of e-mail this means it has to be further encoded using quoted printable or base64. This extra stage of encoding carries a significant size penalty. For base64, the overhead is 33⅓%, while for quoted printable the overhead varies depending on how ASCII-heavy the text is; for French the overhead is about 14%, for non-Roman scripts containing no ASCII characters the overhead is 200%!. In most cases UTF-7 will be smaller than the combination of UTF-8 with either quoted printable or base64 (even for ASCII-heavy languages such as French, UTF-7 is about 4% smaller than UTF-8 quoted printable).

Compared to UTF-16
- Advantages
  - Unicode code points in the ASCII range (Πρότυπο:Uplusfirst0000 to U+007F, including the basic Latin alphabet and the space character, can be represented in a single byte. Therefore text consisting of mostly diacritic-free Latin letters will be around half the size in UTF-8 than it would be in UTF-16, and text in many other alphabets will be slightly smaller in UTF-8 than it would be in UTF-16 because of the presence of spaces.
  - Most existing computer programs (including operating systems) were not written with Unicode in mind, and using UTF-16 with them would create major compatibility issues as it is not a superset of ASCII. UTF-8 allows programs to treat ASCII as they always did, and changes behaviour only for non-ASCII characters that were different by location anyway.
- Disadvantages
  - UTF-8 is variable-length; that means that different characters take sequences of different lengths to encode. The acuteness of this could be decreased, however, by creating an abstract interface to work with UTF-8 strings, and making it all transparent to the user. While UTF-16 is technically also variable length many people do not know this or simply do not care about the rarely used code points outside the BMP.
  - Chinese, Japanese, and Korean (CJK) ideographs use three bytes in UTF-8, but only two in UTF-16. So CJK text takes up more space when represented in UTF-8. There are a few other less-well-known groups of code points that this also applies to.

[Επεξεργασία] Ιστορία

UTF-8 was invented by Ken Thompson on September 2, 1992, on a placemat in a New Jersey diner with Rob Pike. The day after, Pike and Thompson implemented it and updated their Plan 9 operating system to use it throughout.

UTF-8 was first officially presented at the USENIX conference in San Diego January 25-29 1993.