Value 'M' cannot be encoded in character set AR8MSWIN1256

Hello
i am using SQL Developer Version 4.0.0.13
when i tried to alter table using GUI i got the follwing error
Version 4.0.0.13
Value 'M' cannot be encoded in character set AR8MSWIN1256

You will need to give more detail on what you are doing, but that is an arabic character set and probably doesn't have an 'M'.
What are the character sets for the database you are using? (select * from nls_database_parameters where parameter in 'NLS_CHARACTER_SET','NLS_NCHAR_CHARACTERSET'))
What is the datatype of the column whose value you are tryig to set?
I suspect this ins't really a SQL Developer problem. Does it also happen in SQL*Plus?

Similar Messages

Database Encoding and character set

Hi,
Is it possible to change [some easier straigtht forward way] the encodings and character set for a database [DB11 in this case]?
I have a database which has UTF16 and MSWIN1252 as the encoding and characterset, i want to change it to UTF8 for some testing and reasons.
Thanks,
Anupam

You should detail what you mean by encoding and character set.
A database has 2 character sets:
- the character set for CHAR, VARCHAR2 and CLOB
- the national character set for NCHAR, NVARCHAR2 and NCLOB.
You have 2 ways to change the database character set:
- with ALTER DATABASE statement
- with export/import
See http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1656

[SOLVED] Browser cannot display the full character set

Characters from some languages like persian, vietnames, japanese, chinese are not displayed in my browsers (I have chromium and firefox installed). The browser just displays little squares. However I don't think it is a problem with the browser but the x installation. I think I have all basic fonts installed.
In my x-installation I have the following fonts installed (These are all fonts I could find via 'pacman -Ss xorg-font').
extra/font-misc-ethiopic 1.0.3-1 (xorg xorg-fonts) [installed]
X.org Misc Ethiopic fonts
extra/xorg-font-util 1.3.0-2 (xorg-fonts xorg) [installed]
X.Org font utilities
extra/xorg-font-utils 7.6-4 [installed]
Transitional package depending on xorg font utilities
extra/xorg-fonts-100dpi 1.0.1-5 (xorg) [installed]
X.org 100dpi fonts
extra/xorg-fonts-75dpi 1.0.3-1 (xorg) [installed]
X.org 75dpi fonts
extra/xorg-fonts-alias 1.0.3-1 [installed]
X.org font alias files
extra/xorg-fonts-cyrillic 1.0.1-4
X.org cyrillic fonts
extra/xorg-fonts-encodings 1.0.4-4 (xorg-fonts xorg) [installed]
X.org font encoding files
extra/xorg-fonts-misc 1.0.1-3 [installed]
X.org misc fonts
extra/xorg-fonts-type1 7.4-3 [installed]
X.org Type1 fonts
Can anybody give me a hint on how to diagnose the problem.
Last edited by helmut (2014-07-10 15:29:41)

Read the wiki article on CJKV fonts: https://wiki.archlinux.org/index.php/Fo … Vietnamese
Last edited by karol (2014-07-10 15:09:16)

Change character set

Hi
is anyone can tell me how to change characterset.
i try with alter session but it doesnt work.
thanks

Article from Metalink
Doc ID:      Note:66320.1
Subject:      Changing the Database Character Set or the Database National Character Set
Type:      BULLETIN
Status:      PUBLISHED
     Content Type:      TEXT/PLAIN
Creation Date:      23-OCT-1998
Last Revision Date:      12-DEC-2003
PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> STARTUP MOUNT; ALTER SYSTEM ENABLE RESTRICTED SESSION; ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; ALTER SYSTEM SET AQ_TM_PROCESSES=0; ALTER DATABASE OPEN; ALTER DATABASE CHARACTER SET <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
     Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Joel P�rez

NLS CHARACTER SET 변경 방법 (ORACLE 7)

제품 : ORACLE SERVER
작성날짜 : 2004-11-09
NLS CHARACTER SET 변경 방법 (ORACLE 7)
======================================
PURPOSE
이 자료는 Oracle RDBMS SERVER에서 NLS CHARACTER SET 변경 방법에 대한
내용을 소개한다.
[ ORACLE 7 에서만 가능 ]
데이타베이스의 CHARACTER SET은 데이타 딕셔너리 테이블인 sys.props$에
들어 있다.
SQL>desc sys.props$
Name Null? Type
NAME NOT NULL VARCHAR2(30)
VALUE$ VARCHAR2(2000)
COMMENT$ VARCHAR2(2000)
SQL>column c1 format a30
SQL>select name c1, value$ c1 from sys.props$;
C1 C1
DICT.BASE 2
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET US7ASCII
NLS_SORT BINARY
GLOBAL_DB_NAME NLSV7.WORLD
여기서 NLS_CHARACTERSET에 현재 DB의 CHARACTER SET이 들어 있는데
이 값을 변경하여 DB의 CHARACTER SET을 변경할 수 있다.
여기서는 US7ASCII에서 KO16KSC5601로 옮기는 경우를 알아보자.
우선 바꾸고자 하는 CHRACTER SET이 지원되는 지를 다음 명령으로
확인한다.
select convert('a','KO16KSC5601','US7ASCII') from dual;
만약 이 Select 문에서 ORA-01482 에러가 발생하면 지정한 CHARACTER
SET이 지원되지 않는 경우이며 에러가 발생하지 않으면 CHARACTER
SET을 변경할 수 있다.
작업을 하기 전에는 만약을 위해서 DB 전체를 백업 받아두도록 한다.
CHARACTER SET 을 잘못 변경하면 DB 를 OPEN 할 수가 없기 때문이다.
1. 다음의 Update문을 실행하여 CHARACTER SET을 변경한다.
UPDATE sys.props$
SET value$ = 'KO16KSC5601'
WHERE name = 'NLS_CHARACTERSET';
Update 시에 NLS_CHARACTERSET을 지원되지 않는 값으로 잘못 설정하거나
실수로 콘트롤 문자 같은 것이 들어가게 되면 DB가 Shutdown 된 다음에는
Startup 이 안되므로 Update 후에 다음 명령으로 확인을 한 다음에
Commit을 하도록 한다.
select name, value$
from sys.props$
where value$ = 'KO16KSC5601';
Select가 제대로 출력되면 Commit 하고 Shutdown 했다가 Startup 하게
되면 새로운 CHARACTER SET 값을 갖게 된다. SELECT가 안 되면 ROLLBACK
하고 UPDATE부터 다시 하도록 한다.
2. 환경 변수 NLS_LANG 을 변경한다.
.profile 에서
NLS_LANG=American_America.KO16KSC5601; export NLS_LANG
또는 .cshrc 에서.
setenv NLS_LANG American_America.KO16KSC5601
*** win95 및 winnt의 client에서는 registry editor에서 NLS_LANG 값을
맞추어준다.
주의 !!!
: 위의 작업을 하기 전에 발생할 가능성이 있는 문제점
1) update 중 KO16KSC5601 이나 US7ASCII 등에서 철자를 잘못 입력하시면,
db 재기동 후에, 다음과 같은 에러가 발생합니다.
ora-12708
12708, 00000, "error while loading create database NLS parameter %s"
2) KO16KSC5601과 US7ASCII의 비교
Character set : KO16KSC5601 인 경우
===================================
: double byte encoding schema 이므로, 한글의 경우 2 bytes 를 크기 1로
계산하는 함수들이 있습니다.
그리고, table , column name에 한글을 double quote 없이 사용할 수 있습니다.
예)
SQL> create table 시험1
2 (컬럼1 varchar(10));
가
a
홍길동
SQL> select length(컬럼1) from 시험1;
1
1
3
SQL> select lengthb(컬럼1) from 시험1;
2
1
6
Character set : US7ASCII 인 경우
=================================
: single byte 7 bit encoding 을 사용합니다.
한글로 된 table, column 이름 사용 시 double quote를 반드시 사용해야 한다.
예)
SQL> create table "사원"
2 ("사원이름" varchar2(10));
가
a
홍길동
SQL> select length("사원이름") from "사원";
2
1
6
SQL> select lengthb("사원이름") from "사원";
2
1
6
US7ASCII일 때에는 vsize, lengthb function의 결과가 length 함수와 모두
동일합니다.
cf) substr, substrb 함수도 위의 length, lengthb의 관계와 같음.

