From 63d9db8438ed6b32c4a85d487c07ea31bda666e4 Mon Sep 17 00:00:00 2001 From: Adrian Kummerlaender Date: Thu, 11 Sep 2014 00:47:56 +0200 Subject: Expanded formatter embellishment templates * XHTML elements "h2" and "h3" are replaced with "h3" and "h4" respectively ** modified all existing contents accordingly ** this was done to avoid the gap between the primary heading and subheadings in the markdown depiction of the contents * fleshed out the InputXSLT project page with further information --- articles/2013-10-06_notizen_zu_cpp_und_unicode.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'articles/2013-10-06_notizen_zu_cpp_und_unicode.md') diff --git a/articles/2013-10-06_notizen_zu_cpp_und_unicode.md b/articles/2013-10-06_notizen_zu_cpp_und_unicode.md index fbc6d63..e900a66 100644 --- a/articles/2013-10-06_notizen_zu_cpp_und_unicode.md +++ b/articles/2013-10-06_notizen_zu_cpp_und_unicode.md @@ -19,7 +19,7 @@ std::string test(u8"Hellø Uni¢ød€!"); Der C++ Standard garantiert uns, dass ein solcher String in UTF-8 enkodiert wird. Auch die Ausgabe von in dieser Form enkodierten Strings funktioniert nach meiner Erfahrung - z.T. erst nach setzen der Lokale mittels _std::setlocale_ - einwandfrei. Probleme gibt es dann, wenn wir den Text als solchen näher untersuchen oder sogar verändern wollen bzw. die Ein- und Ausgabe des Textes in anderen Formaten erfolgen soll. Für letzteres gibt es eigentlich die _std::codecvt_ Facetten, welche aber in der aktuellen Version der GNU libstdc++ noch [nicht implementiert](http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011) sind. Wir müssen in diesem Fall also auf externe Bibliotheken wie beispielweise [iconv](https://www.gnu.org/software/libiconv/) oder [ICU](http://site.icu-project.org/) zurückgreifen. Auch die in der C++ Standard Library enthaltenen Templates zur String-Verarbeitung helfen uns bei Multibyte-Enkodierungen, zu denen auch UTF-8 zählt, nicht viel, da diese mit dem _char_ Datentyp und nicht mit Code-Points arbeiten. So liefert _std::string_ beispielsweise für einen UTF-8 enkodierten String, welcher nicht nur von dem in einer Code-Unit abbildbaren ASCII-Subset Gebrauch macht, nicht die korrekte Zeichenanzahl. Auch eine String-Iteration ist mit den Standard-Klassen nur Byte- und nicht Code-Point-Weise umsetzbar. Wir stehen also vor der Entscheidung eine weitere externe Bibliothek zu verwenden oder Programm-Intern vollständig auf UTF-32 zu setzen. -### Ein UTF-8 Codepoint-Iterator in C++ +## Ein UTF-8 Codepoint-Iterator in C++ Um zumindest für rein lesende Zugriffe auf UTF-8 Strings nicht gleich eine Bibliothek wie Boost oder [easl](http://code.google.com/p/easl/) verwenden zu müssen habe ich einen einfachen UTF-8 Codepoint-Iterator anhand der Spezifikation in [RFC3629](http://tools.ietf.org/html/rfc3629) implementiert. Den Quellcode dieser Klasse stelle ich auf [Github](https://github.com/KnairdA/CodepointIterator) oder in [cgit](http://code.kummerlaender.eu/CodepointIterator/tree/) als Open Source unter der MIT-Lizenz zur freien Verfügung. @@ -71,7 +71,7 @@ for ( UTF8::CodepointIterator iter(test.cbegin()); Die Dereferenzierung einer Instanz des Iterators produziert den aktuellen Code-Point als _char32\_t_, da dieser Datentyp garantiert vier Byte lang ist. Die Ausgabe eines solchen UTF-32 enkodierten Code-Points ist mir allerdings leider nur nach dem Cast in _wchar\_t_ gelungen. Dieser wird trotzdem nicht als Dereferenzierungs-Typ verwendet, da die Länge nicht fest definiert ist, sondern abhängig von der jeweiligen C++ Implementierung unterschiedlich sein kann. Dies stellt jedoch kein größeres Problem dar, da der Iterator für die interne Betrachtung von Strings und nicht zur Konvertierung für die Ausgabe gedacht ist. -### Fazit +## Fazit * UTF-8 ist die Kodierung der Wahl, da Übermenge von ASCII und kompakt für englische Texte * Nicht alle Möglichkeiten die im Standard definiert sind, sind auch implementiert -- cgit v1.2.3