Issue with Japanese character encoding

Hi
I have a Web Service client (in AXIS1.4) which calls a web service with some data, this data has Japanese characters,
When i call Web Service in AXIS 2.0 the Web Service gets proper Japanese characters, but when i call Web Service Developed in JCAPS, this web service does not get proper Japanese characters, but gets ????????
Does anyone have dealt with such situation,
Any ideas

Is the encoding you are using in AXIS 1.4 UTF-8 ?. I think JCAPS supports UTF-8.

Similar Messages

Awt alignment issue with japanese character

I am using japesenes OS(Win XP ) and running awt application (JDK1.6).
For Choice box (dropdown box) ,if the font is less than 15 and if there
is a mixture of japanese and number ,the numbers and the Japanese characters
are not vertically aligned.
I am using java.awt.Choice component to display all the months
Choice month =new Choice();
month.insert ("1 \u6708", 0);
month.insert ("2 \u6708", 1);
month.insert ("3 \u6708", 2); .. so on
While running the applet , in display window
The numbers and the Japanese characters are not vertically aligned.
When a month is selected, it is slightly truncated at the top.
My default font is [family=SansSerif,name=sansserif,style=plain,size=12]
when i change the font to 15,the characters are properly aligned.
Did anyone faced this before? if so can you please clarify why this behaviour when font size
is less than 15 or how to resolve this issue without changing the font size .
thanks in advance,
ruhul

Hi,
I have also faced the above mentioned issue.The workaround of using Full Width unicode though resolves the alignment of Japanese with english/numbers/special characters.
There is other issues with this to mention a few:
(a) The text is still top aligned.
(b) A leading and trailing space is added to the value in the choice component when full width unicode value is used instead of english/number/special characters.
It would nice if the mentioned issues could be resolved or if a work around could be suggested.

Issue with Weblogic character encoding

