强制Unicode数据传输实用程序用于iSeries AS400用于TSV制表符分隔文件 [英] Force Unicode on Data Transfer utility for iSeries AS400 for TSV tab delimited files

问题描述

我正在为IBM i使用数据传输实用程序，以便从我的AS400创建TSV文件，然后将其导入到我的SQl Server数据仓库。

I am using Data Transfer utility for IBM i in order to create TSV files from my AS400s and then import them to my SQl Server Data Warehouse.

SO关于SSIS编码脚本的问题我想停止在SSIS任务中使用转换，并从源头准备好数据。

Following this: SO Question about SSIS encoding script i want to stop using conversion in SSIS task and have the data ready from the source.

我已经尝试使用恶意代码页TSV的创建（1200等），但1208只能把戏的一半：它创建UTF8，然后我必须转换为unicode，如另一个问题所示。

I have tried using vatious codepages in TSV creation (1200 etc.) but 1208 only does the trick in half: It creates UTF8 which then i have to convert to unicode as shown in the other question.

什么CCSID我从一开始就得用unicode呢？

What CCSID i have to use to get unicode from the start?

实用程序截图：

推荐答案

在IBM i上，CCSID支持是无缝的。想象一下表格是德语编码的情况，你的工作是英文，你正在用法语创建一个新的表 - 所有这些都是默认编码为中文的系统。对于这些操作系统，请使用适当的CCSID，操作系统将为您执行字符编码转换。

On IBM i, CCSID support is intended to be seamless. Imagine the situation where the table is in German encoding, your job is in English and you are creating a new table in French - all on a system whose default encoding is Chinese. Use the appropriate CCSID for each of these and the operating system will do the character encoding conversion for you.

不幸的是，许多中端系统配置不正确。他们的系统默认CCSID是没有CCSID /二进制 - 在CCSID支持之前大约20年前的时间。 DSPSYSVAL QCCSID将告诉您系统的默认CCSID是什么。如果是65535，那就是'二进制'。这不会导致问题的结束，因为操作系统无法确定真正的字符编码是什么。因为CCSID（65535）设置了很多年，所以系统上几乎所有的表都有这样的编码。系统上的所有作业都以此编码运行。当系统上的所有内容都是65535时，操作系统不需要进行任何字符转换，而且似乎都很好。

Unfortunately, many midrange systems aren't configured properly. Their system default CCSID is 'no CCSID / binary' - a remnant of a time some 20 years ago, before CCSID support. DSPSYSVAL QCCSID will tell you what the default CCSID is for your system. If it's 65535, that's 'binary'. This causes no end of problems, because the operating system can't figure out what the true character encoding is. Because CCSID(65535) was set for many years, almost all the tables on the system have this encoding. All the jobs on the system run under this encoding. When everything on the system is 65535, then the OS doesn't need to do any character conversion, and all seems well.

然后，有人需要多字节字符。它可能是一种亚洲语言，或者在您的情况下，Unicode。如果整个系统是二进制/不转换，这可能非常令人沮丧，因为在本质上，系统管理员对于对数据库和作业产生影响的字符编码已经对操作系统撒谎。

Then, someone needs multi-byte characters. It might be an Asian language, or as in your case, Unicode. If the system as a whole is 'binary / no conversion' it can be very frustrating because, essentially, the system admins have lied to the operating system with respect to the character encoding that is effect for the database and jobs.

我猜你正在处理CCSID（65535）环境。我想你将不得不要求一些变化。至少，使用像EBCDIC US English（37）这样适当的CCSID创建一个新的/工作表。使用像CPYF这样的系统实用程序填充此表。现在尝试下载，使用一个CCSID为13488.如果这样做需要，那么也许你需要的是一个中间的表来传递你的数据。

I'm guessing that you are dealing with a CCSID(65535) environment. I think you are going to have to request some changes. At the very least, create a new / work table using an appropriate CCSID like EBCDIC US English (37). Use a system utility like CPYF to populate this table. Now try to download that, using a CCSID of say, 13488. If that does what you need, then perhaps all you need is an intermediate table to pass your data through.

最终，正确的解决方案是正确的CCSID配置。让管理员设置QCCSID系统值，并考虑更改现有表上的编码。之后，系统将根据需要无缝地处理多个编码。

Ultimately, the right solution is a proper CCSID configuration. Have the admins set the QCCSID system value and consider changing the encoding on the existing tables. After that, the system will handle multiple encodings seamlessly, as intended.

这篇关于强制Unicode数据传输实用程序用于iSeries AS400用于TSV制表符分隔文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！