You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2010/01/07 23:44:54 UTC

[jira] Created: (DERBY-4508) ij on slavic machine does not create files with appropriate encoding

ij on slavic machine does not create files with appropriate encoding
--------------------------------------------------------------------

                 Key: DERBY-4508
                 URL: https://issues.apache.org/jira/browse/DERBY-4508
             Project: Derby
          Issue Type: Bug
          Components: Tools
    Affects Versions: 10.5.3.0
         Environment: PC (windows Server 2007) with codepage Cp852 (console.encoding is Cp852)
            Reporter: Myrna van Lunteren


On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.

For instance, consider the following string with non-ascii characters: Českýnázev

When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
   ij> connect 'jdbc:derby:Českýnázev;create=true';
ij creates a database that on the OS shows like so: ¬eskěn zev

When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).

Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
(only 1 method, main), with appropriate  imports):
-----------------------
    public static void main(String[] args) throws Exception {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader in = new BufferedReader(isr);
        String inputString = in.readLine();
        System.out.println("inputString: " + inputString);
        
        File f = new File(inputString);
        f.createNewFile();
        System.out.println("created a file called " + inputString);
        
        in.close();
        isr.close();
    }
----------------------------------------
Sun's jdk 1.6 gives the following output:
------------------
Českýnázev
inputString: Českýnázev
created a file called Českýnázev
------------------
While IBM's jdk 1.6 does this:
------------------
Českýnázev
inputString: ¬eskěn zev
created a file called ¬eskěn zev
------------------
However in both cases the file created on the OS (dos prompt, looks like the way ij created the database dir:
¬eskěn zev

If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=pl when starting ij, the file created has the expected name, so this is a workaround.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DERBY-4508) ij on slavic machine does not create files with appropriate encoding

Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-4508:
--------------------------------------

    Attachment: GarbledFilename.java

attaching the simple repro

> ij on slavic machine does not create files with appropriate encoding
> --------------------------------------------------------------------
>
>                 Key: DERBY-4508
>                 URL: https://issues.apache.org/jira/browse/DERBY-4508
>             Project: Derby
>          Issue Type: Improvement
>          Components: Tools
>    Affects Versions: 10.5.3.0
>         Environment: PC (windows Server 2007) with codepage Cp852 (console.encoding is Cp852)
>            Reporter: Myrna van Lunteren
>         Attachments: GarbledFilename.java
>
>
> On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.
> For instance, consider the following string with non-ascii characters: Českýnázev
> When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
>    ij> connect 'jdbc:derby:Českýnázev;create=true';
> ij creates a database that on the OS shows like so: ¬eskěn zev
> When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).
> Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
> (only 1 method, main), with appropriate  imports):
> -----------------------
>     public static void main(String[] args) throws Exception {
>         InputStreamReader isr = new InputStreamReader(System.in);
>         BufferedReader in = new BufferedReader(isr);
>         String inputString = in.readLine();
>         System.out.println("inputString: " + inputString);
>         
>         File f = new File(inputString);
>         f.createNewFile();
>         System.out.println("created a file called " + inputString);
>         
>         in.close();
>         isr.close();
>     }
> ----------------------------------------
> Sun's jdk 1.6 gives the following output:
> ------------------
> Českýnázev
> inputString: Českýnázev
> created a file called Českýnázev
> ------------------
> While IBM's jdk 1.6 does this:
> ------------------
> Českýnázev
> inputString: ¬eskěn zev
> created a file called ¬eskěn zev
> ------------------
> However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
> ¬eskěn zev
> If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=Cp852 when starting ij, the file created has the expected name, so this is a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DERBY-4508) ij on slavic machine does not create files with appropriate encoding

Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-4508:
--------------------------------------

    Description: 
On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.

For instance, consider the following string with non-ascii characters: Českýnázev

When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
   ij> connect 'jdbc:derby:Českýnázev;create=true';
ij creates a database that on the OS shows like so: ¬eskěn zev

When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).

Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
(only 1 method, main), with appropriate  imports):
-----------------------
    public static void main(String[] args) throws Exception {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader in = new BufferedReader(isr);
        String inputString = in.readLine();
        System.out.println("inputString: " + inputString);
        
        File f = new File(inputString);
        f.createNewFile();
        System.out.println("created a file called " + inputString);
        
        in.close();
        isr.close();
    }
----------------------------------------
Sun's jdk 1.6 gives the following output:
------------------
Českýnázev
inputString: Českýnázev
created a file called Českýnázev
------------------
While IBM's jdk 1.6 does this:
------------------
Českýnázev
inputString: ¬eskěn zev
created a file called ¬eskěn zev
------------------
However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
¬eskěn zev

