Jaka jest zaleta wyboru kodowania ASCII w porównaniu z UTF-8?

W niektórych przypadkach może przyspieszyć dostęp do poszczególnych postaci. Wyobraź sobie ciąg str="ABC" zakodowany w UTF8 i ASCII (i zakładając, że język / kompilator / baza danych wie o kodowaniu)

Aby uzyskać dostęp do trzeciego (C) z tego ciągu przy użyciu operatora dostępu do tablicy, który występuje w wielu językach programowania, zrobiłbyś coś takiego jak c = str[2].

Teraz , jeśli łańcuch jest zakodowany w ASCII, wszystko, co musimy zrobić, to pobrać trzeci bajt z łańcucha.

Jeśli jednak łańcuch jest zakodowany w UTF-8, musimy najpierw sprawdzić, czy pierwszy znak jest jednobajtowym czy dwubajtowym znakiem, następnie musimy przeprowadzić to samo sprawdzenie drugiego znaku i dopiero wtedy możemy uzyskać dostęp do trzeci znak. Różnica w wydajności będzie tym większa, im dłuższy ciąg.

Jest to problem na przykład w niektórych silnikach baz danych, gdzie można znaleźć początek kolumny umieszczonej „po” VARCHAR zakodowanym w UTF-8 baza danych musi nie tylko sprawdzić, ile znaków znajduje się w polu VARCHAR, ale także ile bajtów zużywa każdy z nich.

Komentarze

• Jeśli baza danych nie ' nie przechowuje zarówno ” liczby znaków ” i ” liczba bajtów „, a następnie ' d powiem ma ' ma pewne problemy …
• TBH Nie znam bazy danych, w której można by przechowywać …
• @Mchl: jak wyobrażasz sobie, że baza danych wie, kiedy osiągnęła koniec ciągu?
• Zwykle po osiągnięciu 0x00 lub 0x0000
• @DeanHarding W jaki sposób liczba znaków wskazuje, gdzie zaczyna się drugi znak ? A może baza danych powinna również zawierać indeks dla każdego przesunięcia znaku? Uwaga: nie są to ' tylko 2 znaki, ale mogą mieć maksymalnie 4 (chyba że ' s 6) stackoverflow.com/questions/9533258/… . (Myślę, że to ' to jedyny utf-16, który miał naprawdę długie obrzydliwości, które mogą zniszczyć twój system)

Jeśli „zamierzasz używać tylko podzbioru US-ASCII (lub ISO 646) UTF-8, to nie ma żadnej realnej korzyści dla jednego z nich; w rzeczywistości wszystko jest kodowane identycznie.

Jeśli zamierzasz wyjść poza zestaw znaków US-ASCII i użyć (na przykład) znaków z akcentami, umlautami itp., które są używane w typowych W przypadku języków zachodnioeuropejskich istnieje różnica – większość z nich nadal można zakodować jednym bajtem w ISO 8859, ale zakodowanie w UTF-8 wymaga dwóch lub więcej bajtów. Istnieją również oczywiście wady: ISO 8859 wymaga użycia pewnych środków pozapasmowych do określenia używanego kodowania i obsługuje tylko jeden z tych języków na raz. Na przykład możesz zakodować wszystkie znaki cyrylicy (rosyjskie, białoruskie itp.) alfabet używając tylko jednego bajtu na sztukę, ale jeśli potrzebujesz / chcesz mieszać te ze znakami francuskimi lub hiszpańskimi (innymi niż te z podzbioru US-ASCII / ISO 646), masz pecha – musisz całkowicie w tym celu zmień zestawy znaków.

ISO 8859 jest naprawdę przydatne tylko w przypadku alfabetów europejskich. Aby obsługiwać większość alfabetów używanych w większości alfabetów chińskiego, japońskiego, koreańskiego, arabskiego itd., musisz użyć zupełnie inne kodowanie. Niektóre z nich (np. Shift JIS dla języka japońskiego) są absolutnym problemem. Jeśli jest jakaś szansa, że kiedykolwiek zechcesz je obsługiwać, uważam, że warto użyć Unicode tylko w

ANSI może oznaczać wiele rzeczy, w większości 8-bitowe zestawy znaków w tym zakresie (jak strona kodowa 1252 pod Windows).

Być może myślałeś o ASCII, który jest 7-bitowy i stanowi właściwy podzbiór UTF-8. To znaczy. każdy poprawny strumień ASCII jest również prawidłowym strumieniem UTF-8.

Jeśli myślisz o 8-bitowych zestawach znaków, jedną bardzo ważną zaletą byłoby to, że wszystkie reprezentowane znaki są dokładnie 8-bitowe, gdzie w UTF -8 mogą mieć maksymalnie 24 bity.

Komentarze

• tak i ' mówię o 7-bitowy zestaw ASCII. czy możesz pomyśleć o jednej korzyści, jaką kiedykolwiek będziemy musieli zapisać jako ascii zamiast utf-8? (ponieważ 7-bitowy i tak zostałby zapisany jako 8-bitowy, rozmiar pliku byłby dokładnie taki sam)
• Jeśli masz znaki większe niż wartość Unicode 127, nie można ich zapisać w ASCII.
• @Pacerier: Dowolny ciąg ASCII jest ciągiem UTF-8 , więc nie ma żadnej różnicy . Procedura kodowania może być szybsza w zależności od reprezentacji ciągu znaków używanej platformy, chociaż nie ' nie spodziewałbym się znacznego przyspieszenia, podczas gdy masz znaczną stratę elastyczności.
• @Thor właśnie dlatego i ' m pytam, czy zapisywanie jako ASCII ma w ogóle jakieś zalety.
• @Pacerier, jeśli zapiszesz XML jako ASCII, musisz użyć np & # 160; dla niełamliwej przestrzeni. Jest to bardziej wypełniające, ale sprawia, że dane są bardziej odporne na błędy kodowania ISO-Latin-1 i UTF-8. To właśnie robimy, ponieważ nasza platforma bazowa wykonuje wiele niewidzialnej magii z postaciami. Pozostanie w ASCII sprawia, że nasze dane są bardziej niezawodne.

Tak, nadal istnieją przypadki użycia, w których ASCII ma sens: formaty plików i protokoły sieciowe . W szczególności do zastosowań, w których:

• Masz dane, które są generowane i używane przez programy komputerowe, nigdy nie są prezentowane użytkownikom końcowym;
• Ale do których są przydatne programiści, aby móc czytać, aby ułatwić programowanie i debugowanie.

Używając ASCII jako kodowania, unikasz złożoności kodowania wielobajtowego, zachowując przynajmniej część czytelności dla człowieka.

Kilka przykładów:

• HTTP to protokół sieciowy zdefiniowany za pomocą sekwencji oktetów, ale jest bardzo przydatne (przynajmniej dla programistów anglojęzycznych), że odpowiadają one kodowaniu ASCII słów, takich jak „GET”, „POST”, „Accept-Language” itd.
• typy fragmentów w formacie obrazu PNG składają się z czterech oktetów, ale jest to przydatne, jeśli programujesz koder lub dekoder PNG, który oznacza„ dane obrazu ”, a PLTE oznacza„ paletę ”.

Oczywiście musisz uważaj, aby dane naprawdę nie były prezentowane użytkownikom końcowym, ponieważ jeśli okażą się widoczne (jak to miało miejsce w przypadku adresów URL), to użytkownicy będą słusznie oczekiwać, że dane być w języku, który potrafią czytać.

Komentarze

• Dobrze powiedziane. To ' to trochę ironiczne, że HTTP, protokół, który transmituje najwięcej Unicode na naszej planecie, musi obsługiwać tylko ASCII. (Wydaje mi się, że to samo dotyczy TCP i IP, obsługi binarnej, obsługi ASCII … to wszystko, czego potrzebujesz na tym poziomie stosu, ')

