Character Set Scanner utility for HP Open Alpha VMS

I would like to know if there are any character set scanner utilities available for Oracle 817 and 920 for HP Open Alpha VMS 7.3-1

Please post this question in the Downloads forum.
The URL is:
Downloads Issues

Similar Messages

USING THE CHARACTER SET SCANNER

How can I find and download the Character Set Scanner utility mentioned in MetaLink document # 66320.1.
Thanks
Pratap

I would like to know if there exists a database character set
scanner for ORACLE816. If not, can I use the ORACLE817 scanner
to scan my ORACLE816 database?Check out the Globalization Support Home page
http://technet.oracle.com/tech/globalization/content.html and go
to the scanner download page for more info.
Is it important to use a scanner if I am converting my database
from, say, WE8ISO8859P1 character set to UTF8? Yes definitely. The scanner will identify
1. If you have any invalid WE8ISO8859P1 data in your database ,
these will be lost during the character set conversion process.
2. If there are any data cell expansions, so that column widths
can be expanded to cater for the new sizing.
3. Area of possible character set conversion and truncation of
data.
Can I assume that a database UTF8 will automatically store all
my original characters correctly?UTF8 can store all the characters from WE8ISO8859P1 ,and it can
be stored correctly if your NLS configuration is correct . The
key is your client NLS_LANG character set setting .
I have a client with NLS_LANG set to UFT8. When I exported my
database (in WE8ISO8859P1) from my client, the export was done
in the client's setting i.e. UTF8. Can I assume that the
conversion was done at the time of export itself?Yes, your assumption is correct.

Download Oracle 10g Character set scanner for Solaris

http://www.oracle.com/technology/software/tech/globalization/index.html
the above link contains only the oracle 9i Character set scanner but I need the Oracle 10g Character set scanner for Solaris
please assist me.

