Was bedeuten die Hochkommas (Apostrophen) vor Zahlen, Gelbeträgen oder Kalenderdaten, und wie werde ich sie los?

Manche Zellinhalte, die numerische Daten darstellen sollten, sind als solche nicht formatierbar, und Berechnungen damit funktioniren auch oft nicht wie erwartet.
Wenn für die Zelle keine feste Ausrichtung gewählt ist, erscheinen diese Inhalte links, als ob sie Texte wären. Sonst ist zunächst nichts auffällig, aber wenn man man die Zelle zum Editieren betritt (F2) oder in die Formelleiste geht, erscheint vor dem Wert ein Hochkomma.
Was bedeuten diese Hochkommas (Apostrophen) vor Zahlen, Gelbeträgen oder Kalenderdaten, und wie werde ich sie los, ohne jede einzelne Zelle dieser Art zu bearbeiten?

Für Zellen in Calc gibt es dreierlei Inhaltstypen: Zahl, Text und Formel. Falls eine Formel vorliegt, gibt es wieder drei Ergebnistypen: Zahl, Text oder Fehlerwert.

Wenn eine Zelle scheinbar eine Zahl enthält, bei Bearbeitung aber ein Hochkomma davor anzeigt, dann ist der Inhaltstyp ‘Text’. Geschriebene Zahlen sind eben auch Zeichenfolgen, und in diesem Sinne Text. Gibt man eine Zahl mit der Tastatur ein, liegt zunächst immer eine Zeichenfolge vor, und erst bei Beendigung der Eingabe kann Calc entscheiden, welchen Inhaltstyp die Zelle bekommen soll. Es findet ein sogenannter Erkennungsprozess statt. Die Erkennung als Zahl, genauer als numerische Eingabe (auch Daten, Zeitwerte …), kann man unterbinden, indem man als erstes Zeichen ein Hochkomma eingibt. Genau genommen läuft trotzdem ein Erkennungsversuch … Das alles ist im Detail elend kompliziert, und außerdem von der “Lokalisierung” abhängig.

Zahlenförmige Inhalte, die doch als Text behandelt werden, können nun auch beim (ungeschickten) Import aus einer Textdatei (meist .CSV Format) entstehen, wenn man versäumt, den Rat von @karolus (Siehe seinen Kommentar!) zu befolgen - und dann Ärger machen. In diesem Fall treten die “Scheinzahlen” gewöhnlich in ganzen Spalten (Kopf ggf. ausgenommen) auf. Um sie hier nachträglich als echte Zahlen erkennen zu lassen, geht man am besten so vor:

  1. Die betreffende Spalte (jeweils genau eine!) selektieren
    2) > ‘Daten’ > ‘Text in Spalten…’ wählen …
    Man sieht nun den gleichen Dialog wie beim Import von CSV (oder “Unformatierter Text”).
  2. Für die Spalte ‘Standard’ wählen, und dann ggf. den passenden ‘Spaltentyp:’.
  3. OK
  4. Ggf. mit 1) für die nächste Spalte mit Scheinzahlen fortfahren…
    Fertig!

Sind die “Scheinzahlen” eher verstreut, und will man in einem ganzen Bereich (evtl. Mehrfachbereich), der über mehrere Spalten verteilt ist, zahlenförmige Texte nachträglich erkennen lassen, kann man auch das Werkzeug ‘Suchen und ersetzen’ verwenden. Für die davon eingesetzten Zeichenketten findet nämlich ein neuer Erkennungsprozess statt. Wie das geht, ist im angehängten Beispiel “ask62932deScheinzahlenUmwandeln001” demonstriert.

PS Wenn das nicht funktioniert, kann es daran liegen, dass für die betroffenen Zellen als “Zahlenformat” die Verwirrungseinstellung ‘Text’ vorgenommen wurde, die natürlich kein Zahlenformat ist, sondern den Erkennungsprozess unterdrückt. Allerdings wird in diesem Fall gar bei Bearbeitung gar kein Hochkomma angezeigt.

Hallo
Bleibt noch hinzuzufügen, daß 3), 4), 5) in den meisten Fällen schon während des Csv-Imports geschehen sollte, dann brauchts hinterher keine Reperatur für jede Spalte extra.

