Wieloplatformowe łańcuchy znaków (i Unicode) w C++

Question

W końcu wróciłem do mojego głównego zadania - przeniesienia raczej dużego projektu C++ z Windowsa na Maca.

Od razu uderzył mnie problem, w którym wchar_t ma 16 bitów w systemie Windows, ale 32 bitów na Macu. Jest to problem, ponieważ wszystkie łańcuchy są reprezentowane przez wchar_t, a tam będą przesyłane dane stringów pomiędzy maszynami Windows i Mac (zarówno w danych na dysku, jak iw sieciowych formularzach danych). Ze względu na sposób, w jaki działa, nie byłoby łatwo przekształcić ciągi w jakiś popularny format przed wysłaniem i odebraniem danych.

Naprawdę zaczęliśmy ostatnio obsługiwać znacznie więcej języków, dlatego zaczynamy zajmować się wieloma danymi Unicode (jak również obsługą języków pisanych od prawej do lewej).

Mogę teraz kombinować wiele pomysłów i powodować więcej problemów dla siebie niż potrzebnych, dlatego właśnie zadaję to pytanie. Uważamy, że przechowywanie wszystkich danych w łańcuchu w pamięci jako UTF-8 ma wiele sensu. Rozwiązuje problem wchar_t będący różnym rozmiarem, co oznacza, że ​​możemy w łatwy sposób obsługiwać wiele języków, a także dramatycznie zmniejsza nasz ślad pamięci (mamy mnóstwo - głównie angielskich - napisów) załadowanych) - ale nie wygląda na to, że wiele osób robi to. Czy jest coś, czego nam brakuje? Istnieje oczywisty problem, z którym musisz sobie poradzić, gdzie długość łańcucha może być mniejsza niż rozmiar pamięci przechowującej dane ciągu.

Lub używa UTF-16 lepszym pomysłem? Czy powinniśmy trzymać się wchar_t i napisać kod, aby przekonwertować między wchar_t i, powiedzmy, Unicode w miejscach, w których odczytujemy/zapisujemy na dysku lub w sieci?

Zdaję sobie sprawę, że jest to niebezpiecznie bliskie pytania o opinie - ale denerwujemy się, że przeoczyliśmy coś oczywistego, ponieważ nie wydaje się, że istnieje wiele klas ciągów Unicode (na przykład) - ale jest jeszcze mnóstwo kod do konwersji do/z Unicode jak w boost :: locale, iconv, utf-cpp i ICU.

Answer 1

Zawsze używaj protokołu zdefiniowanego dla bajtu, gdy jest zaangażowany plik lub połączenie sieciowe. Nie należy polegać na tym, jak kompilator C++ przechowuje cokolwiek w pamięci. W przypadku tekstu Unicode oznacza to wybór zarówno kolejności kodowania, jak i kolejności bajtów (w porządku, UTF-8 nie dba o kolejność bajtów). Nawet jeśli platformy, które obecnie chcesz obsługiwać, mają podobne architektury, prawdopodobnie pojawi się inna popularna platforma z innym zachowaniem lub nawet nowy system dla jednej z twoich istniejących platform, a będziesz zadowolony, że napisałeś przenośny kod.

Answer 2

Zgodnie z ogólną zasadą: UTF-16 do przetwarzania, UTF-8 do komunikacji &.

Oczywiście, każda zasada może zostać złamana, a ta nie jest wyryta w kamieniu. Ale musisz wiedzieć, kiedy można go przerwać.

Na przykład dobrym pomysłem może być użycie czegoś innego, jeśli środowisko, którego używasz, potrzebuje czegoś innego. Jednak interfejsy API systemu Mac OS X używają formatu UTF-16, takiego samego jak system Windows. Tak więc UTF-16 ma więcej sensu. Łatwiej jest konwertować, zanim umieścisz/uzyskasz rzeczy w sieci (ponieważ prawdopodobnie robisz to w 2-3 procedurach) niż robi się wszystkie konwersje, aby wywołać interfejsy API systemu operacyjnego.

Ważne jest również rodzaj aplikacji, którą tworzysz. Jeśli jest to coś z bardzo małym przetwarzaniem tekstu i bardzo małymi wezwaniami do systemu (coś takiego jak serwer e-mail, który głównie przenosi obiekty bez ich zmiany), UTF-8 może być dobrym wyborem.

Więc tak bardzo, jak możesz nienawidzić tej odpowiedzi, "to zależy".

Answer 3

Zwykle używam UTF-8 jako wewnętrznej reprezentacji. Tracisz tylko sprawdzanie długości łańcucha, z czego tak naprawdę nie jest przydatne. W przypadku konwersji interfejsu API systemu Windows używam własnych funkcji konwersji Win32 I devised here. Ponieważ Mac i Linux to (dla większość z nich to ze standardowym UTF-8, nie ma potrzeby konwertowania czegokolwiek). Darmowe bonusy:

1. użyć zwykłego starego std::string.
2. Transport w sieci/strumieniu bajtów.
3. Dla większości języków, ładny ślad pamięci.
4. Dodatkowe funkcjonalności: utf8cpp

Answer 4

ICU ma C++ klasy String, UnicodeString