WChars, kodowanie, standardy i przenośność

Poniższe pytania mogą nie kwalifikować się jako pytanie typu SO; jeśli jest to poza granicami, proszę, powiedz mi, żebym sobie poszedł. Pytanie tutaj brzmi zasadniczo: "czy dobrze rozumiem standard C i czy jest to właściwy sposób, aby przejść do rzeczy?"

Chciałbym prosić o wyjaśnienie, potwierdzenie i poprawki w moim zrozumieniu obsługi znaków w C (a więc C++ i C++0x). Po pierwsze, ważna uwaga:

przenośność i serializacja są pojęciami ortogonalnymi.

Przenośne rzeczy to rzeczy jak C, unsigned int, wchar_t. Serializowalne rzeczy to rzeczy takie jak uint32_t lub UTF-8. "Przenośny" oznacza, że można przekompilować to samo źródło i uzyskać wynik pracy na każdej obsługiwanej platformie, ale reprezentacja binarna może być zupełnie inna (lub nawet nie istnieje, np. TCP-over-carrier pigeon). Serializowalne rzeczy z drugiej strony zawsze mają tę samą reprezentację, np. plik PNG, który mogę odczytać na moim systemie Windows na pulpicie, w telefonie lub na szczoteczce do zębów. Rzeczy przenośne są wewnętrzne, rzeczy serializowalne zajmują się we/wy. rzeczy przenośne są typami, rzeczy serializowalne wymagają typu.

• wchar_t, setlocale(), mbsrtowcs()/wcsrtombs(): standard C nie mówi nic o"kodowaniu" ; w rzeczywistości jest całkowicie agnostyczny dla dowolnego tekstu lub kodowania właściwości. To tylko mówi " twój punkt wejścia jest main(int, char**); otrzymujesz typ wchar_t, który może pomieścić wszystkie znaki Twojego systemu; dostajesz funkcje do odczytu wejściowych sekwencji znaków i przekształcania ich w wykonalne stringi i vice versa.

• iconv() i UTF-8,16,32: funkcja / biblioteka do transkodowania między dobrze zdefiniowanymi, określonymi, stałymi kodowaniami. Wszystkie kodowania obsługiwane przez iconv są powszechnie zrozumiałe i uzgodnione, z jednym wyjątkiem.

Most między przenośny, kodujący-agnostyczny świat C z jego przenośnym typem znakowym wchar_t i deterministycznym światem zewnętrznym jest konwersja iconv pomiędzy WCHAR-T i UTF .

Więc, czy zawsze powinienem przechowywać moje ciągi wewnętrznie w kodowaniu-agnostic wstring, interfejs z CRT poprzez wcsrtombs(), i używać iconv() do serializacji? Koncepcyjnie:

                        my program
    <-- wcstombs ---  /==============\   --- iconv(UTF8, WCHAR_T) -->
CRT                   |   wchar_t[]  |                                <Disk>
    --- mbstowcs -->  \==============/   <-- iconv(WCHAR_T, UTF8) ---
                            |
                            +-- iconv(WCHAR_T, UCS-4) --+
                                                        |
       ... <--- (adv. Unicode malarkey) ----- libicu ---+

Praktycznie oznacza to, że napisałbym dwie okładki dla mojego punktu wejścia do programu, np. dla C++:

// Portable wmain()-wrapper
#include <clocale>
#include <cwchar>
#include <string>
#include <vector>

std::vector<std::wstring> parse(int argc, char * argv[]); // use mbsrtowcs etc

int wmain(const std::vector<std::wstring> args); // user starts here

#if defined(_WIN32) || defined(WIN32)
#include <windows.h>
extern "C" int main()
{
  setlocale(LC_CTYPE, "");
  int argc;
  wchar_t * const * const argv = CommandLineToArgvW(GetCommandLineW(), &argc);
  return wmain(std::vector<std::wstring>(argv, argv + argc));
}
#else
extern "C" int main(int argc, char * argv[])
{
  setlocale(LC_CTYPE, "");
  return wmain(parse(argc, argv));
}
#endif
// Serialization utilities

#include <iconv.h>

typedef std::basic_string<uint16_t> U16String;
typedef std::basic_string<uint32_t> U32String;

U16String toUTF16(std::wstring s);
U32String toUTF32(std::wstring s);

/* ... */

Jest to jest właściwy sposób na napisanie idiomatycznego, przenośnego, uniwersalnego, niezwiązanego z kodowaniem rdzenia programu przy użyciu tylko czystego standardu C / C++, wraz z dobrze zdefiniowanym interfejsem I / O do UTF przy użyciu iconv? (Zwróć uwagę, że kwestie takie jak normalizacja Unicode lub zamiana znaków diakrytycznych są poza zakresem; dopiero gdy zdecydujesz, że chcesz Unicode (W przeciwieństwie do jakiegokolwiek innego systemu kodowania, który możesz sobie wyobrazić), nadszedł czas, aby poradzić sobie z tymi specyfikacjami, np. używając dedykowanej biblioteki, takiej jak libicu.)

Aktualizacje

Po wielu bardzo miłych komentarzach chciałbym dodać kilka uwag:

• Jeśli aplikacja wyraźnie chce radzić sobie z tekstem Unicode, należy zrobić iconv - conversion część rdzenia i użyć uint32_t/char32_t-struny wewnętrzne z UCS-4.

• Windows: chociaż używanie szerokich ciągów jest ogólnie w porządku, wydaje się, że interakcja z konsolą (dowolną konsolą, jeśli o to chodzi) jest ograniczona, ponieważ nie wydaje się być wsparciem dla żadnego sensownego kodowania wielobajtowej konsoli i mbstowcs jest zasadniczo bezużyteczny (inny niż dla trywialnego rozszerzenia). Otrzymywanie szerokich argumentów z, powiedzmy, Explorer-drop razem z GetCommandLineW+CommandLineToArgvW działa (być może powinno być osobne opakowanie Dla Windows).

• Systemy plików: systemy plików nie wydają się mieć pojęcia kodowania i po prostu przyjmują dowolny łańcuch zakończony znakiem null jako nazwę pliku. Większość systemów przyjmuje ciągi bajtów, ale Windows / NTFS zajmuje 16-bitowe struny. Należy zachować ostrożność podczas odkrywania, które Pliki istnieją i podczas przetwarzania tych danych (np. sekwencje char16_t, które nie stanowią poprawnego UTF16 (np. nagie zastępcze) są poprawnymi nazwami plików NTFS). Standard C fopen nie jest w stanie otworzyć wszystkich plików NTFS, ponieważ nie ma możliwej konwersji, która mapuje wszystkie możliwe 16-bitowe ciągi. Może być wymagane użycie specyficznego dla systemu Windows _wfopen. Jako następstwo, ogólnie nie ma dobrze zdefiniowanego pojęcia " ile znaków" zawierać nazwę danego pliku, ponieważ nie ma pojęcia "znak" w pierwszej kolejności. Caveat emptor.