Чи має бути кодування символів, крім UTF-8 (а може бути, UTF-16 / UTF-32)?

Моє домашнє тварина переглядає стільки програмних проектів, які мають гори коду для підтримки набору символів. Не зрозумійте мене неправильно, я весь за сумісність, і я радий, що текстові редактори дозволяють відкривати та зберігати файли в декількох наборах символів. Мене дратує те, як розповсюдження не універсальних кодувань символів позначається "належною підтримкою Unicode", а не "проблемою".

Наприклад, дозвольте мені вибрати PostgreSQL та підтримку його набору символів . PostgreSQL має справу з двома типами кодування:

• Кодування клієнта: використовується в спілкуванні між клієнтом і сервером.
• Кодування сервера: використовується для внутрішнього зберігання тексту в базі даних.

Я можу зрозуміти, чому добре підтримувати багато кодувань клієнтів. Це дозволяє клієнтам, які не працюють в UTF-8, спілкуватися з PostgreSQL, не потребуючи перетворення. Що я не отримую: чому PostgreSQL підтримує кілька кодувань сервера ? Файли баз даних (майже завжди) несумісні з однієї версії PostgreSQL до наступної, тому сумісність між версіями тут не є проблемою.

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

Я вважаю, що всі не універсальні набори символів повинні бути застарілими. Чи є якась вагома причина, чому вони не повинні?

Оскільки ви згадали про PostgreSQL, я можу сказати з деяким авторитетом, що головна причина вбивства, чому кодування на стороні сервера, які не UTF8 підтримуються настільки детально, полягає в тому, що японцям це потрібно. Мабуть, ідентичне перетворення в обидва кінці між Unicode та різними японськими «застарілими» кодуваннями не завжди можливо, і в деяких випадках таблиці конверсій навіть відрізняються між постачальниками. Це насправді збиває з пантелику, але, мабуть, так. (Широка підтримка набору символів також є однією з причин, чому PostgreSQL настільки популярний в Японії.)

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

Деякі інші причини, згадані в інших відповідях, також застосовуються в якості підтверджуючих аргументів. Але поки японці наклали вето, підтримку налаштування символів не можна зменшити.

Дві очевидні причини: залежно від даних, які ви зберігаєте, перетворення в інший формат може зайняти небагато часу та додаткового місця. Якщо ви зберігаєте 400 мегабайт інформації, подвоєння потреб у пам’яті не є великою справою - але якщо ви зберігаєте 400 терабайт, це починає означати трохи більше. Перетворення 400 терабайт даних з (скажімо) Shift-JIS в UTF-x також може зайняти трохи часу.

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

Якщо ви починали з бази даних, яка (наприклад) підтримує лише ASCII, можливо, буде вагома причина для дискусії про те, чи є сенс додавати підтримку для всіх цих кодувань - але якщо ви вже підтримуєте їх, від випадання мало що виграти підтримка для них.

Зауважте, зокрема, що ви, мабуть, отримаєте майже нічого на шляху спрощення коду чи чогось подібного. Вони все одно потребуватимуть всіх процедур перетворення, щоб у будь-якому разі вирішувати конверсії між клієнтом та сервером. Таким чином, відмова від підтримки означатиме відмову від одного (другорядного) виклику функції на шляху "запису на диск" та "читання з диска", але мало (якщо нічого іншого). Якби ви підтримували навіть два кодування на диску, ви навіть не отримали цього - у вас все одно буде функціонувати виклик там, тому все, що ви дійсно зробили б, було б обмеження кола кодувань, підтримуваних цією функцією.

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

Існує кілька проблем із збереженням UTF-8 на сервері:

1. Яка межа VARCHAR(20)стовпця? Це 20 байт чи 20 "символів" (а в Unicode, що таке "символ", якщо брати до уваги поєднання символів, лігатур тощо)? Гірше, що ж CHAR(20)де насправді потрібно резервувати весь можливий простір: я вірю в MySQL, він резервує 4-кратну кількість байтів для стовпчиків, кодованих UTF-8 (тобто 80 байт за CHAR(20)), просто для обробки найгіршого випадку.
2. Вам потрібно здійснювати постійні перетворення кодування між кодуванням сервера та кодуванням вашого клієнта. Ви можете стверджувати, що ви також хочете припинити підтримку декількох кодування клієнтів, але якщо ви цього не зробите, то всі рядки потрібно постійно конвертувати. Якщо ви можете зіставити кодування вашого сервера та кодування клієнта, конверсії не потрібні.
3. Як зазначають інші, UTF-8 є досить ефективним для зберігання англійського тексту, але він дуже неефективний для інших мов - зокрема східноазіатських мов. Ви можете дозволити використовувати UTF-16 або UTF-8 як костюми, я думаю. Або стискати текст, але це робить індексацію та пошук неефективними.