If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=pl when starting ij, the file created has the expected name, so this is a workaround.


  was:
On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.

For instance, consider the following string with non-ascii characters: Českýnázev

When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
   ij> connect 'jdbc:derby:Českýnázev;create=true';
ij creates a database that on the OS shows like so: ¬eskěn zev

When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).

Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
(only 1 method, main), with appropriate  imports):
-----------------------
    public static void main(String[] args) throws Exception {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader in = new BufferedReader(isr);
        String inputString = in.readLine();
        System.out.println("inputString: " + inputString);
        
        File f = new File(inputString);
        f.createNewFile();
        System.out.println("created a file called " + inputString);
        
        in.close();
        isr.close();
    }
----------------------------------------
Sun's jdk 1.6 gives the following output:
------------------
Českýnázev
inputString: Českýnázev
created a file called Českýnázev
------------------
While IBM's jdk 1.6 does this:
------------------
Českýnázev
inputString: ¬eskěn zev
created a file called ¬eskěn zev
------------------
However in both cases the file created on the OS (dos prompt, looks like the way ij created the database dir:
¬eskěn zev

If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=pl when starting ij, the file created has the expected name, so this is a workaround.





> ij on slavic machine does not create files with appropriate encoding
> --------------------------------------------------------------------
>
>                 Key: DERBY-4508
>                 URL: https://issues.apache.org/jira/browse/DERBY-4508
>             Project: Derby
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 10.5.3.0
>         Environment: PC (windows Server 2007) with codepage Cp852 (console.encoding is Cp852)
>            Reporter: Myrna van Lunteren
>
> On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.
> For instance, consider the following string with non-ascii characters: Českýnázev
> When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
>    ij> connect 'jdbc:derby:Českýnázev;create=true';
> ij creates a database that on the OS shows like so: ¬eskěn zev
> When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).
> Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
> (only 1 method, main), with appropriate  imports):
> -----------------------
>     public static void main(String[] args) throws Exception {
>         InputStreamReader isr = new InputStreamReader(System.in);
>         BufferedReader in = new BufferedReader(isr);
>         String inputString = in.readLine();
>         System.out.println("inputString: " + inputString);
>         
>         File f = new File(inputString);
>         f.createNewFile();
>         System.out.println("created a file called " + inputString);
>         
>         in.close();
>         isr.close();
>     }
> ----------------------------------------
> Sun's jdk 1.6 gives the following output:
> ------------------
> Českýnázev
> inputString: Českýnázev
> created a file called Českýnázev
> ------------------
> While IBM's jdk 1.6 does this:
> ------------------
> Českýnázev
> inputString: ¬eskěn zev
> created a file called ¬eskěn zev
> ------------------
> However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
> ¬eskěn zev
> If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=pl when starting ij, the file created has the expected name, so this is a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DERBY-4508) ij on slavic machine does not create files with appropriate encoding

Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-4508:
--------------------------------------

    Description: 
On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.

For instance, consider the following string with non-ascii characters: Českýnázev

When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
   ij> connect 'jdbc:derby:Českýnázev;create=true';
ij creates a database that on the OS shows like so: ¬eskěn zev

When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).

Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
(only 1 method, main), with appropriate  imports):
-----------------------
    public static void main(String[] args) throws Exception {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader in = new BufferedReader(isr);
        String inputString = in.readLine();
        System.out.println("inputString: " + inputString);
        
        File f = new File(inputString);
        f.createNewFile();
        System.out.println("created a file called " + inputString);
        
        in.close();
        isr.close();
    }
----------------------------------------
Sun's jdk 1.6 gives the following output:
------------------
Českýnázev
inputString: Českýnázev
created a file called Českýnázev
------------------
While IBM's jdk 1.6 does this:
------------------
Českýnázev
inputString: ¬eskěn zev
created a file called ¬eskěn zev
------------------
However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
¬eskěn zev

If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=Cp852 when starting ij, the file created has the expected name, so this is a workaround.


  was:
On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.

For instance, consider the following string with non-ascii characters: Českýnázev

When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
   ij> connect 'jdbc:derby:Českýnázev;create=true';
ij creates a database that on the OS shows like so: ¬eskěn zev

When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).

Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
(only 1 method, main), with appropriate  imports):
-----------------------
    public static void main(String[] args) throws Exception {
        InputStreamReader isr = new InputStreamReader(System.in);
        BufferedReader in = new BufferedReader(isr);
        String inputString = in.readLine();
        System.out.println("inputString: " + inputString);
        
        File f = new File(inputString);
        f.createNewFile();
        System.out.println("created a file called " + inputString);
        
        in.close();
        isr.close();
    }