Po pierwsze: twój tytuł używa / d ANSI, podczas gdy w tekście odnosisz się do ASCII. Należy pamiętać, że ANSI nie równa się ASCII. ANSI zawiera zestaw ASCII. Ale zestaw ASCII jest ograniczony do pierwszych 128 wartości liczbowych (0 – 127).

Jeśli wszystkie dane są ograniczone do ASCII (7-bitowe), nie ma znaczenia, czy używasz UTF-8 , ANSI lub ASCII, ponieważ zarówno ANSI, jak i UTF-8 zawierają pełny zestaw ASCII. Innymi słowy: wartości liczbowe od 0 do 127 włącznie reprezentują dokładnie te same znaki w ASCII, ANSI i UTF-8.

Jeśli potrzebujesz znaków spoza zestawu ASCII, musisz wybrać kodowanie. Możesz użyć ANSI, ale wtedy napotkasz problemy ze wszystkimi różnymi stronami kodowymi.Utwórz plik na komputerze A i przeczytaj go na komputerze B może / będzie generować śmiesznie wyglądające teksty, jeśli te maszyny są skonfigurowane do używania różnych stron kodowych, proste, ponieważ wartość numeryczna nnn reprezentuje różne znaki na tych stronach kodowych.

Ta „piekielna strona kodowa” jest powodem, dla którego zdefiniowano standard Unicode . UTF-8 to tylko jedno kodowanie tego standardu, jest ich znacznie więcej. UTF-16 jest najczęściej używanym kodowaniem, ponieważ jest to natywne kodowanie dla systemu Windows.

Więc jeśli potrzebujesz obsługiwać cokolwiek poza 128 znakami zestawu ASCII, radzę wybrać UTF-8 . W ten sposób nie ma to znaczenia i nie musisz martwić się o to, z której strony kodowej twoi użytkownicy skonfigurowali swoje systemy.

Komentarze

• Jeśli nie potrzebuję obsługi więcej niż 128 znaków, jaka jest zaleta wyboru kodowania ACSII nad kodowaniem UTF8?
• Poza ograniczeniem się do tych 128 znaków? Niewiele. UTF-8 został specjalnie zaprojektowany, aby obsłużyć ASCII i większość zachodnich języków, które ” tylko ” wymagają ANSI. Przekonasz się, że UTF-8 zakoduje tylko stosunkowo niewielką liczbę wyższych znaków ANSI z więcej niż jednym bajtem. Jest powód, dla którego większość stron HTML domyślnie używa UTF-8 …
• @Pacerier, jeśli ' nie potrzebujesz kodowania powyżej 127, wybranie ASCII może być warte, gdy używasz jakiegoś API do kodowania / dekodowania, ponieważ UTF wymaga dodatkowej weryfikacji bitowej, aby uznać dodatkowe bajty za ten sam znak, może wymagać dodatkowych obliczeń zamiast czystego ASCII, który po prostu odczytuje 8 bitów bez weryfikacji. Zalecam jednak używanie ASCII tylko wtedy, gdy naprawdę potrzebujesz wysokiego poziomu optymalizacji w dużych (dużych) obliczeniach i wiesz, co ' robisz w tej optymalizacji. Jeśli nie, po prostu użyj UTF-8.