ASCII 129

Greetings,
I'v got a Problem
At my report (generated with CR 11) is a formularfield located, witch calculates a string used for barcode-font. For our customers we use some applications once with the runtimefiles and viewes from Crystal 8.5 and on the other hand crystal 11. It works without problems. But this formularfield formatted with the barcode-font works different on using viewer CR 11 in contrast using CR 85. By viewing this report, generated with the engine of CR 11, the Ascii-sign 129 is missing. So the barcode can no be read from the scanner. Using the same formularfield with same dates on CR 85-report viewing with the 8.5 viewer - all works. We swap the font, printers, drivers for printers repeatedly always the same result. If the barcodefont isn't installed, you can see the string but in the preview and printout of the report generated with cr 11 is missing Ascii-sign 129. But only at one costumer. Using the same Report (Cr 11) with exact the similar dates at our environment or at our other customers it works. What should be the problem? All our costomers using the same runtimfiles for the 11 and 8.5 crystal with the latest updates, patches and monthly hotfixes. The formluar functioned definitively. What is the differnt between Cr 85 an Cr 11 by using fonts? I'm deeply grateful for any tip.
Markus

Hi Markus
You might like to see the Service Pack3 read me that fixed some issues for ASCII for CR 11.
Here is the [link|http://ftp1.businessobjects.com/outgoing/CMS/crXIwin_en_sp3.pdf]
Please also provide some more details about the exact version of Crystal 11.
Regards
Sourashree

Similar Messages

  • Problem converting hex -values changes

    Guys,
    I have a hex value 0x81(ascii 129). when I convert that to a string by passing this value through byte array it gets converted to " ? "(ascii 63) which is 3f in hex when converted back. I am not sure what is wrong here. Could someone help me.
    Thanks in advance.

    Guys,
    I have a hex value 0x81(ascii 129). when I convert
    that to a string by passing this value through byte
    array it gets converted to " ? "(ascii 63) which is
    3f in hex when converted back. I am not sure what is
    wrong here. Could someone help me.
    Thanks in advance.this is an extended ascii char a u with two dots on it. The default encoding for Strings is iso-8859-1 and I guess this char is not supported there. When creating a String specifiy encoding utf8.

  • Ascii character 129 for newline in the text file

    Hi there,
    I have java program that makes JDBC connection and reads through a table, write a column in text file, after each column puts delimiter "|"and after each row prints in the next line.
    This is the code below.
    public void queryRecords() {
             Statement stmt           = null;
            ResultSet rset           = null;
            try {
                  stmt = con.createStatement();
                  int numRows = 0;
                File file           = new File("/tmp/temp.txt");
                FileWriter writer   = new FileWriter(file, false);
                BufferedWriter pw      = new BufferedWriter(writer);
                rset = stmt.executeQuery("SELECT * FROM mytable");
                ResultSetMetaData rsmd = rset.getMetaData();
                int colCount = rsmd.getColumnCount();
                while (rset.next()) {
                    for (int i = 1;i <= colCount; i++) {
                        String st = rsmd.getColumnTypeName(i);
                        if (st.equals("DATE")) {
                            Date d1 = rset.getTimestamp(i);
                            pw.write(d1 + "|");
                        } else {
                            Object o1 = rset.getObject(i);
                            if (o1 != null) {
                                pw.write(o1 + DELIM);
                            } else {
                                pw.write(DELIM);
                    pw.newLine();
                pw.close();
                 rset.close();
                 stmt.close();When i open this Temp.txt file in notepad i see ascii character 129 (rectangular box) instead of the new line. But when i print the file i have each row in a separate line.
    Why could this be happening??
    Please help...

    hi,
    Try PrintWriter instead :
    File file = new File("D:/testing.txt");
            //FileWriter writer   = new FileWriter(file, false);
            //BufferedWriter pw      = new BufferedWriter(writer);
            PrintWriter pw = new PrintWriter(file);
            pw.print("aaa");
            pw.print("|");
            pw.print("aaa");
         public static void main(String[] args) throws Exception {
              File file = new File("/test/test.txt");
            //FileWriter writer   = new FileWriter(file, false);
            //BufferedWriter pw      = new BufferedWriter(writer);
            PrintWriter pw = new PrintWriter(file);
            pw.print("aaa");
            pw.print("|");
            pw.print("aaa");
            pw.print("|");
            pw.print("aaa");
            pw.println();
            pw.print("aaa");
            pw.print("|");
            pw.print("aaa");
            pw.print("|");
            pw.print("aaa");
            pw.close();
         }hth

  • Writing ASCII 0x81 to file with PrintStream

    Hello
    I am trying to export textfiles to an other system (IBM AS400). But for that i need to convert some special characters. It works fine with most of the characters (i simply replace the characters in the String that i write to the File (String.replace(oldchar, newchar))
    One character gives me trouble. I need to convert the char 0xFC to 0x81. But if i try to write this character to the File (I am using PrintWriter because i want to use the println(...) method) all i get in the File is the character 0x3F.
    I tried different methods to write this char (0x81) but only if i use the OutputStream directly am I able to write 0x81 to the File.
    Here is a sample code to illustrate my problem
    public static void main(String[] args) {
            FileOutputStream fo = null;
            PrintStream p = null;
            //PrintWriter p = null; //if i use PrintWriter the problem is the same
            FileReader fi = null;
            BufferedReader d = null;
            String sampleFile = "c:\\only81.txt"; //contains 3 Lines of (char)0x81
            String outFile = "c:\\test.txt";
            try {
                fo = new FileOutputStream(outFile);
                p = new PrintStream(fo);
                fi = new FileReader(sampleFile);
                d = new BufferedReader(fi);
                p.println("Test to write ASCII 0x81 (129)");
                String temp = null;
                while ((temp = d.readLine()) != null)
                    p.println(temp);  //all stored chars are 0x3F
                for (char i = 1; i<512; i++) //char 0x80-0x9F are all
                    p.print(i);                     //stored as 0x3F (also chars>FF)
                p.flush();
                fo.write(129);     //these 4 lines actually work
                fo.write(0x81);
                fo.write((char)129);
                fo.write((char)0x81);
                d.close();
                fi.close();
                p.close();
                fo.close();
            } catch (FileNotFoundException e) {
                e.printStackTrace();
            } catch (IOException e) {
                e.printStackTrace();
        }What i would really like to understand is why there is the problem with the chars 0x80-0x9F (even my IDE (Eclipse)) has problems displaying the char in its Editor)
    and how i can write 0x81 to a file (when 0x81 is part of a String)

    You are writing with the default encoding, which is UTF-8Printwriter p = new PrintWriter(new OutputStreamWriter(new FileOutputStream(outFile), "ISO-8859-1"));will not have the same problem.
    Use the same for readingBufferedReader d = new BufferedReader(new InputStreamReader(new FileInputStream(sampleFile), "ISO-8859-1"));

  • Problem convertting certain extended ascii characters

    I'm having problems with the extended ascii characters in the range 128-159. I'm working with SQL server environment using java. I originally had problems with characters in the range 128-159 when I did a 'select char_col from my_table' I always get junk when I try to retreive it from the ResultSet using the code 'String str = rs.getString(1)'. For example char_col would have the ascii character (in hex) '0x83' but when I retrieved it from the database, my str equaled '0x192'. I'm aware there is a gap in the range 128-159 in ISO-8859-1 charset. I've tracked the problem to be a charset issue converting the extended ascii characters in ISO-8859-1 into java's unicode charset.
    I looked on the forum and it said to try to specify the charset when I retreived it from the resultset so I did 'String str = new String(rs.getBytes(), "ISO-8859-1")' and it was able to read the characters 128-159 correctly except for five characters (129, 141, 143, 144, 157). These characters always returned the character 63 or 0x3f. Does anyone who what's happening here? How come these characters didn't work? Is there a workaround this? I need to use only use java and its default charsets and I don't want to switch to the windows Cp1252 charset cuz I'm using the java code in a unix environment as well.
    thanks.
    -B

    Normally your JDBC driver should understand the charset used in the database, and it should use that charset to produce a correct value for the result of getString(). However it does sometimes happen that the database is created by programs in some other language that ignore the database's charset and do their own encoding, bypassing the database's facilities. It is often difficult to deal with that problem, because the custodians of those other programs don't have a problem, everything is consistent for them, and they will not allow you to "repair" the database.
    I don't mean to say that really is your problem, it is a possibility though. You are using an SQL Server JDBC driver, aren't you? Does its connection URL allow you to specify the charset? If so, try specifying that SQL-Latin1 thing and see if it works.

  • Exchanging non ASCII bytes by socket tcp

    Hello:
    I'm trying to exchange characters between 0-255 of ascii characters table. I'm using the CharToByteConverter and ByteToCharConverter classes on my client/server programs, but I can't get it.
    The client/server programs use socket tcp, but I'm not sure the data structures that I must to use in order to send bytes with these characteristics (0-255 ascii characters)
    For example I need to send the next array to server program:
    char[] car = new char[15];
    car[0] = (char)129;
    car[1] = (char)12;
    car[2] = (char)201;
    car[3] = (char)1;
    car[4] = (char)48;
    car[5] = (char)48;
    car[6] = (char)1;
    car[7] = (char)1;
    car[8] = (char)95;
    car[9] = (char)4;
    car[10] = (char)17;
    car[11] = (char)3;
    car[12] = (char)22;
    car[13] = (char)38;
    car[14] = (char)53;
    Note: In UDP protocol (socket UDP) the interchange data and the conversions work correctly.
    Any comment will be appreciated, regads,
    Ulises

    You are right. The modem is a device that works (send
    and recive) with tcp/ip or UDP/IP protocol (is a
    modem GPRS). So, I can simulate him with a java
    program sending data by socket tcp/ip. In this case
    is the same.
    The format message is a fact. I can't to choose it.Then that is the message that you are dealing with.
    Presumably this is because you are only writing the client or server and not both.
    >
    My problem is that, for example, I'm waiting (my java
    program with server socket tcp/ip actually) for a
    byte 129 how first byte, but instead of it, I receive
    a byte 63.
    Then one of the following is true.
    - You are using a class that you should not be, like DataInputStream or String.
    - Your understanding of the message protocol is incorrect (perhaps because the spec is wrong.)
    - Or the message that is being sent is wrong but presumably there is nothing that you can do about that.
    Sockets send and receive bytes. They don't send and receive characters.
    Now it could be that the data being sent is indeed characters but that has nothing to do with the socket. It doesn't transform them, map them, nor touch them in any way.
    In addition, depending of the data structure used
    (char [] or byte []) how buffer, I lose some bytes.Then either you are doing something wrong (like using the buffer size rather than the read size) or the message protocol is very ill defined. If the second then you will have to develope a fuzzy algorithm to guess at the correct behavior.

  • Outlook voting responds with ASCII characters

    Issue: A user sends an e-mail with the voting options configured. When the recipient responds without editing the response, the reply comes back with a bunch of Asian,etc... ASCII characters. If the response is edited, the response looks normal. This is
    happening for multiple users on multiple Outlook version. Is there a default template that has gotten corrupted somewhere? How is the default reponse formed that I might fix this?
    Source code of responses:
    <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">&#18492;&#19796;&#15948;&#18492;
    &#16709;&#15940;&#8508;&#11565;&#21536;&#28005;&#27760;&#29793;&#8293;&#25959;&#25966;&#24946;&#25972;
    &#8292;&#31074;&#17696;&#25464;&#24940;&#28009;&#29285;&#19744;&#26977;&#8300;&#26948;&#25459;&#24940;
    &#28009;&#29285;&#8307;&#28271;&#12576;&#14896;&#14642;&#13114;&#8247;&#30036;&#29541;&#24932;&#11385;
    &#13344;&#19744;&#29281;&#26723;&#12832;&#12592;&#8244;&#11565;&#3390;&#15370;&#21587;&#19545;&#8261;&
    #31092;&#25968;&#29757;&#30821;&#12148;&#29539;&#15987;&#11856;&#25699;&#13620;&#13879;&#13360;&#26157
    ;&#25910;&#11622;&#14644;&#12901;&#14637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873;&#12337;&#134
    13;&#31520;&#2573;&#19721;&#21057;&#18759;&#14926;&#12320;&#28003;&#12320;&#28003;&#12320;&#29808;&#25
    73;&#3453;&#19466;&#11849;&#25699;&#13620;&#13879;&#13360;&#26157;&#25910;&#11622;&#14644;&#12901;&#14
    637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873;&#12337;&#13413;&#31520;&#2573;&#19721;&#21057;&#1
    8759;&#14926;&#12320;&#28003;&#12320;&#28003;&#12320;&#29808;&#2573;&#3453;&#17418;&#22089;&#25390;&#1
    3412;&#14133;&#12342;&#11572;&#13926;&#26213;&#13357;&#25913;&#11570;&#13625;&#12853;&#25645;&#12596;&
    #14389;&#12644;&#12598;&#25904;&#8244;&#3451;&#2314;&#16717;&#18258;&#20041;&#8250;&#25392;&#8301;&#25
    392;&#8301;&#28720;&#3444;&#32010;&#2573;&#16724;&#19522;&#11845;&#25699;&#13620;&#13879;&#13360;&#261
    57;&#25910;&#11622;&#14644;&#12901;&#14637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873;&#12337;&#1
    3413;&#24916;&#27746;&#8293;&#3451;&#2314;&#16717;&#18258;&#20041;&#8250;&#25392;&#8301;&#25392;&#8301
    ;&#28720;&#3444;&#32010;&#2573;&#18756;&#11862;&#25939;&#29795;&#28521;&#12654;&#31520;&#2573;&#28681;
    &#26465;&#14949;&#21280;&#25445;&#26996;&#28271;&#3377;&#32010;&#2573;&#12092;&#21587;&#19545;&#15941;
    &#2573;&#12092;&#17736;&#17473;&#3390;&#15370;&#20290;&#22852;&#3390;&#15370;&#8272;&#27747;&#29537;&#
    15731;&#25699;&#13620;&#13879;&#13360;&#26157;&#25910;&#11622;&#14644;&#12901;&#14637;&#13621;&#11570;
    &#13412;&#13617;&#25656;&#13873;&#12337;&#13413;&#15422;&#20527;&#3390;&#15370;&#8272;&#27747;&#29537;
    &#15731;&#25699;&#13620;&#13879;&#13360;&#26157;&#25910;&#11622;&#14644;&#12901;&#14637;&#13621;&#1157
    0;&#13412;&#13617;&#25656;&#13873;&#12337;&#13413;&#9790;&#25198;&#28787;&#15419;&#20527;&#3390;&#1537
    0;&#8272;&#27747;&#29537;&#15731;&#25699;&#13620;&#13879;&#13360;&#26157;&#25910;&#11622;&#14644;&#129
    01;&#14637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873;&#12337;&#13413;&#15422;&#19785;&#8263;&#25
    705;&#18749;&#18253;&#8241;&#28514;&#25714;&#29285;&#12349;&#29472;&#25458;&#8765;&#26979;&#14948;&#28
    009;&#26465;&#25701;&#12337;&#12853;&#11833;&#20554;&#16455;&#24884;&#14648;&#25954;&#13624;&#13358;&#
    14691;&#14694;&#13874;&#8761;&#30496;&#25705;&#26740;&#12605;&#12344;&#26656;&#26981;&#26727;&#15732;&
    #14388;&#12064;&#15422;&#20527;&#3390;&#15370;&#8272;&#27747;&#29537;&#15731;&#25699;&#13620;&#13879;&
    #13360;&#26157;&#25910;&#11622;&#14644;&#12901;&#14637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873
    ;&#12337;&#13413;&#15422;&#20294;&#21582;&#25376;&#27759;&#29295;&#9021;&#12336;&#12343;&#12387;&#3390
    ;&#15370;&#21064;&#26912;&#15716;&#21064;&#8241;&#28515;&#28524;&#15730;&#12323;&#13874;&#25143;&#8289
    ;&#15919;&#2573;&#12092;&#20294;&#21582;&#15422;&#20294;&#21582;&#29472;&#31337;&#15717;&#8242;&#24934
    ;&#25955;&#16701;&#26994;&#27745;&#15422;&#20294;&#21582;&#29472;&#31337;&#15717;&#15921;&#25932;&#249
    35;&#8300;&#26948;&#25459;&#24940;&#28009;&#29285;&#8250;&#28233;&#28518;&#28018;&#29793;&#28521;&#830
    2;&#2573;&#28515;&#29806;&#26977;&#25966;&#8292;&#28265;&#29728;&#26984;&#8307;&#11621;&#24941;&#27753
    ;&#8236;&#28265;&#27747;&#25717;&#28265;&#8295;&#28257;&#8313;&#26982;&#25964;&#8307;&#29300;&#28257;&
    #28019;&#29801;&#25972;&#8292;&#26999;&#26740;&#26912;&#11380;&#27936;&#31073;&#25376;&#28271;&#24948;
    &#28265;&#3360;&#25354;&#28271;&#26982;&#25956;&#29806;&#24937;&#8300;&#25965;&#26980;&#24931;&#8300;&
    #29295;&#25120;&#29557;&#28265;&#29541;&#8307;&#28265;&#28518;&#28018;&#29793;&#28521;&#8302;&#28265;&
    #25972;&#25710;&#25701;&#28448;&#27758;&#8313;&#28518;&#8306;&#29557;&#8293;&#31074;&#29728;&#25960;&#
    3360;&#26890;&#29806;&#28261;&#25956;&#8292;&#25970;&#26979;&#26992;&#28261;&#10356;&#10611;&#9774;&#2
    5198;&#28787;&#8251;&#28225;&#8313;&#28277;&#30049;&#26740;&#29295;&#31337;&#25701;&#25632;&#29545;&#2
    7747;&#29551;&#29301;&#11365;&#29984;&#25971;&#8236;&#28515;&#31088;&#28265;&#11367;&#3360;&#25610;&#2
    9545;&#29300;&#25193;&#29813;&#28521;&#8302;&#29295;&#29728;&#27489;&#28265;&#8295;&#26223;&#24864;&#3
    1086;&#24864;&#29795;&#28521;&#8302;&#24930;&#25971;&#8292;&#28271;&#29728;&#25960;&#25376;&#28271;&#2
    5972;&#29806;&#8307;&#26223;&#29728;&#26984;&#8307;&#28005;&#26977;&#8300;&#29545;&#3360;&#29450;&#293
    00;&#25449;&#27764;&#8313;&#29296;&#26735;&#25193;&#29801;&#25701;&#9774;&#25198;&#28787;&#8251;&#2593
    8;&#26998;&#30565;&#25120;&#8313;&#28257;&#8313;&#28265;&#26980;&#26998;&#30052;&#27745;&#28448;&#2674
    0;&#29285;&#29728;&#24936;&#8302;&#26740;&#8293;&#28265;&#25972;&#25710;&#25701;&#3360;&#29194;&#25445
    ;&#28777;&#25961;&#29806;&#25632;&#25967;&#8307;&#28526;&#8308;&#24951;&#30313;&#8293;&#29295;&#29472;
    &#29301;&#25970;&#25710;&#29285;&#29728;&#25960;&#28704;&#31080;&#26995;&#26979;&#28257;&#28717;&#2979
    3;&#25961;&#29806;&#28704;&#26994;&#26998;&#25964;&#25959;&#28448;&#8306;&#28257;&#8313;&#2573;&#29807
    ;&#25960;&#8306;&#25964;&#24935;&#8300;&#26994;&#26727;&#29556;&#9774;&#25198;&#28787;&#8251;&#26185;&
    #31008;&#30063;&#29216;&#25445;&#26981;&#25974;&#8292;&#26740;&#29545;&#25888;&#27949;&#26977;&#8300;&
    #28265;&#25888;&#29298;&#29295;&#8236;&#27760;&#24933;&#25971;&#25632;&#27749;&#29797;&#8293;&#29801;&
    #3360;&#26890;&#28013;&#25701;&#24937;&#25972;&#31084;&#24864;&#25710;&#28192;&#29807;&#26217;&#8313;&
    #26740;&#8293;&#25971;&#25710;&#29285;&#25120;&#8313;&#25970;&#30068;&#28274;&#25888;&#24941;&#27753;&
    #15406;&#17967;&#20047;&#15956;&#17980;&#20047;&#8276;&#26995;&#25978;&#12861;&#15422;&#20294;&#21582;
    &#26144;&#25441;&#15717;&#29249;&#24937;&#15980;&#12092;&#20294;&#21582;&#8254;&#2573;&#20540;&#25376;
    &#24940;&#29555;&#25405;&#13412;&#14133;&#12342;&#11572;&#13926;&#26213;&#13357;&#25913;&#11570;&#1362
    5;&#12853;&#25645;&#12596;&#14389;&#12644;&#12598;&#25904;&#15924;&#12092;&#20294;&#21582;&#3390;&#15
    370;&#21064;&#26912;&#15716;&#21064;&#8241;&#28515;&#28524;&#15730;&#12323;&#13873;&#25143;&#8290;&#1
    5919;&#2573;&#2573;&#20540;&#15422;&#20527;&#15422;&#17967;&#20047;&#15956;&#2573;&#20540;&#15422;&#2
    0527;&#3390;&#15370;&#8272;&#27747;&#29537;&#15731;&#25699;&#13620;&#13879;&#13360;&#26157;&#25910;&#
    11622;&#14644;&#12901;&#14637;&#13621;&#11570;&#13412;&#13617;&#25656;&#13873;&#12337;&#13413;&#15422
    ;&#20527;&#15422;&#17967;&#20047;&#15956;&#2573;&#20540;&#15422;&#20527;&#3390;&#15370;&#15952;&#1209
    2;&#15952;&#12092;&#20294;&#21582;&#15422;&#17967;&#20047;&#15956;&#2573;&#20540;&#15422;&#20527;&#15
    422;&#20527;&#15422;&#17967;&#20047;&#15956;&#12092;&#20294;&#21582;&#15422;&#20527;&#15422;&#16943;&
    #17487;&#15961;&#12092;&#21576;&#19533;&gt;&#2573;

    Hi,
    Which type of email account is the user using?
    If we check the vote response message from web access, can you see the unreadable characters?
    We can also try to change the encoding to check if the unreadable characters will disappear. To do this, open the vote response, click 8) or Western European (Windows).
    Please let me know the result.
    Regards,
    Steve Fan
    Forum Support
    Come back and mark the replies as answers if they help and unmark them if they provide no help.
    If you have any feedback on our support, please click
    here

  • Extended ascii problem

    I would like to concat the character with ascii 150 with a string, but encountered problems the only char i get is '?'. I tried all sorts of character set but never got it right.

    perhaps an ugly ansi to unicode character mapping
    switch(AsciiVal)
    case 128: shiftedCharAsciiVal = 8364;
    break;
    case 129: AsciiVal = 220; //need to verify??
    break;
    case 130: AsciiVal = 8218;
    break;
    case 131: AsciiVal = 402;
    break;
    case 132: AsciiVal = 8222;
    break;
    case 133: AsciiVal = 8230;
    break;
    case 134: AsciiVal = 8224;
    break;
    case 135: AsciiVal = 8225;
    break;
    case 136: AsciiVal = 710;
    break;
    case 137: AsciiVal = 8240;
    break;
    case 138: AsciiVal = 352;
    break;
    case 139: AsciiVal = 8249;
    break;
    case 140: AsciiVal = 338;
    break;
    case 141: AsciiVal = 204; //need to verify??
    break;
    case 142: AsciiVal = 381; //need to verify??
    break;
    case 143: AsciiVal = 197; //need to verify??
    break;
    case 144: AsciiVal = 201; //need to verify??
    break;
    case 145: AsciiVal = 8216;
    break;
    case 146: AsciiVal = 8217;
    break;
    case 147: AsciiVal = 8217;
    break;
    case 148: AsciiVal = 8221;
    break;
    case 149: AsciiVal = 8226;
    break;
    case 150: AsciiVal = 8211;
    break;
    case 151: AsciiVal = 8212;
    break;
    case 152: AsciiVal = 732;
    break;
    case 153: AsciiVal = 732;
    break;
    case 154: AsciiVal = 353;
    break;
    case 155: AsciiVal = 8250;
    break;
    case 156: AsciiVal = 339;
    break;
    case 157: AsciiVal = 165; //need to verify??
    break;
    case 158: AsciiVal = 382; //need to verify??
    break;
    case 159: AsciiVal = 376;
    break;
    default: System.out.println("do something");
    }

  • Convert smart quotes and other high ascii characters to HTML

    I'd like to set up Dreamweaver CS4 Mac to automatically convert smart quotes and other high ASCII characters (m-dashes, accent marks, etc.) pasted from MS Word into HTML code. Dreamweaver 8 used to do this by default, but I can't find a way to set up a similar auto-conversion in CS 4.  Is this possible?  If not, it really should be a preference option. I code a lot of HTML emails and it is very time consuming to convert every curly quote and dash.
    Thanks,
    Robert
    Digital Arts

    I too am having a related problem with Dreamweaver CS5 (running under Windows XP), having just upgraded from CS4 (which works fine for me) this week.
    In my case, I like to convert to typographic quotes etc. in my text editor, where I can use macros I've written to speed the conversion process. So my preferred method is to key in typographic letters & symbols by hand (using ALT + ASCII key codes typed in on the numeric keypad) in my text editor, and then I copy and paste my *plain* ASCII text (no formatting other than line feeds & carriage returns) into DW's DESIGN view. DW displays my high-ASCII characters just fine in DESIGN view, and writes the proper HTML code for the character into the source code (which is where I mostly work in DW).
    I've been doing it this way for years (first with GoLive, and then with DW CS4) and never encountered any problems until this week, when I upgraded to DW CS5.
    But the problem I'm having may be somewhat different than what others have complained of here.
    In my case, some high-ASCII (above 128) characters convert to HTML just fine, while others do not.
    E.g., en and em dashes in my cut-and-paste text show as such in DESIGN mode, and the right entries
        &ndash;
        &mdash;
    turn up in the source code. Same is true for the ampersand
        &amp;
    and the copyright symbol
        &copy;
    and for such foreign letters as the e with acute accent (ALT+0233)
        &eacute;
    What does NOT display or code correctly are the typographic quotes. E.g., when I paste in (or special paste; it doesn't seem to make any difference which I use for this) text with typographic double quotes (ALT+0147 for open quote mark and ALT+0148 for close quote mark), which should appear in source code as
        &ldquo;[...]&rdquo;
    DW strips out the ASCII encoding, displaying the inch marks in DESIGN mode, and putting this
        &quot;[...]&quot;
    in my source code.
    The typographic apostrophe (ALT+0146) is treated differently still. The text I copy & paste into DW should appear as
        [...]&rsquo;[...]
    in the source code, but instead I get the foot mark (both in DESIGN and CODE views):
    I've tried adjusting the various DW settings for "encoding"
        MODIFY > PAGE PROPERTIES > TITLE/ENCODING > Encoding:
    and for fonts
        EDIT > PREFERENCES > FONTS
    but switching from "Unicode (UTF-8)" to "Western European" hasn't solved the problem (probably because in my case many of the higher ASCII characters convert just fine). So I don't think it's the encoding scheme I use that's the problem.
    Whatever the problem is, it's caused me enough headaches and time lost troubleshooting that I'm planning to revert to CS4 as soon as I post this.
    Deborah

  • To display non US-ASCII filename in file download dialog - Help Needed

    Hi,
    Our application supports to upload a file with name in chinese/japanese language. When user tries to download filedownload dialog box is appearing with the filename as junk characters.
    How to solve this issue to display the filename as uploaded.
    Thanks in advance
    ~kans

    bsampieri, issue is in display of the file name in
    file download dialog.
    ~kansI understood that, but my thought was that the HTTP headers content type containing a charset of UTF-8 might help. I don't know for sure, but otherwise, I don't know how to get the browser to otherwise not assume ASCII.

  • What is the diffrence between ASCII and BIN mode

    Hello All,
    What is the diffrence between ASCII and BIN mode
    Regards,
    Lisa.

    'ASC' :
    ASCII format. The table is transferred as text. The conversion exits are
    carried out. The output format additionally depends on the parameters
    CODEPAGE, TRUNC_TRAILING_BLANKS, and TRUNC_TRAILING_BLANKS_EOL.
    'IBM' :
    ASCII format with IBM codepage conversion (DOS). This format correspond
    to the 'ASC' format when using target codepage 1103. This codepage is
    often used for data exchange by disc.
    'DAT' :
    Column-by-column transfer. With this format, the data is transferred as
    with ASC text. However, no conversion exists are carried out and the
    columns are separated by tab characters. This format creates files that
    can be uploaded again with gui_upload or ws_upload.
    'DBF' :
    The data is downloaded in dBase format. Because in this format the file
    types of the individual columns are included, import problems, for
    example, into Microsoft Excel can be avoided, especially when
    interpreting numeric values.
    'WK1' :
    The data is downloaded in Lotus 1-2-3 format.
    'BIN' :
    Binary format. The data is transferred in binary format. There is no
    formatting and no codepage conversion. The data is interpreted row by
    row and not formatted in columns. Specify the length of the data in
    parameter BIN_FILESIZE. The table should consist of a column of type X,
    because especially in Unicode systems the conversion of structured data
    into binary data leads to errors.

  • Wrong ASCII values for control characters in Variables and Stack Call in CVI2013?

    Hi,
    I think there is an error in  "Variables and Call Stack" window if you want to look for your variables in ASCII format.
    The control characters (0 -  31) are not shown correct. They are shifted 2.
    For example:
    Character in Decimal format is 10 (LF) but when you are chancing to ASCII format it is showing \012.
    The same with 13 (CR). This character is \015 in ASCII format.
    I think that was no problem in CVI2012.
    Best regards
    Gunther
    Solved!
    Go to Solution.

    I'm not using CVI2013 yes so I cannot respond regarding this specific product, but the code you are showing are the octal equivalent of the decimal value you specified: it could be that control characters (or generally speacking non-printable ones) are replaced with their octal equivalent in string view.
    Proud to use LW/CVI from 3.1 on.
    My contributions to the Developer Zone Community
    If I have helped you, why not giving me a kudos?

  • Converting ASCII text (byte array ending in null) to a String

    Hi all,
    I am trying to convert a null terminated ascii string stored in a byte array to a java String. When I pass the byte array to the String constructor it
    does not detect/interpret the null as a terminator for the ascii string. Is this something I have to manually program in? ie Check for where the null is and then
    pass that subarray of everything before the null to the String constructor?
    example of problem
    //               A   B  C   D   null   F   (note F is junk in the array, and should be ignored since it is after null)
    byte[] asciiArray = { 65, 66, 67, 68, 0,  70 };
    System.out.println(new String(asciiArray, "UTF-8"));
    //this prints ABCD"sqare icon"F

    Why do you expect the null character to terminate the string? If you come from a C or C++ background, you need to understand that java.lang.String is not just a mere character array. It's a full-fledged Java object that knows its length without having any need for null terminator. So Ascii 0 is just another character for String object. To achieve what you want to do, you have to manually loop through the byte array and stop when you encounter a null character.

  • Problem with java, ASCII and Linux

    Hi Friends,
    I has a Linux RedHat 9.0 with a jre1.5.0_04 (rpm package of Sun).
    I has a problem with ASCII , for example :
    import java.io.*;
    public class HolaMundo
    public static void main (String[] args)
    System.out.println("Hol� M�ndo");
    this programs runs ok on my windows jdk so it prints "Hol� M�ndo", but when i run the same HolaMundo.class program on my linux redhat it prints "Hol�� M��ndo"
    I think the problem is with the ASCII table that uses the linux version of jre, but i dont know how to solve this problem. I need a Spanish-European ASCII table on my application but i think it is working with a US-ASCII table.
    Then i has installed a kaffe 1.0 (rpm) java machie on this linux and this solve the problem but i has another problems of compatibility with this old version of java kaffe.
    Do you know whats happening?
    Thanks in advance.

    The problem doesn't have to do anything with Java or Linux as far as i can see. It's more likely a problem with Windows XP and IE. Be assured that normally downloading the Linux JDK in windows is not a problem.

  • Unicode and ascii conversion help needed

    I am trying to read passwords from a foxpro .dbf. The encrpytion of the password is crude, it takes the ascii value of each char entered and adds an integer value to it, then stores the complete password to the table. So to decode, just subtract same integer value from each chars retieved from .dbf. pretty simple.
    The problem is that java chars and strings are unicode, so when my java applet retrieves these ascii values from the .dbf they are treated as unicode chars, if the ascii value is over 127 I have problems.
    The question. how can i retrieve these ascii values as ascii values in java?
    Should I use an InputStream like:
    InputStream is=rs.getAsciiStream("password");
    Is there a way to convert from unicode to extended ascii?
    Some examples would be helpful, Thanks in advance.

    version 1
    import java.nio.charset.Charset;
    import java.nio.ByteBuffer;
    import java.nio.CharBuffer;
    class Test {
        static char[] asciiToChar(byte[] b) {
            Charset cs = Charset.forName("ASCII");
            ByteBuffer bbuf = ByteBuffer.wrap(b);
            CharBuffer cbuf = cs.decode(bbuf);
            return cbuf.array();
        static byte[] charToAscii(char[] c) {
            Charset cs = Charset.forName("ASCII");
            CharBuffer cbuf = CharBuffer.wrap(c);
            ByteBuffer bbuf = cs.encode(cbuf);
            return bbuf.array();
    }version 2
    import java.io.*;
    import java.nio.charset.Charset;
    class Test {
        static char[] asciiToChar(byte[] b) throws IOException {
            Charset cs = Charset.forName("ASCII");
            ByteArrayInputStream bis = new ByteArrayInputStream(b);
            InputStreamReader isr = new InputStreamReader(bis, cs);
            char[] c = new char[b.length];
            isr.read(c, 0, c.length);
            return c;
        static byte[] charToAscii(char[] c) throws IOException {
            Charset cs = Charset.forName("ASCII");
            ByteArrayOutputStream bos = new ByteArrayOutputStream();
            OutputStreamWriter osw = new OutputStreamWriter(bos, cs);
            osw.write(c, 0, c.length);
            osw.flush();
            byte[] b = bos.toByteArray();
            return b;
    }

Maybe you are looking for