제품 : ORACLE SERVER
작성날짜 : 2004-11-09
NLS CHARACTER SET 변경 방법 (ORACLE 7)
======================================
PURPOSE
이 자료는 Oracle RDBMS SERVER에서 NLS CHARACTER SET 변경 방법에 대한
내용을 소개한다.
[ ORACLE 7 에서만 가능 ]
데이타베이스의 CHARACTER SET은 데이타 딕셔너리 테이블인 sys.props$에
들어 있다.
SQL>desc sys.props$
Name Null? Type
NAME NOT NULL VARCHAR2(30)
VALUE$ VARCHAR2(2000)
COMMENT$ VARCHAR2(2000)
SQL>column c1 format a30
SQL>select name c1, value$ c1 from sys.props$;
C1 C1
DICT.BASE 2
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET US7ASCII
NLS_SORT BINARY
GLOBAL_DB_NAME NLSV7.WORLD
여기서 NLS_CHARACTERSET에 현재 DB의 CHARACTER SET이 들어 있는데
이 값을 변경하여 DB의 CHARACTER SET을 변경할 수 있다.
여기서는 US7ASCII에서 KO16KSC5601로 옮기는 경우를 알아보자.
우선 바꾸고자 하는 CHRACTER SET이 지원되는 지를 다음 명령으로
확인한다.
select convert('a','KO16KSC5601','US7ASCII') from dual;
만약 이 Select 문에서 ORA-01482 에러가 발생하면 지정한 CHARACTER
SET이 지원되지 않는 경우이며 에러가 발생하지 않으면 CHARACTER
SET을 변경할 수 있다.
작업을 하기 전에는 만약을 위해서 DB 전체를 백업 받아두도록 한다.
CHARACTER SET 을 잘못 변경하면 DB 를 OPEN 할 수가 없기 때문이다.
1. 다음의 Update문을 실행하여 CHARACTER SET을 변경한다.
UPDATE sys.props$
SET value$ = 'KO16KSC5601'
WHERE name = 'NLS_CHARACTERSET';
Update 시에 NLS_CHARACTERSET을 지원되지 않는 값으로 잘못 설정하거나
실수로 콘트롤 문자 같은 것이 들어가게 되면 DB가 Shutdown 된 다음에는
Startup 이 안되므로 Update 후에 다음 명령으로 확인을 한 다음에
Commit을 하도록 한다.
select name, value$
from sys.props$
where value$ = 'KO16KSC5601';
Select가 제대로 출력되면 Commit 하고 Shutdown 했다가 Startup 하게
되면 새로운 CHARACTER SET 값을 갖게 된다. SELECT가 안 되면 ROLLBACK
하고 UPDATE부터 다시 하도록 한다.
2. 환경 변수 NLS_LANG 을 변경한다.
.profile 에서
NLS_LANG=American_America.KO16KSC5601; export NLS_LANG
또는 .cshrc 에서.
setenv NLS_LANG American_America.KO16KSC5601
*** win95 및 winnt의 client에서는 registry editor에서 NLS_LANG 값을
맞추어준다.
주의 !!!
: 위의 작업을 하기 전에 발생할 가능성이 있는 문제점
1) update 중 KO16KSC5601 이나 US7ASCII 등에서 철자를 잘못 입력하시면,
db 재기동 후에, 다음과 같은 에러가 발생합니다.
ora-12708
12708, 00000, "error while loading create database NLS parameter %s"
2) KO16KSC5601과 US7ASCII의 비교
Character set : KO16KSC5601 인 경우
===================================
: double byte encoding schema 이므로, 한글의 경우 2 bytes 를 크기 1로
계산하는 함수들이 있습니다.
그리고, table , column name에 한글을 double quote 없이 사용할 수 있습니다.
예)
SQL> create table 시험1
2 (컬럼1 varchar(10));
가
a
홍길동
SQL> select length(컬럼1) from 시험1;
1
1
3
SQL> select lengthb(컬럼1) from 시험1;
2
1
6
Character set : US7ASCII 인 경우
=================================
: single byte 7 bit encoding 을 사용합니다.
한글로 된 table, column 이름 사용 시 double quote를 반드시 사용해야 한다.
예)
SQL> create table "사원"
2 ("사원이름" varchar2(10));
가
a
홍길동
SQL> select length("사원이름") from "사원";
2
1
6
SQL> select lengthb("사원이름") from "사원";
2
1
6
US7ASCII일 때에는 vsize, lengthb function의 결과가 length 함수와 모두
동일합니다.
cf) substr, substrb 함수도 위의 length, lengthb의 관계와 같음.

