{"id":55000280,"date":"2015-06-01T00:00:00","date_gmt":"2020-01-24T15:59:21","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=280"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Kodierte_Texte_mit_VBA_umwandeln","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Kodierte_Texte_mit_VBA_umwandeln.html","title":{"rendered":"Kodierte Texte mit VBA umwandeln"},"content":{"rendered":"

Auch wenn die Assistenten von Access zum Import und Export von Textdateien über ihre Einstellungsseiten genügend Möglichkeiten bieten, um mit allen erdenklichen Formaten zurechtzukommen, gibt es häufig Situationen, in denen die Verarbeitung über VBA-Programmierung benötigt wird. Hier geht es in erster Linie um den Umgang mit Texten in unterschiedlicher Sprachkodierung.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1503_Textumwandlung.mdb<\/b>.<\/p>\n

Sprachen, Codepages, CharacterSets<\/h2>\n

Beleuchten wird zunächst, was es mit den Sprachcharakteristiken von Textdateien auf sich hat. Wenn Sie sich eingehender mit Textformaten beschäftigen – Stichwort Internationalisierung -, so begegnen Sie immer wieder Begriffen, wie Language Id<\/b>, Locale Identifier<\/b> (LCID<\/b>), Codepage<\/b>, Unicode<\/b> und Character Set<\/b>. Jeder hat seine eigene Bedeutung und doch hängen alle irgendwie miteinander zusammen. Grundsätzlich geht es dabei nicht nur um Textdateien, sondern generell um den Umgang mit Texten im System. Betroffen sind damit etwa die Tastatur, die Textausgabe auf dem Bildschirm, Schriftarten, oder auch die Interaktion mit dem Internet.<\/p>\n

An oberster Stelle steht die Sprache eines Textes, die wiederum einer Gruppe von Sprachen angehören kann. Deutsch etwa gehört zur Gruppe Westeuropa und USA<\/b>. Windows unterstützt von Haus aus mehrere Sprachgruppen und Sprachen. Dabei gibt es einen Unterschied zwischen nur unterstützten und den installierten Sprachen. Während es genau 17 Gruppen gibt, kann die Zahl der zugehörigen Sprachen selbst variieren. Für den Umgang mit Texten ist die Gruppierung weniger interessant, denn sie betrifft vor allem die Tastaturbelegung, die in der Regel pro Sprachgruppe eindeutig ist.<\/p>\n

Welche Sprachen Windows unterstützt können Sie mit einem Doppelklick auf die Tabelle tblLCIDs<\/b> der Beispieldatenbank herausfinden (siehe Bild 1). In der zweiten Spalte finden Sie die Sprache, in der dritten das zugehörige Land. Auf die Bedeutung der vierten (CP<\/b>) kommen wir noch zu sprechen. Das Feld LCID<\/b> legt die eindeutige Id der Sprache fest. Diese Zahl werden Sie häufiger unter Windows finden. Schauen Sie etwa in den Order von Microsoft Office<\/b> im Explorer zu Ihrer Office-Version. Dort werden Sie als Unterverzeichnisse die von Ihrem Office unterstützten Sprachen als LCID<\/b> finden. Die 1033<\/b> für Englisch (USA<\/b>) ist immer mit dabei, die 1031<\/b> für Deutsch wahrscheinlich auch. In diesen Verzeichnissen befinden sprachspezifische Ressourcen für Office. Installieren Sie etwa zusätzlich die Rechtschreibprüfung für Französisch, so entsteht hier ein weiterer Ordner mit dem Namen 1036<\/b>.<\/p>\n

\"Inhalt<\/a><\/p>\n

Bild 1: Inhalt der Tabelle tblLCIDs mit den von Windows unterstützten Sprachen<\/p>\n

Ist die Sprache mit ihrer LCID<\/b> noch eindeutig, so ist es das Land nicht. Filtern Sie die Tabelle nach dem Land Deutschland<\/b>, so ergeben sich vier Datensätze, unter denen sich etwa auch das sehr spezielle Niedersorbisch<\/b> befindet.<\/p>\n

Der Inhalt dieser Tabelle ist keineswegs in Stein gemeißelt. Je nach Windows-Version, -Installationsoptionen und -Sprache kann sie andere Datensätze aufweisen. Sie können die Tabelle auf Ihrem System selbst erstellen. Dazu gibt es im VBA-Modul mdlTextconverter<\/b> der Beispieldatenbank eine Prozedur EnumLanguageGroupsLocales<\/b>. die Sie aus dem Direktfenster des VBA-Editors heraus aufrufen können. Sie löscht zunächst den Inhalt der Tabelle und erstellt ihn dann über verschiedene API-Funktionen neu. Es gibt allerdings keine API-Funktion, die die Sprachen direkt aufzählen könnte. Erst müssen die einzelnen Sprachgruppen ermittelt (EnumLanguageGroups<\/b>), in einer Collection zwischengespeichert und anschließend der Sprach-Enumeration übergeben werden. In Listing 1 sehen Sie den Code der Prozedur, der hier nur exemplarisch angeführt wird.<\/p>\n

Sub <\/span>EnumLanguageGroupsLocales()\r\n     Dim <\/span>vID As Variant<\/span>\r\n     \r\n     Set<\/span> colInfo = New<\/span> VBA.Collection\r\n     CurrentDb.Execute \"DELETE FROM tblLCIDs\"\r\n     CurrentDb.Execute \"INSERT INTO tblLCIDs(LCID,Language,Country,CP) \" & _\r\n         \"VALUES (0,'(Unbekannt)','(Unbekanntes Land)',0)\"\r\n     \r\n     EnumLanguageGroups\r\n     For Each vID In colInfo\r\n         EnumLanguageGroupLocales AddrOf(AddressOf LanguageGroupLocalesProc), _\r\n             ByVal CLng(Val(\"&H\" & vID)), ByVal 0&, 0&\r\n     Next<\/span> vID\r\nEnd Sub<\/span><\/pre>\n
Listing 1: Prozedur zum Füllen der Tabelle tblLCIDs mit Sprachdatensätzen<\/p>\n
Denn im Rahmen dieses Beitrags würde es eindeutig zu weit führen, die nicht unkomplizierten und mit API-Aufrufen gespickten Funktionen näher zu erläutern. Und ohne API-Funktionen kommt man allein mit den Bordmitteln der VBA-, Access- und Office-Bibliotheken bei diesem Thema nicht weiter.<\/p>\n
Kommen wir zu der vierten Spalte der Tabelle mit dem Namen CP<\/b>, was ein Kürzel für Codepage<\/b> darstellt. Dort ist zu jeder Sprache die Vorgabe-Codepage<\/b> zu finden. Was aber ist eine Codepage<\/b> Dazu ein Ausflug in die binäre Speicherung von Texten: Für jedes Zeichen wird bei Single-Byte-Formaten (ANSI, OEM<\/b>) genau ein Byte festgelegt. Schreiben Sie ein A<\/b> in einen Text, so finden Sie unter einem Hex-Editor an dieser Stelle die Zahl 65. Genauso gut können Sie auch VBA bemühen:<\/p>\n
  Asc (\"A\")   -> 65\r\n Chr (65) -> \"A\"<\/pre>\n
Die 65 <\/b>kennzeichnet, welches Zeichen innerhalb der deutschen Sprach-Codepage zu finden ist. Eine Codepage<\/b> ist damit imgrunde eine Tabelle mit 255 Datensätzen, die jeder Position ein bestimmtes Zeichen zuordnet. Und eben diese Position ist, je nach Sprache, unterschiedlich.  So ermitteln Sie etwa für ein ü<\/b> den Code 220<\/b>. In Russland aber kennt man kein ü<\/b>. Die dort verwendete Codepage<\/b> ordnet der 220 ein anderes, ein kyrillisches Zeichen zu. Ein Text in deutscher Sprache mit Umlauten wird dort falsch dargestellt, wenn er mit dem russischen Notepad<\/b> geöffnet wird. Ein russisches Word<\/b> hingegen wird beim öffnen der Textdatei nachfragen, welche Codepage<\/b> zu verwenden ist, und erst nach Einstellung von Westeuropa (Windows)<\/b> das korrekte Ergebnis zeitigen.<\/p>\n
Die Codepage<\/b> ist also die zentrale Schaltstelle, wenn es um Textverarbeitung geht. Erst sie ermöglicht es, einem Byte-Code ein bestimmtes Zeichen zuzuordnen.<\/p>\n
Nun braucht es nicht für jede einzelne Sprache eine gesondert Codepage. Die ANSI<\/b>–Codepage<\/b> für Westeuropa (1252<\/b>) etwa kennt fast alle benötigten Zeichen für die Sprachen Europas, also die deutschen Umlaute und die französischen oder spanischen Akzente.<\/p>\n
Es ist demnach ökonomischer, mehreren Sprachen eine Codepage zuzuweisen. So steht in der CP<\/b>-Spalte der Sprachtabelle für Deutsch, Italienisch, Französisch, Spanisch, Englisch überall die 1252<\/b>. Filtern Sie die Tabelle nach diesem Wert: Erstaunlicherweise gibt es über Hundert Sprachen, die sich diese Codepage<\/b> teilen.<\/p>\n
Nun kann man sich eine Zahl als Bezeichner für eine Codepage<\/b> nur schwer merken. Deshalb haben Codepages auch Namen. öffnen Sie die Tabelle tblCodepages<\/b> der Beispieldatenbank (siehe Bild 2). Sie finden dort unter dem Feld Description<\/b> die Bezeichnungen der Codepages<\/b>. Die 1251<\/b> nennt sich exakt ANSI – Lateinisch I<\/b>. Das ist gut zu wissen, denn eine Bezeichnung mit dem Teilinhalt Westeuropa<\/b> werden Sie nämlich vergeblich suchen.<\/p>\n
\"Inhalt<\/a><\/p>\n
Bild 2: Inhalt der Tabelle tblCodepages<\/p>\n
In der Tabelle sind allerlei kryptische Codepages<\/b> aufgeführt, die zum großen Teil veraltet und nicht mehr in Gebrauch sind.<\/p>\n
Sie werden sie unter Umständen dennoch benötigt, wenn Sie es mit Textdateien zu tun haben, die aus IT-Urzeiten stammen, wie die IBM<\/b>-Codes. Eher noch treffen Sie auf Texte von MS-DOS-Systemen, die in der Tabelle durch das Präfix OEM<\/b> gekennzeichnet sind.<\/p>\n
Es gibt überdies ein Problem mit diesen Bezeichnungen, die leider nicht so eindeutig sind. Die Bezeichnungen in der Tabelle sind das Resultat einer Windows-API-Funktion, die in der Prozedur GetCPName<\/b> der Beispieldatenbank zum Einsatz kommt:<\/p>\n
  GetCPName (1252) \r\n- > \"(ANSI - Lateinisch I)\"<\/pre>\n
Mithilfe dieser Prozedur und derjenigen zum Auflisten der Codepages<\/b> (EnumCodepages<\/b>), aufgerufen aus dem VBA-Direktfenster, können Sie den Inhalt der Tabelle neu erstellen. Wie wir noch sehen werden, gibt es aber auch noch die Möglichkeit, sich über DAO<\/b> und die Access Database Engine<\/b> alle Codepages<\/b> ausgeben zu lassen. Dieses Ergebnis gibt die Tabelle tblCodepagesDAO<\/b> wieder. Und dort steht für die Codepage<\/b> 1252<\/b> die Bezeichnung Westeuropäisch (Windows)<\/b>. Damit Sie alle Sprachen, die zugehörigen Default-Codepages<\/b> und deren Bezeichnungen im Blick haben, fasst die Abfrage qry_LCID_CP<\/b> die drei besprochenen Tabellen zusammen und gibt sie wie in Bild 3 wieder. Sie sollte genügen, um aus einer Bezeichnung die zugehörige Codepage zu identifizieren. Denn diese Bezeichnungen listen etwa die Kombinationsfelder von Access oder Word auf, wenn es um die Auswahl einer Codepage<\/b> geht.<\/p>\n
\"Alle<\/a><\/p>\n
Bild 3: Alle Sprachen und deren Codepages gibt die Abfrage qry_LCID_CP aus<\/p>\n
Zuletzt fehlt noch die Erläuterung des Begriffs Character Set<\/b>, zu Deutsch Zeichensatz. Die Zuordnung der Bytes eines Textes zu bestimmten Zeichen über die Codepage ist das Eine, die visuelle Darstellung dieses Zeichens über Schriften das Andere. Eine Schriftart kann mit der Codepage allein noch nichts anfangen. Der Satz von darstellbaren Zeichen ist durch den Zeichensatz definiert. Die wiederum ist ebenfalls über eine bestimmte Nummer gekennzeichnet. Die Funktion CharSetFromCP<\/b> der Beispieldatenbank nimmt als Parameter eine Codepage entgegen und gibt die ID des zugehörigen Zeichensatzes zurück:<\/p>\n
  CharSetFromCP(1252)\r\n  -> 0 (Deutsch, System-Zeichensatz)\r\n  CharSetFromCP(1251)\r\n -> 204 (Russisch, Kyrillisch)<\/pre>\n
Das Ergebnis 0 bedeutet, dass es sich um den Vorgabezeichensatz des installierten Systems handelt. Um kyrillische Zeichen darzustellen, benötigen Sie das CharacterSet 204. <\/p>\n
Die Standardschriftarten von Windows, wie Arial<\/b>, Times New Roman<\/b>, Courier New<\/b>, et cetera, enthalten alle diese Zeichen. Die Nummer des Zeichensatzes identifiziert dann, welcher Block von Zeichen zu verwenden ist.<\/p>\n
Unicode<\/h2>\n
Bisher ging es nur im Texte im Single-Byte-Format<\/b>, wobei ANSI<\/b> der Standard ist. Die Beschränkung auf 256 mögliche Zeichen durch ein Byte führt hier zum beschriebenen System mit den LCIDs<\/b> und Codepages<\/b>, welches einige Kopfschmerzen bereiten kann. Um einiges angenehmer ist da das Unicode<\/b>-Format, das jedem Zeichen mehrere Bytes spendieren kann.<\/p>\n
Bei UTF-16<\/b> sind das pro Zeichen in der Regel zwei Bytes. Dadurch steigt die Zahl zuordenbarer Zeichen auf 2^16, was für alle Zeichen dieser Welt ausreicht. Um Codepages<\/b> müsste man sich im Prinzip keine Gedanken mehr machen, wenn alle Texte in diesem Format gespeichert wären. Allerdings bedeutet diese Erweiterung noch nicht, dass damit auch die Sprache des Textes bekannt ist und welcher Zeichensatz zur Darstellung kommen soll. Insofern behält das System um LCIDs<\/b>, Codepages<\/b> und Charactersets<\/b> weiterhin seine Bedeutung.<\/p>\n
Bei UTF-8 <\/b>wird es komplizierter, weil ein Zeichen meist ein Byte belegt, aber bei spezielleren Zeichen bis zu vier. Der Beginn eines Mehr-Byte-Zeichens wird durch bestimmte Flag-Bytes eingeleitet.<\/p>\n
Dasselbe gilt für das wenig verbreitete UTF-7<\/b>, welches eine noch komplexere Kodierung vorsieht, denn ein Zeichen wird hier durch nur 7 Bits eines Bytes identifiziert. Infolgedessen sind speziellere Zeichen durch eine ganze Kette von Byte-Anweisungen repräsentiert.<\/p>\n
Eigentlich ist das UTF-8<\/b>-Format das optimalste, weil es alle Zeichen darstellen kann, aber wenig Platz benötigt. Weil es jedoch durch variable Byte-Anzahl pro Zeichen etwas schwieriger zu handhaben ist, verwendet VBA ausschließlich das UTF-16<\/b>-Format. Tatsächlich sind alle Strings unter VBA solche Unicode-Strings. Das lässt sich leicht nachweisen. Während die Funktion Len<\/b> die Zahl der Zeichen eines Strings zurückgibt, ermittelt LenB<\/b> die Anzahl der Bytes, die dafür benötigt werden. Sie gibt grundsätzlich das Doppelte aus:<\/p>\n
  Len<\/span> (\"ACCESS\")  -> 6\r\n LenB (\"ACCESS\") ->12<\/pre>\n
Intern steht dieser Text mit diesen Bytes im Speicher:<\/p>\n
65 - 0 - 67 - 67 - 0 - 69 - 0 - 83 -0 - 83 - 0<\/pre>\n
Das macht auch schon deutlich, dass UTF-16<\/b> zur Speichervergeudung neigt. Der häufigste Wert in diesen Strings ist 0. Da Strings in Textfeldern seit Access 2000 ebenfalls grundsätzlich in UTF-16 gespeichert sind, sieht Access die Möglichkeit vor, für diese Felder als Eigenschaft die Unicode-Kompression einzuschalten, um Speicherplatz zu sparen. Die Kompression elimiert die ganzen Nullen und führt intern zu einem Format, das UTF-8 ähnelt.<\/p>\n
Es gibt also einige Varianten von Unicode<\/b>, und bei Unicode-Textdateien kommt noch ein weiterer Stolperstein hinzu. Es gibt zum einen solche Dateien, die die Bytes vertauschen. Der String oben sieht dann so aus:<\/p>\n
0 - 65 - 0 - 67 - 67 - 0 - 69 - 0 - 83 -0 - 83 <\/pre>\n
Hier handelt es sich um die LE-Variante (Low Endian<\/b>), während VBA die BE-Variante (Big Endian<\/b>) nutzt. Zum anderen kann eine Unicode-Datei noch sogenannte Lead-Bytes<\/b> ganz zu Anfang beherbergen, die sie eindeutig als im Unicode-Format kodiert kennzeichnen soll. Das ist im Allgemeinen die Byte-Folge 255, 254 oder 254, 255, je nachdem, ob es sich um Big Endian<\/b> oder Low Endian <\/b>handelt. Bei UTF-8<\/b> stehen hier sogar 3 Lead-Bytes<\/b>.<\/p>\n
All dies macht klar, dass auch Textdateien im Unicode-Format Probleme bescheren können. Damit VBA mit Strings korrekt umgehen kann, müssen diese immer in UTF-16 vorliegen. Auch alle Steuerelemente, etwa die Textbox, erwarten dieses Format, sonst kommt es zu seltsamen Zeichenfolgen. <\/p>\n
Texte konvertieren<\/h2>\n
Die wichtigste VBA-Funktion zur Umwandlung von ANSI<\/b> in Unicode<\/b> und zurück ist StrConv<\/b>:<\/p>\n
  StrConv (\"ACCESS\", vbUnicode)\r\n-> \"A C C E S S\"\r\n  StrConv (\"ACCESS\", vbFromUnicode)\r\n-> \"\"<\/pre>\n
Da der übergebene String bereits im Unicode-Format vorliegt, verdoppelt VBA nicht nur das Zeichen-Byte, sondern auch die interne Null, was zu drei Nullen führt, die als Leerzeichen ausgegeben werden. Umgekehrt bildet sich bei der Konvertierung aus Unicode nach ANSI zwar eine gültige Byte-Folge, die aber von VBA nicht angezeigt werden kann, was durch die Fragezeichen deutlich wird. Kombinieren Sie beide Funktionen, so erhalten Sie ein sinnvolles Ergebnis und den Nachweis, dass bei der Konvertierung nach ANSI nichts verloren ging:<\/p>\n
  StrConv(StrConv(\"ACCESS\", _         vbFromUnicode),vbUnicode)\r\n- > \"ACCESS\"<\/pre>\n
Eine Besonderheit von StrConv<\/b> ist, dass es nicht nur Strings als Parameter entgegennimmt, sondern auch Byte-Arrays. Oder aus Byte-Arrays wieder Strings erzeugen kann:<\/p>\n
Dim <\/span>bin() As Byte<\/span>\r\nbin = StrConv(\"ACCESS\", vbFromUnicode)\r\n  UBound<\/span>(bin)  '-> 5 = 6 Bytes\r\n  StrConv(bin, vbUnicode)\r\n-> \"ACCESS\"<\/pre>\n
über Byte-Arrays können Strings so am einfachsten manipuliert werden.<\/p>\n
Ein weiterer Parameter von StrConv<\/b>, der optional angegeben werden kann, ist LCID<\/b>. Damit kann eine Sprache festgelegt werden, in die der String konvertiert werden soll und umgekehrt. Das macht es möglich einen String von einer Sprach-Id in die andere umzuwandeln. Die Funktion ConvertUnicodeToUnicode<\/b> (Listing 2) der Beispieldatenbank macht sich das zunutze. Hier wird aus dem übergebenen Text zunächst ein Byte-Array erzeugt. Dabei wird der Parameter LCID<\/b> weggelassen, was bedeutet, dass StrConv<\/b> die Sprach-Id des Systems verwendet und damit einen westeuropäischen Text. Beim Zurückverwandeln in einen String als Rückgabe der Funktion jedoch wird die LCID<\/b> eingesetzt, die als optionaler Parameter übergeben wurde. Rufen Sie die Funktion etwa so auf:<\/p>\n
Public Function <\/span>ConvertUnicodeToUnicode(ByVal sText As String<\/span>, _\r\n     Optional<\/span> lLCID As Long<\/span>) As String<\/span>\r\n     Dim <\/span>bin() As Byte<\/span>\r\n     \r\n     On Error GoTo<\/span> Fehler\r\n     If <\/span>lLCID = 0 Then<\/span> lLCID = GetSystemDefaultLangID\r\n     bin = StrConv(sText, vbFromUnicode)\r\n     ConvertUnicodeToUnicode = StrConv(bin, vbUnicode, lLCID)\r\n     Exit Function<\/span>\r\n     \r\nFehler:\r\n     MsgBox<\/span> \"Ungültige Sprach-ID (LCID)\", vbCr<\/span>itical\r\nEnd Function<\/span><\/pre>\n
Listing 2: Funktion zum Konvertieren eines Textes mithilfe einer Sprach-ID  (LCID)<\/p>\n
  ConvertUnicodeToUnicode( _ \r\n\"André\",1031)<\/pre>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t