Was würde kaputt gehen, wenn das Gebietsschema C UTF-8 anstelle von ASCII wäre?

Das Gebietsschema C. ist nicht das Standardgebietsschema. Es ist ein Gebietsschema, das garantiert kein „überraschendes“ Verhalten hervorruft. Eine Reihe von Befehlen hat eine garantierte Form (z. B. ps oder df -Header, date format) im Gebietsschema C oder POSIX. Für Codierungen (LC_CTYPE) wird garantiert, dass [:alpha:] nur die ASCII-Buchstaben usw. enthält. Wenn das Gebietsschema C geändert würde, würde dies viele Anwendungen auffordern, sich schlecht zu verhalten. Beispielsweise können sie ungültige UTF-8-Eingaben ablehnen, anstatt sie als Binärdaten zu behandeln.

Wenn alle Programme auf Ihrem System UTF-8 verwenden sollen, setzen Sie das Standardgebietsschema auf UTF-8 . Das heißt, alle Programme, die eine einzelne Codierung manipulieren. Einige Programme bearbeiten nur Byte-Streams und kümmern sich nicht um Codierungen. Einige Programme bearbeiten mehrere Codierungen und kümmern sich nicht um das Gebietsschema (z. B. legt ein Webserver oder Webclient die Codierung für jede Verbindung in einem Header fest oder liest sie).

Sie sind ein bisschen verwirrt, denke ich. Das „C-Gebietsschema“ ist ein Gebietsschema wie jedes andere, das, wie Sie hervorheben, herkömmlicherweise ein Synonym für 7-Bit-ASCII ist.

Es ist in die C-Bibliothek eingebaut, nehme ich an, dass das Bibliothek hat eine Art Fallback – es kann kein Gebietsschema geben.

Dies hat jedoch nichts damit zu tun, wie aus C-Code erstellte Programme mit Eingaben umgehen. Das Gebietsschema wird verwendet, um Eingaben zu übersetzen, die an einer ausführbaren Datei übergeben werden. Wenn das Systemgebietsschema UTF-8 ist, erhält das Programm UTF-8, unabhängig davon, ob seine Quelle in C oder so geschrieben wurde sonst. Also:

Ich wäre überrascht, Code zu sehen, der nur saubere 7-Bit-Eingaben verarbeiten kann und nicht einfach für die Annahme eines UTF-8- angepasst werden kann. aktiviert C

Ist nicht wirklich sinnvoll. Eine minimale Standard-C-Quelle, die von der Standardeingabe liest, empfängt einen Bytestrom vom System. Wenn das System UTF-8 verwendet und den Stream von einer HID-Hardware erzeugt hat, enthält dieser Stream möglicherweise UTF-8-codierte Zeichen. Wenn es von einem anderen Ort stammt (z. B. einem Netzwerk, einer Datei), kann es alles enthalten, was die Annahme eines UTF-8-Standards nützlich macht.

Die Die Tatsache, dass das Gebietsschema C ein viel eingeschränkterer Zeichensatz ist als das Gebietsschema UTF-8, hat nichts damit zu tun. Es wird nur „das C-Gebietsschema“ genannt, aber tatsächlich hat es nicht mehr oder weniger mit dem Verfassen von C-Code zu tun als jeder andere.

Sie können UTF-8-Zeichen tatsächlich in c fest codieren -strings in der Quelle. Vorausgesetzt, das System ist UTF-8, sehen diese Strings korrekt aus, wenn sie von der resultierenden ausführbaren Datei verwendet werden.

Der Link „Roger Leigh“, den Sie in einem Kommentar gepostet haben, bezieht sich meiner Meinung nach auf die Verwendung von erweiterter Satz (UTF-8) als das C-Gebietsschema in einer C-Bibliothek, die für eine eingebettete Umgebung bestimmt ist, sodass kein anderes Gebietsschema geladen werden muss, damit das System damit umgehen kann UTF-8.

Die Antwort auf die Frage „Was würde brechen, wenn das C-Gebietsschema UTF-8 anstelle von ASCII wäre?“ Lautet, würde ich raten , nichts, Außerhalb einer eingebetteten Umgebung usw. besteht jedoch keine große Notwendigkeit, dies zu tun. Es ist jedoch sehr wahrscheinlich, dass dies irgendwann zur Norm für Bibliotheken wie GNU C wird (ich denke, es könnte genauso gut sein).

Kommentare

• Das Verhalten verschiedener Systemaufrufe wird beeinflusst Durch den Zeichensatz des Gebietsschemas erkennt beispielsweise « isupper() keinen A-Umlaut (Ä) als Großbuchstabe im Standard-Gebietsschema C. » (von man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() ist ein weiterer Systemaufruf, der ebenfalls durch die Tatsache beeinflusst wird, dass C nur als ASCII definiert ist.
• Ja, (theoretisch) werden diese durch die Gebietsschema, aber dieses Gebietsschema ist normalerweise UTF-8, es ist nicht unbedingt ' C ' . In GNU sind sie jedoch ' in dieser Hinsicht fehlerhaft: gnu.org/software/gnulib/manual/html_node/isupper. html Beachten Sie, dass 100% der Grundlagen eines Unix-Systems in C codiert sind, sodass die Idee, dass " C nicht ' UTF-8 nicht verarbeiten " ist gut, einfach falsch und offensichtlich falsch. Wenn ein in C geschriebenes Programm nicht mit UTF-8 umgehen könnte, würde ' kein UTF-8 auf dem System sein. Zeitraum.
• Qv. auch die POSIX isupper () Seite pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " im aktuellen Gebietsschema des Prozesses ", nicht " das Gebietsschema C ". Dies gilt auch für den ISO-Standard, der sich auf " im Gebietsschema C " und " im aktuellen Gebietsschema ", normalerweise in der Form ", wenn das aktuelle Gebietsschema lautet das C-Gebietsschema " usw. Denken Sie auch unter Linux an die Implementierung von GNU C ' Einige der ctype-Funktionen sind fehlerhaft.
• @gioele Dies sind Bibliotheksfunktionen, keine Systemaufrufe. Syscalls sind Aufrufe des Kernels und werden von Gebietsschemas nicht beeinflusst: Gebietsschemas existieren nur auf Benutzerebene.
• @goldilocks ' ist nicht ganz richtig, dass " 100% der Grundlagen eines Unix-Systems sind in C " codiert. Auf einer bestimmten Ebene muss man so ziemlich ein bisschen Assembler oder möglicherweise Assembler-ähnliches C haben. Beispiele hierfür sind der Bootloader-Loader (kein Tippfehler), der eigentliche Prozess des Taskwechsels und a wenige andere ähnlich niedrige Funktionen. Darüber hinaus stimme ich jedoch zu, dass C (oder höhere Sprachen) wahrscheinlich in der gesamten Codebasis verwendet werden.