----------------------------------------
Sun's jdk 1.6 gives the following output:
------------------
Českýnázev
inputString: Českýnázev
created a file called Českýnázev
------------------
While IBM's jdk 1.6 does this:
------------------
Českýnázev
inputString: ¬eskěn zev
created a file called ¬eskěn zev
------------------
However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
¬eskěn zev

If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=pl when starting ij, the file created has the expected name, so this is a workaround.



> ij on slavic machine does not create files with appropriate encoding
> --------------------------------------------------------------------
>
>                 Key: DERBY-4508
>                 URL: https://issues.apache.org/jira/browse/DERBY-4508
>             Project: Derby
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 10.5.3.0
>         Environment: PC (windows Server 2007) with codepage Cp852 (console.encoding is Cp852)
>            Reporter: Myrna van Lunteren
>
> On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.
> For instance, consider the following string with non-ascii characters: Českýnázev
> When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
>    ij> connect 'jdbc:derby:Českýnázev;create=true';
> ij creates a database that on the OS shows like so: ¬eskěn zev
> When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).
> Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
> (only 1 method, main), with appropriate  imports):
> -----------------------
>     public static void main(String[] args) throws Exception {
>         InputStreamReader isr = new InputStreamReader(System.in);
>         BufferedReader in = new BufferedReader(isr);
>         String inputString = in.readLine();
>         System.out.println("inputString: " + inputString);
>         
>         File f = new File(inputString);
>         f.createNewFile();
>         System.out.println("created a file called " + inputString);
>         
>         in.close();
>         isr.close();
>     }
> ----------------------------------------
> Sun's jdk 1.6 gives the following output:
> ------------------
> Českýnázev
> inputString: Českýnázev
> created a file called Českýnázev
> ------------------
> While IBM's jdk 1.6 does this:
> ------------------
> Českýnázev
> inputString: ¬eskěn zev
> created a file called ¬eskěn zev
> ------------------
> However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
> ¬eskěn zev
> If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=Cp852 when starting ij, the file created has the expected name, so this is a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DERBY-4508) ij on slavic machine does not create files with appropriate encoding

Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-4508:
--------------------------------------

    Issue Type: Improvement  (was: Bug)

After some more experiments and further checking, it seems that the only information available to the jvm relating to the codepage/chcp of the OS is the IBM jvm specific console.encoding.

I'm changing this to an enhancement request - perhaps we can modify the ij scripts so that we set -Dderby.ui.codeset gets set in accordance with the codepage on the OS by default.

> ij on slavic machine does not create files with appropriate encoding
> --------------------------------------------------------------------
>
>                 Key: DERBY-4508
>                 URL: https://issues.apache.org/jira/browse/DERBY-4508
>             Project: Derby
>          Issue Type: Improvement
>          Components: Tools
>    Affects Versions: 10.5.3.0
>         Environment: PC (windows Server 2007) with codepage Cp852 (console.encoding is Cp852)
>            Reporter: Myrna van Lunteren
>
> On a machine configured with slavic codeset Cp852 ij does not always create (or access) files with appropriate characters.
> For instance, consider the following string with non-ascii characters: Českýnázev
> When starting ij using only defaults: java org.apache.derby.tools.ij (or using one of the ij scripts from bin) and issueing the following connect statement:
>    ij> connect 'jdbc:derby:Českýnázev;create=true';
> ij creates a database that on the OS shows like so: ¬eskěn zev
> When I have a file - e.g. simple.sql - that does this connect, the file created on the OS has the expected name (Českýnázev).
> Using a simple program that does the same as org.apache.derby.iapi.tools.i18n.LocalizedInput
> (only 1 method, main), with appropriate  imports):
> -----------------------
>     public static void main(String[] args) throws Exception {
>         InputStreamReader isr = new InputStreamReader(System.in);
>         BufferedReader in = new BufferedReader(isr);
>         String inputString = in.readLine();
>         System.out.println("inputString: " + inputString);
>         
>         File f = new File(inputString);
>         f.createNewFile();
>         System.out.println("created a file called " + inputString);
>         
>         in.close();
>         isr.close();
>     }
> ----------------------------------------
> Sun's jdk 1.6 gives the following output:
> ------------------
> Českýnázev
> inputString: Českýnázev
> created a file called Českýnázev
> ------------------
> While IBM's jdk 1.6 does this:
> ------------------
> Českýnázev
> inputString: ¬eskěn zev
> created a file called ¬eskěn zev
> ------------------
> However in both cases the file created on the OS (dos prompt, windows explorer) looks like the way ij created the database dir:
> ¬eskěn zev
> If we specify -Dfile.encoding=Cp852, or -Dderby.ui.codeset=Cp852 when starting ij, the file created has the expected name, so this is a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.