Arabic Character set conversion-help needed

We have our main database running in 10g (Solaris o/s) & planning to move these to RAC 11g.
One of our old oracle DB(8.0.5)/solaris, which is not used till recently need to upgrade to 10g Rel2.
I know Supported direct upgrade 8.0.6/8.1.7/9i -> 10g
Current DB: 8.0.5 (Character Set: AR8ISO8859P6)
Target DB : 10g Rel 2 (Character Set: AR8MSWIN1256)
I am thinking to go the following way by using exp/imp
8.0.5(AR8ISO8859P6) -> 8.1.7(AR8ISO8859P6) -> 10G(AR8MSWIN1256)
OR
8.0.5(AR8ISO8859P6) -> 8.1.7(AR8MSWIN1256) -> 10G(AR8MSWIN1256)
please advice
thanks

(1) At source db 8.0.5 (solaris)
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET AR8ISO8859P6
NLS_SORT BINARY
NLS_NCHAR_CHARACTERSE T AR8ISO8859P6
$set NLS_LANG=AMERICAN_AMERICA.AR8ISO8859P6
$exp sys/dba file=full251109.dmp full=y
(2):>> At target db 10g R2 (solaris)
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RRRR
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET AR8ISO8859P6
NLS_SORT BINARY
NLS_NCHAR_CHARACTERSET UTF8
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
$export NLS_LANG=AMERICAN_AMERICA.AR8ISO8859P6
$imp testdba/testdba file=full251105.dmp fromuser=PROFINAL touser=PROFINAL
*$csscan testdba/testdba FULL=Y FROMCHAR=AR8ISO8859P6 TOCHAR=AR8ISO8859P6 LOG=P6check CAPTURE=Y ARRAY=100000 PROCESS=2*
There is EXCEPTIONAL DATA in .err file+
clients accessing 8.0.5 dataabase uses characterset AR8IS08859P6, which is SAME as 8.0.5 database
-CSSCAN result->>[Database Scan Parameters]
Parameter Value
CSSCAN Version v2.1
Instance Name MIG1
Database Version 10.2.0.1.0
Scan type Full database
Scan CHAR data? YES
Database character set AR8ISO8859P6
FROMCHAR AR8ISO8859P6
TOCHAR AR8ISO8859P6
Scan NCHAR data? NO
Array fetch buffer size 100000
Number of processes 2
Capture convertible data? YES
[Scan Summary]
Some character type data in the data dictionary are not convertible to the new
haracter set Some character type application data are not convertible to the new characters
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 2,235,403 0 0 *1,492*
CHAR 1,097 0 0 0
LONG 155,188 0 0 6
CLOB 24,643 0 0 0
VARRAY 21,352 0 0 0
Total 2,437,683 0 0 1,498
Total in percentage 99.939% 0.000% 0.000% 0.061%
The data dictionary can not be safely migrated using the CSALTER script
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 16,986,594 0 0 *1,240,383*
CHAR 164,114 0 0 0
LONG 7 0 0 0
CLOB 1 0 0 0
VARRAY 1,436 0 0 0
Total in percentage 93.256% 0.000% 0.000%
6.744%
[Distribution of Convertible, Truncated and Lossy Data by Table]
USER.TABLE Convertible Truncation Lossy
PROFINAL.BASE_MASTER_DATAS 0 0 *362,003*
PROFINAL.CODE_ALLOW 0 0 *53*
PROFINAL.CODE_ALLOWANCE_TYPES 0 0 *1*
PROFINAL.CODE_BONUS_TYPES 0 0 *2*
PROFINAL.CODE_BRANCHES 0 0 *2*
PROFINAL.CODE_CERTIFICATES 0 0 *94*
Kindly help,,,
Edited by: userR12 on Nov 25, 2009 1:43 AM
Edited by: userR12 on Nov 25, 2009 1:52 AM

