Яка перевага вибору кодування ASCII над UTF-8?

Усі символи в ASCII можна кодувати за допомогою UTF-8 без збільшення сховища (для обох потрібен байт сховища).

UTF-8 має додаткову перевагу підтримки символів, що перевищує "ASCII-символи". Якщо це так, то чому ми колись обиратимемо кодування ASCII через UTF-8?

Чи є випадок використання, коли ми виберемо ASCII замість UTF-8?

У деяких випадках це може прискорити доступ до окремих персонажів. Уявіть рядок, str='ABC'закодований в UTF8 та ASCII (та припускаючи, що мова / компілятор / база даних знає про кодування)

Для доступу до третього Cсимволу ( ) з цієї рядки за допомогою оператора доступу до масиву, який представлений багатьма мовами програмування, ви б зробили щось подібне c = str[2].

Тепер, якщо рядок кодується ASCII, все, що нам потрібно зробити, - це отримати третій байт з рядка.

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

Це питання, наприклад, у деяких двигунах баз даних, де знайти початок стовпця, розміщеного "після" VARCHAR, що кодується UTF-8, базі даних не потрібно лише перевіряти кількість символів у полі VARCHAR, але і як багато байтів, які використовує кожен з них.

Якщо ви збираєтесь використовувати лише підмножину US-ASCII (або ISO 646) UTF-8, то немає реальної переваги тому чи іншому; насправді все закодовано однаково.

Якщо ви збираєтеся вийти за межі набору символів US-ASCII та використовувати (наприклад) символи з наголосами, умлаутами тощо, які використовуються в типових західноєвропейських мовах, то є різниця - більшість із них все ще можуть повинні бути закодовані одним байтом в ISO 8859, але при кодуванні в UTF-8 знадобиться два або більше байти. Звичайно, є і недоліки: ISO 8859 вимагає використання деяких позадіапазонних засобів, щоб вказати кодування, яке використовується, і воно підтримує лише одинцих мов одночасно. Наприклад, ви можете кодувати всі символи кириличного (російського, білоруського тощо) алфавіту, використовуючи лише один байт за штуку, але якщо вам потрібно / хочете змішати їх з французькими чи іспанськими символами (крім тих, що є в US-ASCII / Підмножина ISO 646) вам майже не пощастило - для цього вам доведеться повністю змінити набори символів.

ISO 8859 дійсно корисний лише для європейських алфавітів. Щоб підтримувати більшість алфавітів, які використовуються в більшості китайських, японських, корейських, арабських тощо, алфавітів, ви повинні використовувати деякі зовсім інші кодування. Деякі з них (наприклад, JIS Shift для японців) є абсолютним болем для боротьби. Якщо є якийсь шанс, що ви коли-небудь захочете їх підтримати, я вважаю, що варто використовувати Unicode на всякий випадок.

ANSI може бути багатьма речами, в основному це 8-бітові набори символів (наприклад, сторінка коду 1252 в Windows).

Можливо, ви думали про ASCII, який є 7-бітним і належним підмножиною UTF-8. Тобто будь-який дійсний потік ASCII також є дійсним потоком UTF-8.

Якщо ви думали про 8-бітові набори символів, однією з дуже важливих переваг було б те, що всі представлені символи є точно 8-бітними, де в UTF-8 їх може бути до 24 біт.

Так, все ж є випадки використання, коли ASCII має сенс: формати файлів та мережеві протоколи . Зокрема, для використання, де:

• У вас є дані, які генеруються та споживаються комп'ютерними програмами, ніколи не представлені кінцевим користувачам;
• Але які корисні для програмістів вміння читати, для зручності розробки та налагодження.

Використовуючи ASCII в якості кодування, ви уникаєте складності багатобайтового кодування, зберігаючи принаймні деяку читабельність людини.

Кілька прикладів:

• HTTP - це мережевий протокол, визначений через послідовності октетів, але дуже корисно (принаймні, для англомовних програмістів), що вони відповідають кодуванню ASCII таких слів, як "GET", "POST", "Accept-Language" та так далі.
• Ці типи порцій в форматі PNG зображень складаються з чотирьох октетів, але це зручно , якщо ви програмуєте кодер PNG або декодер , який IDATозначає «дані зображення», а PLTEзначить «палітра».

Звичайно, ви повинні бути обережними, що дані дійсно не будуть представлені кінцевим користувачам, тому що якщо вони виявляться видимими (як це було у випадку з URL-адресами), то користувачі справедливо очікують, що ці дані будуть мовою, яку вони можуть читати.

Перш за все: у вашому заголовку використовується / d ANSI, тоді як у тексті ви посилаєтесь на ASCII. Зверніть увагу, що ANSI не дорівнює ASCII. ANSI включає в себе набір ASCII. Але набір ASCII обмежений першими 128 числовими значеннями (0 - 127).

Якщо всі ваші дані обмежені ASCII (7-бітними), не має значення, чи використовуєте ви UTF-8, ANSI або ASCII, оскільки і ANSI, і UTF-8 містять повний набір ASCII. Іншими словами: числові значення від 0 до 127 включають абсолютно однакові символи в ASCII, ANSI та UTF-8.

Якщо вам потрібні символи поза набором ASCII, вам потрібно вибрати кодування. Ви можете використовувати ANSI, але тоді ви стикаєтеся з проблемами всіх різних сторінок коду. Створіть файл на машині A і прочитайте його на машині B, можливо, / буде створювати кумедні тексти, якщо ці машини створені для використання різних сторінок коду, просто, оскільки числове значення nnn являє собою символи різниці на цих кодових сторінках.

Цей "код кодової сторінки" є причиною визначення стандарту Unicode . UTF-8 - це лише одне кодування цього стандарту, їх набагато більше. UTF-16 є найбільш розповсюдженим, оскільки це кодування для Windows.

Отже, якщо вам потрібно підтримати що-небудь понад 128 символів набору ASCII, моя порада - перейти з UTF-8 . Таким чином це не має значення, і вам не потрібно турбуватися про те, на яку кодову сторінку ваші користувачі налаштували свої системи.