Inhaltsverzeichnis
Wahrscheinlich wird jede Industrie erwachsen. Im Rückblick auf das letzte Jahrzehnt ist einer der wesentlichsten Bereiche dieses Erwachsenwerdens die Möglichkeit, dass jeder einen Computer bedienen kann. Das war nicht immer so, tatsächlich war es vor gar nicht allzu langer Zeit üblich, dass Software exklusiv für das Land geschrieben wurde, in dem sie verwendet werden sollte.
Von all den Anstrengungen, die unternommen wurden, um eine native Sprachunterstützung für alle Computer-Nutzer zur Verfügung zu stellen, ist den Anstrengungen der Openi18n-Organisation besondere Beachtung zu schenken.
Samba-2.x unterstützte ein einzelnes Locale durch einen Mechanismus namens codepages. Samba-3 ist dazu bestimmt, eine echte transglobale Plattform für die Datei- und Druckerfreigabe zu werden.
Computer kommunizieren in Zahlen. Jede Zahl wird in einen korrespondierenden Buchstaben übersetzt. Die Bedeutung, die einer entsprechenden Zahl zugeordnet wird, hängt vom genutzten Character Set (Charset) ab.
Ein Charset kann als Tabelle angesehen werden, die dazu verwendet wird, die Nummern in entsprechende Buchstaben umzuwandeln. (Es gibt unterschiedliche Charsets mit deutschen Umlauten, japanischen Zeichen usw.) Der „American Standard Code for Information Interchange“ (ASCII) war bis heute das maßgebliche Buchstaben-Schema, das von Computern verwendet wurde. ASCII ist ein Charset, das 128 Buchstaben darstellen kann. Die Verwendung dieser Kodierung bedeutet, dass jeder Buchstabe genau ein Byte groß ist.
Es gibt auch Charsets, die erweiterte Zeichen unterstützen, aber diese brauchen zumindest doppelt so viel Speicherplatz wie die ASCII-Kodierung. Solche Zeichensätze können 256 * 256 = 65.536 Zeichen enthalten, was mehr ist, als alle möglichen Zeichen, die man sich vorstellen kann. Diese Charsets werden Multibyte-Charsets genannt, weil sie mehr als ein Byte zum Speichern eines Zeichens verwenden.
Ein standardisiertes Multibyte-Charset ist als Unicode bekannt. Ein großer Vorteil bei der Verwendung eines Multibyte-Charsets ist, dass Sie nur eines brauchen. Man muss sich nicht mehr darum kümmern, dass zwei Computer dasselbe Charset verwenden, wenn sie miteinander kommunizieren.
Alte Windows-Clients verwenden Single-Byte-Charsets namens Codepages von Microsoft. Es gibt jedoch keine Unterstützung für das Aushandeln des Charsets im SMB/CIFS-Protokoll. Daher müssen Sie gewährleisten, dass Sie den richtigen Zeichensatz verwenden, wenn Sie mit einem älteren Client arbeiten. Neuere Clients (Windows NT, 200x, XP) verwenden bereits Unicode im Netzwerk.
Seit Samba-3 kann Samba Unicode über das Netzwerk verwenden (und tut es auch). Intern kennt Samba drei Typen von Zeichensätzen:
Dies ist der Zeichensatz, der intern von Ihrem Betriebssystem verwendet wird. Die Voreinstellung ist UTF-8, was passend für die meisten Systeme ist und alle Zeichen aller Sprachen abdeckt. Die Voreinstellung in älteren Samba-Versionen war ASCII.
Dies ist der Zeichensatz, den Samba verwendet, um Meldungen auf Ihrem Bildschirm anzuzeigen. Er sollte allgemein derselbe sein wie unix charset.
Dies ist der Zeichensatz, den Samba verwendet, um mit DOS- und Windows 9x/Me-Clients zu kommunizieren. Mit allen neueren Clients wird Unicode gesprochen. Die Voreinstellung hängt von den auf Ihrem System installierten Zeichensätzen ab. Führen Sie testparm -v | grep „dos charset“ aus, um den Standard-Zeichensatz auf Ihrem System angezeigt zu bekommen.
Da vorhergehende Samba-Versionen keinerlei Zeichensatz-Konvertierung vorgenommen haben, sind die Zeichen in den Dateinamen üblicherweise im UNIX-Charset nicht korrekt, sondern nur im lokalen Zeichensatz, der von den DOS/Windows-Clients verwendet wird.
Bjoern Jacke hat ein Werkzeug namens convmv geschrieben, das mit einem einzelnen Befehl ganze Verzeichnisstrukturen in andere Zeichensätze konvertiert.
Das Einrichten japanischer Zeichensätze ist ziemlich schwierig. Das liegt hauptsächlich an Folgendem:
Der Windows-Zeichensatz ist nicht originalen japanischen Standard-Zeichensatz hinaus erweitert (JIS X 0208) und nicht standardisiert worden. Das bedeutet, dass die strikt standardisierte Implementierung nicht den vollen Windows-Zeichensatz unterstützen kann.
Es gibt einige japanische Codierungsmethoden, die, hauptsächlich aus historischen Gründen, nicht vollständig kompatibel zueinander sind. Es gibt zwei Hauptcodierungen. Die eine ist die Serie Shift_JIS, die in Windows und einigen UNIX-Varianten verwendet wird; die andere ist die Serie EUC-JP, die in den meisten UNIX-Varianten und in Linux verwendet wird. Außerdem hat Samba früher auch einige einzigartige Codierungen namens CAP und HEX angeboten, um die Interoperabilität mit CAP/NetAtalk und UNIX-Varianten, die keine japanischen Dateinamen verwenden können, zu gewährleisten. Einige Implementationen der Serie EUC-JP unterstützen nicht den vollen Windows-Zeichensatz.
Es gibt einige Umwandlungstabellen zwischen Unicode und überlieferten japanischen Zeichensätzen. Eine ist kompatibel mit Windows, eine andere basiert auf der Referenz des Unicode-Konsortiums, wieder andere sind gemischte Implementationen. Das Unicode-Konsortium definiert offiziell keine solchen Umwandlungstabellen, also kann es auch keine Standard-Tabelle geben.
Der Zeichensatz und die Umwandlungstabellen, die in iconv() verfügbar sind, basieren auf der verfügbaren iconv-Library. Zusätzlich können sich die japanischen Locale-Namen auf den verschiedenen Systemen unterscheiden. Das bedeutet, dass der Wert der Zeichensatz-Parameter von der von Ihnen verwendeten Implementation von iconv() abhängt.
Obwohl in Windows intern die Codierung „2 byte fixed UCS-2“ verwendet wird, wird in japanischen Umgebungen üblicherweise die Shift_JIS-Codierung so verwendet, wie in englischsprachigen Umgebungen ASCII.
dos charset und display charset sollten auf das Locale gesetzt werden, das kompatibel zu dem Zeichensatz und zu der Codierung ist, die unter Windows eingesetzt werden. Das ist üblicherweise CP932, hat aber manchmal einen anderen Namen.
unix charset kann entweder Shift_JIS, EUC-JP oder UTF-8 sein. UTF-8 ist immer verfügbar, aber die Verfügbarkeit anderer Locales und deren Namen hängen vom verwendeten System ab.
Sie können zusätzlich erwägen, die Serie Shift_JIS als Wert des Parameters unix charset zu verwenden, indem Sie das Modul vfs_cap verwenden, das dasselbe bewirkt wie das Setzen des Parameters „coding system = CAP“ in der Samba-Serie 2.2.
Wie man unix charset setzt, ist eine schwierige Frage. Die folgenden führt neben weitern Details die Vor- und Nachteile bei der Verwendung der verschiedenen Werte auf.
Die Shift_JIS-Serie ist ein Locale, das äquivalent zu Shift_JIS ist und als Standard im japanischen Windows verwendet wird. Im Falle von Shift_JIS würde ein Dateiname, der aus 0x8ba4 und 0x974c (einem japanisches 4-Byte-Zeichen, das „Freigabe“ bedeutet) und „.txt“ besteht und von Windows aus auf Samba geschrieben wird, unter UNIX zu 0x8ba4, 0x974c, „.txt“ werden (einem 8-Byte-Binär-String) wie unter Windows.
Die Shift_JIS-Serie wird üblicherweise in kommerziellen UNIX-Varianten, HP-UX und AIX als japanisches Locale verwendet. (Es ist jedoch auch möglich, die Serie EUC-JP zu verwenden.) Um die Shift_JIS-Serie auf diesen Plattformen zu verwenden, kann man die von Windows angelegten japanischen Dateinamen auch unter UNIX verwenden.
Wenn Ihr UNIX bereits mit Shift_JIS arbeitet und es einen Benutzer gibt, der japanische Dateinamen verwenden muss, die von Windows aus geschrieben werden, ist die Shift_JIS-Serie die beste Wahl. Es könnten jedoch beschädigte Dateinamen angezeigt werden, und einige Befehle, die nicht mit Nicht-ASCII-Dateinamen umgehen können, könnten bei der Analyse der Dateinamen abgebrochen werden. Insbesondere könnten „\ (0x5c)“ in Dateinamen vorkommen, mit denen besonders vorsichtig umgegangen werden muss. Also sind Sie besser beraten, Dateinamen, die von Windows auf UNIX geschrieben werden, nicht zu ändern.
Beachten Sie, dass die meiste freie Software, die „japanisiert“ wurde, nur mit EUC-JP funktioniert. Sie sollten prüfen, ob diese Software auch mit Shift_JIS funktioniert.
Die EUC-JP-Serie entspricht einem Locale, das äquivalent zum Industrie-Standard EUC-JP ist, der in japanischem UNIX weit verbreitet ist (obwohl EUC auch Spezifikationen für andere Sprachen enthält, wie EUC-KR). Wenn Sie die EUC-JP-Serie einsetzen, würde ein japanischer Dateiname, der aus 0x8ba4 und 0x974c und „.txt“ besteht und von Windows auf Samba geschrieben wird, unter UNIX zu 0xb6a6, 0xcdad, „.txt“ werden (einem 8-Byte-Binär-String).
EUC-JP wird üblicherweise unter OpenSource-UNIX, Linux und FreeBSD als japanisches Locale verwendet und auf kommerziellem UNIX, Solaris, IRIX und Tru64-UNIX (obwohl es unter Solaris auch möglich ist, Shift_JIS und UTF-8 zu verwenden und unter Tru64-UNIX Shift_JIS). Um die EUC-JP-Serie zu verwenden, können die meisten japanischen Dateinamen, die von Windows angelegt wurden, auch unter UNIX verwendet werden. Außerdem arbeitet die meiste „japanisierte“ freie Software ausschließlich mit EUC-JP.
Es wird empfohlen, die Serie EUC-JP zu verwenden, wenn man japanische Dateinamen unter diesen UNIX-Varianten einsetzt.
Obwohl es kein Zeichen gibt, das ähnlich sorgfältig behandelt werden muss wie „\ (0x5c)“, können trotzdem beschädigte Dateinamen angezeigt werden, und einige Befehle, die nicht mit Nicht-ASCII-Dateinamen umgehen können, könnten bei der Analyse der Dateinamen abgebrochen werden.
Außerdem können, wenn Sie Samba mit einer anderen installierten libiconv kompiliert haben, das in libiconv enthaltene eucJP-ms-Locale und das im Betriebssystem enthaltene EUC-JP-Serien-Locale eventuell inkompatibel sein. In diesem Fall sollten Sie inkompatible Zeichen in Dateinamen vermeiden.
UTF-8 entspricht einem Locale, das äquivalent zu UTF-8 ist, dem internationalen Standard, der vom Unicode-Konsortium definiert wurde. In UTF-8 ist ein Zeichen durch 1-3 Bytes beschrieben. Im Falle von Japanisch werden die meisten Zeichen durch 3 Bytes beschrieben. Da unter Windows zur Darstellung von Japanisch Shift_JIS verwendet wird, wo ein Zeichen durch 1 oder 2 Bytes repräsentiert wird, wächst prinzipiell die Byte-Länge eines UTF-Strings auf die 1,5-fache Länge des originalen Shift_JIS-Strings an. Im Falle von UTF-8 wird ein japanischer Dateiname, der aus 0x8ba4, 0x974c und „.txt“ besteht und von Windows auf Samba geschrieben wird, unter UNIX zu 0xe585, 0xb1e6, 0x9c89, „.txt“ (einem 10-Byte-Binär-String).
Auf Systemen, wo iconv() nicht verfügbar oder inkompatibel zu Windows ist, ist UTF-8 das einzige verfügbare Locale.
Es gibt keine Systeme, die UTF-8 als voreingestelltes Locale für Japanisch benutzen.
Es könnten beschädigte Dateinamen angezeigt werden; und einige Befehle, die nicht mit Nicht-ASCII-Dateinamen umgehen können, könnten bei der Analyse der Dateinamen abgebrochen werden, besonders wenn „\ (0x5c)“ in Dateinamen vorkommen, womit vorsichtig umgegangen werden sollte. Also rühren Sie Dateinamen, die von Windows auf UNIX geschrieben wurden, besser nicht an.
Zusätzlich gilt (obwohl das nicht direkt mit Samba zu tun hat): Da es einen feinen Unterschied zwischen der Funktion iconv(), die allgemein unter UNIX verwendet wird, und den Funktionen auf anderen Plattformen wie Windows und Java gibt (was die Umwandlungstabelle zwischen Shift_JIS und Unicode betrifft), sollten Sie vorsichtig im Umgang mit UTF-8 sein.
Obwohl Mac OS X UTF-8 als seine Codierung für Dateinamen einsetzt, verwendet es eine erweiterte UTF-8-Spezifikation, mit der Samba nicht umgehen kann. Also ist das UTF-8-Locale nicht für Mac OS X verfügbar.
Die CAP-Codierung ist eine Spezifikation, die in CAP und NetAtalk verwendet wird (beides sind Dateiserver für Macintosh-Rechner). Im Falle der CAP-Codierung wird ein japanischer Dateiname, der aus 0x8ba4, 0x974c und „.txt“ besteht und von Windows auf Samba geschrieben wird, unter UNIX zu „:8b:a4:97L.txt“ (einem 14-Byte-ASCII-String).
In der CAP-Codierung wird ein Byte, das nicht als ASCII-Zeichen dargestellt werden kann (0x80 oder höher), als „:xx“ codiert. Sie müssen darauf achten, „\(0x5c)“ in Dateinamen zu verwenden, aber die Dateinamen werden nicht beschädigt, wenn ein System nicht mit Nicht-ASCII-Dateinamen umgehen kann.
Der größte Verdienst der CAP-Codierung ist die Kompatibilität der Codierung mit CAP und NetAtalk. Da CAP und NetAtalk üblicherweise die Dateinamen auf UNIX mit CAP-Codierung schreiben, müssen Sie die CAP-Codierung einsetzen, wenn ein Verzeichnis sowohl mit Samba als auch mit NetAtalk freigegeben wird, um beschädigte Nicht-ASCII-Dateinamen zu vermeiden.
Es gibt jedoch einige Systeme, auf denen NetAtalk gepatcht wurde, um Dateinamen mit EUC-JP zu schrieben (z.B. japanisches Vine-Linux). Hier müssen Sie statt CAP EUC-JP verwenden.
vfs_cap selbst ist für Nicht-Shift_JIS-Locales verfügbar, die nicht mit Nicht-ASCII-Zeichen umgehen können, oder für Systeme, die Dateien mit NetAtalk freigeben.
Um die CAP-Codierung mit Samba-3 zu verwenden, sollten Sie den Parameter unix charset und VFS wie folgt verwenden:
Beispiel 27.1. VFS-CAP
| [global] |
| dos charset = CP932 Der Name des Locale CP932 könnte auch anders lauten |
| unix charset = CP932 |
... |
| [cap-share] |
| vfs option = cap |
Sie sollten den Parameter unix charset auf CP932 setzen, wenn Sie GNU libiconv verwenden. Dadurch werden die Dateinamen in der Freigabe „cap-share“ mit CAP-Codierung geschrieben.
Dieser Abschnitt enthält noch zusätzliche Informationen zu individuellen Implementierungen:
Damit libiconv sauber mit Japanisch umgeht, sollten Sie den Patch libiconv-1.8-cp932-patch.diff.gz auf libiconv-1.8 anwenden.
Wenn Sie das gepatchte libiconv-1.8 verwenden, sind folgende Einstellungen verfügbar:
dos charset = CP932 unix charset = CP932 / eucJP-ms / UTF-8 | | | +-- EUC-JP Serie +-- Shift_JIS Serie display charset = CP932
Andere japanische Locales (z.B. Shift_JIS und EUC-JP) sollten wegen mangelnder Kompatibilität zu Windows nicht verwendet werden.
Damit die GNU glibc sauber mit Japanisch umgeht, sollten Sie den Patch auf glibc-2.2.5/2.3.1/2.3.2 anwenden oder die „patch-merged“-Versionen, glibc-2.3.3 oder später, einsetzen.
Bei der Verwendung der oben genannten glibc sind folgende Einstellungen verfügbar:
| dos charset = CP932 |
| unix charset = CP932 / eucJP-ms / UTF-8 |
| display charset = CP932 |
Andere japanische Locales (z.B. Shift_JIS und EUC-JP) sollten wegen mangelnder Kompatibilität zu Windows nicht verwendet werden.
Vor den Samba-2.2-Releases wurde der Parameter „coding system“ wie der Parameter unix charset in Samba-3 verwendet. ??? zeigt die Zuordnungstabelle, wenn man von Samba-2.2 auf Samba-3 migriert.
Tabelle 27.1. Japanische Zeichensätze in Samba-2.2 und Samba-3
| Samba-2.2-Kodierungssystem | Samba-3-Unix-Charset |
|---|---|
| SJIS | Shift_JIS-Serie |
| EUC | EUC-JP-Serie |
| EUC3[a] | EUC-JP-Serie |
| CAP | Shift_JIS-Serie + VFS |
| HEX | derzeit kein Zeichensatz vorhanden |
| UTF8 | UTF-8 |
| UTF8-Mac[b] | derzeit kein Zeichensatz vorhanden |
| andere | derzeit kein Zeichensatz vorhanden |
[a] Existiert nur in der japanischen Samba-Version [b] Existiert nur in der japanischen Samba-Version | |
„Samba beschwert sich über eine fehlende Datei CP850.so.“
Antwort: CP850 ist die Voreinstellung für dos charset. Das dos charset wird zur Umwandlung von Daten in die Codepage verwendet, die Ihre DOS-Clients verwenden. Wenn Sie keine DOS-Clients haben, können Sie diese Meldung getrost ignorieren.
CP850 sollte von Ihrer lokalen iconv-Implementation unterstützt werden. Stellen Sie sicher, dass Sie alle erforderlichen Pakete installiert haben. Wenn Sie Samba aus dem Quelltext kompiliert haben, prüfen Sie, dass configure iconv gefunden hat.