Czy kodowanie znaków oprócz UTF-8 (a może UTF-16 / UTF-32) powinno być przestarzałe?

Mój wkurzony zwierzak patrzy na tak wiele projektów oprogramowania, które mają góry kodu do obsługi zestawu znaków. Nie zrozum mnie źle, jestem za zgodą i cieszę się, że edytory tekstu pozwalają otwierać i zapisywać pliki w wielu zestawach znaków. Denerwuje mnie to, jak rozprzestrzenianie się nie uniwersalnych kodowań znaków jest oznaczone jako „właściwe wsparcie Unicode”, a nie „problem”.

Na przykład pozwól mi wybrać PostgreSQL i obsługę zestawu znaków . PostgreSQL zajmuje się dwoma typami kodowania:

• Kodowanie klienta: Używany w komunikacji między klientem a serwerem.
• Kodowanie na serwerze: służy do wewnętrznego przechowywania tekstu w bazie danych.

Rozumiem, dlaczego obsługa wielu kodowań klientów jest dobra. Umożliwia klientom, którzy nie działają w UTF-8, komunikowanie się z PostgreSQL bez konieczności przeprowadzania konwersji. Nie rozumiem: dlaczego PostgreSQL obsługuje wiele serwerów kodowanie ? Pliki bazy danych (prawie zawsze) są niekompatybilne z jedną wersją PostgreSQL do następnej, więc zgodność między wersjami nie jest tutaj problemem.

UTF-8 to jedyny standardowy zestaw znaków zgodny z ASCII, który może kodować wszystkie punkty kodowe Unicode (jeśli się mylę, daj mi znać). Jestem w obozie, że UTF-8 jest najlepszy zestawem znaków, ale jestem gotów znosić inne uniwersalne zestawy znaków, takie jak UTF-16 i UTF-32.

Uważam, że wszystkie nie uniwersalne zestawy znaków powinny być przestarzałe. Czy jest jakiś ważny powód, dla którego nie powinni?

Odkąd wspominałeś o PostgreSQL, mogę z pewnym autorytetem powiedzieć, że głównym zabójczym powodem, dla którego kodowania po stronie serwera inne niż UTF8 są obsługiwane tak szczegółowo, jest to, że Japończycy tego potrzebują. Najwyraźniej identyczna konwersja w obie strony między Unicode a różnymi japońskimi „starszymi” kodowaniami nie zawsze jest możliwa, aw niektórych przypadkach tabele konwersji są nawet różne u różnych dostawców. To naprawdę zaskakujące, ale najwyraźniej tak. (Rozbudowana obsługa zestawu znaków jest również jednym z powodów, dla których PostgreSQL jest tak popularny w Japonii).

Ponieważ mówimy o systemie baz danych, jednym z głównych zadań jest niezawodne przechowywanie i pobieranie danych, zgodnie z definicją użytkownika, więc konwersja stratnego zestawu znaków czasami nie powiedzie się. Jeśli masz do czynienia z przeglądarką internetową, powiedzmy, gdzie naprawdę ważne jest to, czy wynik wygląda dobrze, to prawdopodobnie możesz uniknąć obsługi mniejszego kodowania, ale w systemie baz danych masz dodatkowe wymagania.

Niektóre z innych powodów wymienionych w innych odpowiedziach mają również zastosowanie jako argumenty wspierające. Ale dopóki Japończycy to zawetują, nie można zmniejszyć obsługi konfiguracji postaci.

Dwa oczywiste powody: w zależności od przechowywanych danych, konwersja do innego formatu może zająć sporo czasu i dodatkowego miejsca. Jeśli przechowujesz 400 megabajtów informacji, podwojenie wymagań dotyczących miejsca to nic wielkiego - ale jeśli przechowujesz 400 terabajtów, zaczyna to oznaczać nieco więcej. Konwersja 400 terabajtów danych z (powiedzmy) Shift-JIS na UTF-x również może zająć trochę czasu.

Staje się to szczególnie trudne, jeśli masz (na przykład) gwarancje bezawaryjności, które mówią, że baza danych będzie dostępna dla wszystkich, ale powiedzmy, 10 minut w danym roku, a baza danych jest aktualizowana kilkaset razy na sekundę. Pamiętaj, że w takiej sytuacji nadal można zarządzać dużymi konwersjami, ale nie jest to coś lekkiego. W niektórych przypadkach przygotowanie się do takiej konwersji może zająć lata .

Jeśli zaczynasz od bazy danych, która (na przykład) obsługuje tylko ASCII, może istnieć dobry powód do debaty, czy warto dodać obsługę wszystkich tych kodowań - ale jeśli już je obsługujesz, niewiele zyskasz porzuceniu wsparcie dla nich.