APPLICATION TOP Character set conversion

Hi,
I am changing the characterset of application from UTF8 to AR8MSWIN1256.
After running adadmin, i am getting the following errors in
manifest_lossy.lst file
Source Character Set: UTF8 Destination Character Set: AR8MSWIN1256
Original Source Buffer is:+---------------------------------------------------------------------------+
Application Object Library: Version : 12.0.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
module:
Current system time is 12-APR-2011 17:52:10
APP-FND-01630: Cannot open file pE<87> for reading
Cause: wffpath encountered an error when attempting to open file pE<87> for reading.
Action: Verify that the filename is correct and that the environment variables controlling that filename are correct.
Action: If the file is opened in read mode, check that the file exists. Check that you have privileges to read the file in the file directory. Contact your system administrator to obtain read privileges.
Action: If the file is opened in write or append mode, check that you have privileges to create and write files in the file directory. Contact your system administrator to obtain create and write privileges.
Concurrent request completed successfully
Current system time is 12-APR-2011 17:52:18
Round-trip Source Buffer is:+---------------------------------------------------------------------------+
Application Object Library: Version : 12.0.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
thanks

Please post the details of the application release, database version and OS.
I am changing the characterset of application from UTF8 to AR8MSWIN1256.How did you change it? Please post the steps.
Any reason for this conversion?
APP-FND-01630: Cannot open file pE<87> for readingDo you get this error with all concurrent requests or specific ones only?
Was the concurrent request output file generated successfully?
APP-FND-1630 Error For All Concurrent Requests that access the database. [ID 554377.1]
Thanks,
Hussein

What Determines the "File Character Set" on Export?

When we Export a Page, for example, from APEX, the File Character Set is defaulted to some value (and not editable). On some of our instances, this defaults to "Western European Windows 1252" while on others it is "Unicode UTF-8." Specifically, what setting is being used to make this determination? This is kind of a pain because we have some environments wherein we are promoting changes from environment to environment and these settings differ. If, during import, the user neglects to set this to the same File Character Set in which the file was originally exported, we get issues (non-printable control characters and the like). Therefore, we'd love to make all of the environments match but, aren't sure how to do this.
Thanks,
-Joe
Edited by: Joe Upshaw on Apr 10, 2013 3:25 PM

Hello Joe,
In your environment, the character set of the APEX exported files is set according to the DAD character set, and with your APEX version, it must be set to AL32UTF8 (regardless of the database character set).
Re: Export - File Character Set list is read only (fixe UTF-8 value)
You should check the DAD character set setting in the environments in which APEX is not exporting the files using UTF8.
Regards,
Arie.
&diams; Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.
&diams; Author of Oracle Application Express 3.2 – The Essentials and More

How to add a new character set encoding?

Hello,
can anybody please explain to me, how to add a new character set encoding to Mac OS Tiger?
I have two Mac laptops, a new one with Snow Leopard and an older one with Tiger, and on the old one i cannot use or enable anywhere the "Russian (DOS)" character set encoding, which i need to be able to use some old text files.
On the Snow Leopard, this encoding is present in the list of available encodings of TextWrangler, but not in TIger.
If i have understood correctly, this is not a problem of TextWrangler, and the same encodings are available systemwide.
So, the question is: how to add new encodings to Tiger (or to Mac OS in general)?
Thanks.

