Das ist ein wirklich langjähriges Problem in meiner Arbeit, dass ich merke, dass ich immer noch keine gute Lösung für ...
habeC hat alle seine Charaktertestfunktionen für ein int definiert:
%Vor%Aber Zeichen werden oft signiert, und ein vollständiges Zeichen passt oft nicht in eine int oder in eine einzelne Speichereinheit, die für Strings ****** verwendet wird.
Und diese Funktionen waren die logische Vorlage für aktuelle C ++ - Funktionen und -Methoden und haben die Grundlage für die aktuelle Standardbibliothek geschaffen. Tatsächlich werden sie immer noch unterstützt, afaict.
Wenn Sie issspace übergeben (* pchar), können Sie Probleme mit der Zeichenerweiterung haben. Sie sind schwer zu sehen und daher sind sie meiner Erfahrung nach schwer zu schützen.
In ähnlicher Weise, weil isspace () und seine Art alle Take-Ints sind, und weil die tatsächliche Breite eines Zeichens oft ohne String-Analyse unbekannt ist - was bedeutet, dass jede moderne Zeichen-Bibliothek im Grunde niemals um Chars oder wchar_t's herumlaufen sollte nur Zeiger / Iteratoren, denn nur durch die Analyse des Zeichenstroms können Sie wissen, wie viel davon ein einzelnes logisches Zeichen zusammensetzt, ich bin ein wenig im Nachteil, wie ich die Probleme am besten angehen könnte?
Ich erwarte immer eine wirklich robuste Bibliothek, die darauf basiert, den Größenfaktor irgendeines Charakters zu abstrahieren und nur mit Strings zu arbeiten (mit Dingen wie Issspace usw.), aber entweder habe ich es verpasst, oder es gibt noch einen einfacheren Lösung starrte mich ins Gesicht, dass alle von euch (wer weiß, was du tust) benutzen ...
** Diese Probleme treten bei Zeichenkodierungen fester Größe nicht auf, die vollständig ein vollständiges Zeichen enthalten können - UTF-32 ist anscheinend die einzige Option mit diesen Eigenschaften (oder spezialisierten Umgebungen, die sich auf ASCII oder. beschränken) einige solche).
"Wie testen Sie Whitespace, Isprintable usw. auf eine Weise, die nicht unter zwei Problemen leidet:
1) Zeichenerweiterung und
2) Zeichenprobleme mit variabler Breite
Schließlich sind die meisten Zeichenkodierungen mit variabler Breite: UTF-7, UTF-8, UTF-16, sowie ältere Standards wie Shift-JIS. Sogar erweitertes ASCII kann das einfache Vorzeichenerweiterungsproblem haben, wenn der Compiler char als eine vorzeichenbehaftete 8-Bit-Einheit behandelt.
Unabhängig von der Größe Ihres char_type ist das bei den meisten Zeichencodierungsschemata falsch.
Dieses Problem tritt in der Standard-C-Bibliothek sowie in den C ++ - Standardbibliotheken auf; was immer noch versucht, char und wchar_t, anstatt String-Iteratoren in den verschiedenen Isspace, isprint, etc. Implementierungen zu übergeben.
Tatsächlich ist es genau diese Art von Funktionen, die die Generizität von std :: string bricht. Wenn es nur in Speichereinheiten funktioniert und nicht versucht, die Bedeutung der Speichereinheiten als logische Zeichen zu verstehen (wie zum Beispiel der Issraum), dann wäre die Abstraktion viel ehrlicher und würde uns Programmierer dazu zwingen, nachzusehen woanders für gültige Lösungen ...
Alle, die teilgenommen haben. Zwischen dieser Diskussion und den WChars, Codierungen, Standards und Portabilität habe ich einen viel besseren Überblick die Probleme. Obwohl es keine einfachen Antworten gibt, hilft jedes Verständnis.
Wie testen Sie auf Leerzeichen, isprintable usw., auf eine Weise, die nicht von zwei Problemen leidet:
1) Zeichenerweiterung
2) Zeichenfolgen mit variabler Breite
Schließlich haben alle gängigen Unicode-Kodierungen eine variable Breite, unabhängig davon, ob Programmierer dies erkennen oder nicht: UTF-7, UTF-8, UTF-16, sowie ältere Standards wie Shift-JIS ...
Offensichtlich müssen Sie eine Unicode-fähige Bibliothek verwenden, da Sie (richtig) gezeigt haben, dass die C ++ 03-Standardbibliothek dies nicht ist. Die C ++ 11-Bibliothek wurde verbessert, ist aber immer noch nicht gut genug für die meisten Anwendungen. Ja, einige Betriebssysteme haben eine 32-Bit wchar_t, die sie in die Lage versetzt, UTF32 korrekt zu handhaben, aber das ist eine Implementierung und wird nicht von C ++ garantiert und ist für viele Unicode-Aufgaben nicht im entferntesten ausreichend, wie zum Beispiel über Grapheme (Buchstaben) .
IBMICU
Libiconv
microUTF-8
UTF-8 CPP, Version 1.0
utfproc
und viele mehr auf Ссылка .
Wenn es weniger um spezifische Charaktertests geht und mehr über Code-Praktiken im Allgemeinen: Tue was immer dein Framework tut. Wenn Sie für Linux / QT / Networking codieren, behalten Sie alles intern in UTF-8. Wenn Sie mit Windows arbeiten, behalten Sie alles intern in UTF-16. Wenn Sie mit Codepunkten herumhantieren müssen, behalten Sie alles intern in UTF-32. Ansonsten (für portablen, generischen Code), mach was immer du willst, egal was du willst, du musst sowieso für irgendein OS übersetzen.
Ich denke, Sie verwirren eine ganze Reihe von nicht verwandten Konzepten.
Erstens ist char einfach ein Datentyp. Ihre erste und wichtigste Bedeutung ist "die grundlegende Speichereinheit des Systems", d. H. "Ein Byte". Seine Signierung ist absichtlich der Implementierung überlassen, so dass jede Implementierung die am besten geeignete (d. H. Hardwareunterstützte) Version auswählen kann. Sein Name, der "Charakter" suggeriert, ist möglicherweise die schlechteste Entscheidung im Design der C-Programmiersprache.
Das nächste Konzept ist das einer Textzeichenfolge. Bei der Gründung ist Text eine Abfolge von Einheiten, die oft "Charaktere" genannt werden, aber es kann mehr involviert sein. Zu diesem Zweck prägt der Unicode-Standard den Begriff "Codepunkt", um die grundlegendste Texteinheit zu bezeichnen. Vorerst und für uns Programmierer ist "text" eine Folge von Codepunkten.
Das Problem ist, dass es mehr Codepunkte als mögliche Bytewerte gibt. Dieses Problem kann auf zwei verschiedene Arten überwunden werden: 1) Verwenden einer Multi-Byte-Codierung , um Codepunkt-Sequenzen als Byte-Sequenzen darzustellen; oder 2) einen anderen grundlegenden Datentyp verwenden. C und C ++ bieten tatsächlich beide Lösungen: Die native Hostschnittstelle (Befehlszeilenargumente, Dateiinhalte, Umgebungsvariablen) werden als Byte Sequenzen bereitgestellt; aber die Sprache bietet auch einen undurchsichtigen Typ wchar_t für "den Zeichensatz des Systems", sowie Übersetzungsfunktionen zwischen ihnen ( mbstowcs / wcstombs ).
Leider gibt es nichts besonderes an "dem Zeichensatz des Systems" und der "System-Multibyte-Kodierung", so dass Sie, wie so viele SO-Benutzer vor Ihnen, verwirrt darüber sind, was Sie mit diesen mysteriösen, breiten Charakteren tun sollen. Was die Leute heute wollen, ist eine definitive Kodierung, die sie plattformübergreifend teilen können. Die einzige nützliche Kodierung, die wir zu diesem Zweck haben, ist Unicode , die einer großen Anzahl von Codepunkten eine textuelle Bedeutung zuweist (bis zu 2 21 im Moment). . Zusammen mit der Textkodierung kommt eine Familie von Byte-String-Kodierungen, UTF-8, UTF-16 und UTF-32.
Der erste Schritt zum Untersuchen des Inhalts einer gegebenen Textzeichenfolge besteht also darin, ihn von jeder Eingabe, die Sie haben, in eine eindeutige (Unicode) Codierung umzuwandeln. Diese Unicode-Zeichenfolge kann selbst in einem der Transformationsformate codiert sein, aber die einfachste ist eine Sequenz von Rohcodepunkten (normalerweise UTF-32, da wir keinen brauchbaren 21-Bit-Datentyp haben).
Die Durchführung dieser Umwandlung ist bereits außerhalb des C ++ - Standards (auch des neuen), daher benötigen wir hierfür eine Bibliothek. Da wir nichts über unseren "System-Zeichensatz" wissen, brauchen wir auch die Bibliothek, um das zu handhaben.
Eine beliebte Bibliothek der Wahl ist iconv() ; Die typische Sequenz geht von Eingabe multibyte char* über mbstowcs() zu einer std::wstring oder wchar_t* breite Zeichenfolge und dann über iconv() 's WCHAR_T-to-UTF32 Konvertierung in ein std::u32string oder uint32_t* roh Unicode Codepunktsequenz.
An diesem Punkt endet unsere Reise. Wir können nun den Textcodepunkt entweder durch einen Codepunkt untersuchen (was ausreichen könnte, um zu sagen, ob etwas ein Leerzeichen ist); oder wir können eine schwerere Textverarbeitungsbibliothek aufrufen, um komplizierte Textoperationen an unserem Unicode-Codepunktstrom auszuführen (wie Normalisierung, Kanonisierung, Präsentationsumwandlung usw.). Dies geht weit über den Rahmen eines Universalprogrammierers und den Bereich der Textverarbeitungsspezialisten hinaus.
Es ist in jedem Fall ungültig, einen anderen negativen Wert als EOF an isspace und die anderen Zeichenmakros zu übergeben. Wenn Sie char c haben und testen möchten, ob es ein Leerzeichen ist oder nicht, führen Sie isspace((unsigned char)c) aus. Dies betrifft die Erweiterung (durch Null-Ausdehnung). isspace(*pchar) ist flach falsch - schreibe es nicht, lass es nicht stehen, wenn du es siehst. Wenn man sich in Panik ausbreitet, wenn man es sieht, ist es weniger schwer zu sehen.
fgetc (zum Beispiel) gibt bereits entweder EOF oder ein Zeichen zurück, das als unsigned char gelesen und dann in int konvertiert wurde, daher gibt es kein Zeichenerweiterungsproblem für die Werte von diesem.
Das ist aber wirklich eine Kleinigkeit, da die Standardzeichen-Makros Unicode oder Multi-Byte-Codierungen nicht abdecken. Wenn Sie Unicode richtig handhaben möchten, benötigen Sie eine Unicode-Bibliothek. Ich habe nicht untersucht, was C ++ 11 oder C1X in dieser Hinsicht bieten, außer dass C ++ 11 std::u32string hat, was vielversprechend klingt. Davor ist die Antwort, etwas Implementierungsspezifisches oder Drittanbieter zu verwenden. (Un) Glücklicherweise gibt es viele Bibliotheken zur Auswahl.
Es kann sein (ich spekuliere), dass eine "vollständige" Unicode-Klassifikationsdatenbank so groß ist und sich so ändern kann, dass es für den C ++ - Standard unpraktisch wäre, "volle" Unterstützung zu verlangen. Es hängt in gewissem Maße davon ab, welche Operationen unterstützt werden sollten, aber Sie können nicht das Problem lösen, dass Unicode in 20 Jahren (seit der ersten Standardversion) 6 Hauptversionen durchlaufen hat, während C ++ in 13 Jahren 2 Hauptversionen hatte . Soweit es C ++ betrifft, ist die Menge der Unicode-Zeichen ein sich schnell bewegendes Ziel, so dass es immer implementierungsdefiniert sein wird, welche Code-Punkte das System kennt.
Im Allgemeinen gibt es drei korrekte Möglichkeiten, Unicode-Text zu behandeln:
Konvertiert bei allen E / A (einschließlich Systemaufrufen, die Zeichenfolgen zurückgeben oder akzeptieren) alles zwischen einer extern verwendeten Zeichencodierung und einer internen Codierung mit fester Breite. Sie können sich dies als "Deserialisierung" bei der Eingabe und "Serialisierung" bei der Ausgabe vorstellen. Wenn Sie einen Objekttyp mit Funktionen zum Konvertieren in / aus einem Bytestream hätten, würden Sie den Bytestream nicht mit den Objekten verwechseln oder Abschnitte des Bytestreams auf Snippets serialisierter Daten untersuchen, die Sie zu erkennen glauben. Es muss für diese interne Unicode-String-Klasse nicht anders sein. Beachten Sie, dass die Klasse nicht% /% sein kann und je nach Implementierung möglicherweise auch nicht std::string . Geben Sie einfach vor, dass die Standardbibliothek keine Zeichenfolgen bereitstellt, wenn es hilft, oder verwenden Sie std::wstring von etwas, das groß ist wie der Container, aber eine Unicode-fähige Bibliothek, um etwas anspruchsvoller zu machen. Möglicherweise müssen Sie auch die Unicode-Normalisierung verstehen, um sich mit Kombinationsmarkierungen und ähnlichem zu befassen, da selbst in einer Unicode-Codierung mit fester Breite mehr als ein Codepunkt pro Glyphe vorhanden sein kann.
Verwirre dich mit einer Ad-hoc-Mischung aus Byte-Sequenzen und Unicode-Sequenzen und beobachte sorgfältig, welches was ist. Es ist wie (1), aber normalerweise härter, und daher kann es, obwohl es potentiell korrekt ist, in der Praxis genauso leicht schiefgehen.
(Nur für spezielle Zwecke): Verwenden Sie UTF-8 für alles. Manchmal ist dies gut genug, wenn Sie beispielsweise nur Eingaben auf Grundlage von ASCII-Satzzeichen parsen und Zeichenketten für die Ausgabe verketten. Grundsätzlich funktioniert es für Programme, bei denen man nichts mit dem gesetzten Top-Bit verstehen muss, sondern einfach unverändert weitergeben. Es funktioniert nicht so gut, wenn Sie Text tatsächlich rendern oder anderweitig Dinge tun müssen, die ein Mensch für "offensichtlich" halten würde, aber tatsächlich komplex sind. Wie die Sortierung.
Ein Kommentar von vorne: Die alten C-Funktionen wie isspace haben int für übernommen
Ein Grund: Sie unterstützen auch EOF als Eingabe, also müssen sie in der Lage sein
um einen weiteren Wert zu unterstützen, der in char passt. Das
"Naive" Entscheidung war erlaubt char zu signieren-aber
Wenn sie nicht signiert wäre, hätte dies schwerwiegende Auswirkungen auf die Leistung
PDP-11.
Nun zu Ihren Fragen:
1) Erweiterung signieren
Die C ++ Funktionen haben dieses Problem nicht. In C ++, der
"Korrekte" Art und Weise Dinge zu testen wie zB ob ein Charakter ist
Ein Leerzeichen dient dazu, die std::ctype -Facette von dem gewünschten Gebietsschema zu übernehmen.
und es zu benutzen. Natürlich hat die C ++ - Lokalisierung in <locale>
wurde sorgfältig entworfen, um es so schwer wie möglich zu machen, aber wenn
Du machst irgendeine nennenswerte Textverarbeitung, die dir bald einfallen wird
Ihre eigenen Convenience-Wrapper: ein funktionelles Objekt, das ein Gebietsschema annimmt
und die Maske, die angibt, welche Eigenschaft du testen willst, ist nicht schwer.
Machen Sie es zu einer Vorlage für die Maske und geben Sie das Argument locale ein
Der Standardwert für das globale Gebietsschema ist ebenfalls kein Hexenwerk. Einwerfen
einige typedefs, und Sie können Dinge wie IsSpace() zu std::find übergeben.
Die einzige Subtilität besteht darin, die Lebensdauer des Objekts std::ctype zu verwalten
Du hast es zu tun. Etwas wie das Folgende sollte jedoch funktionieren:
(Angesichts des Einflusses der STL ist es etwas überraschend, dass die Standard definierte nicht so etwas wie Standard.)
2) Zeichenprobleme mit variabler Breite.
Es gibt keine echte Antwort. Alles hängt davon ab, was Sie brauchen. Für einige
Anwendungen, suchen nur ein paar bestimmte Single-Byte-Zeichen ist
ausreichend, und alles in UTF-8 zu halten, und das Multi-Byte zu ignorieren
Probleme, ist eine praktikable (und einfache) Lösung. Darüber hinaus ist es oft
nützlich, um in UTF-32 zu konvertieren (oder abhängig von der Art von Text, den Sie sind
(UTF-16), und verwenden Sie jedes Element als einen einzigen Codepunkt. Zum
Volltext-Handling, auf der anderen Seite müssen Sie damit umgehen
Multi-Code-Point-Zeichen, auch wenn Sie UTF-32 verwenden: die Sequenz
\u006D\u0302 ist ein einzelnes Zeichen (ein kleiner m mit einem Zirkumflex über
es).
Ich habe die Internationalisierungsfähigkeiten der Qt-Bibliothek nicht so oft getestet, aber von dem, was ich weiß, ist QString voll Unicode-bewusst und verwendet QChar's, die Unicode-Zeichen sind. Ich kenne die interne Implementierung von diesen nicht, aber ich erwarte, dass dies QChar's Zeichen in variabler Größe impliziert.
Es wäre komisch, sich an ein so großes Framework wie Qt zu binden, nur um Strings zu verwenden.
Sie scheinen eine auf 7-Bit-Ascii definierte Funktion mit einer universellen Raumerkennungsfunktion zu verwechseln. Zeichenfunktionen in Standard C verwenden int , um nicht mit verschiedenen Codierungen umzugehen, sondern um EOF als Out-of-Band-Indikator zu verwenden. Es gibt keine Probleme mit der Zeichenerweiterung, da die Nummern, für die diese Funktionen definiert sind, kein 8. Bit haben. Ein Byte mit dieser Möglichkeit zu versehen, ist ein Fehler von Ihnen.
Plan 9 versucht, dies mit einer UTF-Bibliothek zu lösen und nimmt an, dass alle Eingabedaten UTF-8 sind. Dies ermöglicht ein gewisses Maß an Rückwärtskompatibilität mit ASCII, so dass nicht-kompatible Programme nicht alle abstürzen, sondern neue Programme korrekt geschrieben werden können.
Der allgemeine Begriff in C ist sogar, dass ein char* ein Array von Buchstaben darstellt. Es sollte stattdessen als ein Block von Eingabedaten angesehen werden. Um die Buchstaben aus diesem Stream zu erhalten, verwenden Sie chartorune() . Jedes Rune ist eine Repräsentation eines Buchstabens (/ symbol / codepoint), so dass man endlich eine Funktion isspacerune() definieren kann, die einem endlich sagt, welche Buchstaben Leerzeichen sind.
Arbeiten Sie mit Arrays von Rune wie mit char arrays, um eine String-Manipulation durchzuführen, und rufen Sie runetochar() auf, um Ihre Buchstaben in UTF-8 umzukodieren, bevor Sie sie schreiben.
Das Problem der Zeichenerweiterung ist einfach zu lösen. Sie können entweder verwenden:
isspace((unsigned char) ch) isspace(ch & 0xFF) char zu einem unsignierten Typ macht Was das Problem der Zeichen mit variabler Länge betrifft (ich nehme UTF-8 an), hängt es von Ihren Bedürfnissen ab.
Wenn Sie nur mit den ASCII-Leerzeichen \t\n\v\f\r zu tun haben, funktioniert isspace einwandfrei; Die Nicht-ASCII-UTF-8-Code-Einheiten werden einfach als Nicht-Leerzeichen behandelt.
Aber wenn Sie die zusätzlichen Unicode-Leerzeichen \x85\xa0\u1680\u180e\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u2028\u2029\u202f\u205f\u3000 erkennen müssen, ist es ein bisschen mehr Arbeit. Sie könnten eine Funktion in der Art von
Dabei konvertiert decode_char eine UTF-8-Sequenz in den entsprechenden Unicode-Codepunkt und is_unicode_space gibt true für Zeichen mit der Kategorie Z oder für die Cc -Zeichen zurück, die Leerzeichen sind. iswspace kann oder kann nicht mit Letzteren helfen, abhängig davon, wie gut Ihre C ++ - Bibliothek unterstützt Unicode. Es empfiehlt sich, eine dedizierte Unicode-Bibliothek für den Job zu verwenden.
Die meisten Strings verwenden in der Praxis eine Multibyte-Codierung wie UTF-7, UTF-8, UTF-16, SHIFT-JIS, usw.
Kein Programmierer würde UTF-7 oder Shift-JIS als interne Repräsentation verwenden, wenn sie keine Schmerzen haben. Bleiben Sie bei ŬTF-8, -16 oder -32 und konvertieren Sie sie nur nach Bedarf.
Ihr Präambel-Argument ist etwas inakkurat und unfair. Es ist einfach nicht im Bibliotheksdesign, Unicode-Kodierungen zu unterstützen - sicherlich nicht mehrere Unicode-Kodierungen.
Die Entwicklung der C- und C ++ - Sprachen und eines Großteils der Bibliotheken stammt aus der Zeit vor der Entwicklung von Unicode. Außerdem benötigen sie als Ebenensprachen des Systems einen Datentyp, der der kleinsten adressierbaren Wortgröße der Ausführungsumgebung entspricht. Leider ist der Typ char überladen, um sowohl den Zeichensatz der Ausführungsumgebung als auch das minimal adressierbare Wort darzustellen. Es ist Geschichte, die gezeigt hat, dass dies vielleicht fehlerhaft ist, aber das Ändern der Sprachdefinition und tatsächlich der Bibliothek würde eine große Menge von Legacy-Code zerstören, so dass solche Dinge zu neueren Sprachen wie C # mit einem 8-Bit byte überlassen werden. und distinct char type.
Außerdem macht die variable Kodierung von Unicode-Darstellungen es für einen eingebauten Datentyp als solchen ungeeignet. Sie sind sich dessen natürlich bewusst, da Sie vorschlagen, dass Unicode-Zeichenoperationen an Zeichenfolgen und nicht an Maschinenworttypen ausgeführt werden sollten. Dies würde Bibliotheksunterstützung erfordern und wie Sie darauf hinweisen, wird dies von der Standardbibliothek nicht bereitgestellt. Dafür gibt es eine Reihe von Gründen, aber in erster Linie liegt es nicht in der Domäne der Standardbibliothek, genauso wie es keine Standardbibliotheksunterstützung für Netzwerke oder Grafiken gibt. Die Bibliothek adressiert intrinsisch nichts, was nicht generell von allen Zielplattformen vom tief eingebetteten bis zum Supercomputer unterstützt wird. All diese Dinge müssen entweder vom System oder von Bibliotheken von Drittanbietern bereitgestellt werden.
Die Unterstützung für mehrere Zeichenkodierungen bezieht sich auf die System- / Umgebungsinteroperabilität, und die Bibliothek soll das auch nicht unterstützen. Der Datenaustausch zwischen inkompatiblen Verschlüsselungssystemen ist ein Anwendungsproblem, kein Systemproblem.
"Wie testen Sie auf Leerzeichen, isprintable usw. in einer Weise, dass hat nicht zwei Probleme:
1) Unterschreiben Sie die Erweiterung und
2) Zeichenprobleme mit variabler Breite
isspace () berücksichtigt nur die unteren 8-Bits. Seine Definition besagt explizit, dass die Ergebnisse nicht definiert sind, wenn Sie ein Argument übergeben, das nicht als vorzeichenloses Zeichen oder gleich dem Wert des Makro-EOF dargestellt werden kann. Das Problem tritt nicht auf, wenn es so verwendet wird, wie es beabsichtigt war. Das Problem ist, dass es für den Zweck ungeeignet ist, auf den Sie es anscheinend anwenden.
Immerhin sind alle gängigen Unicode-Kodierungen unterschiedlich breit, ob Programmierer es realisieren oder nicht: UTF-7, UTF-8, UTF-16 auch wie ältere Standards wie Shift-JIS
isspace () ist nicht für Unicode definiert. Sie benötigen eine Bibliothek, die für die Verwendung einer bestimmten Codierung ausgelegt ist. Diese Frage Was ist die beste Unicode-Bibliothek für C? kann relevant sein.
Tags und Links c c++ character-encoding special-characters