Schreiben von Japanischen Schriftzeichen in Dateinamen durch Agent unter Linux

[Tode]

Ein Agent soll Daten aus einer Notes- Datenbank exportieren und legt dabei Dateien mit einem Namen an, der aus dem gekürzten Subject des Dokuments besteht. Hat alles wunderbar funktioniert. Doch nun haben wir Japanische Dokumente zu exportieren.

Hat sowas schon mal jemand gemacht?
Das Problem ist, dass die Dateinamen im Linux nur als Fragezeichen oder Kästchen ankommen...

Wir überprüfen gerade parallel, was man u.U. im Linux einstellen muss, aber vielleicht ist da ja jemand schon drüber gestolpert,
und kann auf die schnelle sagen, wo man da drehen muss...

[mezz]

locale richtig konfiguriert?

ansonsten vermutlich falsches encoding beim anlegen der dateien verwendet. ggf. reparieren mit convmv(1)

[Tode]

Sorry... aber wenn ich wüsste, wie man die locale richtig konfiguriert, hätte ich nicht gefragt...
Und convmv ist ein guter Tipp, hilft mir aber nicht wirklich weiter...

Ich versuche nochmal genauer zu beschreiben, wahrscheinlich war es zu ungenau:

Auf dem Linux host ist LANG=en_US.UTF-8

Ich starte einen Agenten, der Verzeichnisse (mit der LotusScript- Funktion mkdir) erstellt und Dateien dahin extrahiert.
Der name der Verzeichnisse ist das Subject der Dokumente (die dummerweise eben auch Double- Byte- Characters enthalten können).
Auch die Namen der extrahierten Dateien enthalten teilweise Japanische Zeichen.

Jetzt habe ich im Filesystem Dateinamen und Verzeichnisse, die nur aus Fragezeichen und Kästchen bestehen.

Was muss ich tun, damit der mkdir und der Detach in LotusScript korrekte Japanische Verzeichnisse anlegen können?

[mezz]

Ich versuche nochmal genauer zu beschreiben, wahrscheinlich war es zu ungenau:

Auf dem Linux host ist LANG=en_US.UTF-8

ok, aber welche?
hint: die können z.b. auch per user definiert sein, wenn dein server mit anderen locale settings läuft als der rest des systems ist es auch irgendwo klar das er ein anderes encoding benutzt.

[Tode]

Wir haben uns mit dem User angemeldet, unter dem der Domino- Dienst läuft. Dessen $LANG habe ich hier geposted.

Wir werden -bei Gelegenheit- versuchen, die locale dieses Benutzers Permanent auf ja_JP.eucJP zu setzen, um zu sehen, ob das was bringt.
Bis dahin schaue ich mal, ob noch jemand eine andere Idee hat...

[Pyewacket]

Ich kenne japanische Schriftzeichen nur vom Windows Notesclient her und dort werden
hierzulande nur kleine Quadrate angezeigt wenn die entsprechenden Fonts nicht installiert sind
(Unterstützung für Ostasiatische Zeichensätze). Eventuell ist das unter Linux ähnlich.

Im Filesystem sind mir die japanischen Schriftzeichen jetzt noch nicht untergekommen aber bei Datenbanktiteln
und Designelementnamen werden sie fleissig verwendet. Die zuständigen Kollegen
sind aber vor Ort, insofern können die damit umgehen.

[Mitch]

Ich kann hier auch nicht wirklich helfen, nur aus meiner Erfahrung berichten, dass es scheinbar zwei verschiedene Ebenen der Zeichensätze gibt.

Ich habe z.B. auf meinen Rechnern immer die Unterstützung asiatischer Zeichen installiert und kann auch wunderbar Dokumente lesen, schreiben oder im Web surfen.

Mit Software aus China hatte ich aber oft große Probleme, da teilweise die Installationen fehlschlugen und/oder/weil die Strings/Pfade/Oberfläche nur aus besagten Quadraten und Fragezeichen bestand(en).

Ein zweiter Haken taucht ab und an bei westlicher Software auf, die für diese Zeichensätze nicht ausgelegt sind. So kann ich die chinesisch benannten JPGs ehemaliger Kommilitonen mit dem einen Bildbetrachter ansehen, mit dem anderen aber nicht - i.e. mit einer asiatischen Notes-Installation könnte es vielleicht schon anders aussehen.

Wenn ich folgenden Code in einem Button ausführe:

Code

	fileNumber% = Freefile 
	fileName$ = "C:\Temp\中文.txt"
	Open fileName$ For Output As fileNumber%
	Print #fileNumber%, "大家好"

... dann kriege ich sowohl im Dateinamen als auch in der Datei nur die Kästchen. Es ist mir aber manuell sehr wohl möglich eine TXT-Datei mit entsprechendem Namen und Inhalt anzulegen.

Mit dem technischen Hintergrund habe ich mich aber noch nie auseinander gesetzt.

Gruß,

Mitch

[koehlerbv]

Torsten, vielleicht sollten wir morgen mal unseren grössten japanischen Kunden anzapfen? Deren IT sollte ja Bescheid wissen, und spätestens im HQ von denen gibt es auch Linux-Spezialisten für sowas.

Bernhard

[Pyewacket]

Notes verwendet für derartige Zeichensätze die LMBCS Codierung, das OS Unicode.
Da ist dann auch noch eine Umsetztabelle im Spiel.

[koehlerbv]

Die Frage ist: Was macht der Domino unter Linux oder Linux selbst aus den Codes, und wie wird es dann wieder zurückgegeben an den Domino.
Interessantes Thema, mit dem ich mich zu meiner Schande leider noch nie so richtig ernsthaft / fundiert beschäftigt habe.

Bernhard

[mezz]

Wir haben uns mit dem User angemeldet, unter dem der Domino- Dienst läuft. Dessen $LANG habe ich hier geposted.

Wir werden -bei Gelegenheit- versuchen, die locale dieses Benutzers Permanent auf ja_JP.eucJP zu setzen, um zu sehen, ob das was bringt.
Bis dahin schaue ich mal, ob noch jemand eine andere Idee hat...

ja, aber das hängt dann an der loginshell, wie startest du denn den server? manuell von dieser shell oder per script?

mach doch mal ein "load ../../../../usr/bin/locale"  auf der domino konsole.

edit: das sollte schon irgendwas mit ".utf-8" sein

[Pyewacket]

Hallo Torsten,

WIE schreibst du die Datei?
Ich hab eben etwas rumgespielt, wenn ich mit

    fh=freefile   
    Open "d:\デイジー" For Output As #fh
    Print #fh,"Hello World デイジー"
    Close #fh

unter Windows die Datei schreiben will bekomme ich im Directory und Dateiinhalt
nur die Kästchen angezeigt obwohl der Filename im Client selber korrekt angezeigt wird.

Schreibe ich die Datei dagegen mit

    Set stream = session.CreateStream
    stream.open( "d:\デイジー 2" )
    Call stream.WriteText("Hello World デイジー")
    Call stream.Close()

Dann ist sowohl die Anzeige des Verzeichnisses als auch der Dateiinhalt korrekt.
Ich habs jetzt nur mit Windows ausprobiert, ich könnte mir aber vorstellen daß sich das
unter Linux genauso verhält.

Gruss
 Peter

[pram]

Hallo Torsten,

bringt es dir vielleicht etwas, wenn du die Dateinamen mit @UrlEncode in ein normales ASCII-Format konvertierst (oder muss wirklich der japanische Name als Dateiname verwendet werden? Weil Sonderzeichen machen früher oder später ja immer wieder Probleme.)

Was machst du mit den restlichen Sonderzeichen, wie / \ ? * + ...
Und mit dem ":", der ist zwar erlaubt, erzeugt aber unter Windows einen unsichtbaren NFTS-Stream.


Gruß
Roland

[Tode]

@Peter: Leider habe ich nicht die Wahl, mit Streams zu arbeiten, es geht um Verzeichnisnamen und Attachments, die gelöst werden... Werde es trotzdem mal probieren

@Roland: Die Sonderzeichen, die in Windows nicht erlaubt sind, werden schon "gecleant"... Das ist nicht das Problem. Das konvertieren in ASCII habe ich auch schon probiert... Hilft nicht wirklich, weil ich die Dateinamen dann wieder nicht zurückgewandelt bekomme, wenn Sie erst mal da liegen...

@All: Danke für die vielen Tipps...

[Thomas Schulte]

mit schönen Grüßen von IBM ...

http://www-01.ibm.com/support/docview.wss?uid=swg21284370

Am dem Java Wrapper bin ich gerne bereit mitzuschreiben.

[Tode]

Na wunderbar... Argh...