Pl see MOS Doc 745809.1 (Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
HTH
Srini

Please remove/clarify download for "Oracle8 8.0.6 Character set scanner"

All Oracle documentation says that the first 0.0 version of Character set scanner was supplied with 8.1.7.0 s/w of the database (also see Note:179843.1 - Versioning of the Character Set Scanner).
The OTN download site provides a link (broken link) to csscan of version 1.0 for "Oracle8 8.0.6 Character set scanner for Solaris" at
http://otn.oracle.com/software/tech/globalization/htdocs/utilsoft.html#10
that confuses customers.
As the download link is broken, it is impossible to check what executables this link really leads to.
Please either document this exception somewhere that csscan is in fact available for 8.0.6 database, and why this is true ONLY on Solaris,
or
simply remove the link if created by mistake.
Thank you,
Svetlana Grove
Technical Specialist

The first version of CSSCAN was shipped with 8.1.7 of the database on all Oracle RDBMS platforms. Due to customer demands, backports were made available for 8.1.6 (NT and Solaris) and 8.0.6 (Solaris) also.
We decided to make these pre-8.1.7 CSSCAN available for download on OTN as well.
The download links are not broken. There is a policy in place for Oracle employees, they are restricted from downloading between 6am and 6pm US-PST on business days.

Oracle 8.0.6 & 8.1.6 Character set scanners available for download

The latest version of the character set scanner version 1.0
(based on the 9.0.1 version) is now available on OTN. Oracle has
backported this utility to the following RDBMS releases 8.0.6
(Solaris), 8.1.6 (NT, Solaris) and 8.1.7 (NT, Solaris) .
For more information, please refer to the following URL
http://otn.oracle.com/tech/globalization/content.html

Please feel free to provide any feedback (Bugs, enhancements
etc.) that you may have on the character set scanner in the
discussion forum.

Character Set Scanner Download

Multiple attempts to download and 'untar/uncompress' the file yields checksum errors. The downloads were for Solaris, both 32 and 64 bit (V9.2). Any way to have these posted files checked?

Pl see MOS Doc 745809.1 (Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
HTH
Srini

How to set default path for file open in SQL Developer

Hi,
I am new to Oracle SQL Developer. Everytime when I open a file, it will default to the install directory. It is hurtingmy hand because I have to click back to the folder where I put my sql statements.
Is there any way to set the Home or Work button to point to the location I like? or add anther button to point to my folder? I just don't want to click 5 to 10 times to open a file.

There are a few things. One is that you can set a working directory for any files you run in the SQL Worksheet i.e. @myfile.sql will pick up this directory.
You can also set a preference for exporting files.
Also if you use File -> Open, it should remember where you were the last time, so you hunt the first time, then it remembers for the next time. There is a bug for ctrl-O that always goes back to the original directory, but that has been fixed for the next patch release, so ctrl -O will also remember where you were last.
The differences here are because we are dependent on the IDE from JDeveloper, and so we don't have full control over the Save and Open dialogs. We are aware of this frustration and are planning to change this for a future release.
Regards
Sue

Metadata character set translation

Hi does any one have an idea how to have your Aperture metadata info exported in the CP 1252 encoding? (Windows Western Europe). (Standard is MAC encoding.)
All my accents in French, German, Spanish and Dutch words come out garbled when I upload my photos to my photo agencies, or my web based Photoshelter archive.
I've tried a lot. So far my only solution is to export my files. Open them in FotoStation which has a conversion function. This is a lot of work though since adding and changing keywords in that program is extremely user unfriendly.
Any advice welcome!
Ronald

We bought SAP R3 system that uses base with WE8DEC set but saves character data in CL8ISO8859P5 for Russian languageI understand your configuration/requirement. The supported way for you to do this is to change your database character set to match the encoding of the data in the database. If you are sure they are all Russian data in CL8ISO8859P5 encoding formats (The Character set scanner utility shipped in 8.1.7 can assist you in verifying the data inside your db) .
Since your Oracle db supports SAP R3 , it is better if you contact SAP on whether they support the changing the db chacter set and the steps involved .

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

Changing DB character set for only one schema

We are interested in changing the characterset of only one user from Western European to AL32UTF8.
Could you please verify if the following steps will be correct to do the same.
1. Run CSScan on the one user
2. Fix any issues
3. Export that one user (with NLS_LANG set to <your old database character set>)
4. Create a new database in the AL32UTF8 character set
5. Import that one user into the new database (with NLS_LANG set to <your old database character set>)

Actually your title is a little incorrect. You are not changing CS for only one schema in existing DB which is not possible. You are trying to migrate a schema to new CS DB. Which is totally doable and your approach is mostly correct.
Database Character Set Scanner provide user scan mode
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch12scanner.htm#i1006013
Mostly the issue could be data truncation, especially if you have column defined using char or varchar2 vs nchar and nvarchar2
because char/varchar is defined in bytes, AL32UTF8 is multi-bytes char set, some character of your old data could saved more than 1 bytes in new DB and can't fit into the column size.

How to change the character set?

Platform is win2000 and oracle 8.17. I need to write data in Bulragian. Automatic character converter in oracle didn't work! Database is created already!
Is there any function in pl/sql or Java that can convert character set in cl8mswin1251? When I read the data from database there are only ?????
Thank you in advance!

I'm not sure what you're asking here. "Will it be ok" for what?
Assuming
- you read the chapter I linked to,
- ran the character set scanner,
- the character set scanner indicated that all your existing data is properly encoded ISO 8859-1
- the character set scanner indicated that all the ISO 8859-1 data could be converted to Windows-1252
- all the national character set data was properly encoded in whatever national character set the database had
- you did the export properly
- you did the import properly
- your client NLS_LANG settings are all correct
then sure, everything should be OK.
If you skipped one of these steps, I would again strongly encourage you to read the chapter I linked to originally as well as the Metalink article others have pointed you to.
Justin

How do you define which character set gets embedded with a font embedded in the library (i.e. Korean)?

I have project that uses a shared fonts. The fonts are all
contained in a single swf ("fonts.swf"), are embedded in that swf's
library and are set to export for actionscript and runtime sharing.
The text in the project is dynamic and is loaded in from
external XML files. The text is formatted via styles contained in a
CSS object.
This project needs to be localized into 20 or so different
languages.
Everything works great with one exception: I can’t
figure out how to set which character set gets exported for runtime
sharing. i.e. I want to create a fonts.swf that contains Korean
characters, change the XML based text to Korean and have the text
display correctly.
I’ve tried changing the language of my OS (WinXP) and
re-exporting but that doesn’t work correctly. I’ve also
tried adding substitute font keys to the registry (at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes) as outlined here:
http://www.quasimondo.com/archives/000211.php
but the fonts I added did not show up in Flash's font menue.
I’ve also tried the method outlined here:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_16275
to no avail.
I know there must be a simple solution that will allow me to
embed language specific character sets for the fonts embedded in
the library but I have yet to discover what it is.
Any insight would be greatly appreciated.
http://www.quasimondo.com/archives/000211.php
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_16275

Thanks Jim,
I know that it is easy to specify the language you want to
use when setting the embed font properties for a specific text
field but my project has hundreds of text fields and I'm setting
the font globally by referencing the font symbols in a single swf.
I have looked at the info you've pointed out but wasn't
helped by it. What I'd like to be able to do is to tell Flash to
embed a language specific character-set for the font symbols in the
library. It currently is only embedding Latin characters even
though I know the fonts specified contains characters for other
languages.
For example. I have a font symbol in the libary named
"Font1". When I look at its properties I can see it is spcified as
Tahoma. I know the Tahoma font on my system contains the characters
for Korean but when I compile the swf it only contains Latin
characters (gylphs) - this corresponds to the language of my OS (US
English). I want to know how to tell Flash to embedd the Korean
language charaters rather than or as well as the Latin characters
for any given FONT SYMBOL. If I could do that, then, when I enter
Korean text into my XML files the correct characters will be
available to Flash. As it is now, the characters are not available
and thus the text doesn' t display.
Make sense?
Many thanks,
Mike

Character Set questions on setup

I am trying to determine what the best setup recommendations are for creating non_English Oracle 10g databases. I have not had much experience building databases for non_English locales, so this is getting a little overwhelming as I have been researching Oracle's Database Globalization Support Guide. Obviously it has a wealth of information and I am trying to determine what applies to us at this point and time.
Generally when someone buys our product they create a new Oracle instance for our app. I need to be able to recommend proper database settings/parameters for potential global customers who purchase our software to run on Oracle.
Currently my biggest question is what to recommend for the Database Characterset on db creation. Currently the DB Character Set we recommend (for standard U.S. installs on Windows) is the default WE8MSWIN1252 character set. Our application is non-unicode. It has been recommended to me from an outside consultant that we "must" use UTF-8 for DB and National Character Set settings, as opposed to WE8MSWIN1252 or WE8ISO8859P1. I should mention that our focus at this point and time is getting a solution for French, German, and Spanish. We are also more concerned about a single language setup than multilanguage - although that is a definite future consideration.
What impact can using UTF-8 as opposed to WE8MSWIN1252 or WE8ISO8859P1 have on a non-unicode application? I hope I am explaining the situation well enough as I am fairly new and still getting to know our application. I am kind of getting thrown into the i18n fire...
Any input is greatly appreciated. Thanks.

Your questions are certainly valid but you have not given any details about your application: what it does, what technologies and access drivers are employed, and what client operating systems are supported. This determines how much effort is required to make the application Unicode-enabled and what are the risks coming from each of the possible approaches.
As long as your application can work with single-byte character sets only and as long as it is not expected to contain multibyte data, and as long as it supports Windows only, the Oracle character set corresponding to relevant Windows ANSI code page is the correct choice. For English, French, German, Spanish, and other Western European languages, WE8MSWIN1252 is right one.
Processing of WE8MSWIN1252 is easier and somehow faster than processing AL32UTF8 (i.e. UTF-8) data. One character corresponds to one byte and this simplifies some aspects of text processing.
On the other hand, world becomes smaller and smaller in the Internet area. Companies that never did any business abroad start to talk to customers around the world because somebody found their website. Western European companies take advantage of the European Union enlargement and start making business in new countries. Therefore, it is dangerous to assume that a company currently interested in a monolingual, single-byte solution will not want to migrate to a multilingual and multibyte solution in few years.
If you follow a few rules in database design and programming, you can run your single-byte application against an AL32UTF8 database, even if you do not get a multilingual system in this way. Such configuration has the huge advantage of avoiding the need of a complex and resource consuming task of migrating the database character set to Unicode in future, when your customer asks for multilingual support. Upgrading binaries of your application to an Unicode-enabled version is usually fast, migrating the database character set is not.
The main rules you should follow are:
1) Use character length semantics to define column and PL/SQL variable lengths, i.e. say VARCHAR2(10 CHAR) instead of VARCHAR2(10 [BYTE]). If you do not want to modify all creation scripts to include the CHAR keyword, issue ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR at the beginning of each script. I recommend modifying the scripts.
2) Do not use VARCHAR2 columns longer than 1000 characters, CHAR columns longer than 500 characters, and PL/SQL VARCHAR2/CHAR variables longer than 8190 characters. This guarantees that in the future no AL32UTF8 string will exceed the hard limit of 4000/2000/32760 bytes. Use CLOB for longer text.
3) Use SUBSTR/LENGTH/INSTR in place of SUBSTRB/LENGTHB/INSTRB. Use SUBSTRB/LENGTHB/INSTRB only when dealing with legacy stuff or Data Dictionary that still use byte length semantics.
4) Define the client setting - mainly NLS_LANG - to correctly correspond to the character set processed by your application.
5) Modify interfaces to other databases, if any, to cope with the character length semantics. You do not have to do much if the other databases follow the same rules.
The cost of running the database in Unicode is not high for most languages, though languages that do not use Latin script, such as Russian, Greek, or Japanese, need significantly more storage for the textual data (but only textual data in those languages - this is only some fraction of all data in the database). Processing is slower by a few percent as compared to single-byte character sets (unless a lot of textual processing is performed in the database, in which case the percentage may be higher - benchmark recommended). This costs can be usually compensated by adding some more computing power (GHz and disks). Unless your application needs a VLDB (very large database) and almost saturates the system, you should not notice a big difference.
-- Sergiusz

