Βασικώς, η κατανόηση της διεθνοποίησης της HTML είναι πολύ απλή και ευθύς, μόλις ξεκαθαριστεί η γενική ιδέα. Αλλά από τακτική εμπειρία παρανοήσεων, νιώθω οτι θα πρέπει να θέσω μια προειδοποίηση. Το πρόβλημα, σε πολλές περιπτώσεις, είναι οτι πολλοί το αντιμετωπίζουν με προκαταλήψεις από άλλες συγγραφικές καταστάσεις (πχ. επεξεργαστές κειμένου) που κάνουν δύσκολη την κατανόηση της λειτουργίας των πραγμάτων στην HTML. Συχνά έχουν πείσει τους εαυτούς των οτι γνωρίζουν σχεδόν τα πάντα που χρειάζονται να ξέρουν, απλά και μόνο αν μπορούσαν να πάρουν μια ευθεία απάντηση στην ερώτηση που τους απασχολεί: και τότε ανακαλύπτουν οτι η απάντηση δεν δείχνει να βγάζει νόημα και πιστεύουν οτι ο απαντών παριστάνει τον χαζό. Αυτό που πραγματικά συμβαίνει είναι οτι θα πρέπει να αναθεωρήσουν τις απόψεις των, δυστυχώς.
Αν πάντως θέλετε μια απλή συνταγή "κάντο έτσι" χωρίς τις εξηγήσεις, μπορείτε να πηδήξετε ως την "Συντηρητική προσέγγιση".
Το έγγραφο αυτό είναι μετάφραση του γνησίου αγγλικού κειμένου του Αλαν Φλάβελλ. Η μετάφραση έγινε από τον Πάνο Στόκα ο οποίος αναλαμβάνει την ευθύνη για τυχόν λάθη.
Η σελίδα αυτή σκοπεύει στην εξήγηση των αρχών της διεθνοποίησης της HTML (internationalization ή "i18n") όπως σχετίζονται με τα δεδομένα που περνούν στο δίκτυο. Συμπεριλαμβάνεται, επίσης μια πρακτική συζήτηση για την υποστήριξη από τους browsers. Δεν μπαίνει όμως η σελίδα αυτή σε πρακτικές τεχνικές για την συγγραφή τέτοιων σελίδων, ούτε ασχολείται με έγγραφα περιορισμένα σε μία μόνο διάλεκτο εκτός του συνόλου Latin-1: βλέπε την εξήγηση στο εξώφυλλο.
Ο αναγνώστης μπορεί να εξετάσει την ακόλουθη λίστα ερωτήσεων και απαντήσεων, για να δεί πως θα ταιριάξουν οι δικές του απαντήσεις με αυτές που δίνονται εδώ. Στο σημείο αυτό, δεν χρειάζεται γνώση ειδικευμένης ορολογίας· πρόκειται για πρακτικές ερωτήσεις σχετικά με το τί θα πρέπει να δείχνει ένας browser ανταποκρινόμενος σε κάποιες κατασκευές HTML, σύμφωνα με τις προδιαγραφές HTML4/RFC2070 (πάντως οι απαντήσεις βγάζουν καλύτερο νόημα εάν έχετε ένα νοερό μοντέλο σε αρμονία με την εν λόγω προδιαγραφή).
Να έχετε υπόψιν οτι μπορεί να μην πάρετε τα σωστά αποτελέσματα από τον browser που χρησιμοποιείτε, για διαφόρους λόγους. Ο browser μπορεί να είναι έκδοσης που δεν υπακούει με τις προδιαγραφές, η μπορεί να μην τον έχετε διαμορφώσει σωστά (σε διαθέσιμα fonts και τις απαιτήσεις του λειτουργικού συστήματος) για χρήση που απαιτείται στις προδιαγραφές του WWW. Τα θέματα αυτά συζητούνται αργότερα, αλλά αρχικώς δεν είναι απαραίτητο να κατανοείτε τις απαιτήσεις των προδιαγραφών.
Ποιό είναι το νόημα των ακόλουθων σε ένα κείμενο HTML4.0 που έχει σταλεί με charset=koi8-r ;
Α: είναι ο χαρακτήρας στη θέση 241 του κωδικού koi8-r, δηλαδή ο χαρακτήρας YA (μοιάζει με ένα αντίστροφο R).
A: είναι ο χαρακτήρας στην θέση 241 του σετ χαρακτήρων της HTML4.0, δηλαδή του iso-10646/unicode, συνεπώς είναι η ñ (n-tilde). (οι κωδικοί χαρακτήρων από το 0-255 στο iso-10646 είναι ίδιοι με το iso-8859-1, τον παραδοσιακό κώδικα χαρακτήρων της HTML2.0).
A: προφανώς, αυτό είναι και πάλι n-tilde (ναι!).
A: είναι ο χαρακτήρας στην θέση 153 της κωδικοσελίδας koi8-r , δηλ. το σύμβολο "μεγαλύτερο ή ίσον".
A: σε ότι αφορά την HTML/SGML, αυτός δεν έχει οριστεί. Δείχνει να είναι μια αριθμητική αναφορά σε χαρακτήρα, αλλά αναφέρεται σε μια θέση του σετ χαρακτήρων του εγγράφου οπου δεν βρίσκονται εκτυπώσιμοι χαρακτήρες. Προσέξτε οτι αυτή η κατασκευή δεν θα απορριφθεί από έναν ελεγκτή της SGML, αφού τεχνικώς είναι "αόριστη" και όχι "αδύνατη". Οι λεπτομέρειες είναι ανεπαίσθητες για να ακολουθήσουμε ως εκεί, αρκεί να πούμε οτι δεν θα πρέπει να χρησιμοποιείτε αυτόν τον τρόπο (ακόμα και αν φαίνεται να παράγει ένα αποτέλεσμα που θέλατε στον browser που χρησιμοποιείτε). Αν και δεν θα απορριφθεί από έναν επίσημο ελεγκτή, η κατασκευή αυτή θα πρέπει σίγουρα να σημειωθεί από έναν καλό διορθωτή ή "καθαριστή" (linter) της HTML.
A: η αναφορά στους χάρτες του Unicode, ή ίσως πιο απλά στην προδιαγραφή της HTML4.0, δείχνει οτι αυτό είναι το ελληνικό "ρο". Ναι, σύμφωνα με τους κανόνες της HTML4.0, μπορείτε να χρησιμοποιείτε αριθμητικές αναφορές χαρακτήρων σε unicode, ακόμα και όταν χρησιμοποιείτε ένα 8-μπιτο "charset" (κωδικοποίηση χαρακτήρων). Στην πραγματικότητα, αυτή είναι ακριβώς η στιγμή που χρειάζεστε αριθμητικές αναφορές σε χαρακτήρες. (Κρίμα όμως, για τη Netscape.)
Μπορούμε τώρα να θέσουμε μια παρόμοια σειρά ερωτήσεων αλλά με το σετ χαρακτήρων iso-8859-7 (ελληνικά) αυτή τη φορά. Ορίστε τα ενδιαφέροντα σημεία.
A: αυτός είναι ένας χαρακτήρας στη θέση 241 του κωδικού iso-8859-7, που είναι το "ρο".
A: Αυτός είναι και πάλι ο χαρακτήρας στη θέση 241 του σετ χαρακτήρων εγγράφου HTML, δηλαδή ñ (n-tilde).
A: στον κωδικό iso-8859-7 (ελληνικά), όπως και σε άλλους κωδικούς iso-8859-n το διάστημα δεκαδικών 128-159 είναι δεσμευμένο για λειτουργίες ελέγχου και δεν χρησιμοποιείτε για εκτυπώσιμους χαρακτήρες. Αυτός ο 8-μπιτος κώδικας είναι απαράδεκτος σε ένα έγγραφο HTML με αυτό το σετ χαρακτήρων. (Και θα πρέπει να απορριφθεί από έναν επίσημο ελεγκτή.)
A: όπως και πρίν, αυτή η σημείωση είναι αόριστη σε τεχνικούς όρους και δεν θα πρέπει να χρησιμοποιείται. Κάτι τέτοιo θα ήταν πραγματικά ασυνεπές προς το σετ χαρακτήρων.
A: αυτή είναι η σωστή αριθμητική αναφορά σε χαρακτήρα για το ελληνικό "ρο", όπως ήδη γράφτηκε.
Εξετάζουμε τώρα μια παρόμοια σειρά ερωτήσεων σχετικά με τo Δυτικοευρωπαϊκό σετ χαρακτήρων των MS-Windows, γνωστό και σαν windows-1252. Εδώ υπάρχει μια ειδική αιτία σύγχυσης: όλες οι τιμές των εκτυπώσιμων χαρακτήρων του iso-8859-1 συμπίμπτουν με τους ίδιους κωδικούς με αυτόν τον κώδικα των Windows - αλλά επίσης, ο κώδικας των Windows βάζει εκτυπώσιμους χαρακτήρες στην περιοχή οπου στους κωδικους iso-8859-n είναι κρατημένη για λειτουργίες ελέγχου. Στο unicode, οι χαρακτήρες αυτοί έχουν τιμές άνω του 256 (οι αντίστοιχες τιμές επίσης βρίσκονται και στην προδιαγραφή HTML4.0).
A: στην κωδικοποίηση των Windows, αυτός είναι ο χαρακτήρας "σήμα κατεθέν - trademark" (δεκαδικός 8482 στο unicode). Σε τεχνική γλώσσα, ένα έγγραφο HTML με αυτόν τον χαρακτήρα είναι σωστά καθορισμένο όταν αποστέλλεται με την σωστή τιμή για το "charset". Πάντως, δεν υπάρχει απαίτηση από τα προγράμματα ανάγνωσης HTML να υποστηρίζουν κάθε κωδικοποίηση, και οι κωδικοί του ISO είναι γενικώς προτιμώμενοι από ένα κώδικα αποκλειστικής χρήσης, ακόμα και της Microsoft.
A: όπως και πριν, αυτό είναι αόριστο σε όρους HTML/SGML. Η σωστή αναπαράσταση του trademark σαν αριθμητική αναφορά στην HTML4.0 είναι η ™ ασχέτως της τιμής του "charset".
Κλείνουμε αυτό το πληροφοριακό κουίζ κάνοντας μια παρόμοια ερώτηση για ένα έγγραφο HTML που αποστέλλεται με τιμη charset=utf-8:
A: αυτή είναι πονηρή ερώτηση. στην κώδικοποίηση utf-8, μόνο οι τιμές κάτω του 128 έχουν νόημα σε απομόμωση (συνήθως αναφέρονται στους αντίστοιχους 7-μπιτους χαρακτήρες us-ascii). 8-μπιτοι με τιμές 128 και άνω εμφανίζονται μόνο σαν μέρος της σειράς δύο ή περισσοτέρων 8-μπιτων, με την κάθε σειρά να αναπαριστά έναν χαρακτήρα unicode.
Τι συμβαίνει όμως με τα fonts ; Υποθέτωντας οτι για παράδειγμα έκλεινε κάποιος τις παραπάνω κατασκευές στο FONT FACE=Symbol ;
Η απάντηση σε όρους HTML είναι οτι οι χαρακτήρες σημαίνουν ότι η προδιαγραφή της HTML λέει οτι σημαίνουν, ασχέτως της οπτικής εμφάνισης τους στη σελίδα! Αν σκέπτεστε την προσβασιμότητα στα έγγραφα σας από αυτόματα ευρετήρια, φωνητικούς browsers, κλπ, αυτό είναι πασιφανές. Ο σκοπός του (πλέον αποδοκιμαζόμενου) FONT FACE, όπως και των υποδείξεων για fonts στα cascading style sheets, είναι να επιλέξει fonts με διαφορετική κοσμητική εμφάνιση, και όχι σαν ένα κόλπο για να επαυξήσουμε το ρεπερτόριο των χαρακτήρων. Θα επιστρέψουμε στο θέμα αυτό αργότερα: για την ώρα, παρακαλώ δεχτείτε οτι έχετε για κάθε χαρακτήρα του unicode και ένα (υποθετικό) αντίστοιχο font.
LANG της HTML)Είναι σημαντικό να προσέξτε οτι η HTML κρατά την απόσταση μεταξύ "γλώσσας" και συστήματος γραφής, που είναι δυο διαφορετικά πράγματα. Για παράδειγμα, τα ελληνικά ή τα ιαπωνικά συνεχίζουν να είναι ελληνικά ή ιαπωνικά (γλώσσες) ακόμα και αν γραφτούν σε λατινικούς χαρακτήρες, ενώ τα αγγλικά συνεχίζουν να είναι αγγλικά (γλώσσα) όταν γραφτούν σε, ας πούμε, ιαπωνική σημειογραφία (δηλ. γραφή). Και το σύστημα γραφής καθορίζεται από ποιούς χαρακτήρες χρησιμοποιούνται στο κείμενο, όχι από τα χαρακτηριστικά γραφής στο μαρκάρισμα της HTML.
Εδώ παρέλειπω μερικα θέματα που σχετίζονται με την ενοποίηση των κινεζικών, ιαπωνικών, κορεατικών κ.α. ("CJK") στο Unicode.
Θέλω να τονίσω οτι το κλειδί στην κατανόηση μιας πολύπλοκης κατάστασης είναι η διάσπαση της σε ευκολα διαχειρίσιμα μέρη και η κατανόηση του καθένος από αυτά ξεχωριστά, πριν να τα συναρμολογήσουμε σε απλά, καθορισμένα interfaces. Πολύ συχνά, οι άνθρωποι δεν έχουν έναν καθαρό διαχωρισμό στο μυαλό τους για τους κωδικούς μετάδοσης, τους κωδικούς χακτήρων και τα fonts, και έτσι είναι πολύ εύκολο το να μπερδευτούν, ή να προτείνουν τεχνικές που φαίνονται να δίνουν το επιθυμητό οπτικό αποτέλεσμα αλλά είναι εντελώς ξένες προς τις προδιαγραφές της HTML.
Πιστεύω λοιπόν οτι είναι σημαντικό να κοιτάξουμε στα θέματα αυτά. Πηδήξτε αυτό το μέρος αν θέλετε· αλλά αν έχετε ένα ακατάλληλο νοερό μοντέλο, είναι σίγουρο οτι θα προκαλέσει σύγχυση αργότερα.
Ο WWW βασίζεται σε μοντέλο client-server: οι δια-εφαρμόσιμες προδιαγραφές επικεντρώνονται στο τί σημαίνουν τα δεδομένα όταν περνάται μεταξύ του server και του client. Οι λεπτομέρειες του τί συμβαίνει στον client, και στον server, δεν είναι δουλειά των δια-εφαρμόσιμων προδιαγραφών: αυτό που έχει σημασία είναι οτι συμμετέχοντες θα πρέπει να παράγουν σωστά τα μεταφερόμενα δεδομένα και να μεταφράσουν σωστά το νόημα των λαμβανόμενων δεδομένων. Ο όρος "σωστά" σημαίνει "σε συμφωνία με τις ανοιχτές, δημοσιευμένες, δια-εφαρμόσιμες προδιαγραφές" (δεν σημαίνει απαραιτήτως "τι ήθελε ο συγγραφέας", αφού οι συγγραφείς μπορεί να έχουν προθέσεις που είναι ασύμβατες με τις προδιαγραφές!). Οι δια-εφαρμόσιμες προδιαγραφές δεν χρειάζεται να ασχολούνται με το γεγονός οτι οι Mac έχουν τον δικό τους ιδιόκτητο κώδικα για τις εσωτερικές εφαρμογές, ούτε πραγματι για τα mainframe της IBM που δουλεύουν στο EBCDIC: η ροή δεδομένων που περνά από το δίκτυο θα πρέπει να μεταφραστεί σύμφωνα με τις δια-εφαρμόσιμες προδιαγραφές, ασχέτως των τοπικών λεπτομερειών.
Επικεντρώνουμε λοιπόν στο νόημα των οκτάμπιτων ροών που στέλνει ο server μέσω του δικτύου στον client, και στο νόημα που αναπαριστούν οι οκτάμπιτες ροές αυτές στην HTML και μπορούμε - και θα πρέπει - να απομακρυνθούμε από τις λεπτομέρειες του πως αυτό ή το άλλο πρόγραμμα στον client θα σώσει τα δεδομένα, θα μεταφράσει τα δεδομένα και θα τα περάσει στην οθόνη. Παρεπιπτόντως, θυμηθείτε οτι μερικοί "cients" (πχ. αυτόματα ευρετήρια) δεν μεταφράζουν την πληροφορία οπτικά, και δεν έχουν ιδέα για το πώς ένα συγκεκριμένο font δείχνει: μεταφράζουν μόνο το νόημα των κωδικοποιημένων δεδομένων όπως παρουσιάζεται στις προδιαγραφές της HTML.
Αυτό μπορεί να γίνει εύκολα αν σκεπτόμαστε σε όρους ενός υποθετικού client, που μπορεί να αποθηκεύει τα δεδομένα σε unicode, και που μπορεί να παρουσιάζει κάθε ζητούμενο χαρακτήρα από κάθε ζητούμενο font. Οι πραγματικοί clients μπορεί να συμπεριφέρονται εντελώς διαφορετικά: μπορεί να αποθηκεύουν δεδομένα με κάπως διαφορετικό τρόπο, και η παρουσίασή των μπορεί να οργανώνεται διαφορετικά. Αλλά όσο τα προγράμματα των client συμπεριφέρονται στο εξωτερικό παρατηρητή "σαν να" δούλευαν όπως ο υποθετικός client, τότε οι εσωτερικές λεπτομέρειες δεν έχουν σημασία ("μαύρο κουτί").
Μια χρήσιμη τεχνική για την κατανόηση δικτυακών εφαρμογών είναι το αποκαλούμενο "μοντέλο επιστρώσεων κέηκ".
Θεωρούμενη σαν ένα πρωτόκολλο με επιστρώσεις, η μεταφορά ενός εγγράφου HTML μέσω HTTP είναι αρκετά απλή: το HTTP μεταφέρει μια σειρά οκτάμπιτων δεδομένων με δηλώσεις περιεχομένου σύμφωνες με το MIME που προσδιορίζουν την κωδικοποίηση ("charset"). Αυτό που συμβαίνει από κάτω (σε όρους των πρωτοκόλλων TCP/IP του Internet, των προσβάσεων σε Ethernet και ούτω καθ'εξής) βρίσκεται στα πιο κάτω στρώματα του κέηκ, τα οποία μένουν κρυμμένα για το σκοπό μας.
Στο κατώτερο επίπεδο που δεν χρειάζεται να συζητήσουμε εδώ, χρησιμοποιούμε την πληροφορία "content-type" του ΜΙΜΕ (συγκεκριμένα, το "charset" που δείχνει πως να μεταφράσουμε την οκτάμπιτη ροή τους χαρακτήρες της κωδικοποίησης) ωστε να παράγουμε από την οκτάμπιτη ροή μια ροή χαρακτήρων. Αν και στις απλές περιπτώσεις (πχ. στους κωδικούς iso-8859-n) κάθε οκτάμπιτος αντιστοιχεί σε έναν χαρακτήρα του κωδικού, αυτό σίγουρα δε συμβαίνει πάντα. Σε κάποιους κωδικούς (πχ. στους βασισμένους σε iso-2022) ορισμένες σειρές οκτάμπιτων δεν αντιστοιχούν σε χαρακτήρα του κωδικού, αλλά αντικαθιστούν την "σελίδα" χαρακτήρων με μια άλλη ωστε να εκτείνουν το ρεπερτόριο για τους επόμενους χαρακτήρες. Στο ucs-2, κάθε χαρακτήρας εκπροσωπείται από ένα ζεύγος οκτάμπιτων, ενώ στο utf-8 οι χαρακτήρες εκπροσωπούνται από μεταβλητά νούμερα οκτάμπιτων, από το ένα ως το έξι, συμφωνα με έναν αλγόριθμο.
Είναι λοιπόν βολικό το να σκεπτόμαστε σε όρους του "υποθετικού client" που μετατρέπει κάθε κωδικοποιημένη οκτάμπιτη σειρά, ασχέτως με ποιόν χαρακτήρα εστάλθηκε, σε χαρακτήρες unicode για αποθήκευση και περεταίρω επεξεργασία.
Στο επόμενο υψηλότερο επίπεδο, η απορρέουσα ροή χαρακτήρων πρέπει να αναλυθεί με όρους HTML. Κάνοντας το αυτό, συναντούμε εκπροσωπήσεις τύπου &οντότητα; και αναφορές χαρακτήρων τύπου &#αριθμός; που χρειάζεται να μεταφραστούν. Όπως έχει τονιστεί επαννηλειμένως, αυτές οι εκφράσεις (σύμφωνα με τις προδιαγραφές της HTML) θα πρέπει πάντα να μεταφράζονται με αναφορά στο unicode (δηλ. στο "σετ χαρακτήρων εγγράφου HTML"), και όχι με αναφορά στην κωδικοποίηση ("charset") των εκπεμπόμενων χαρακτήρων. Πράγματι, στον "υποθετικό client" οι λεπτομέρειες για την κωδικοποίηση των αποστελλόμενων αφαιρέθηκε στην "φάση της εισαγωγής" όταν μετατρέψαμε την σειρά οκτάμπιτων σε unicode για αποθήκευση, και το θέμα αυτό μπορεί να ξεχαστεί πλήρως.
Και, φυσικά, οι συλλογισμοί για την μετατροπή εφαρμόζονται όταν επιθυμούμε από έναν client να στείλει πίσω κάποιους χαρακτήρες στον server, πχ. σαν αποτέλεσμα της συμπλήρωσης μιας φόρμας.
Λοιπόν, βάση της "αρχής μαύρου κουτιού" ο client μπορεί να δουλέυει εσωτερικά με κάποιο διαφορετικό τρόπο, αλλά, για η συμμόρφωση με τα στάνταρ επιτάσσει οτι η συμπεριφορά τους θα πρέπει να είναι όμοια με αυτήν του "υποθετικού client". Τέλος, αφού μεταφράσει την ροή των χαρακτήρων σε HTML, ο browser θα πρέπει να το περάσει στην οθόνη. Για το σκοπό αυτό θα πρέπει να χρησιμοποιήσει κάποιο κατάλληλο font.
Σε πρώιμες υλοποιήσεις, τα fonts ήταν μια απλή χαρτογράφηση των 256 διαθέσιμων 8-μπιτων κωδικών σε εκτυπώσιμους χαρακτήρες. Ακολούθως, για κάθε κωδικοποίηση χαρακτήρων θα θέλατε και ένα διαφορετικό font: για το υποθετικό στυλ χαρακτήρων "Απλά" θα χρειαζόσασταν, ας πούμε, Απλά-Latin 1 για το iso-8859-1, Απλά-Greek για το iso-8859-7, Απλά-Russian για το koi8-r και ούτω καθ'εξής. Για κάθε νέα κωδικοποίηση που θα θέλατε να υποστηρίξετε, θα έπρεπε να έχετε ένα νέο font και η δουλεία τελείωνε, ή έτσι φαινόταν. Αχανείς παρατάξεις τέτοιων fonts μπορούν να συλλεχθούν από sites για κατέβασμα, οπου η καθεμιά διαφέρει από την άλλη μερικές φορές σε λίγα μόνο σημεία, και οι βασικοί χαρακτήρες έχουν αντικατασταθεί από εξωτικούς χαρακτήρες απαραίτητους για κάποιους ειδικευμένους σκοπούς.
Πάντως, για να έχουμε αληθή διεθνοποίηση, αυτό δεν είναι αποδεκτό. Θα χρειαστείτε ένα από τα δύο: ένα εκτεταμένο font-family, ή την ικανότητα του browser να προσβαίνει σε πολλά fonts (αισθητικώς συμβατά) ωστε να διαμορφώνει ένα διεθένες έγγραφο. Θυμηθήτε οτι σε όρους HTML το όλο έγγραφο είναι σε ένα "charset", που δεν αλλάξει κωδικούς στη μέση του εγγράφου.
Η επεξεργασία κειμένου, αντιθέτως, τυπικά χρησιμοποιεί ένα διαφορετικό μοντέλο - ένα που δεν προσφέρεται για διαπλατφορμικές μεταφορές εγγράφων, κάτι που είναι εντελώς απαραίτητο για την επιτυχία του WWW. Αντί να σκέπτεται σε όρους του συγγραφέα που "διαλέγει ένα font" με την παραδοσιακή έννοια (πχ. να αλλάζει από Arial-Latin-1 σε Arial-Greek όταν χρειάζεται ελληνικούς χαρακτήρες) και να περνά αυτήν την πληροφορία στον client ωστε να εμφανίσει τον επιθυμητό εξωτικό χαρακτήρα, η HTML4.0 δουλεύει με τρόπους μεταφοράς της παραπομπής του επιθυμητού χαρακτήρα σε unicode και αφήνει την ευθύνη στον client για το πώς να περάσει τον εξωτικό χαρακτήρα στην οθόνη σε θέματα fonts κλπ.
Περίληψη: αυτό που αρχικώς φαινόταν μια συνδυασμένη πράξη: κωδικός-χαρακτήρα μέσα, θέση font έξω, έχει τώρα γίνει μια διαδικασία τριών βημάτων, το καθένα απλό στον εαυτό του, αλλά που ξεχωρίζει τα διαφορετικά θέματα:
Αυτό είναι το υποθετικό μοντέλο, το οποίο θα πρέπει να παρομοιάζουν όλες οι σωστές υλοποιήσεις, ασχέτως της εσωτερικής τους υλοποίησης.
Εντάξει εντάξει, λογικό σχόλιο.
Στη θεωρία, οτιδήποτε έχει περιγραφτεί είναι έγκυρο σύμφωνα με την προδιαγραφή HTML4.0 (ή RFC2070). Δυστυχώς, η κάλυψη των χαρακτηριστικών από τους browsers είναι ακόμα αρκετά ανομοιογενής και είναι αρκετά δύσκολο για τον απλό χρήστη να πάρει οδηγίες για το πως θα πάρει οδηγίες για να ρυθμίσουν την πλατφόρμα και τα προγράμματα σωστά ωστε να πετύχουν αυτές τις δυνατότητες.
Ακόμα και αν χρησιμοποιείτε τις πιο συντηρητικές προσεγγίσεις για να εκμεταλλευτείτε την διεθνοποίηση, που θα περιγράψω αργότερα, συνεχίζετε να βρίσκεστε υπο το ρίσκο οτι μια σημαντική μερίδα αναγνωστών δεν θα μπορούν να διαβάσουν το κείμενο.
Νωρίς το 1998 είχα σχολιάσει εδώ πόσο θλιβερό ήταν το οτι συγγραφείς συνέχιζαν να καταφεύγουν σε κόλπα με το &#αριθμός; ή με το FONT FACE=Symbol, και να παίρνουν τα οπτικά αποτελέσματα που ήθελαν στους browsers της μαζικής αγοράς, αντί να γράφουν σωστή HTML4.0. Είναι όμως μάλλον αναμενόμενο οτι καθώς οι browsers σταδιακά υλοποιούν τις δημοσιευόμενες προδιαγραφές, κάποια από τα κόλπα έχουν σταματήσει, ή θα σταματήσουν, να παράγουν τα λανθασμένα (ή "επιθυμητά") αποτελέσματα. Και σας προειδοποιώ πάλι οτι τα κόλπα με fonts δεν θα περαστούν σωστά στα ευρετήρια από τα ρομπότ και μάλλον δεν θα χειριστούν σωστά από τους αναγνώστες αφής και τους browers ομιλίας: με άλλα λόγια, δίνουν την εμφάνιση οτι δουλεύουν ενώ είναι εντελώς σαθρά σε ένα πολύ πιο βασικό επίπεδο.
Η σύσταση αυτή προορίζεται αποκλειστικά στους συγγραφείς μιας Λατινικής διαλέκτου που μπορεί να θέλουν να περιλάβουν μικρά μέρη από άλλα κείμενα στα έγγραφά τους. Η προσέγγιση αυτή θα ήταν οπωσδήποτε ανεπαρκής σε μια μή Λατινική διάλεκτο, πχ. σε ένα Κυριλλικό έγγραφο οπου μπορεί να χρειάζεται να συμπεριληφθούν μικρά κομμάτια από Ελληνικό, Εβραικό, Γαλλικό ή κάποιο άλλο υλικό.
Για έγγραφα που είναι γραμμένα κυρίως σε λατινικά γράμματα και χρειάζονται κάποιες φορές λίγους μή-λατινικούς ή μαθηματικούς χαρακτήρες κλπ, αυτό είναι αρκετά εφικτό, αν και απαιτεί από τους χρήστες να ρυθμίσουν σωστά τους browsers τους:
Εξήγηση: Οι browsers της Netscape, ακόμα και στην έκδοση 4, δεν μπορούν να αποδώσουν τους περισσότερους χαρακτήρες του unicode αναφερόμενους ως &#αριθμός; εκτός και αν το αναγγελόμενο charset υποδηλώνει unicode. Σε ότι αφορά τις δημοσιευμένες προδιαγραφές φυσικά, αυτό είναι bug. Είναι πολύ χρήσιμο το γεγονός οτι το επτάμπιτο us-ascii είναι υποσύνολο του utf-8. Αυτό όμως σας υποχρεώνει να αναπαραστήσετε τους χαρακτήρες σε Latin-1 των 8 bit με τις δομές τύπου &, εκτός και αν γνωρίζετε πως να παράγετε σωστά κωδικοποιημένες ροές (πράγμα που βρίσκετε εκτός του εύρους αυτής της σημείωσης).
Το αποτέλεσμα μπορεί, με απόλυτη εντιμότητα και συμμόρφωση στα πρωτόκολλα, να δηλωθεί με οποιοδήποτε charset που περιλαμβάνει το us-ascii, όπως το ίδιο το us-ascii, το iso-8859-1 ή το utf-8. Είναι γεγονός το οτι αν δηλωθεί σαν utf-8, οι εκδόσεις 4.xx της Netscape είναι ικανές να το δείξουν σωστά, αλλά δυστυχώς αυτο προκαλεί ένα μικρό bug στον Internet Explorer 4, έναν browser που κατα τα άλλα υποστηρίζει το μέρος αυτό της προδιαγραφής αρκετά καλά. Το πρόβλημα επηρεάζει συνδέσμους που περιέχουν τον χαρακτήρα #, πχ. εσωτερικές συνδέσεις. Είναι λοιπόν μια σύμβαση: αν δηλώσετε συγκεκριμένα το utf-8, τότε οι εκδόσεις NS4.xx μπορούν να δουλέψουν χωρίς συγκεκριμένες πράξεις από το χρήστη, αλλά θα προκαλέσει πρόβλημα στον MSIE4· αν δεν δηλώσετε utf-8 τότε ο MSIE θα δουλέψει σωστά αλλά οι χρήστες του NS4.xx θα πρέπει να διαλέξουν View/ Character Set/ UTF-8 ωστέ να διαβάσουν το κείμενο.
Με κάθε τρόπο, έχουμε απόλυτα σωστή HTML4.0, αν και μάλλον κακοφτιαγμένη εξαιτίας της αναγκης να ξεπερνούμε αυτό το bug της Netscape· browsers όπως ο Alis Tango και πρόσφατες εκδόσεις του Lynx κ.α. είναι συμβατές με τα πρωτόκολλα και θα χειριστούν το θέμα αυτό σωστά.
Θα πρέπει επίσης να επιστήσω την προσοχή οτι μάλλον δεν θα ήταν ρεαλιστικό επι του παρόντος το να υποθέτουμε οτι ο χρήστης που χρησιμοποιεί αυτές τις εκδόσεις των browser θα μπορέσει τελικά να δεί το έγγραφο σωστά, περιλαμβάνοντας και Γιαπωνέζικους, Κυριλλικούς και άλλους χαρακτήρες που μπορεί να έχετε γράψει. Αν και οι πρόσφατες εκδόσεις των "Μεγάλων Δύο" browser είναι ικανές (εν μέσω των περιορισμών που συζητήσαμε εδώ) να δείχνουν αυτούς τους χαρακτήρες, δεν μπορούν να το κάνουν χωρίς τα κατάλληλα fonts και τις απαραίτητες ρυθμίσεις για να χρησιμοποιήσουν αυτά τα fonts. Συνεπώς, οι τεχνικές αυτές είναι μονο για το κοινό που θα κάνει τον κόπο να ρυθμίσει τον browser του. Μπορεί να επιθυμείτε να συμπεριλάβετε ένα μικρό τεστ (πχ. μια σειρά από σχετικούς χαρακτήρες ανιστοιχιζόμενες με την εικόνα της ίδιας σειράς) κάπου στις σελίδες σας εάν η σωστή εμφάνιση των συγκεκριμένων χαρακτήρων είναι απαραίτητη για το περιεχόμενο.
Οι συγγραφείς που ήδη χρησιμοποιούν ένα "εγγενές" σύστημα γραφής, π.χ. Κυριλλικά, Ελληνικά κλπ. σε έναν κατάλληλο 8-μπιτο κωδικό μάλλον γνωρίζουν ήδη οτι οι περισσότερες διαθέσιμες εκδόσεις των browser δεν μπορούν να παρουσιάσουν χαρακτήρες από άλλες κωδικοσελίδες την ίδια στιγμή. Αν τα έγγραφά τους περιλαμβάνουν μόνο το δικό τους σύστημα γραφής, τότε αυτό δεν είναι πρόβλημα, και σίγουρα υπάρχουν εκατομμύρια εγγράφων στον WWW ήδη με αυτήν την μορφή οπότε δεν χρειάζεται καμμιά αλλαγή αν τα έγγραφα συμβαδίζουν με την προδιαγραφή της HTML.
Θα πρέπει όμως να σημειώσουμε εδώ οτι μερικά παλαιά έγγραφα στον WWW βασίζονταν στο γεγονός οτι οι Λατινικές σημειώσεις τύπου &οντότητα; ή/και οι αναφορές τύπου &#αριθμός; στην έκταση 128-255, φαινόταν ωσάν να παρουσίαζαν τους επιθυμητούς χαρακτήρες (ίσως επιλέγοντας ένα συγκεκριμένο font, ή με το να αλλάζουν την κωδικοποίηση χαρακτήρων στον browser) σε πολλές παλιές εκδόσεις browser που προχρονολογούταν των προδιαγραφών διεθνοποίησης: τέτοια έγγραφα δεν είναι σωστή HTML και θα φανούν προβληματικά στους πρόσφατους browsers που ακολουθούν τις προδιαγραφές. Αν αυτά τα προβληματικά έγγραφα μετατραπούν σε 8-μπιτους χαρακτήρες, τότε θα είναι διαθέσιμα και στους δυο τύπους των browser.
Οι συμβουλές εδώ έχουν ενδιαφέρον μόνο αν θέλετε να ετοιμάσετε έγγραφα που χρειάζονται ένα εκτεταμένο ρεπερτόριο χαρακτήρων. Τέτοια έγγραφα είναι διαθέσιμα μόνο στους πρόσφατους browsers όταν είναι σωστά ρυθμισμένοι.
Εγώ ο ίδιος δεν δουλεύω σε περιβάλλον έξω από το Latin-1, οπότε αυτό που θα διαβάσετε εδώ είναι μάλλον από δεύτερο χέρι. Είναι ξεκάθαρο οτι αν βρίσκεστε σε περιοχή Κυριλλικών, Ελληνικών κλπ (ή Ιαπωνικών, Κινεζικών, Κορεατικών... με τα οποία έχω λίγη σχέση ή εμπειρία), δεν θα ήσασταν ευχαριστημένοι με το να γράφετε αναφορές &#bignumber; για την μητρική σας γλώσσα· θα προτιμούσατε να γράψετε με τις κανονικές ανέσεις του συγγραφικού συστήματός σας.
Στη θεωρία, μπορείτε να χρησιμοποιήσετε ένα οκτάμπιτο ρεπερτόριο (εκτός του Latin-1), όπως το Κυριλλικό ή όπως το Ελληνικό, μαζί με το Latin-1:
Δουλεύει αυτό; Και ναί και όχι. Τα charset όπως το iso-8859-7, το koi-8-r κα. υποστηρίζονταν από τους browsers για πολύ περισσότερο και σε πολύ μεγαλύτερη έκταση από το unicode, και αυτοί οι κωδικοί συμπεριλαμβάνουν το us-ascii (δηλαδή όλα τα μή τονισμένα λατινικά γράμματα), οπότε δεν υπάρχει πρόβλημα εδώ, τουλάχιστον σε σχετικά σε ότι αφορά την απεικόνιση εγγράφων HTML. (Υπάρχουν προβλήματα σε άλλες περιοχές, όπως η συμπλήρωση φορμών, μη-λατινικοί χαρακτήρες σε ιδιότητες ALT, τίτλοι κλπ.)
Όταν όμως προσπαθούμε να χρησιμοποιήσουμε το "πάνω μισό" του ρεπερτορίου Latin-1 όμως, τα πράγματα δεν είναι τόσο καλά. Υπάρχουν διαθέσιμες κάποιες παρατηρήσεις συμπεριφοράς των browser που αναφέρθηκαν ξεχωριστά.
Σύμφωνα με την προδιαγραφή HTML4.0, όταν χρησιμοποιείτε ένα charset που περιλαμβάνει μή λατινικούς χαρακτήρες μπορείτε να περιλάβετε τους τονισμένους χαρακτήρες του Latin-1 κλπ. με την χρήση των αναφορών &οντότητα; or &#αριθμός; και αυτό θα δουλέψει σε συμμορφωμένους με τα προτόκολα browsers όπως ο Alis Tango, ο Internet Eplorer 4 και οι τελευταίες εκδόσεις του Internet Explorer 3. Στις αρχικές εκδόσεις του Internet Explorer 3, μόνο η μορφή &entity; απεικονιζόταν σωστά. Οπότε η καλύτερη πιθανότητα επιτυχίας έρχεται από την χρήση της μορφής &οντότητα; στην περίπτωση αυτή - αλλά καμμια μορφή δεν δουλεύει σωστά στον Netscape γενικά. (Μήπως είναι καιρός για την Netscape να προφτάσει το Lynx στο θέμα αυτό;)
Αν θέλετε να χρησιμοποιήσετε ένα 8-μπιτο charset εκτός του Latin-1, τότε επί της παρούσας στιγμής η επικράτηση των χρηστών της Netscape προκαλεί δυστυχώς δυσκολίες όταν θέλετε να χρησιμοποιήσετε χαρακτήρες έξω από αυτό το ρεπερτόριο. Οι ακόλουθες προσεγγίσεις μπορούν να ζυγιστούν, βάσει του τι θέλετε να πετύχετε.
Η διαδικασία που περιέγραψα στην συντηρητική προσέγγιση είναι μάλλον απίθανο να αρέσει στους συγγραφείς των μη λατινικών αλφαβήτων, αφού η &-σημειογραφία για οποιονδήποτε μη 7-μπιτο χαρακτήρα ASCII θα προκαλέσει αφόρητο φούσκωμα στο έγγραφο. Θα μπορούσε όμως να χρησιμοποιηθεί για συγγραφείς των Λατινικών διαλέκτων που θα μπορούσαν να μετατρέψουν με προγραμματισμό τα τονισμένα γράμματα κλπ. σε &-σημειογραφία.
Πέρα από αυτό, πάντως, αν χρειάζεστε ένα πλατύ ρεπερτόριο χαρακτήρων έξω από τους περιορισμούς της 8-μπιτης κωδικοποίησης που ταιριάζει στη διάλεκτό σας, φαίνεται οτι το έγγραφο θα πρέπει να σταλεί στο δίκτυο σε τύπο utf-8 ωστε να γίνει προσβάσιμο στους browsers που χρησιμοποιούν οι χρήστες.
Μπορείτε επίσης να θέλετε να γράψετε τα κείμενά σας σε 8-μπιτο σετ που αντιστοιχεί στη διάλεκτό σας με την εισαγωγή &-σημειογραφίας για τους χαρακτήρες έξω από το σετ. Ένα τέτοιο έγγραφο είναι απόλυτα έγκυρη HTML (αν σταλεί με τον κατάλληλο κωδικό για charset), ακόμα και αν δεν υποστηρίζεται από το Netscape. Συνεπώς, αφού είναι έγκυρο μπορείτε να το επεξεργαστείτε τέλεια με τα διαθέσιμα προγράμματα: δυο απο αυτά περιγράφονται στην σελίδα με τεχνικές, αλλά μπορεί να έχετε ήδη πρόσβαση σε κατάλληλα προγράμματα μετατροπής κωδικών χαρακτήρων.
Δείτε τη σημείωση για τους παλαιούς browsers.
Υπάρχουν μερικές τεχνικές που συζητώνται σε ξεχωριστή σελίδα.
Λοιπόν, θα πρέπει πρώτα να εξηγήσω οτι τα Win95 έχουν υποστήριξη για unicode (σε fonts κα.) προς χρήση από εφαρμογές, ακόμα και αν το λειτουργικό σύστημα δεν "δουλεύει" σε unicode. Αλλά αυτό δεν έχει σημασία.
Ο browser Alis Tango υποστηρίζει το RFC2070 κάτω από Windows 3.1 και μεταγενέστερα σε ένα PC 386 με 8MB μνήμης εδώ και αρκετό καιρό. Σε κάθε περίπτωση, ένας σωστά υλοποιημένος browser μπορεί να έχει ένα εκτεταμένο ρεπερτόριο χρησιμοποιώντας 8-μπιτα fonts, δεν χρειάζεται να χρησιμοποιήσει ένα font τύπου unicode.
Ο Internet Explorer 3 (εκτός από τις αρχικές εκδόσεις), ακόμα και στην 16-μπιτη έκδοση, υποστηρίζει άνετα πολλές 8-μπιτες κωδικοποιήσεις που είναι σε συνδυασμό με το Latin-1, τουλάχιστον. Για παράδειγμα, όταν βλέπω τον πίνακα τεσταρίσματος του koi8-r, ο browser πολύ απλά χρησιμοποιεί το font "ER Bukinist 1251", σαν πηγή Κυριλλικών χαρακτήρων και κάποιο άλλο font για τους τονισμένους λατινικούς χαρακτήρες κλπ.
Όταν τα Win95 εγκαθίστανται, υπάρχει μια επιλογή για την χρήση υποστήριξης διεθνών fonts: θα πρέπει να την επιλέξετε κατά την εγκατάσταση. Ο 32-μπιτος Internet Explorer 4 κάτω από Win95 με μεγάλη άνεση απεικονίζει χαρακτήρες μορφής θ (Θήτα), ‰ (permille) κλπ. σε ένα έγγραφο που έχει σταλεί με κωδικοποίηση διαφορετικά από την Latin-1 (δοκίμασα την koi8-r για παράδειγμα).
Ο IE5 πάει ακόμα πιο μπροστά, εγκαθιστώντας υποστήριξη γλώσσας[4] επιλεκτικά, και όταν συναντά ένα έγγραφο με σύστημα γραφής που δεν έχετε εγκαταστήσει ακόμα, σας προειδοποιεί, και προσφέρεται να κατεβάσει και να εγκαταστήσει τα απαραίτητα συστατικά.
Το μεγάλο πρόβλημα, φοβάμαι, είναι η Netscape που μπορεί να πειστεί σε μια κατα κάποιο τρόπο σωστή λειτουργία αν το σετ χαρακτήρων υποδηλώνει unicode.
Δεν υπάρχει λοιπόν αντίρρηση οτι υπάρχουν ακόμα κάποια πραγματικά προβλήματα ενάντια της χρήσης αυτής της μεθόδου στον WWW, εκτός από ένα ειδικευμένο κοινό που μπορεί να αναμένεται να έχει το κίνητρο να πάρει έναν κατάλληλο browser. Είναι όμως λάθος το να πιστεύουμε οτι η έλλειψη υποστήριξης unicode στα Win95 και στα Win3.x είναι ένα ανυπέρβλητο μέρος του προβλήματος.
Αυτός ο συχνά ζητούμενος τύπος ερωτήσεων δεν έχει απλή λύση, φοβάμαι. Όπως έχει εξηγηθεί, η HTML4.0 επέλεξε να παρουσιάζει χαρακτήρες μέσω του στάνταρ Unicode. Εν ολίγοις, αν οι χαρακτήρες που θέλετε υπάρχουν στο Unicode, τότε έτσι θα πρέπει να τους παρουσιάσετε· αν δεν υπάρχουν τότε δεν μπορείτε να τους παρουσιάστε με κανένα τρόπο στην στάνταρ HTML. Ακόμα και αν μπορέσετε να τους παρουσιάσετε, δεν υπάρχει εγγύηση οτι οι αναγνώστες θα έχουν browsers που υποστηρίζουν αυτό το συγκεκριμένο μέρος του ρεπερτορίου Unicode.
Σίγουρα, θα πείτε "έχω ένα font για αυτό το σύστημα γραφής και θέλω να το χρησιμοποιήσω". Και πράγματι, σε παλαιούς browsers αυτό "δούλευε" χωρίς προβλήματα: παραδίνατε το έγγραφο με μερικούς χαρακτήρες σε Latin-1, καθορίζατε το ειδικό font σας και όλοι οι χαρακτήρες που θέλατε παρουσιαζόταν στην οθόνη. Φαινόταν οτι όλα δούλευαν "κατ ευχήν"· αλλά φοβάμαι οτι δεν δούλευαν όπως "είχαν σχεδιαστεί". Είναι γεγονός οτι μπορείτε να συνεχίσετε να παίζετε αυτά τα παιχνίδια με τα fonts σε κάποια έκταση, αν και δεν είναι εγγυημένα οτι θα δουλέψουν. Μπορεί να υπάρχουν προβλήματα σε άλλες πλατφόρμες (πράγμα που η HTML4.0 προσπαθεί να αποφύγει), και να περιμένετε οτι θα δουλεύουν όλο και λιγότερο καθώς οι browsers αναπτύσσονται προς την συμμόρφωση με τις δημοσιευμένες προδιαγραφές. Μπορεί να φαίνεται σκληρό για κάποιον που έχει μια ουσιαστική απαίτηση για ένα ειδικευμένο σύστημα γραφής που δεν έχει εισαχθεί στο Unicode, ή που δεν υποστηρίζεται από τους διαθέσιμους browsers. Αλλά φοβάμαι οτι έτσι έχει το πράγμα. Υπάρχει μια ξεχωριστή σελίδα σχετικά με το FONT FACE που μπορεί να ρίξει λίγο φώς.
1. Το koi8-r είναι ένα παράδειγμα ένος πολυ-χρησιμοποιημένου 8-μπιτου κωδικού που, αντίθετα με τις σειρές iso-8859-n, κατατάσσει εκτυπώσιμους χαρακτήρες στην περιοχή δεκαδικών 128-159. Αντίθετα από τον κωδικό windows-1252, το άνω μισό διαφέρει αρκετά από τον κωδικό iso-8859-1 που περιγράφεται στην HTML2.0. Για τους δυο αυτούς λόγους, αποτελεί ενα καλό πρώτο παράδειγμα στην επισκόπηση μας. Ακόμα καλύτερα, περιλαμβάνει κάποιους χαρακτήρες από το Latin-1 (copyright, εις το τετράγωνο, κενό που δεν κόβεται κλπ) σε εντελώς διαφορετικές περιοχές κωδικών από τις σειρές iso-8859-x, οπότε είναι από κάθε άποψη ένας χαμός όταν οι σχεδιαστές των browser δεν έχουν κάνει καλά τη δουλειά τους.
2. Η εκμάθηση του πως δουλεύει ο κωδικός utf-8 είναι αρκετά ευθύς αλλα μάλλον λεπτή. Δεν επιθυμώ να την καλύψω εδώ, εφόσον χρησιμοποιώ τη δικιά σας θεώρηση οτι αν τα συγγραφικά εργαλεία δεν το υποστηρίζουν διαφανώς για εσάς, τότε μάλλον δεν θα θέλετε να το δημιουργήσετε από μόνοι σας. Φυσικά μπορείτε να δοκιμάσετε αν θέλετε, οπότε μη με αφήσετε να σας αποθαρρύνω. Απλως δεν νομίζω οτι είναι χρήσιμο να το συμπεριλάβω εδώ εκτός από το οτι είναι ένα πολύ χρήσιμο χαρακτηριστικό του οποίου το 7-μπιτο us-ascii είναι ένα υποσύνολο του utf-8.
3. Χρησιμοποιώντας ένα μη λατινικό ρεπερτόριο σε συνδυασμό με το us-ascii και μόνο, δουλεύει με τους browsers εδώ και αρκετό καιρό αφού δεν απαιτεί τίποτα περισσότερο από ένα font κατάλληλο για το επιλεγμένο 8-μπιτο ρεπερτόριο. Πραγματικά, οι αρχικοί browsers που δεν μπορούσαν ούτε να υποστηρίξουν το στοιχείο "charset", ήταν ικανοί να χρησιμοποιηθούν για ανάγνωση Κυριλλικών ή Ελληνικών κειμένων ή άλλων 8-μπιτων κωδικων με το απλό στρατήγημα της ρύθμισης του browser για να χρησιμοποιήσει ένα κατάλληλο font (παράδειγμα: το ER Bukinist KOI8-R για τον κωδικό koi8-r). Οι παλαιές αυτές εκδόσεις όμως δεν έκαναν διαφοροποίηση μεταξύ της κωδικοποίησης του κειμένου και του σετ χαρακτήρων της HTML, και αν τους ζητιόταν να παρουσιάσουν πχ. την ñ ή το ñ (δες τα παραπάνω παραδείγματα) θα παρουσίαζαν το YA (koi8-r) ή το ρο (iso-8859-7) κλπ. αντί για την n-tilde που απαιτεί το στάνταρ της διεθνοποίησης. Δυστυχώς θα βρείτε παλαιά έγγραφα HTML που υποθέτουν οτι αυτή είναι η σωστή συμπεριφορά και περιλαμβάνουν &-σημειογραφία με το σκοπό την εμφάνιση μη-λατινικών χαρακτήρων, που είναι μεγάλο λάθος και δεν θα παράγει τα επιθυμητά αποτελέσματα στους συμμορφωμένους με τις προδιαγραφές browsers.
4. Η Microsoft αναφέρεται στην υποστήριξη μη λατινικών συστημάτων γραφής σαν υποστήριξη "γλώσσας". Όπως σημείωσα πριν: Σε ορολογία HTML, αυτό δεν είναι πραγματικά σωστό, τα δύο θέματα είναι ανεξάρτητα σε ότι αφορά την HTML.
Τελευταία μεταβολή, Παρασκευή, 03-Απρ-1999 15:48:30 GMT
Γνήσιο υλικό © Copyright 1994 - 1999 Α.Τζ. Φλάβελλ & Πανεπιστήμιο της Γλασκόβης
Μετάφραση από τον Πάνο Στόκα <>