Zwróć uwagę w szczególności, że prawdopodobnie nie zyskasz prawie nic w celu uproszczenia kodu lub czegoś podobnego. Nadal będą potrzebować wszystkich procedur konwersji, aby poradzić sobie z konwersjami między klientem a serwerem. W związku z tym porzucenie obsługi oznaczałoby porzucenie jednego (mniejszego) wywołania funkcji w ścieżkach „zapisu na dysk” i „odczytu z dysku”, ale niewiele (jeśli cokolwiek innego). Gdybyś wspierał nawet dwa kodowania na dysku, nawet byś tego nie zyskał - nadal miałbyś tam wywołanie funkcji, więc tak naprawdę jedyne, co byś zrobił, to ograniczenie zakresu kodowań obsługiwanych przez tę funkcję.

Przynajmniej gdybym to projektował, prawdopodobnie napisałbym rdzeń bazy danych do pracy w UCS-4, a następnie miałbym procedury konwersji między rdzeniem a dyskiem oraz między rdzeniem a użytkownikiem. W obu przypadkach używałbym tego samego zestawu procedur, więc najprostszą drogą byłoby zezwolenie pamięci dyskowej na używanie dokładnie tego samego zestawu kodowań, z którego mogli korzystać klienci.

Jest kilka problemów z przechowywaniem tylko UTF-8 na serwerze:

1. Jaki jest limit VARCHAR(20)kolumny? Czy to 20 bajtów, czy 20 „znaków” (a w Unicode, co to jest „znak”, jeśli weźmie się pod uwagę łączenie znaków, ligatur itp.). Co gorsza, co z tym, CHAR(20)gdzie faktycznie musi zarezerwować całą możliwą przestrzeń: Wierzę w MySQL, rezerwuje 4-krotną liczbę bajtów dla kolumny zakodowanej w UTF-8 (czyli 80 bajtów CHAR(20)) tylko na wypadek najgorszego przypadku.
2. Musisz wykonywać ciągłe konwersje kodowania między kodowaniem serwera a kodowaniem klienta. Możesz argumentować, że chcesz również przestać obsługiwać wiele kodowań klientów, ale jeśli tego nie zrobisz, wszystkie ciągi muszą być cały czas konwertowane. Jeśli możesz dopasować kodowanie serwera i kodowanie klienta, konwersje nie są wymagane.
3. Jak zauważyli inni, UTF-8 jest dość wydajny do przechowywania tekstu w języku angielskim, ale jest bardzo nieefektywny w przypadku innych języków - w szczególności języków wschodnioazjatyckich. Przypuszczam, że można zezwolić na użycie UTF-16 lub UTF-8 jako garniturów. Lub kompresuj tekst, ale powoduje to, że indeksowanie i wyszukiwanie jest nieefektywne.

Powiedziawszy to wszystko, zgadzam się z tobą: starsze kodowania są w większości bezcelowe, a Unicode jest ogólnie najlepszym kodowaniem do zastosowania we wszystkich nowych aplikacjach. Gdybym dzisiaj pisał serwer bazy danych od podstaw, obsługiwałbym tylko Unicode i nie obsługiwałby w ogóle żadnego starszego kodowania.

Różnica polega na tym, że PostgreSQL i większość innych używanych obecnie serwerów baz danych istniały, zanim Unicode stał się realną opcją. Mieli już wsparcie dla kodowania starszego typu (wtedy oczywiście nie byli starszymi wersjami) i po prostu nie ma sensu wyrywanie całego tego kodu z powodów głównie ideologicznych.

Nie-uniwersalne (a konkretnie jednobajtowe) kodowania mają swoje miejsce: w systemach, które:

• Brak wystarczającej ilości pamięci do przechowywania bazy znaków znaków Unicode.
• Mieć jednobajtową czcionkę zakodowaną na stałe w pamięci ROM.
• Nie mają dostępu do Internetu, aby zapewnić źródło plików o różnych kodowaniach.

Tak jest dzisiaj w przypadku niektórych typów urządzeń osadzonych. Ale na pulpicie iw serwerowni kodowania inne niż Unicode powinny być już dawno przestarzałe.

UTF-8 jest najlepszy dla Ciebie egocentryczny ¹ angielski. Gdybyś był Japończykiem, około 99% twoich postaci zajęłoby 3-4 bajty zamiast dwóch w UTF-16.

Dialekty niełacińskie naprawdę cierpią na UTF-8 na poziomie wielkości. Nie zapominaj, że w ciągu kilku lat większość Twoich klientów może być Chińczykami, a chińskie pismo ma miliony znaków. Z UTF-8 nie da się tego tak skutecznie utrzymać.

