ПредишенСледващото

За технически подробности може да се направи, за да RFC 3629 (STD 63) и стандарта Unicode (Sec. 3.9). И няма да има реч за практическата страна на използване на UTF-8.

Погледнете в "Таблица на знаците" на вашия компютър. В UTF-8 кодиране, можете да вземете директно от масата всеки символ и го поставете директно в документа. Ако имате нужда от авторско право, или степента на интеграл - няма нужда да търсите за определен шрифт, да представлява този знак в графичен формат, или дори да измислят някои трикове. В UTF-8 кодиране на всеки символ, независимо дали това е една малка част ⅓ или китайски йероглиф, можете да използвате документа по същия начин, както на латинската буква "А", руската "Y" или знак "+".

Имало едно време, уеб разработчици са били принудени да използват такива обемисти заместители, тъй като UTF-8 все още не съществува. Но сега можете да забравите за двете замяната и за старата кодиране.

Обсъждане на предимствата на UTF-8, би било необходимо да се говори за недостатъците на кодирането. А недостатъци, представете си, че не са. Има само митове и легенди, както и слухове и спекулации, които се разпространиха мъхести консерватори и реакционери хавлиени. Преди много години, някои от недостатъците е наистина случило, но сега те са потънали в забвение.


Браузъри лоша поддръжка UTF-8?

Те казват, че някои хора все още са монтирани по-стари браузъри, които не са в състояние да показва страниците в UTF-8. Това е пълна глупост. Дори и Internet Explorer 4 и Netscape 4, която от дълго време е никой не го използва, разбира UTF-8. А по-модерни браузъри - и още повече.

UTF-8 - не е "новоизлюпена" или "млад" кодиране, тя е била използвана успешно в продължение на повече от десет години. Ако един разработчик е научил за него напоследък, или не знаете до сега - е неговата липса на квалификация, а не за кодиране.


С UTF-8, има проблеми на уеб сървъра?

"Сложих на страницата на сървър, за да UTF-8, както е изписано krakozyabrami" - така че понякога се оплакват начинаещите програмисти. В действителност, този проблем се среща с различни кодировки и не е свързана с някои специфични характеристики на UTF-8. Тук проблемът е, че страницата е направена в един кодиране и HTTP хедъри сървърът съобщава на другата. Необходимо е да конфигурирате сървъра за да бъдат приведени в съответствие с действителното кодиране на уеб страници. Отново, това трябва да се прави с всеки кодиране.


Файловете в UTF-8 заемат много място?

Говори се, че документите в UTF-8 са два пъти повече, отколкото в старите кодировки. Мит е от категорията на "чух звънец, но не знам къде е." В действителност - само по време не е необходимо. Например, ако документът съдържа само ASCII символи (букви, цифри, препинателни знаци и др ...) - в UTF-8 ще отнеме точно същото количество байтове, както във всяка друга. Ако документът съдържа само букви от българската азбука и всякакви други знаци (че ще се съгласите, че е доста рядко) - тогава в UTF-8, това наистина ще бъде два пъти по-голяма. И ако, например, също толкова български и арабски букви - в UTF-8, той ще бъде два пъти по-малко, отколкото, например, в Windows-1251 или Asmo-708.

На същата страница четете в момента, в UTF-8 заема 35 килобайта. И ако го преведе, например, в Windows-1251, той ще заема 26 килобайта (виж за себе си). Между другото, сравнявайки страницата, погледнете колко по-лесно да се чете кода в UTF-8.

Тези, които се грижат за "тегло" трябва да бъде на първо място да се пусне на остарял код атрибути HTML (като cellpadding или valign) и заместващи символи за тези, които не се нуждаят от тях (например, — за дълго тире или   за непрекъсваем интервал). Наистина, понякога става въпрос за сенилност - един почива: "Аз няма да направи страници в UTF-8, тъй като те са от това увеличение," - и по този начин той извайва код ужасни атрибути и замествания, които без тях ще бъде пет пъти по-кратък ,


програмни езици и сървъри на база данни лоша поддръжка UTF-8?

Някой ще каже: "Всичко е наред, толкова дълго, колкото ние се занимаваме с статични уеб страници. Но ако използваме PHP и MySQL, за UTF-8 е по-добре да се забрави. " Това не е вярно. В древни времена, в действителност, някои програмни езици и системи за управление на база данни, не са били в състояние да работи с UTF-8. Но сега всички съвременни езици за програмиране и бази данни са в отлични отношения с това кодиране. А unmodern езици и бази данни да се използват не членóIT: по-старата система, толкова по-лесно е да ги счупи.

На моя личен уеб сайт, можете да видите резултатите от работната програма в PHP 4, който пренася такива думи. Отнема като вход текста в UTF-8 и произвежда един и същ текст в UTF-8, но с преводите. Между другото, източник самия кодóтата програма също е представена в UTF-8.

Все още мога да се демонстрира любител скрипт в Perl, който брои броя на вертикалните линии в буквите на текста. Стартиране на този сценарий, той е като параметър следва да бъдат прехвърлени в текстов файл в UTF-8, например: palki.pl file.txt. Отново, на самия скрипт също е представена в UTF-8.