I think possibly that's in the Get Info window of Finder?
I don't think either that or the input menu have any effect on available encoding choices. Adding languages to system prefs/international/languages can do that, but once you have added Russian there, I don't know of any way to add an additional Russian encoding (there are quite a number of them).

Cannot transliterate character between character sets problem

i hava a database which carset is selected none before
when i want to get data from this database i get the error
java.sql.SQLException: [interclient][interbase]arithmetic exception, numeric overflow, or string truncation
[interclient][interbase]Cannot transliterate character between character sets
     at interbase.interclient.ResultSet.remote_FETCH_ROWS(Unknown Source)
     at interbase.interclient.ResultSet.getNextCursorPosition(Unknown Source)
     at interbase.interclient.ResultSet.next(Unknown Source)
but i m getting the error when rs.next()
so ican't use methods to encode when rs.getBytes.............

i hava a database which carset is selected none
before
when i want to get data from this database i get the
error
java.sql.SQLException:
[interclient][interbase]arithmetic exception, numeric
overflow, or string truncation
[interclient][interbase]Cannot transliterate
character between character sets
atcontact the driver vendor for support.

Flat File Load Issue - Cannot convert character sets for one or more charac

We have recently upgraded our production BW system to SPS 17 (BW SP19)
and we have issues loading flat files (contain Chinese, Japanese and
Korean characters) which worked fine before the upgrade. The Asian
languages appear as invalid characters (garbled) as we can see in PSA. The Character Set
Settings was previously set as Default Setting and it worked fine until
the upgrade abd we referred to note 1130965 and with the code page 1100
the load went through (without the Cannot convert character sets for one or more characters error) however the Asian language characters will appear
as invalid characters. We tried all the code pages suggested in the note e.g.
4102, 4103 etc on the info packages but it did not work. Note that the
flat files are encoded in UTF-8.

I checked lower case option for all IO
When i checked the PSA failed log no of records processed is "0 of 0" my question is with out processing single record system is througing this error message.
When i use same file loading from local workstation no error message
I am thinking when I FTP the file from AS/400 to BI Application Server(Linex) some invalid characters are adding but how can we track that invalid char?
Gurus please share your thoughts on this I will assign full points.
Thanks,

Character set Encoding

Hi,
Everybody i just want to know default character set encoding that is
use to store data in oracle 9i..
or is there any difference between Mssqi2005 character set encoding and oracle 9i character set encoding.
please reply................
regard's
paritosh tomar

DarkFiBrE72 wrote:
Its AL16UTF16,
From metalink
Starting in Oracle 9i the National Characterset (NLS_NCHAR_CHARACTERSET) will be
limited to UTF8 and AL16UTF16.
For more details refer to The National Character Set in Oracle 9i and 10g
Any other NLS_NCHAR_CHARACTERSET will no longer be supported.
When upgrading to 10g the value of NLS_NCHAR_CHARACTERSET is based
on value currently used in the Oracle8 version.
If the NLS_NCHAR_CHARACTERSET is UTF8 then new it will stay UTF8.
In all other cases the NLS_NCHAR_CHARACTERSET is changed to AL16UTF16
and -if used- N-type data (= data in columns using NCHAR, NVARCHAR2 orNCLOB )
may need to be converted.
Edited by: DarkFiBrE72 on Sep 24, 2008 7:12 PMI'm not sure if the OP was referring to the National character set? Is this implied by the corresponding SQL Server characterset mentioned?
Otherwise I would assume we are talking about the Database character set, which allows numerous different character sets and types (single-byte, multi-byte, Unicode etc. depending on Oracle release).
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

How do I specify character set encoding?