W przeciwnym razie, nienawidzę go, gdy mam dokumentów tekstowych, które nie są w UTF- coś . Często zejdę mi z drogi, jeśli muszę mieć odpowiednie kodowanie. W mojej książce kodowania inne niż Unicode są martwe.

_{1. Nie bierz części egocentrycznej osobiście. Chciałem zrobić kolorową ilustrację i tak naprawdę nie mam tego na myśli.}

Unicode jest zasadniczo zepsuty i prawdopodobnie nie zostanie naprawiony. Musi zostać zastąpiony czymś lepszym, czymś naprawdę uniwersalnym. Jeśli coś wymaga przestarzałości, jest to Unicode.

Przykładowe problemy z Unicide:

• UTF8 to rozsądny hack, ale większość oprogramowania opartego na UTF16 jest zepsuta. Większość aplikacji Windows obsługujących Unicode używa UTF16, w tym sam system operacyjny. Najczęstszym problemem nie jest obsługa więcej niż płaszczyzny podstawowej, tj. Znaków wielosłówowych.

• Zjednoczenie Hana to katastrofa nieskrępowana. Niemożliwe jest mieszanie tekstu japońskiego / chińskiego / koreańskiego w jednym dokumencie bez dodatkowych metadanych, a także trudne do wykrycia, której czcionki należy użyć.

• Znaki kombinacyjne to kolejna katastrofa. Bardziej sensowne schematy kodowania odwzorowują jeden znak na jeden kod, co sprawia, że ​​przetwarzanie ciągów znaków jest względnie rozsądne. Unicode nie. Unicode nie jest nawet spójny - znaki Han są przeważnie kombinacjami, ale nie są zakodowane jako takie, jak w przypadku europejskich znaków kombinacyjnych.

• Nazwisk niektórych osób nie można poprawnie zapisać w Unicode lub są one bardzo podatne na niepoprawne renderowanie z powodu wyżej wymienionych problemów. Może to mieć poważne konsekwencje, np. Przy próbie wejścia na pokład samolotu z paszportem, który nie pasuje do (nieprawidłowo) wydrukowanego na bilecie.

Ze względu na te i wiele innych problemów wiele nieanglojęzycznych programów nie może używać Unicode i korzysta z lokalnego kodowania znaków. Jest to szczególnie powszechne w przypadku japońskiego i chińskiego oprogramowania.

Idealnie byłoby, gdyby Unicode był przestarzały. Kodowanie znaków TRON jest całkiem dobrym zamiennikiem Unicode i jest w dużej mierze kompatybilne z istniejącym oprogramowaniem, które nie będzie aktualizowane.

Może do pisania, ale nie do czytania.

Istnieje wiele istniejących treści, które korzystają z tych kodowań, a niektóre kodowania, takie jak base64, nigdzie się nie wybierają, ponieważ niektóre protokoły tekstowe nakazują takie sposoby osadzania danych binarnych.

Prawdziwym problemem jest automatyczne wykrywanie kodowania, które prowadzi do luk bezpieczeństwa. Nie miałbym nic przeciwko, że niektóre niejasne kodowania, takie jak UTF-7, po prostu znikają.

Automatyczne wykrywanie również źle radzi sobie z treściami wytwarzanymi przez naiwne łączenie ciągów bajtów.

Zgadzam się, że domyślne kodowanie znaków dla baz danych i nowych aplikacji powinno być jakimś wariantem UTF. Ja osobiście wybrałbym UTF-16, ponieważ wydaje się, że jest to rozsądny kompromis w zakresie przestrzeni i złożoności (bardziej niż UTF-8). To powiedziawszy, niektóre kodowania znaków nadal mają sens w niektórych przypadkach.

• Jeśli przechowujesz / przenosisz tekst base64, potrzebujesz tylko ASCII i możesz nawet uciec z 7-bitowymi zakodowanymi protokołami, takimi jak e-mail. Dodatkowe obciążenie związane z UTF-8 nie jest konieczne.
• Wiele plików i istniejących danych jest zbudowanych na tych starszych kodowaniach znaków, dlatego umiejętność ich odczytu jest ważna.

Należy pamiętać, że istnieją 4 standardowe algorytmy normalizacji UTF. Jeśli obawiasz się znaków wielopunktowych, możesz użyć jednego z dwóch algorytmów normalizacyjnych, które łączą je w równoważne znaki jednopunktowe. Różnica między nimi dotyczy równoważności logicznej i fizycznej równoważności znaków.