I have struts2 based web application which works fine with tomcat server but when i deployed the application to weblogic 10.3 server it is creating following issue-
1) when i enter data in application forms with £ (pound sign), £ gets converted to ?
My Jsp Page is using ISO-8859-1 charset. please look at the snapshot from jsp page.
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
I have debug the application and came to know that this data (£ sign) is converted to ? before being assigned to corresponding property in action class.
this seems to be issue with encoding of characters with weblogic server.
I have also tried to fix this issue by defining the charset in weblogic.xml file in my application as follows but it does'nt solve this issue. please see the snapshot from weblogic.xml file.
<wls:weblogic-version>10.3</wls:weblogic-version>
<wls:context-root>APMApplication</wls:context-root>
<wls:charset-params>
<wls:input-charset>
<wls:resource-path>/*</wls:resource-path>
<wls:java-charset-name>ISO-8859-1</wls:java-charset-name>
</wls:input-charset>
</wls:charset-params>
Please suggest some solution to fix this issue. thanking you in advance.

"I can not change the charset in jsp pages i.e i have to use ISO-8859-1 in my jsp page which is a must have requirment."
You are right here as the pound sign is not included in UTF-8 (did not know that sorry).
Could you try setting the page directive of the JSP to
<%@ page contentType="text/html;charset=ISO-8859-1" language="java" %>or when you are working with jspx
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns="http://www.w3.org/1999/xhtml" version="2.0">
<jsp:directive.page contentType="text/html;charset=ISO-8859-1"/>
</jsp:root>

Issues with Japanese encoding using Mail

Since recently (I would say since I updated to 10.6), I have an issue with Japanese-encoded (ISO 2022-JP) mails on my English MacOS.
I have no problem to read, edit and write answers to any mails.
However with some ISO JP-2022-JP encoded messages (sent with Thunderbird 2.0.0.23 (Windows/20090812) btw) I have the following misbehaviour:
- if I send the message and let the encoding to "automatic", Mail sends the mail in UTF-8, which I do not want since most of Japanese computer do not understand UTF-8 by default (and the receiver gets panicked: "I can not read your mail T_T !")
- if I set the encoding to "ISO JP-2022-JP", I can not send nor save the message (see [1] at the end of the post). One should note that the error message when saving is really misleading (and yes my hard-drive has a lot of space left) and it should be fixed by Apple.
- if I dig a bit deeper, I can in effect find some characters in the original message which prevent Mail to send my mail. It however does not make any sense since:
- those char were in the original message properly encoded in ISO JP-2022-JP
- those char are always very common ones
The only solution I have found so far is to delete the original message in my mail, which is very frustrating...
A sample of such mail can be found at (I removed personal info. and the mail is about a drinking party):
- http://files.me.com/trouve.antoine/73w3w9
Help would be very appreciated.
Thank you very much.
Antoine
[1] I get the following error messages:
-> try to save:
*This message can’t be saved to the Drafts mailbox.*
The message contains one or more attachments that
are too large to be saved in the Drafts mailbox. Try
deleting some attachments.
->try to send
*Invalid Text Encoding*
Some characters in your message could not be
converted to the “Japanese (ISO 2022-JP)” text
encoding. Choose a different encoding from the
“Text Encoding” menu.

You can find out about the different versions here, for example:
http://en.wikipedia.org/wiki/ISO/IEC_2022
Thank you. I feel a bit stupid for not having looked in Wikipedia at first...
I sometime wonder how could such basic problem like charset not being solved after more than 40 years of computer science...
Here is a note that addresses that problem, but I don't think it works with 10.6. Might be worth a > try:
http://discussions.apple.com/thread.jspa?threadID=121808&tstart=60
Thank for the link.
It seems to still work: new japanese mails are now sent in "ISO 2022-JP-2".
However, for messages with the header explicitly specifying "ISO 2022-JP" (which should be "ISO 2022-JP-2" on my mac) it has no influence.
The only ways I see to solve this issue would be:
i) to force "ISO 2022-JP-2" for all mails (a bit too extreme)
ii) to force the use of "ISO 2022-JP-2" instead of "ISO 2022-JP", but I do not think such precise configuration is possible
This mess appears to be due to Thunderbird which seems to mix "ISO 2022-JP-2" and "ISO 2022-JP", but I do not have any working Thunderbird to test now...

Having major issues with Adobe Media Encoder (AME) - exporting with weird image flickering/colour anomalies, crashing regularly, freezing during encode...!

Hi Guys
I am having some real issues with Adobe Media Encoder (AME) at the moment. It appears that I am unable to encode an h.264 for Vimeo from a Premiere Pro Project file at the moment without at least some weird image issues that are not supposed to be there. These include weird flickering, colour changes, artefacts etc. This is if I am lucky...often I am unable to get the process to complete as the application either crashes and tells me there has been a problem or it simply freezes and I have to force quit the application and often restart my machine.
The problem seems to not to just be with h.264 for the web encodes but also with BluRay h.264 as well. As yet I haven't seen if there is a problem with MPEG-2 for DVD so I will check this out too!
Does anyone else see this happening or does anyone know what might be the problem?
I thought the Premiere Pro project might have been corrupt so tried a different project but the same issues were happening here too.
Any help would be really gratefully received.
Cheers
EDIT - I have just found this online which is exactly the problem I am having! Thanks a bloody bunch Apple! 10.9.3 causing headaches for Mac Pro users | MacIssues
Message was edited by: Alex Cameron

Agreed, I now have a project to GET OUT, and AME crashes consistently 1/3 into the render. It appears to halt all processing after (real time) 00:02:30
Am seriously considering uninstalling CC as I am beginning to find other issues in some apps, and going back to CS6/MC just so I can get work out. Durn it Adobe this is AWFUL!!
Alright, let's try to be constructive instead of throwing rocks... but the frustration level is high, and I have material on deadline. Let's get with this, guys...
What OS Win7, 64-bit
What version of AME/PPro (Please be specific by getting the full version number in the About Adobe Media Encoder screen) 8.2.0.54 Ppro: 8.2.0 (65)
When is it crashing (Again, the more detail here about where it was in the encoding process the better) roughly 1/3 into the sequence, always on exactly the same frame - tried replacing the clip with something different to see if it was a timeline error, and NO EFFECT.
What is your source (PPro project or media file (what kind?)) PPro
If the source if a PPro project, does it work when exporting directly from PPro? NO
What format are you exporting to? H.264, QT, WM, tried everything my client can play.
Do other formats work? MPEG2, QuickTime, etc? NO
Have you tried with GPU rendering on? How about turning it off by switching to Software-only mode? Mine doesn't have any choice, it's software-only.
Have you tried disabling Native Sequence Loading? (AME Preferences: General > Enable Native Sequence Loading) No effect
Other things I tried: uninstalling/reinstalling AME, setting cache to a fast local disk.

Problem while exporting to PDF with japanese character in Crystal Report X1

Hi,
I am using Crystal report X1 with classic ASP on a Windows 2003 Enterprise Server, SP 2. In my application, I have to export the report into PDF, CSV, DOC formats. I am have Japanese strings in the report. While exporting to PDF, empty boxes has displayed in the place of Japanese string and in CSV file, question mark has been displayed instead of Japanese string. But the Doc file is exported correctly. I have not installed any language support software either in server or in client machine. I have used MS Gothic and Arial Unicode MS fonts for the text-objects which has Japanese strings.
Please give me a solution so that I will get PDF file with Japanese strings instead of empty box or question mark.
Do I need to install any language support pack software?
Thanks in advance.
Regards,
Manju

Hi Don,
Thank You for your reply. I have resolved the issue of exporting to pdf from crystal report X1 having Japanese data after installing the language pack.
But when I am exporting to CSV or TXT, i am getting ??? instead of Japanese characters. I have tried "export" through crystal report designer and got ??? instead of Japanese.
The Crystal report version I am using is Crystal report X1 11.0.0.1282
Crystal Report Desinger is installed in Windows Xp machine
Font set for Text object is Arial Unicode MS, MS PMincho, MS PGothic
Does the Crystal report X1 11.0.0.1282 has the UTF-8 support for CVS / txt
Please provide me a solution
Thanks in advance,
Regards,
Manju

Issue with Japanese characters in files/filenames in terminal.

I recently downloaded a zip file with Japanese characters in the archive and in the files within the archive. The name of the archive is "【批量下载】パノプティコン労働歌第一等.zip"
The characters are properly displayed in firefox, chrome, and other applications, but in my terminal some of the characters appear corrupted. Screenshot: https://i.imgur.com/4R22m0D.png
Additionally, this leads to corruption of the files in the archive. When I try to extract the files, this is what happens:
% unzip 【批量下载】パノプティコン労働歌第一等.zip
Archive: 【批量下载】パノプティコン労働歌第一等.zip
extracting: +ii/flac/Let's -+-ʦ1,000,000-.flac bad CRC 5f603d51 (should be debde980)
extracting: +ii/flac/+ѦѾP++ -instrumental-.flac bad CRC 78b93a2d (should be 3501d555)
extracting: +ii/flac/----.flac bad CRC ddeb1d3e (should be c05ae84f)
extracting: +ii/flac/+ѦѾP++.flac bad CRC 0ccf2725 (should be be2b58f1)
extracting: +ii/flac/Let's -+-ʦ1,000,000--instrumental-.flac bad CRC 67a39f8e (should be ece37917)
extracting: +ii/flac/.flac bad CRC f90f3aa0 (should be 41756c2c)
extracting: +ii/flac/ -instrumental-.flac bad CRC 3be03344 (should be 0b7a9cea)
extracting: +ii/flac/---- -instrumental-.flac bad CRC 569b6194 (should be adb5d5fe)
I'm not sure what could be the cause of this. I'm using uxterm with terminus as my main font and IPA gothic (a Japanese font) as my secondary font. I have a Japanese locale set up and have tried setting LANG=ja_JP.utf8 before, but the results never change.
Also, this issue isn't just with this file. This happens with nearly all archives that have Japanese characters associated with it.
Has anyone encountered this issue before or knows what might be wrong?
Last edited by Sanbanyo (2015-05-21 03:12:56)

Maybe 7zip or another tool has workarounds for broken file names, you could try that.
Or you could try to go over the files in the zip archive one-by-one and write it to files out-1, out-2, ..., out-$n without concerning yourself with the file names. You could get file endings back via the mimetype.
This script might work:
#include <stdio.h>
#include <zip.h>
static const char *template = "./out-%04d.bin";
int main(int argc, char**argv)
int err = 0;
zip_t *arc = zip_open((const char*)argv[1], ZIP_RDONLY, &err);
if(arc == NULL)
printf("Failed to open ZIP, error %d\n", err);
return -1;
zip_int64_t n = zip_get_num_entries(arc, 0);
printf("%s: # of packed files: %d\n", argv[1], n);
for(int i = 0; i < n; i++)
zip_stat_t stat;
zip_stat_index(arc, i, ZIP_FL_UNCHANGED, &stat);
char buf[stat.size];
char oname[sizeof(template)];
zip_file_t *f = zip_fopen_index(arc, (zip_int64_t)i, ZIP_FL_UNCHANGED);
zip_fread(f, (void*)&buf[0], stat.size);
snprintf(&oname[0], sizeof(template), template, i);
FILE *of = fopen(oname, "wb");
fwrite(&buf[0], stat.size, 1, of);
printf("%s: %s => %lu bytes\n", argv[1], oname, stat.size);
zip_fclose(f);
fclose(of);
zip_close(arc);
return 0;
Compile with
gcc -std=gnu99 -O3 -o unzip unzip.c -lzip
and run as
./unzip $funnyzipfile
You should get template-named, numbered output files in the current directory.
Last edited by 2ion (2015-05-21 23:09:29)

Some japanese character encoded to "?". Please help me..

My system is below listed.
J2SE 1.4.1
MySql Ver 11.18 Distrib 3.23.52,
Resin 2.1.4
Java application load html document encoded 'SHIFT_JIS' using HtmlURLConnection.
And read the document in 'SHIFT_JIS'.
Almost it appears properly but some of characters printed in '?'.
hm....
I will show my source code.
private String readDocument(URL url) {
String METHOD_NM = ".readDocument()";
try {
HttpURLConnection URLCon = (HttpURLConnection)url.openConnection();
BufferedReader in = new BufferedReader( new InputStreamReader(url.openStream(), "SJIS"));
String inputLine;
On my web server, input the character(printed '?') on textbox in IE6(japanese language pack). and submit. then the character translated the code(ex> #4575; )
The code inserted DB. select from DB the tuple.
and display the IE6. it's ok.
but loaded from japanese html. It's inserted to DB '?'.
and displayed '?' on IE6.
I want to translate the character to code(ex> #5455;).
OK?
Please reply...
p.s I'm sorry my poor english..

Thank you for reply.
but I've already tried that.
I have tried all japanese encoding of "Supported Encodings" from java.
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
I want to convert that.
ex)
?fe? => & # 4532; fe & # 3456; => original charcater is removed blank
This is convert '?' to code number.
In this case '?' is Japanese character.
Please let me know the way..

Problem with Japanese character Codes

I have been working for a company which got a product to support the sms activities. We are developing a new feature which supports Japanese language as of now along with english. We developed a new character set called PDC which is a combination of the following Japanese character sets JIS + SHIFT- JIS+ KATAKANA + ASCII.
I am using Java API Charsets.jar to convert the bytes using the respective character sets to a STRING and presenting the converted STRING on a JSP.
The Problem is I am able to see the Jap Chars which belong to JIS + ASCII but not for KATAKANA and SHIFT-JIS.
I am using the below page tag in JSP.
<%@ page contentType="text/html; charset = JIS " %>
I couldn't find any other tag specifically which supports all the character sets. Could some one please help me?
Pradeep.

Okay... you developed a new character set... that's great. How's the browser supposed to know anything abou it?
Maybe just use UTF-8 which should support all of that and other languages as well and stop boxing yourself into a fixed charset.

Oracle Report Server Issue with Japanese Characters

We are trying to setup a Oracle Report Server to print the Japanese characters in the PDF format.
We have separate Oracle Report servers for printing English, Chinese and Vietnamese characters in PDF formats using Oracle Reports in the production which are running properly with Unix AIX version 5.3. Now we have a requirement to print the Japanese characters. Hence we tried to setup the new server for the same and the configurations are done as same as Chinese/Vietnamese report servers. But we are not able to print the Japanese characters.
I am providing the details which we followed to configure this new server.
1.     We have modified the reports.sh to map the proper NLS_LANG (JAPANESE_AMERICA.UTF8) and other Admin folder settings.
2.     We have configured the new report server via OPMN admin.
3.     We have copied the arialuni.ttf to Printers folder and we have converted this same .ttf file in AFM format. This AFM file has been copied to $ORACLE_HOME/guicommon/gk/JP_Admin/AFM folder.
4.     We have modified the uifont.ali (JP_admin folder) file for font subsetting.
5.     We have put an entry in JP_admin/PPD/datap462.ppd as *Font ArialUnicodeMS: Standard "(Version 1.01)" Standard ROM
6.     We have modified the Tk2Motif.rgb (JP_admin folder) file for character set mapping (Tk2Motif*fontMapCs: iso8859-1=UTF8) as we have enabled this one for other report servers as well.
Environment Details:-
Unix AIX version : 5300-07-05-0831
Oracle Version : 10.1.0.4.2
NLS_LANG : JAPANESE_AMERICA.UTF8
Font Mapping : Font Sub Setting in uifont.ali
Font Used for Printing : arialuni.ttf (Font Name : Arial Unicode MS)
The error thrown in the rwEng trace (rwEng-0.trc) file is as below
[2011/9/7 8:11:4:488] Error 50103 (C Engine): 20:11:04 ERR REP-3000: Internal error starting Oracle Toolkit.
The error thrown when trying to execute the reports is…
REP-0177: Error while running in remote server
Engine rwEng-0 crashed, job Id: 67
Our investigations and findings…
1.     We disabled the entry Tk2Motif*fontMapCs: iso8859-1=UTF8 in Tk2Motif.rgb then started the server. We found that no error is thrown in the rwEng trace file and we are able to print the report also in PDF format… (Please see the attached japarial.pdf for your verification) but we are able to see only junk characters. We verified the document settings in the PDF file for ensuring the font sub set. We are able to see the font sub setting is used.
2.     If we enable the above entry then the rwEng trace throwing the above error (oracle toolkit error) and reports engine is crashed.
It will be a great help from you if you can assist us to resolve this issue…

Maybe 7zip or another tool has workarounds for broken file names, you could try that.
Or you could try to go over the files in the zip archive one-by-one and write it to files out-1, out-2, ..., out-$n without concerning yourself with the file names. You could get file endings back via the mimetype.
This script might work:
#include <stdio.h>
#include <zip.h>
static const char *template = "./out-%04d.bin";
int main(int argc, char**argv)
int err = 0;
zip_t *arc = zip_open((const char*)argv[1], ZIP_RDONLY, &err);
if(arc == NULL)
printf("Failed to open ZIP, error %d\n", err);
return -1;
zip_int64_t n = zip_get_num_entries(arc, 0);
printf("%s: # of packed files: %d\n", argv[1], n);
for(int i = 0; i < n; i++)
zip_stat_t stat;
zip_stat_index(arc, i, ZIP_FL_UNCHANGED, &stat);
char buf[stat.size];
char oname[sizeof(template)];
zip_file_t *f = zip_fopen_index(arc, (zip_int64_t)i, ZIP_FL_UNCHANGED);
zip_fread(f, (void*)&buf[0], stat.size);
snprintf(&oname[0], sizeof(template), template, i);
FILE *of = fopen(oname, "wb");
fwrite(&buf[0], stat.size, 1, of);
printf("%s: %s => %lu bytes\n", argv[1], oname, stat.size);
zip_fclose(f);
fclose(of);
zip_close(arc);
return 0;
Compile with
gcc -std=gnu99 -O3 -o unzip unzip.c -lzip
and run as
./unzip $funnyzipfile
You should get template-named, numbered output files in the current directory.
Last edited by 2ion (2015-05-21 23:09:29)

External Table - Issues With Special Character.

I have an external table that reads from a fixed length file. The file is expected to contain special characters. In my case the word containing special character is "Göteborg". Because "ö" is a special character, looks like Oracle is considering it as 2 bytes. That causes the trouble. The subsequent fields in the files get shifted by 1 byte thereby messing up the data. Has anyone faced the issue before. So far we have tried the following solution:
Changed the value of NLS_LANG to AMERICAN_AMERICA.WE8ISO8859P1
Tried Setting the Database Character set to UTF-8
Tried changing the NLS_LENGTH_SYMMANTIC to CHAR instead of BYTE using ALTER SYSTEM
Tried changing the External table characterset to: AL32UTF8
Tried changing the External table characterset to: UTF-8
Nothing works. Other details include:
• File is UTF-8 encoded
• Operating System : RHEL
• Database: Oracle 11gR2
Any thing else that I might be missing? Any help will be appreciated. Thanks in advance!
Ganesh

CREATE TABLE "APP_XXX_XX_XXXX"(
"KEY_NO" NUMBER,
"XXX_XXX_XXXXX" VARCHAR2(1 CHAR),
"XXX_XXX_XXXXX" NUMBER(9,0),
"XXX_XXX_XXXXX" NUMBER(4,0),
"XXX_XXX_XXXXX" NUMBER(2,0),
"XXX_XXX_XXXXX" NUMBER(3,0))
ORGANIZATION EXTERNAL
( TYPE ORACLE_LOADER
DEFAULT DIRECTORY "DIR"
ACCESS PARAMETERS
( RECORDS DELIMITED BY NEWLINE
CHARACTERSET 'UTF8'
LOGFILE APP_XXX_XX_XXXX_%A_%P.LOG'
BADFILE 'APP_XXX_XX_XXXX_%A_%P.BAD'
DISCARDFILE 'APP_XXX_XX_XXXX_%A_%P.DSC'
FIELDS(
KEY_NO POSITION(1:9) INTEGER EXTERNAL,
XXX_XXX_XXXXX POSITION(10:10) CHAR,
XXX_XXX_XXXXX POSITION(11:19) INTEGER EXTERNAL,
XXX_XXX_XXXXX POSITION(11:14) INTEGER EXTERNAL,
XXX_XXX_XXXXX POSITION(15:16) INTEGER EXTERNAL,
XXX_XXX_XXXXX POSITION(17:19) INTEGER EXTERNAL)
LOCATION
( 'FILE1.TXT')
REJECT LIMIT UNLIMITED
PARALLEL 4;
The data forms part of a major driver table, which I may not be able to provide as per the NDA with my company.
The Script I have shared is standard template for creating external table as part of our applications.
We majorly cater for EU regions with this project.(European Characterset needed to be supported)
Thanks
Ganesh
Edited by: RGRAM on Feb 11, 2011 12:44 PM

Issue with Dutch character

Hello All,
Currently we are facing the problem with few Dutch characters.
We are using the EP 6.0, ECC 5.0 and MSSQL Server 2000 and Dutch language is installed in the ECC.
For some Web Dynpro applications I have used ECC as the backend and for some other applications, I have used MSSQL Server 2000 as a backend.
When I enter the text values (with Dutch characters) it takes the # symbol for the ECC based application. But this problem is not happening for the all the Dutch characters only for characters which is above 255 ASCII code.
ECC recognize the characters like ú, û, ü which falls below 255. At the same time the ECC doesnu2019t recognize the following characters like ś, ŝ, ş etc which is greater than 255.
Example in the ECC based applications:
I have to insert the Customer name: Hariúś in the ECC using a Web Dynpro application through the portal. But it takes the name like Hariú#.
The same character recognizes problem in the SQL side is happening. It is working fine for the characters like ú, û, ü. But when you take the characters like ś, ŝ, ş it takes the character s.
Example in the SQL based applications:
I have to insert the Customer name: Hariúś in the SQL tables using a Web Dynrpo application through the portal. But it takes the name like Hariús.
We tried in ECC 6.0 version but in vain. Kindly help on the same
Regards,
Anand

Hi
I had an issue on EP 7.0 / ERP 6.0 (non-unicode) with german special characters lately. I understand your issue does not match 100% to mine. But you might want to give the solution a try.
After i set -Dfile.encoding=ISO8859-1 on the portal the characters displayed correctly. You will need the configtool to do that and you have to set in the server parameters (where you set your java heap and garbage collecting options).
You can look at this SAP note for details: [73606 - Supported Languages and Code Pages|https://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?numm=73606]
Best regards, Michael

Collation issue with Japanese characters in Oracle8i

Hi,
I have japanese data in a varchar2 column in an Oracle8i instance which contains both single byte and multibyte Japanese characters. The encoding type of the instance is UTF-8.
I want to sort them in such a way that equivalent single byte and multibyte Japanese characters are treated as same. Also while selecting, if I specify the single byte characters in the where condition it should select both single and double byte characters and vice-versa.
The functionality I'm looking for is similar to the one which can be achieved by using Collator class in Java with FULL_DECOMPOSITION as decmposition mode.
Could anyone please let me know how can I do it ?
Thanks in advance.
Best Regards,
Sourav

Maybe 7zip or another tool has workarounds for broken file names, you could try that.
Or you could try to go over the files in the zip archive one-by-one and write it to files out-1, out-2, ..., out-$n without concerning yourself with the file names. You could get file endings back via the mimetype.
This script might work:
#include <stdio.h>
#include <zip.h>
static const char *template = "./out-%04d.bin";
int main(int argc, char**argv)
int err = 0;
zip_t *arc = zip_open((const char*)argv[1], ZIP_RDONLY, &err);
if(arc == NULL)
printf("Failed to open ZIP, error %d\n", err);
return -1;
zip_int64_t n = zip_get_num_entries(arc, 0);
printf("%s: # of packed files: %d\n", argv[1], n);
for(int i = 0; i < n; i++)
zip_stat_t stat;
zip_stat_index(arc, i, ZIP_FL_UNCHANGED, &stat);
char buf[stat.size];
char oname[sizeof(template)];
zip_file_t *f = zip_fopen_index(arc, (zip_int64_t)i, ZIP_FL_UNCHANGED);
zip_fread(f, (void*)&buf[0], stat.size);
snprintf(&oname[0], sizeof(template), template, i);
FILE *of = fopen(oname, "wb");
fwrite(&buf[0], stat.size, 1, of);
printf("%s: %s => %lu bytes\n", argv[1], oname, stat.size);
zip_fclose(f);
fclose(of);
zip_close(arc);
return 0;
Compile with
gcc -std=gnu99 -O3 -o unzip unzip.c -lzip
and run as
./unzip $funnyzipfile
You should get template-named, numbered output files in the current directory.
Last edited by 2ion (2015-05-21 23:09:29)

Dynamic table issue with special character

Hi All,
While creating a dynamic internal table if the fieldname in the fieldcatalog contains any special character like dot(.) , ot is showing the message without creating the dynamic internal table.
* Create a dynamic internal table with this structure
CALL METHOD cl_alv_table_create=>create_dynamic_table
EXPORTING
i_style_table = 'X'
it_fieldcatalog = gt_dyn_fcat
IMPORTING
ep_table = gt_dyn_table
EXCEPTIONS
generate_subpool_dir_full = 1
OTHERS = 2
gt_dyn_fcat contains fieldname with dot.
So the table gt_dyn_table is not creating.
I searched in SCN andd found another method
CALL METHOD
cl_abap_structdescr=>create
But the same issue is aslo here in this method.
Please suggest me any new method in sap to solve the issue.
Best Regards,
Munu

Hi,
Every programing language has its syntax rules.
If you want to use this language you have to follow the rules.
All the peoples involve with SAP ABAP must follow the rules.
and here it is: from http://help.sap.com/abapdocu_740/en/abennaming_conventions.htm
How abut using underscores (_)
Regards.

Issue with Turkish character in PDF

Hi all,
For a particular requirement we had to print a layout in smartform and send them as a PDf attachement. The steps are explained below.
1) Create a layout with the Smartform(No spool generated but the OTF is being obtained for PDF)
2) The obtained OTF is converted into PDF and sent as a mail.
While one of this above 2 process the turkish character get changed/corrupted depending upon the users default printer. Could anynone let me know how can I prevent this by manual(Through code while caling SF) providing a printer to the smartform.
Regards
Simin.

Hi Gungor,
The User parameter is not empty.
1) If I put a printer which does not support Turkish in the user parameters. The PDF created by the program has junk characters
2) If I put a printer which supports Turkish in the user parameters. The PDF created by the program has turkish characters.
Though I forcibly pass the printer while calling smartforms in the program, Why is the program still depending on the users parameters.
My Need is to remove this dependecy of the program over the default printer in the User Master.
Regards,
Simin.

Issue with Japanese character encoding

Similar Messages

Maybe you are looking for