Hi,
I already defined sub-class META from DOCUMENT class thru xml.
Now I am trying to upload META files thru xml and its working fine.
But when I see properties from web, I don't see "Character Set" define.
As a result I can't use BufferedReader(doc.getContentReader())
Exception in thread "main" oracle.ifs.common.IfsException: IFS-32245: Cannot con
vert content to Reader - content does not have an associated character encoding.
at oracle.ifs.server.S_Media.convertInputStreamToReader(S_Media.java:1960)
at oracle.ifs.server.S_Media.getReaderFromObject(S_Media.java:1423)
at oracle.ifs.server.S_Media.getContentReader(S_Media.java:1408)
How can I specify encoding character set from xml?
Of if possible can I specify while defining class(META in this case).
Thanks,
-Niraj

Luis,
Each take encoding name arguments using the Java naming conventions.
If you want to do this automatically when you upload your XML file, you
will need to write a server-side representation of your "META" ClassObject
and provide an 'extendedPostInsert' implementation. In this method, you can
parse the XML content and pull out an encoding if you specify it within the
XML file. Could you explain in little more details?
If you can provide me links to any resouces, that would be great.
Thanks,
-Niraj

Lyrics character set encoding?

Hi,
For a few of my songs, I accidentily pasted in some French lyrics from Safari while I was using BIG5 character encoding. I've since corrected the lyrics but I think the iPod still tries to show the lyrics using BIG5 encoding. Everything looks ok in iTunes but accented marks don't show up correctly on my nano.
There's probably a painful way to fix this. Maybe there's an easy way?

DarkFiBrE72 wrote:
Its AL16UTF16,
From metalink
Starting in Oracle 9i the National Characterset (NLS_NCHAR_CHARACTERSET) will be
limited to UTF8 and AL16UTF16.
For more details refer to The National Character Set in Oracle 9i and 10g
Any other NLS_NCHAR_CHARACTERSET will no longer be supported.
When upgrading to 10g the value of NLS_NCHAR_CHARACTERSET is based
on value currently used in the Oracle8 version.
If the NLS_NCHAR_CHARACTERSET is UTF8 then new it will stay UTF8.
In all other cases the NLS_NCHAR_CHARACTERSET is changed to AL16UTF16
and -if used- N-type data (= data in columns using NCHAR, NVARCHAR2 orNCLOB )
may need to be converted.
Edited by: DarkFiBrE72 on Sep 24, 2008 7:12 PMI'm not sure if the OP was referring to the National character set? Is this implied by the corresponding SQL Server characterset mentioned?
Otherwise I would assume we are talking about the Database character set, which allows numerous different character sets and types (single-byte, multi-byte, Unicode etc. depending on Oracle release).
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Region type URL and character set encoding

Hello,
I'd like to include static html page using URL region, but there is some translation done between encoding of input static html page and output of HTML DB. Does anyone know how the file encoding is translateded when the page is rendered?
I have tried some encodings of input file (CP1250, UTF-8, Unicode) but it did not work.

DarkFiBrE72 wrote:
Its AL16UTF16,
From metalink
Starting in Oracle 9i the National Characterset (NLS_NCHAR_CHARACTERSET) will be
limited to UTF8 and AL16UTF16.
For more details refer to The National Character Set in Oracle 9i and 10g
Any other NLS_NCHAR_CHARACTERSET will no longer be supported.
When upgrading to 10g the value of NLS_NCHAR_CHARACTERSET is based
on value currently used in the Oracle8 version.
If the NLS_NCHAR_CHARACTERSET is UTF8 then new it will stay UTF8.
In all other cases the NLS_NCHAR_CHARACTERSET is changed to AL16UTF16
and -if used- N-type data (= data in columns using NCHAR, NVARCHAR2 orNCLOB )
may need to be converted.
Edited by: DarkFiBrE72 on Sep 24, 2008 7:12 PMI'm not sure if the OP was referring to the National character set? Is this implied by the corresponding SQL Server characterset mentioned?
Otherwise I would assume we are talking about the Database character set, which allows numerous different character sets and types (single-byte, multi-byte, Unicode etc. depending on Oracle release).
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Value 'M' cannot be encoded in character set AR8MSWIN1256

Similar Messages

Maybe you are looking for