從字符串中提取日期時的不可翻譯字符

我正在嘗試從自由文本字段中提取日期（因爲我們的過程非常棒，如下所示：\）並繼續觸發Teradata錯誤6706.我使用的正則表達式是：REGEXP_SUBSTR(original_field,'(\d{2})\/(\d{2})\/(\d{4})',1) AS new_field。我不確定該字段的類型HELP TABLE在該字段的類型列中有一個空白。從字符串中提取日期時的不可翻譯字符

我已經嘗試使用TRANSLATE(col USING LATIN_TO_UNICODE)以及UNICODE_TO_LATIN進行轉換，這些實際上都會導致錯誤。直接CAST(original_field AS VARCHAR(255))不能解決這個問題，儘管這個演員確實有效。我也曾嘗試從現場剝離各種特殊字符（換行符，回車等），然後讓REGEXP_SUBSTR自己和我已經提到的CAST & TRANSLATEs進行破解。

在這一點上，我不知道這個問題可能是什麼，並可以使用一些額外的選項的指導嘗試。

來源

2017-07-20 JMichael

您是否嘗試使用regexp_replace去除所有非字母數字字符？在真正的免費文本字段中，你不知道你最終會得到什麼樣的垃圾。 – Andrew

我做了一系列'OREPLACE's。當我使用''[\ r \ t \ n \ e \ f]''時，'REGEXP_REPLACE'遇到了同樣的錯誤，因此我爲什麼使用OREPLACE和十六進制代碼。 – JMichael

您是否嘗試過使用REGEXP_INSTR來查找包含可翻譯範圍之外的值的記錄？你是否反對觀點？ –

是：工作的最終版本最終被

, 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

無論出於何種原因，使用TRIM內TRANSLATE似乎導致的問題。只有當我從TRANSLATE中劃分出任何和所有功能後，TRANSLATE以及REGEXP_SUBSTR才起作用。

來源

2017-07-21 13:02:25 JMichael

你可能試圖用'CHAR2HEXINT（field）'來檢查壞數據中實際包含的內容，它是可能是十六進制'1A'，請參閱https://stackoverflow.com/q/40138725 – dnoeth

我通過其他方法找到了它。它是ASCII字符＃26（退格）。 – JMichael

那麼，十六進制'1A'等於十進制'26' :-) – dnoeth

從字符串中提取日期時的不可翻譯字符

回答

相關問題