Unübersetzbares Zeichen beim Extrahieren von Daten aus Zeichenfolgen

Ich versuche, Daten aus einem Freitextfeld zu extrahieren (weil unser Prozess so großartig ist: \) und weiterhin Teradata-Fehler 6706 zu treffen. Die Regex, die ich verwende ist: REGEXP_SUBSTR(original_field,'(\d{2})\/(\d{2})\/(\d{4})',1) AS new_field. Ich bin mir nicht sicher, ob der Feldtyp HELP TABLE in der Spalte Typ für das Feld leer ist.Unübersetzbares Zeichen beim Extrahieren von Daten aus Zeichenfolgen

Ich habe bereits versucht, mit TRANSLATE(col USING LATIN_TO_UNICODE), sowie UNICODE_TO_LATIN konvertieren, die beide tatsächlich den Fehler selbst verursachen. Ein Straight CAST(original_field AS VARCHAR(255)) behebt das Problem nicht, obwohl dieser Cast funktioniert. Ich habe auch versucht, verschiedene Sonderzeichen (Zeilenumbruch, Wagenrücklauf, etc.) aus dem Feld zu strippen, bevor ich die REGEXP_SUBSTR einen Riss bei ihm machen lassen, sowohl von sich selbst als auch mit den bereits erwähnten CAST & TRANSLATEs.

An diesem Punkt bin ich nicht sicher, was das Problem sein könnte, und könnte einige Hinweise auf zusätzliche Optionen zu versuchen.

Quelle

2017-07-20 JMichael

Haben Sie versucht, mit regexp_replace alle nicht-alphanumerischen Zeichen zu entfernen? Es gibt keinen Hinweis darauf, welche Art von Müll Sie in einem wirklich freien Textfeld landen könnten. – Andrew

Ich habe eine Reihe von 'OREPLACE's gemacht. 'REGEXP_REPLACE' hat den gleichen Fehler gefunden, als ich ''[\ r \ t \ n \ e \ f]'' verwendet habe, weshalb ich mit dem OREPLACE und den Hex-Codes gegangen bin. – JMichael

Haben Sie versucht, die REGEXP_INSTR zu verwenden, um Datensätze zu finden, die Werte außerhalb des übersetzbaren Bereichs enthalten? Laufen Sie gegen eine Aussicht? –

Die endgültige Version, die funktioniert beendet

, CASE 
    WHEN TRANSLATE_CHK(field USING LATIN_TO_UNICODE) = 0 THEN 
     REGEXP_SUBSTR(TRANSLATE(field USING LATIN_TO_UNICODE),'(\d{2})\/(\d{2})\/(\d{4})',1) 
    ELSE NULL 
END AS Ref_Date

Aus irgendeinem Grund ist, nach oben, mit einem TRIM innerhalb der TRANSLATE um ein Problem zu verursachen scheint. Nur einmal habe ich alle Funktionen aus dem Inneren der TRANSLATE tat die TRANSLATE, und damit die REGEXP_SUBSTR, arbeiten.

Quelle

2017-07-21 13:02:25 JMichael

Sie könnten versuchen, zu überprüfen, was in den schlechten Daten tatsächlich enthalten ist' CHAR2HEXINT (Feld) ', es ist wahrscheinlich hex '1A', siehe https://stackoverflow.com/q/40138725 – dnoeth

Ich hatte es über eine alternative Methode gefunden. Es war ASCII-Zeichen # 26 (Rücktaste). – JMichael

Nun, Hexadezimal '1A' gleich Dezimal' 26' :-) – dnoeth

Unübersetzbares Zeichen beim Extrahieren von Daten aus Zeichenfolgen

Antwort

Verwandte Themen