Synchronisation: Wenn auf dem Handy Einträge geändert werden sollten sie in einem speziellen Feld als verändert markiert werden (neues Detail »Notiz« anlegen mit Inhalt »*upd« für »update«); die Änderungen werden vor einem neuen Export aus kadressbook aufs Handy dann in kadressbook manuell aufgenommen indem man die vom Handy auf dem Computer übertragene vCard-Datei nach »*upd« durchsucht und die entsprechenden Einträge in kadressbook aktualisiert.

Transfer Zusammenfassung: verwende ~/Envirionment/Sprachkommunikation/Handy.Adressbuch/vcf2nokia.sh entsprechend der in diesem Script enthaltenen Anleitung.

Transfer Diskussion: direkter Export aus kadressbook ist nicht möglich da »Datei -> Exportieren -> Export auf Mobiltelefon …« gnokii verwendet und dies keinen Upload durchführen kann. Auch »gammu –savefile VCARD10|VCARD21« ist nicht brauchbar, denn dieser Befehl dient dazu aus einer zuvor erzeugten Backup-Datei vCard-Dateien zu erzeugen. Aber es funktioniert hervorragend, ein Backup mit »gammu –backup backup.vcf -yes« zu erzeugen, dieses dann zu editieren und mit »gammu –restore backup.vcf« wieder aufzuspielen. Also ist es auch möglich, einen aus kadressbook exportierten Teil des Adressbuchs hochzuladen (das Telefon verwendet vCard 2.1). Dabei muss man allerdings einige Einschränkungen des vCard-Formats beachten sonst entsteht bei »gammu textall –restore adressbook.vcf« etwas wie:
Phonebook entry written - error
Too much entries
[ERROR 21: Function not supported by phone.]
Funktion wird nicht vom Telefon unterstützt.
[Closing]
Beschränkungen des vCard-Formats des Telefonbuchs:

• Zeilen dürfen nicht die VCF-typischen Umbrüche haben, denn Inhalte aus der zweiten und folgenden Zeilen werden nicht übernommen (oder nur dann nicht wenn UNIX-Zeilenumbrüche verwendet werden?)
• Es kann nur eine Adresse angelegt werden, weitere Adressen werden ignoriert.
• Die Informationen »Bild« und »Anrufergruppe« werden aus dem Telefon nicht in die vom Telefon exportierte vCard aufgenommen (sonst aber alle Informationen), es wird also schwierig sein sie mit dem Adressbuch abzugleichen.
• Man kann nur insgesamt 5 Telefonnummern zu einem Eintrag hinzufügen (ggf. darunter solche mit gleichem Typ), sonst erscheint »Speicher für diesen Eintrag voll«.
• Einträge können auch nicht eine beliebige Anzahl Details aufnehmen, sonst entsteht die Fehlermeldung »Too much entries«. Dabei werden evtl. nur die zulässigen Einträge gezählt. Es scheint dass die max. Anzahl der Datenbytes relevant ist, nicht die Anzahl von Einträgen an sich (meist sind 12-14 Einträge möglich).
• Die E-Mail-Adresse darf keinen Zusatz »;TYPE=PREF« haben sonst wird sie nicht mit aufgenommen (es ergibt sich aber auch kein Fehler).
• Die Einträge »FN:«, »UID:«, »BDAY:« dürfen enthalten sein, haben aber keinen Effekt.
• Ein Eintrag »ADR:« mit abweichendem Inhalt von »LABEL:« ist erlaubt, wird jedoch ignoriert. Auch der Adresstyp darf angegeben sein, wird jedoch ebenfalls ignoriert.
• »\n« darf in Einträgen enthalten sein, wird jedoch literal statt als Zeilenumbruch interpretiert
• Ein Eintrag »N:Nachname;Vorname;;;« erscheint später als »NachnameVorname« im Telefonbuch. Man sollte also den Eintrag »N:« entfernen und »FN:« zu »N:« machen vor einem Upload.
• Telefonnummern dürfen keine Leerzeichen, Buchstaben und Sonderzeichen enthalten sonst entsteht der Fehler »unknown 67«.
• Bei Telefonnummern muss der Typ ohne den Vorsatz »TYPE=« angegeben werden, sonst wird die Telefonnummer ignoriert.
• Der Zusatz »;VOICE« bei Telefonnummern wie er beim Backup aus dem Telefon generiert wird ist unnötig, es hat keinen Effekt wenn man ihn weglässt.
• Zeilen über einer bestimmten Menge Zeichen (etwa 200) führen bei der Vorverarbeitung in gammu zu Speicherzugriffsfehlern; es wird am besten sein alle Zeilen nach 76 Zeilen umzubrechen wie in kaddressbook gemacht
• Das Feld »ORG:« wird vom Telefon nicht unterstützt; es ist unnötig da sein Inhalt von kaddressbook auch noch in »FN:« aufgenommen wird.
• Es ist nicht klar was man in VCF-Dateien verwenden muss um Zeilenumbrüche in Feldern (z.B. in »LABEL:« und »NOTE:«) zu erzeugen; »\n« erscheinen als Literale, Unix-Newline-Zeichen (LF) oder DOS-Newline-Zeichen (CR+LF) bewirken dass nur die erste Zeile übernommen wird (selbst wenn die folgenden Zeilen VCF-typisch eingerückt sind). Beim Auslesen von im Telefon erzeugten Zeilenumbrüchen erscheinen diese als »=0A«, aber die Übertragung der ausgelesenen Datei zurück zum Telefon bewirkt dass dort dann »=0A« als Literal steht. Dasselbe passiert mit beliebigen Kombinationen von »=0A« (LF, ASCII 10) und »=0D« (CR, ASCII 13), alleine oder zusammen.
• Die Markierung »PREF« bei Telefonnummern hat keinen Effekt. Stattdessen wird die erste Telefonnummer jeder vCard als Standardnummer markiert. Und das obwohl bein Auslesen der vCards aus dem Telefon die Standardnummern mit »PREF« markiert sind!
• Wenn man »PREF« verwenden will (obwohl es keinen Effekt hat) so muss es als erstes verwendet werden: »TEL;HOME;PREF:2222222222« wird ignoriert, »TEL;PREF;HOME:2222222222« wird akzeptiert.
• Das Feld »LABEL:« darf kein (literales) Semikolon enthalten sonst wird es nicht akzeptiert; ein Semikolon kann auch nicht quoted printable kodiert werden (=3B), denn dann erscheint =3B als Literal.
• »LABEL:« und »NOTE:« werden nach 60 Zeichen abgeschnitten. Auch im Telefon können keine Zeichen hinzugefügt werden. Man sollte als »Straße« abkürzen und das Land nicht angeben.
• Felder mit einer zu langen Zeichenkette ohne Leerzeichen werden bereits nach 5 Zeichen abgeschnitten.
• Man sollte das Feld »PHOTO:« entfernen, nicht wegen des Telefons, sondern weil diese lange Zeile in gammu zu einem Speicherzugriffsfehler führt.
• Sonderzeichen werden UTF-8 kodiert und dann quoted-printable kodiert, “ß” hat deshalb zwei Bytes: “=C3=9F”. Siehe: www.utf8-zeichentabelle.de .
• Einbyte-Zeichen (bezogen auf UTF-8) können nicht quoted printable kodiert angegeben werden.

