Ich beginne bei der Mikrotypografie: bedingter Trennstrich, Halbgeviertstrich und natürlich geschütztes Leerzeichen. Ich zeige, dass man ein „Wort“ vor dem Leerzeichen mit dem Wort „hinter“ dem Leerzeichen zusammenhalten kann, indem man die Tastenkombination [Umschalt] + [Strg] + [Leertaste] drückt:
Was passiert? Richtig: die Steuerungsleiste von teams wird aufgerufen:*ggrrrrrr*
Also gut – dann muss ich dieses Zeichen über Einfügen / Symbol einfügen. Da mir teams die Taste „gestohlen“ hat …
Ich öffne im Windows-Explorer das Eigenschaftenfenster einer Datei und wechsle auf die Registerkarte „Sicherheit“. Dort finde ich den Dateinamen mit Pfad, den ich markiere und nach Excel kopiere. Achtung: Ich markiere von rechts nach links:
Ein zweites Mal – jetzt wird von links nach rechts markiert und anschließend kopiert:
Ich kopiere beide Varianten nach Excel – die erste ist oben, die zweite unten. Ich ermittle die Anzahl der Zeichen mit LÄNGE und bin erstaunt. Ich löse das erste Zeichen mit der Funktion LINKS heraus und bin wieder erstaunt:
Wandelt man das Zeichen vor dem Laufwerksbuchstaben D mit Code in den ASCII-Code um und mit ZEICHEN wieder zurück, so erhält man ein „?“
Ich bin erstaunt.
Noch schlimmer wird es, wenn man mit PowerQuery und diese Access-Datenbank zugreift
und den Pfad durch den ersten Text ersetzt:
DataFormat.Error: Der angegebene Dateipfad muss ein gültiger absoluter Pfad sein.
lautet die Fehlermeldung. Man sieht das Zeichen nicht – weder in Excel noch in Word, im Editor oder in PowerQuery. Und wundert sich über diese merkwürdige Fehlermeldung.
Da gibt es nur eine Lösung: Will man den Dateinamen mit Pfad ermitteln, muss man im Explorer über das Symbol „Pfad kopieren“ den Verzeichnisnamen und Dateinamen in die Zwischenablage kopieren. (danke an Martin Weiß für diesen Tipp)
Nennen wir ihn B. B. kann für Björn stehen. Oder für Benno. Für Benjamin oder für Boris. Egal. Wir nennen ihn B.
B. ist Teilnehmer meiner Excelschulung und stellt eine Frage zum Aufbereiten von CSV-Dateien, die er in regelmäßigen Abständen erhält. Er denkt an eine VBA-Lösung – ich schlage PowerQuery vor. Die Datei wird aufgerufen, transformiert und nach Excel zurück geschrieben.
Allerdings: der Pfad, beziehungsweise der Dateiname soll variabel sein. Eigentlich kein Problem, denke ich, und lasse B. Pfad und Dateiname in die Excelmappe schreiben, mit einer Überschrift versehen und in eine (intelligente) Tabelle umwandeln.
Beide Tabellen werden nach PowerQuery gezogen, und dort mit einem Drilldown in einen Text verwandelt. Sie werden in dem Befehl
File.Contents
verwendet; die Sicherheitsstufe dieser Arbeitsmappe wurde ignoriert. Und dann das Erstaunliche:
DataFormat.Error: Der angegebene Dateipfad muss ein gültiger absoluter Pfad sein.
Stirnrunzeln.
Probieren. Beispielsweise Pfad und Dateiname in PowerQuery (oder in Excel) zu verketten und diese Zeichenkette zu verwenden. Beides schlägt fehl:
Immer wieder die gleiche Fehlermeldung:
DataFormat.Error: Der angegebene Dateipfad muss ein gültiger absoluter Pfad sein.
In Ruhe, alleine, und ohne B. schaue ich mir die Zeichenkette genau an und probiere. Erstaunt stelle ich fest, dass das erste Zeichen nicht der Laufwerksbuchstabe ist. In Excel kann man das mit der Funktion LINKS oder TEIL ermitteln. Der ASCII-Code lautet 63 – eigentlich ein Fragezeichen.
Ich überlege, probiere und frage B. Er hat eigentlich nur den Namen des Verzeichnisses aus den Dateieigenschaften kopiert. Und ich habe ihm zugesehen.
Ich weiß nicht, wie dieses merkwürdige Zeichen in die Excelzelle gelangt ist. Ich weiß, dass Excel bei einigen Zeichen (geschützte Leerzeichen, bedingte Trennstriche, …), die man über Word, Outlook oder eine Webseite nach Excel kopieren kann, Probleme hat. Aber hier? Keine Ahnung.
Lösung des Problems: Pfad neu tippen – und dann klappt es!?!
Kennt ihr das? Ich bislang nicht. Ich erhalte eine Exceldatei, die auf dem Macintosh erstellt wurde. Ich versuche die Datei als PDF zu speichern im Format PDF/A:
Excel weigert sich mit der Bemerkung:
Das Dokument wurde nicht gespeichert. Das Dokument ist möglicherweise geöffnet, oder beim Speichern ist ein Fehler aufgetreten.
Ich kreise den Fehler ein und finde ihn schließlich in einer Zelle. Darin befinden sich Zeilenumbrüche ([ALT] + [Enter]). Die mag mein PDF/A für PC nicht …
Perfide! Ich erhalte eine CSV-Datei und öffne sie per Doppelklick in Excel – alles prima:
Bei einer anderen Datei jedoch:
Werden Umlaute und Sonderzeichen (€) „zerschossen“. Da eine CSV-Datei eine Textdatei ist, lohnt sich ein Blick in den Editor. Wurde das Dateiformat auf ANSI oder UTF-8 mit BOM ( Byte Order Mark) eingestellt, funktioniert alles prima. Jedoch bei „reinem“ UTF werden Sonderzeichen nicht korrekt codiert.
Ein Öffnen mit dem Konvertierungsassistenten würde helfen – dort kann man die Codierung explizit angeben.
PowerQuery und VBA wären weitere Lösungswege:
Aber Excel hat keine Einstellungsoptionen, die dieses Format richtig erkennt und interpretiert. Ärgerlich, wenn ein System SOLCHE CSV-Dateien liefert …
Amüsant: Ich sehe einen Bindestrich, der aber eigentlich gar nicht drin ist:
Man kann ihn analysieren:
=CODE(TEIL(B32;8;1))
liefert die Zahl 173. Mit ZEICHEN(173) kann man ihn nachbauen.
Und wo kommt der her? Der Text wurde von einer Internetseite kopiert – irgendein Trennstrich, der in Excel nichts verloren hat. Übrigens: SÄUBERN putzt ihn nicht raus!
Ich erstelle ein Dokument mit über 500 Seiten. Ich möchte ein PDF für die Druckvorstufe daraus erstellen. Auf Seite 344 brincht der PDF-Creator ab. Nach langem Suchen finde ich den Übeltäter: Als ich Sonderzeichen (» und «) eingefügt haben (Einfügen / Symbol), werden diese in der Schrift Nyala formatiert. Und das bereitet meinem PDF-Creator Probleme. Keine Ahnung, wo Word diese Schrift herholt?
In den letzten drei Tagen habe ich libreOffice Calc unterrichtet. Die Landeshauptstadt München setzt die – nicht mehr aktuelle – Version 5.1 ein. Nach drei Tagen Calc weiß man Excel zu schätzen.
Wenn man ein Tabellenblatt schützt, kann man immer noch einen Doppelklick in eine geschützte Zelle machen. Aber natürlich nicht mehr ändern. Im Funktionsassistenten funktioniert die Tastenkombination [Shift] + [F4] zum Umwandeln in einen absoluten Bezug nicht.
Die Liste könnte endlos fortgesetzt werden. Amüsiert hat mich Folgendes. In einen Text wird über Einfügen / Sonderzeichen aus der Schriftart Symbol das Summensymbol (Σ):
Nach Bestätigen der Eingabe sieht die Zelle folgendermaßen aus:
Ein Trost: in der aktuellen Version 5.2 ist dieser Bug behoben. Das nützt den Mitarbeiterinnen und Mitarbeitern der Landeshauptstadt Münchens allerdings nichts…
Amüsant. Ich schreibe in eine Zelle, die mit der Schriftart „Calibri“ formatiert ist, mit dem Zahlenformat und mit dem Zellformat „Standard“ einen Text.
Ich bestätige die Eingabe:
Schwupp: Lustige Zeichen.
Der Kenner bemerkt sofort, dass Excel die Zelle automatisch in der Schriftart WingDings formatiert hat. Der Grund: in den drei Zellen darüber befinden sich Zeichen, die über Einfügen / Symbol aus der Schriftart WingDings eingefügt wurden. Sobald mindestens drei WingDings-Zeichen übereinander stehen, „vermutet“ Excel, dass das nächste Zeichen nun auch in der gleichen Schrift formatiert werden soll. Will ich das? Nein!
Ich gestehe: ich habe zirka fünf Minuten gesucht. Ich habe eine Datei erhalten, über die jemand sagte, dass in einer Zelle ein merkwürdiges Zeichen sei, das er nicht löschen könne. Mein Hinweis, dass die Funktion SÄUBERN dieses Zeichen möglicherweise „wegputzt“ wurde nicht bestätigt. Ich habe mir dann die Datei schicken lassen:
Das Telefon
Der Blick in die Bearbeitungsleiste zeigt mir, dass die Zelle leer ist. Das Symbol steht auch nicht ein einer anderen Zelle, die mit dem Befehl „über Auswahl zentrieren“ in der Zelle A6 dargestellt wird. Das Verbinden von Zellen, rechtsbündig, an der Unterkante ausrichten, … brachte keinen Erfolg:
Wo ist das Telefon?
Das Telefon befindet sich wirklich in der Zelle wie das Einfügen von Zeilen bewies:
Das Telefon lässt sich verschieben, aber ist nicht auffindbar.
Ich gesteht: Ich habe zufällig Entdeckt, dass das Telefon kein Sonderzeichen (Wingdings?) war, sondern ein Bild, das AUF der Tabelle liegt. Der sich ändernde Mauszeiger liefert den entscheidenden Hinweis:
