CCSID切換會有什麼已知問題嗎？

Question

我不熟悉db2/iSeries，但我正在努力允許來自多種語言的字符存儲在db2表中。 將db2/iSeries表中的列從CCSID 37更改爲1208是否存在任何明顯問題？如何切換CCSID會影響已存儲在列中的數據？

Answer 1

你會看到一些可怕的消息：

CREATE TABLE QTEMP/TEST (FLD1 CHAR (10) CCSID 37 NOT NULL WITH DEFAULT) 

ALTER TABLE QTEMP/TEST ALTER COLUMN FLD1 SET DATA TYPE CHARACTER ( 
10) CCSID 1208 NOT NULL WITH DEFAULT 

CPD32CC - Change to field FLD1 may result in data loss. 
--reason code 02: 02 - The new length is shorter than the current length. 
CPA32B2 - Change of file TEST may cause data to be lost. (C I) 
SQL0460 - Truncation of data may have occurred for ALTER TABLE of TEST in QTEMP. 

不過，假設數據是α，你不應該失去任何東西。

但是，試圖存儲一個需要DBCS編碼的10個字符的字符串將失敗，因爲列長度仍然只有10個字節......並且您需要22個字節用於CCSID 1208中的一個10個字符的DBSC字符串。雖然關於截斷的消息不會消失，除非您將長度增加到28？）

如果將類型更改爲使用UTF-16（CCSID 1200）的NCHAR，系統會自動將10識別爲字符長度並分配20個字節來存儲它。

ALTER TABLE QTEMP/TEST ALTER COLUMN FLD1 SET DATA TYPE NCHAR(10) NOT NULL WITH DEFAULT 

也就是說，假設您的文件是現有應用程序的一部分，更改表格只是問題的開始。

現有的RPG程序必須重新編譯，並且很可能會被修改。

您可以通過使用從Unicode轉換爲EBCDIC的LF（查看）圖層來解決該需求。這有助於當前的數據。但對於實際需要unicode的新數據無助。

另外，包含在IBM iAccess for Windows中的舊版本的5250仿真器不支持unicode。您需要使用較新的Access Client Solution（ACS）仿真器或基於瀏覽器的IBM iAccess for Web。