Единственият проблем с програмата-сървър - е, че много от тях са конфигуриран по подразбиране да не UTF-8 и други кодировки. Ами преконфигурира; ние сме с вас малки деца до навсякъде просто използвайте настройките по подразбиране.


Търсачките не работят добре с UTF-8?

Повече чуваме, ако търсачките "спънат" на UTF-8. Тази информация, отново, остаряла възраст от осем. Тук имате, например, търсачката "Яндекс":

Уверете се, че то е перфектно да намеря нищо на моя личен сайт, където, наред с други неща, работата му е "трудно" не само UTF-8, но също така се измества с думи.

Така, че няма противопоказания за широко използване на UTF-8. Тези, които вярват по различен начин, просто зад пъти.


Когато UTF-8, не е необходимо да се използва

Разбира се, има моменти, когато най-добрият UTF-8 кодиране да се използва все още нежелателно. Въпреки, че това не е ситуацията, която плаши последователи vysherazvenchannyh митове.

На първо място, понякога ние не трябва да създадете нов документ и да прави промени в съществуващ. Обикновено в такива случаи няма смисъл да я превърне в съществуващия документ в кодирането на UTF-8, така че трябва да го редактирате в кодирането, в която е представена.

На второ място, понякога на мястото на работа, предвижда ядро ​​софтуер (така наречената "двигател"), който не може да работи с UTF-8. В такава ситуация, разбира се, трябва да се помисли дали има възможност да се коригира "двигател" или да го замени с друг. Но това не винаги е възможно. Някои софтуер осигурява основната функционалност на достойнство, за които можете да се примири с остаряла кодиране.

Надявам се, че по-нататъшни указания ще бъде полезно, когато се работи с UTF-8.

Байт Поръчка Mark (BOM) - трите въздушни байта автоматично се записват в началото на документа и да показват, че той се записва в UTF кодиране. Подробности могат да бъдат намерени в указателя, но практическата страна е, че режийните байта в UTF-8 не са необходими, но, напротив, може да заблуди някои по-стари браузъри и други програми.


Се създаде прост клавиши за бърз достъп за специални символи

Разбира се, когато имам нужда от рядко се използва символ - буквата "ръка" или емотикон характер - имам предвид на "Таблица на знаците".
Определя характера когато това се налага

Уверете се, че уеб сървър, казва правилното кодиране страници. Ако не - се свържете с администратора на сървъра или да чете основния материал за това как да промените настройките за кодиране.

Има хостинг услуги (хостинг), които "здраво прикрепени" и да е кодиране и не позволяват на собствениците на уеб сайтове да използват други кодировки. С такива хостинги не се свързват Artóхм. Какво кодиране направи страници - да се реши на разработчика на сайта, а не обслужва местоположението му.

В HTML код, той често има смисъл да се използва мета елемент:

Има различни мнения за използването на мета да определите кодирането. Веднъж си помисли, че този елемент е по-вредни от полза. Въпреки това, редица изследвания и личен опит ме накара да преразгледа своята позиция. Или да не прилага мета - трябва да се разглеждат отделно за всеки конкретен обект.

Каквото и кодиране можете да използвате, е необходимо да се помни, че браузъри показват само тези символи, които са в шрифтовете, инсталирани на вашия компютър. "Знаците" показва точно тях. Списък на стандартните Windows шрифтове, поставени в раздел "Справки".

В Unicode, можете да намерите много други знаци - руни, като например, буквите на глаголицата, разнообразие от икони и пиктограми. Но за да ги вмъкнете в документа няма да работи: по-голямата част от потребителите не разполагат с шрифта, в който да представи тези герои. Има дори UTF-8, за всички свои качества, не можем да помогнем. Ние трябва да се пускат такива символи като растерни изображения (както е направено тук), или да се търсят други заобиколни.

Много други "екзотични" герои обикновено са на разположение на компютрите на потребителите, но браузърът трябва да помогне да се намери правилният шрифт. Например, за да се покажат славянските букви или математически символи (∀ и т.н.) - Позовавам се на CSS шрифт на «Светъл Sans Unicode».

Един от малкото митове в полза на UTF-8 кодиране каза, че това, компютърът ще покаже тези герои, които са недостижим в някоя от старите кодиране. Но чудеса не се случват: ако не разполагате с шрифта на вашия компютър, в който требъл Clef присъства - вие няма да видите този символ в UTF-8 със същия успех, както във всяка друга кодиране.

Основното предимство на UTF-8 - не е магическа разширен набор от символи, както и лесен начин за тяхното включване в документа.

Ако не сте запознати с Unicode, тогава може би сте любопитни защо предлагам е UTF-8, но не и други модерни кодиране - например, UTF-16 или UTF-32. Отговорът е: те предоставят същите важните предимства като UTF-8, но има редица недостатъци. На първо място, те са, за разлика от UTF-8 е наистина значително да увеличи "теглото" на файла. На второ място, с тях, а в някои браузъри, използвани понастоящем все още има проблеми.

Между другото, консорциума W3C препоръчва да използвате за вашия уеб страници е UTF-8.

Но не забравяйте, че светът се променя непрекъснато. Може би някаква причина в бъдеще, което ще ни принуди да се откаже от UTF-8 и отидете на някои много по-напреднали кодиране. Когато това се случи, аз ще ви уведомим.

Подкрепете проекта - споделете линка, благодаря!