German character set issues on Solaris

Hi,
I am facing an issue with German character settings with my Java application on a solaris box.
When I run my application on the box, and I pass an input file with German special characters they get converted as ?. However, other normal English characters are formed properly.
When I run the same application on another Solaris box with a different JRE, the German characters are formed properly.
I understand that there is a difference in the archiecture between the 2 boxes ie.e
64 bit SPARC machine v/s 32 bit x86 machine
the JRE
1.4.2_03(64bit) v/s 1.4.1_01
I am tryinbg to evaludate further differences between the 2 environments to pinpoint the issue, and get this resolved on the 1st box.
Can anyone provide me any inputs?
Lavin

When you read the file, please point out what character set using. For example:
FileInputStream fstream = new FileInputStream(url.getFile());
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader(new InputStreamReader(in, Charset.forName("ISO-8859-1")));
br.readLine();
This link possibly can help you.
http://www.velocityreviews.com/forums/t126128-jdk-14-character-set-change.html

Need to add Polish option to character set menu in SAP Gui

Basis Gurus,
We have installed the Polish language on our unicode R/3 system and now
need to add it as a character set option in the Gui menu.
Menu Path:
Customize Local Layout --> Character Set --> (Missing Option for Polish)
I have searched OSS and online resources and have not found out how to
add an entry in this menu.
I did alter the file frontEN.txt in which the menu entries are built,
but did this not add the entry.
Can you please advise on the procedure to add this entry. Our
developers need it to view special Polish characters in their SapScript.
Thanks,
Jeff Martens

Deepak,
Thanks for the reply. I've read that document before, it's helpful with some of the I18N settings, but does not explain how to add a language to the "character set" menu.
Does anyone know if this is possible?
Thanks,
Jeff

Character Set Scanner utility for HP Open Alpha VMS

Similar Messages

Maybe you are looking for