Danke, @karolus !

Umgebung: Windows 7 64bit, Benutzer ohne Admin Rechte,
Jahrelange Nutzung von CALC für Auswertungen von Messdaten

Problem: Seit Version 5.0.5.2 von CALC wird bei der Eingabe von Zahlen zwar die Zahl angezeigt, die Zahl kann jedoch nicht bei Berechnungen verwendet werden.
Das Format der Zelle: Standard - Deutsch (Deutschland).
Nach Änderung des Formates zu: Deutsch (Deutschland)
wird in dem Eingabefeld vor der Zahl ein Hochkomma angezeigt!
Nach dem Entfernen des Hochkommas werden die Berechnungen ausgeführt.
Dieses Fehlverhalten tritt auch bei der Version 5.1.1.3 auf.

Workaround:
Ich setze zuerst das Format aller Zellen auf: Deutsch (Deutschland)

Ich habe das Problem bei Bugzilla: Bug 98354 gemeldet.

(Das scheint mir keine Antwort.)
Die Hochkommas sind nicht wirklich in den Zellen enthalten. Sie werden nur benutzt um anzuzeigen, dass etwas, was aussieht wie eine Zahl, alls Text behandelt wird (bei Eingabe: werden soll).
Bei den Zelleigenschaften wird dann etwas irreführend das vorige ‘Zahlen’-Format angezeigt.
Nur das Zahlenformat auf ‘Standard’ (o.ä.) zu setzen genügt allerdings noch nicht, um bereits eingegebenen Inhalt als Zahl zu erkennen.

Messdaten werden oft aus csv-Dateien importiert, in die von einem Datenlogger geschrieben wurde, So und in verwandter Weise können genau die Dinge passieren, die in meiner früheren Antwort angesprochen sind.
Falls weitere Fragen offen sind, bitte besser einen neuen Thread anfangen.

Ich habe die dem Bugreport tdf#98354 angehängten Dateien geprüft. Wenn ich im ersten Beispiel, das unerkannte Zahlen (mit Komma) enthält, im eine weitere Zelle der Spalte A 5,5 eintippe, wird sofort die Zahl erkannt. Wenn ich in A1 die ohnehin angezeigte 1,1 nochmals eintippe, wird die Zahl erkannt …
Wie, ganz genau ist es zu diesen unerkannten Zahlen gekommen?
(Der ‘F&R’ -Trick funktioniert auch einwandfrei.)

NB Für die Zahlerkennung ist die Sprache der Benutzeroberfläche belanglos. Es kommt auf das ‘Gebietsschema’ an. Allerdings scheint das ‘Deutsch (Deutschland)’ zu sein, weil wes ja so als Default angezeigt wird. Allerdings wird nur ‘Default’ mit der Datei gespeichert, nicht das zugeordnete Gebietsschema. Falls also die Datei in einem LibO/AOO mit z.B. ‘locale:’ ‘English (UK)’ geöffnet war als die Eingaben / der Import gemacht wiurden, konnten die kommaseparierten Dezimalbrüche nicht erkannt…

…werden. Nach dem Speichern unter der ‘locale’ en-GB wird beim späteren Öffnen unter de kein neuer Zahlerkennungsversuch durchgeführt. Das muss man extra anstoßen.
Als Sprache unter dem ‘Zahlen’-Reiter bei den Zelleigenschaften wird aber jetzt ‘Default - Deutsch (Deutschland)’ angezeigt.

Ich habe das Verzeichnis:
C:\Users\Theo\AppData\Roaming\LibreOffice\4
gelöscht.
Nach dem Start von CALC wird das Verzeichnis neu angelegt.
Danach funktioniert CALC wieder wie erwartet.

Arbeite mit Ubuntu 16.04 und der neuesten LO-Version. Habe das Problem hauptsächlich bei xls - Import - der schnellste Weg für mich ist (betrifft ja meistens dann die ganze Spalte) - Spalte ausschneiden - in gedit einfügen, wieder ausschneiden, in LO wieder einfügen et voilà. Den Tipp mit dem Editor habe ich mal auf der Suche nach einer Problemlösung in einem OO-Forum gelesen und der ist echt Gold wert.