oracle中utf-8到utf-16的转换
我实际上以UTF-8格式将资源存储在DB中。但是当我现在想将它们全部转换为UTF-16时。因为德语有一些字符，例如 1/4。现在我想避免这些。我尝试遵循该语句，但在结果字符串中出现了一些框....
> select convert('Inhalt hinzufügen','AL16UTF16LE','AL32UTF8') from dual
result : it is not allowing me to copy paste it :(. But result is coming properly except boxes in middle of each character
还有其他方法吗？
SELECT *
FROM v$nls_parameters
WHERE parameter LIKE '%CHARACTERSET';
表明我的数据库字符集是WE8MSWIN1252，而我的国家字符集是AL32UTF16。
当我使用 DUMP 函数查看实际存储在表中的数据时，输出如下：
SELECT dump( your_column, 1016 ), your_column
FROM your_table
WHERE some_key_column = <<value that gives you the row you're interested in>>
类型=1 长度=54 字符集=WE8MSWIN1252： 4d,c3,b6,63,68,74,65,6e,20,53,69,65,20,64,69,65,73,65,20,5a,65,69,6c,65,20, 77,69 ,72,6b,6c,69,63,68,20,65,6e,64,67,c3,bc,6c,74,69,67,20,6c,c3,b6,73,63,68,65 ,6e,3f, Möchten Sie diese Zeile wirklich endgültig löschen？
I actually stored resources in DB in UTF-8 format. But when I want to convert them all into UTF-16 now. As the german language is having some characters like 1/4. Now I want to avoid those. I have tried with following the statement, but got some boxes in result string....
> select convert('Inhalt hinzufügen','AL16UTF16LE','AL32UTF8') from dual
result : it is not allowing me to copy paste it :(. But result is coming properly except boxes in middle of each character
is there any alternative approach?
SELECT *
FROM v$nls_parameters
WHERE parameter LIKE '%CHARACTERSET';
indicates that my database character set is WE8MSWIN1252 while my national character set is AL32UTF16.
When I use the DUMP function to view the data that is actually stored in my table, this is the output:
SELECT dump( your_column, 1016 ), your_column
FROM your_table
WHERE some_key_column = <<value that gives you the row you're interested in>>
Typ=1 Len=54 CharacterSet=WE8MSWIN1252:
4d,c3,b6,63,68,74,65,6e,20,53,69,65,20,64,69,65,73,65,20,5a,65,69,6c,65,20,77,69,72,6b,6c,69,63,68,20,65,6e,64,67,c3,bc,6c,74,69,67,20,6c,c3,b6,73,63,68,65,6e,3f,
Möchten Sie diese Zeile wirklich endgültig löschen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于您的数据库字符集是 WE8MSWIN1252，因此您的数据实际上可能不会存储为 UTF-8。如果实际数据存储在 CHAR、VARCHAR2 或 CLOB 列中，则该数据要么使用 Windows-1252 字符集存储，要么存储不正确。您可能错误地配置了 NLS 环境，导致您实际上在数据库中存储了 UTF-8 数据，但希望不是这种情况。
根据 DUMP 函数的输出，您希望在数据的第三个位置存储什么字符？ 0xB6 是实际存储在数据库中的数据，它映射到 Windows-1252 中的段落符号 ¶字符集。假设这不是您期望的字符，则表明存储在数据库中的数据已损坏。
您的数据是用什么语言编写的？您要存储的所有字符都存在于 Windows-1252 字符集中 中吗？
您是否正在尝试更改数据的存储方式？或者您是否正在尝试以不同的字符集检索数据？
如果数据库字符集是 AL32UTF8，国家字符集是 AL32UTF16，并且您希望使用 UTF-16 将数据存储在数据库中，则需要将数据移动到 NVARCHAR2 或 NCLOB 列中。
如果您尝试将数据以 UTF-8 格式存储在数据库中，然后以 UTF-16 格式将其发送到客户端，则可以通过配置客户端的 NLS 设置自动完成此操作。具体如何执行取决于客户端访问数据库的方式（JDBC、ODBC 等）。
Since your database character set is WE8MSWIN1252, your data is hopefully not actually stored as UTF-8. If the actual data is being stored in a CHAR, VARCHAR2, or CLOB column, the data is either stored using Windows-1252 character set or the data has been stored incorrectly. It is possible that you have configured your NLS environment incorrectly so that you're actually storing UTF-8 data in the database but hopefully not the case here.
Based on the output of the
DUMPfunction, what character do you expect to be stored in the third position of the data? 0xB6 is the data that is actually stored in the database which maps to the paragraph symbol ¶ in the Windows-1252 character set. Assuming that is not the character that you expect, it would appear that the data that is stored in the database has been corrupted.What language(s) is your data written in? Are all the characters that you want to store present in the Windows-1252 character set?
Are you trying to change how the data is stored? Or are you trying to retrieve the data in a different character set?
If the database character set is AL32UTF8, the national character set is AL32UTF16, and you want to store the data in the database using UTF-16, you'd need to move the data into a NVARCHAR2 or NCLOB column.
If you are trying to store the data in a UTF-8 format in the database but then send it to the client in UTF-16, that can be done automatically by configuring the client's NLS settings. Exactly how you do that will depend on how the client accesses the database (JDBC, ODBC, etc.).