Perl & MongoDB Binärdaten

8

Aus dem MongoDB Handbuch:

  

Standardmäßig sind alle Datenbankzeichenfolgen UTF8. Um Bilder, Binärdateien,   und andere Nicht-UTF8-Daten können Sie die Zeichenfolge als Referenz an die übergeben   Datenbank.

Ich hole Seiten und möchte den Inhalt für die spätere Verarbeitung speichern.

  • Ich kann mich nicht auf Meta-Zeichensatz verlassen, weil viele Seiten utf8-Inhalt haben, aber iso-8859-1 oder ähnliches falsch deklarieren
  • kann also Encode nicht verwenden (kenne den ursprünglichen Zeichensatz nicht)
  • Daher möchte ich den Inhalt einfach speichern as flow of bytes (Binärdaten) für die spätere Verarbeitung

Fragment meines Codes:

%Vor%

Aber Fehler bekommen:

  

Breites Zeichen bei der Unterprogrammeingabe bei   /opt/local/lib/perl5/site_perl/5.14.2/darwin-multi-2level/MongoDB/Collection.pm   Zeile 296.

Dies ist der einzige Ort, wo ich Daten speichern.

Die Frage: Die einzige Möglichkeit, binäre Daten in MondoDB zu speichern, ist sie z. mit base64?

    
jm666 20.06.2012, 08:41
quelle

2 Antworten

4

Sieht aus wie eine weitere traurige Geschichte über _utf8_ flag ...

Ich könnte falsch liegen, aber es scheint, dass headers_as_string und content Methoden von HTTP :: Message ihre Zeichenfolgen als eine Folge von Zeichen zurückgeben. Der MongoDB-Treiber erwartet jedoch, dass die Strings, die explizit an ihn übergeben werden, als "Binärdateien" eine Sequenz von Oktetten darstellen - daher das Warndrama.

Eine ziemlich hässliche Lösung ist es, das utf8 -Flag auf $ rowhead und $ rowbody in Ihrem Code zu entfernen (ich frage mich, ob es nicht wirklich vom MongoDB-Treiber selbst gemacht wird?), in etwa so ...

%Vor%

Die Alternative ist die Verwendung von encode('utf8', $rawhead) - aber dann sollten Sie decode verwenden, wenn Sie Werte aus der Datenbank extrahieren, und ich bezweifle, dass es nicht hässlicher ist.

    
raina77ow 20.06.2012, 09:53
quelle
0

Ihre Daten sind Zeichen, keine Oktette. Ihre Annahme scheint zu sein, dass Sie die Dinge nur als Oktette durchgehen, aber Sie müssen diese Annahme früher irgendwie verletzt haben, indem Sie eingehende Textdaten dekodiert haben, vielleicht sogar ohne dass Sie es bemerkt haben.

Also einfach nicht dekodieren, Daten bleiben Oktette, das Speichern in der db wird nicht fehlschlagen.

    
daxim 20.06.2012 09:37
quelle

Tags und Links