Gute Befehle zum Testen:

Ein vollständiger, funktionierender Eintrag mit Details aller Arten und Nummern aller Arten sieht so aus
(mit Kommentaren):

BEGIN:VCARD
VERSION:2.1
N:Formatierter Name
  # alternative Form wenn Sonderzeichen (angehängtes »ö«):
  # N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Formatierter Name =C3=B6
  # Zusatz »;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE« ist wohl auch bei anderen Textfeldern möglich.
TEL:0049123456789
  # allgemeine Nummer ohne Typ; Nummern mit gleichem Typ sind erlaubt und überschreiben sich nicht
  # die erste Nummer wird als Standardnummer verwendet
TEL;PREF;CELL:0049123456789
  # Mobiltelefon als Standardnummer; »;PREF« muss zuerst stehen, ist bei allen Typen möglich, hat keinen Effekt
TEL;FAX:0049123456789
TEL;HOME;VOICE:0049123456789
TEL;WORK;VOICE:0049123456789
EMAIL:user@example.org
URL:http://www.example.org
NOTE:Note
LABEL:Test1
ADR:Test1
  # LABEL und ADR: Postadresse 1
LABEL:Test2
ADR:Test2
  # LABEL und ADR: Postadresse 2
END:VCARD

Achtung: manche VCF-Dateien führen beim versuchten Upload zum Absturz des Nokia 6610i und damit (über
Änderung des Netzwerkstatus der IR-verbindung und einen Treiber-Bug) möglicherweise auch zum Einfrieren
des Computers. Zum Beispiel diese VCF-Datei:
BEGIN:VCARD
N:Vorname Nachname
NOTE:Test1
NOTE:Test2
NOTE:Test3
NOTE:Test4
NOTE:Test5
NOTE:Test6
NOTE:Test7
NOTE:Test8
NOTE:Test9
NOTE:Test10
NOTE:Test11
NOTE:Test12
NOTE:Test13
NOTE:Test14
NOTE:Test15
NOTE:Test16
VERSION:2.1
END:VCARD