Сказавши все це, я згоден з вами: застарілі кодування здебільшого безглузді, а Unicode - це, як правило, найкраще кодування для всіх нових програм. Якби я сьогодні писав сервер бази даних з нуля, я б підтримував тільки Unicode і взагалі не підтримував би застаріле кодування.

Різниця полягає в тому, що PostgreSQL та більшість інших серверів баз даних, які використовуються сьогодні, існували раніше, ніж Unicode був життєздатним варіантом. Тож у них вже була підтримка застарілих кодувань (вони, звичайно, не були тоді, як наслідок) і просто не так багато сенсу виривати весь цей код з значних ідеологічних причин.

Універсальні (а саме однобайтові) кодування мають своє місце: У системах, які:

• Не вистачає пам'яті, щоб зберігати базу даних символів Unicode.
• Мати однобайтовий шрифт, жорстко закодований в ПЗУ.
• Не майте доступу до Інтернету, щоб забезпечити джерело файлів, кодованих різним чином.

Це актуально сьогодні для деяких типів вбудованих пристроїв. Але на робочому столі, так і в серверній кімнаті, кодування без Unicode має бути давно застарілим тепер.

UTF-8 - найкращий для вас егоцентричний ¹ динамік англійської мови. Якби ви були японцями, приблизно 99% ваших персонажів брали б 3-4 байти замість двох в UTF-16.

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

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

_{1. Не сприймайте егоцентричну участь особисто. Мені хотілося зробити барвисту ілюстрацію, і я цього не маю на увазі.}

Юнікод принципово порушений і навряд чи коли-небудь буде виправлений. Його потрібно замінити чимось кращим, чимось справді універсальним. Якщо що-небудь потребує депресії, це Unicode.

Приклади проблем із програмою Unicide:

• UTF8 - це розумний злом, але більшість програм на базі UTF16 зламана. Більшість програм Windows, які підтримують Unicode, використовують UTF16, включаючи саму ОС. Найпоширеніша проблема - це не підтримка більше, ніж основна площина, тобто багатослівні символи.

• Об’єднання Хань - це незручне лихо. Неможливо змішати японський / китайський / корейський текст в одному документі без зайвих метаданих, і важко визначити, який шрифт слід використовувати.

• Комбінаційні персонажі - ще одна катастрофа. Більш розумні схеми кодування відображають один символ на один код, що робить обробку рядків відносно здоровими. Unicode не робить. Unicode навіть не є послідовним - Хан символи - це переважно комбінації, але не кодуються як такі, де є європейські комбінаційні символи.

• Імена деяких людей не можуть бути записані правильно в Unicode, або вони дуже схильні до неправильного відображення через вищезазначені проблеми. Це може мати серйозні наслідки, наприклад, при спробі сісти на літак з паспортом, який не відповідає тому, що (неправильно) надруковано в квитку.

Через ці проблеми та багато іншого, багато програм, які не є англійською мовою, не можуть використовувати Unicode і покладаються на локальні кодування символів. Особливо це стосується японського та китайського програмного забезпечення.

В ідеалі Unicode слід застаріти. Кодування символів TRON є досить хорошою заміною для Unicode і значною мірою сумісно для існуючого програмного забезпечення, яке не оновлюється.

Можливо, для письма, але не для читання.

Існує багато існуючого вмісту, який використовує ці кодування, а деякі кодування, такі як base64, нікуди не діваються, оскільки деякі текстові протоколи наказують їм як способи вбудовування двійкових даних.

Справжньою проблемою є автоматичне виявлення кодувань, що призводить до захисту дірок. Я б не проти бачити, як деякі незрозумілі кодування, такі як UTF-7, просто зникають.

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

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

• Якщо ви зберігаєте / передаєте текст base64, вам потрібен лише ASCII, і ви навіть можете піти з 7-бітових закодованих протоколів, таких як електронна пошта. Додаткові накладні витрати UTF-8 не потрібні.
• На цих старих кодуваннях символів побудовано декілька файлів та існуючих даних, важливо мати можливість їх читання.

Зауважте, що існує 4 стандартних алгоритму нормалізації UTF. Якщо вас турбують символи з кількома кодами, ви можете використовувати один з двох алгоритмів нормалізації, які згортають їх у еквівалентний символ однокодової точки. Різниця між ними пов'язана з логічною еквівалентністю та фізичною еквівалентністю символів.