Japanese (double byte) on MySQL / CF MX

trying to get CF MX english version to work with MySQL
database; I have heard it is possible to set a connection string
for JIS character sets in the CF database admin section - I am not
sure how to do this - is anyone familiar with this?
thanks

Assuming you are using the MySql J connector:
http://dev.mysql.com/doc/refman/5.0/en/cj-configuration-properties.html
HTH
Tim Carley
www.recfusion.com
[email protected]

Similar Messages

Japanese double byte characters

Hi all,
We have a ECC 6.0 system and we are introducing Japanese markets.
When we try to see table KNA1: SE16-->KNA1 and we search a word in Japanese language written in single-byte format, there is no problem, the search returns us the entries.
But when we try to serach the very same word in Japanese written in double-byte format, the search does not return any result.
How can we activate that the search matches the word entered in double-byte, with single-byte entries in the table??
Our system is Unicode.
We have seen some forum results:
Prerequisites
u2022 Modify the codepage to level 8000
u2022 Install Japanese language package for SAP
u2022 Activate English and Japanese language in Windows
u2022 Activate Multibyte support in SAP GUI: ALT-F12 -> Options -> I18N tab -> Enable Multibyte support
u2022 Change SAP font script to u2018Japaneseu2019
But the thing is that we have SAPGUI 7.20 version, and we do not find the way to activate multibyte...
Thanks!

Hi,
SAP note 1428423 describes the necessary functionality needed.
However this is not implemented in SAP ERP 6.0 standard.
The tools described in the note could be used to modify the system. But I think this would be a high effort.
Best regards,
Nils Buerckel
SAP AG

Form English Char ( Single Byte ) TO Double Byte ( Japanese Char )

Hello EveryOne !!!!
I need Help !!
I am new to Java ,.... I got assignment where i need to Check the String , if that string Contains Any Non Japanse Character ( a~z , A~Z , 0 -9 ) then this should be replaced with Double Byte ( Japanese Char )...
I am using Java 1.2 ..
Please guide me ...
thanks and regards
Maruti Chavan

hello ..
as you all asked Detail requirement here i an pasting C code where 'a' is passed as input character ..after process it is giving me Double Byte Japanese "A" .. i want this to be Done ..using this i am able to Convert APLHA-Numeric from singale byte to Doubel Byte ( Japanse ) ...
Same program i want to Java ... so pleas guide me ..
#include <stdio.h>
int main( int argc, char *argv[] )
char c[2];
char d[3];
strcpy( c, "a" ); // a is input char
d[0] = 0xa3;
d[1] = c[0] + 0x80;
printf( ":%s:\n", c ); // Orginal Single byte char
printf( ":%s:\n", d ); // Converted Double Byte ..
please ..
thax and regards
Maruti Chavan

Double Byte Characters for Japanese Kanji Language

Hello All,
How can you identify the Double Byte characters and how we can check whether they are double byte characters or not.
Can you please tell me the double byte characters from Japanese Kanji language for the characters.
This is very urgent.I will reward you with points.
Thanks,
Karan

*& Report YTEST_LOGIC
REPORT teched_unicode_solution_1               .
*** Exercise 1: Distinction between byte and character length
*** after Unicode enabling
parameter: param type c.
PERFORM test1 USING param.
* FORM test1
FORM test1 USING text TYPE c.
DATA: len1 TYPE i,
        len2 TYPE i,
        off TYPE i.
DESCRIBE FIELD text LENGTH len1 IN BYTE MODE.
DESCRIBE FIELD text LENGTH len2 IN CHARACTER MODE.
WRITE:/ LEN1, LEN2.
ENDFORM.                                                    "test1
Use the above code to find which characters are double bytes and which are not...
The double byte characters will have double the length when they are in the byte mode..
reward points for helpful answers
Edited by: Rahul Kavuri on Mar 26, 2008 6:35 PM

Regardibg double byte data type in Xi(japanese character)

hi am giving japanese character(double byte) as a input data types, will you please tell me how to give whether as a string or constant ..etc. and please give information generally about double byte data type
regards,
S.K.Karthikeyan.

Hi Stefan,
I got your point it's really helpful for me.
I have one more doubt;
Is there any equivalent type for double byte char in XI ?
regards,
S.K.Karthikeyan.

Double byte language i.e Japanese or Chinese text in non Unicode System

Hi,
I have translated text into Chinese and Japanese in a Unicode system and want to move it into a non Unicode system. Would Chinese/Japanese characters display correctly in a non Unicode system when moved from Unicode system. I am doing translation in ECC60 or SAP 4.7 Unicode system and moving to SAP 4.7 non Unicode system.
Thanks
Balakrishna

Hi Balakrishna,
in general the transport between Unicode and Non-Unicode systems is supported.
However there are restrictions, which are outlined in SAP note 638357.
In your case it is a prerequisite that the objects to be transported are language dependent (text lang. flag is set on the language key - see SAP note 480671) and the languages are properly setup in the target systems.
For double byte data there is a specific issue when transferring data from Unicode to Non-Unicode:
In a Non-Unicode system, one double-byte character needs two bytes, therefore e.g. in a 10 char field, 5 double byte chars are fitting. In a Unicode system, you can insert 10 double-byte chars in a 10 char field. Hence there is a risk of truncating characters in case of Unicode --> Non-Unicode communication.
Please also have a look at SAP notes 1322715 and 745030.
Best regards,
Nils

Using Double Byte Characters in URL For Session Variables

When I supply the value for a session variable in the URL for an IRPT page where the value contains double byte characters, Japanese in this case, the characters are corrupted by the time they are entered for the session variables. Does anyone know a solution to this problem or experience in this area? Currently using xMII 11.5 SR3.

Hi Bryan,
I would suspect that under the covers the session variable is of datatype string. For double byte characters, it would need to be wstring. There is a better explanation to be found at:
Link: [Kanji and Java Datatypes|http://www.unix.com.ua/orelly/java-ent/jenut/ch10_04.htm] or you can try google on Kanji Datatype OR Kanji Java Datatype
It could also be a problem with the operating system which I ran into about 10 years ago, but I would hope that Microsoft had moved beyond that by now.
Maybe some more technical folks could chime in to confirm or deny my explanation.
Mike
Edited by: Michael Appleby on Jul 8, 2008 5:23 PM

Crystal XI R2 exporting issues with double-byte character sets

NOTE: I have also posted this in the Business Objects General section with no resolution, so I figured I would try this forum as well.
We are using Crystal Reports XI Release 2 (version 11.5.0.313).
We have an application that can be run using multiple cultures/languages, chosen at login time. We have discovered an issue when exporting a Crystal report from our application while using a double-byte character set (Korean, Japanese).
The original text when viewed through our application in the Crystal preview window looks correct:
性能著概要
When exported to Microsoft Word, it also looks correct. However, when we export to PDF or even RPT, the characters are not being converted. The double-byte characters are rendered as boxes instead. It seems that the PDF and RPT exports are somehow not making use of the linked fonts Windows provides for double-byte character sets. This same behavior is exhibited when exporting a PDF from the Crystal report designer environment. We are using Tahoma, a TrueType font, in our report.
I did discover some new behavior that may or may not have any bearing on this issue. When a text field containing double-byte characters is just sitting on the report in the report designer, the box characters are displayed where the Korean characters should be. However, when I double click on the text field to edit the text, the Korean characters suddenly appear, replacing the boxes. And when I exit edit mode of the text field, the boxes are back. And they remain this way when exported, whether from inside the design environment or outside it.
Has anyone seen this behavior? Is SAP/Business Objects/Crystal aware of this? Is there a fix available? Any insights would be welcomed.
Thanks,
Jeff

Hi Jef
I searched on the forums and got the following information:
1) If font linking is enabled on your device, you can examine the registry by enumerating the subkeys of the registry key at HKEY_LOCAL_MACHINEu2013\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink to determine the mappings of linked fonts to base fonts. You can add links by using Regedit to create additional subkeys. Once you have located the registry key that has just been mentioned, from the Edit menu, Highlight the font face name of the font you want to link to and then from the Edit menu, click Modify. On a new line in the dialog field "Value data" of the Edit Multi-String dialog box, enter "path and file to link to," "face name of the font to link".u201D
2) "Fonts in general, especially TrueType and OpenType, are u201CUnicodeu201D.
Since you are using a 'true type' font, it may be an Unicode type already.However,if Bud's suggestion works then nothing better than that.
Also, could you please check the output from crystal designer with different version of pdf than the current one?
Meanwhile, I will look out for any additional/suitable information on this issue.

Converting Japanese two Byte Character...

Hi,
I am doing a Scenario outbound from R/3.
I am triggering the message via proxy using japanese language and sending to XI.
In XI, we are getting the Mapping Error.
Some records in the message contains single byte characters and some records having double byte characters.
For single byte characters, XI is able to generate the target structure in the Mapping. But it is not able to convert the double byte characters to the target structure.
Can any one help me to resolve this issue....
Thanks in advance...
Regards,
Vasu

Hi,
Japanese data are Shift JIS encoded ? Maybe changing the encoding (or encoding declaration) could help ?
Chris

PDF acceleration F5 BigIP WA and double byte characters

We have been trying to use the F5 appliance from BigIP to accelerate the delivery of PDF files from SharePoint over the WAN. However, we encountered problems with the double-byte files many months ago and have been trying to resolve the problem with F5. We have turned off PDF acceleration on the F5 because of the problems. The problem occurs when PDF files have Kanji characters in the file name. If the file names are English (single byte) the problem does not occur, even if the content of the PDF contains Kanji characters.
After many months of working with F5, they are now saying that the problem is with the Adobe plug-in to Internet Explorer. Specifically they say:
The issue is a result of Adobe's (not F5's) handling of the linearization request of PDF’s with the Japanese character set over 300 KB when the Web Accelerator is enabled on the BigIP (F5) appliance. We assume the issue exists for all double-byte languages, not only Japanese. If a non-double byte character set is used, this works fine. “Linearization” is a feature which allows the Adobe web plug-in to start displaying the PDF file while it is still being downloaded in the background.
The F5 case number is available to anybody from Adobe if interested.
The F5 product management and the F5 Adobe relationship manager have been made aware of this and will bring this issue up to Adobe. But this is as far as F5 is willing to pursue as a resolution. F5 consider this an Adobe issue, not a F5 issue.
Anybody know if this is truly a bug with the PDF browser plug-in? Anybody else experienced this?

Your searches should have also come up with the fact that CR XI R2 is not supported in .NET 2008. Only CR 2008 (12.x) and Crystal Reports Basic for Visual Studio 2008 (10.5) are supported in .NET 2008. I realize this is not good news given the release time line, but support or non support of cr xi r2 in .net 2008 is well documented - from [Supported Platforms|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7081b21c-911e-2b10-678e-fe062159b453
] to [KBases|http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes_boj/sdn_oss_boj_dev/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/scn_bosap/notes.do], to [Wiki|https://wiki.sdn.sap.com/wiki/display/BOBJ/WhichCrystalReportsassemblyversionsaresupportedinwhichversionsofVisualStudio+.NET].
Best I can suggest is to try SP6:
https://smpdl.sap-ag.de/~sapidp/012002523100015859952009E/crxir2win_sp6.exe
MSM:
https://smpdl.sap-ag.de/~sapidp/012002523100000634042010E/crxir2sp6_net_mm.zip
MSI:
https://smpdl.sap-ag.de/~sapidp/012002523100000633302010E/crxir2sp6_net_si.zip
Failing that, you will have to move to a supported environment...
Ludek
Follow us on Twitter http://twitter.com/SAPCRNetSup
Edited by: Ludek Uher on Jul 20, 2010 7:54 AM

Double byte characters in a String - Help needed

Hi All,
Can anyone tell me how to find the presence of a double byte ( Japanese ) character in a String. I need to check whether the String contains a Japanese character or not. Thanx in advance.
Ramya

/** returns true if the String s contains any "double-byte" characters */
public boolean containsDoubleByte(String s) {
for (int i=0; i<s.length(); i++) {
    if (isDoubleByte(s.charAt(i)) {
      return true;
return false;
/** returns true if the char c is a double-byte character */
public boolean isJapanese(char c) {
if (c >= '\u0100' && c<='\uffff') return true;
return false;
// simpler: return c>'\u00ff';
/** returns true if the String s contains any Japanese characters */
public boolean containsJapanese(String s) {
for (int i=0; i<s.length(); i++) {
    if (isJapanese(s.charAt(i)) {
      return true;
return false;
/** returns true if the char c is a Japanese character. */
public boolean isJapanese(char c) {
// katakana:
if (c >= '\u30a0' && c<='\u30ff') return true;
// hiragana
if (c >= '\u3040' && c<='\u309f') return true;
// CJK Unified Ideographs
if (c >= '\u4e00' && c<='\u9fff') return true;
// CJK symbols & punctuation
if (c >= '\u3000' && c<='\u303f') return true;
// KangXi (kanji)
if (c >= '\u2f00' && c<='\u2fdf') return true;
// KanBun
if (c >= '\u3190' && c <='\u319f') return true;
// CJK Unified Ideographs Extension A
if (c >= '\u3400' && c <='\u4db5') return true;
// CJK Compatibility Forms
if (c >= '\ufe30' && c <='\ufe4f') return true;
// CJK Compatibility
if (c >= '\u3300' && c <='\u33ff') return true;
// CJK Radicals Supplement
if (c >= '\u2e80' && c <='\u2eff') return true;
// other character..
return false;
/* NB CJK Unified Ideographs Extension B not supported with 16-bit unicode. Source: http://www.alanwood.net/unicode */
}

SDK double bytes

Hi All
I'd like to ask you something. I updated a business partners data by using SDK, but Japanese characters which is double byte are broken and can't be seen on my PC.
What kind of　setting do I need to use double bytes characters like Japanese?
Thanks,
Satoru

> Does your answer suggest that data-loading is enabled
> only if the source data is in Unicode?
Yes and no. I do not know the topic well enough to give you a precise answer. Your post was about "double-byte characters". So my question was whether you meant UTF-16 character encoding. I don't know whether there are other double-byte character encoding schemes in the asian sphere (assuming you work there).
At any rate, it is obvious the encoding of the source data and the one the DTW/API expects ought to match. Let's hope none of them awaits LATIN-1 in one of its more obscure parts.
Have you tried importing data with XML? You can specify the encoding explicitly with that.
No idea about the JCO, nohow.
I'm afraid I can't tell you much more. I tried to narrow down your problem, and do hope there'll be someone around these parts who can solve it.

Double byte font problem

I'm trying to track down a double byte font that's worked its way into a form. When I try and open the form in Reader I get an error message saying to download the Japanese font pack.
In Acrobat the font shows up as KozGoPr6N-Medium Type 1 CID. I've hunted through the xml source with no luck and also taken a look at any special characters used. Being an XFA PDF I can't use my usual tools like Pitstop to track it down.
I've seen this happen once before when trying to use some upper unicode characters but we aren't using any in this form from what I can see. Webdings and Wingdings 2 are being used for a few characters but I tried them on their own and they don't seem to be the problem. I've also tried unembedding fonts but no luck.
Any ideas?

Figured it out...had to print the form to a normal pdf so I could run a preflight on it.
Form some reason Designer(?) encodes some upper unicode characters as Japanese? Or something. I ran into this a while back when trying to use a couple of up/down arrow characters in a form.
Turns out the offending character was an N or M space. I replaced it with a Tab character and it's now fine.

Double-byte parser

Hey,
I need to load in 400 character string of data into text using the FM SAVE_TEXT in chucks of 60 characters. If the user logs in Japanese, they could be loading in a mix of single byte and double characters. I need to be able to check if I break my string of data at the 60th character, will I be corrupting a double character.
Does anyone know how to perform this test in ABAP?
Thanks for the feedback! Bill

Hi Bill,
If you are on version 6.2+ you could try using the NUMOFCHAR( ) command.
I guess you could do something like:
* First determine the number of actual
* characters in 60th and 61st bytes.
w_num_of_chars = NUMOFCHAR( w_text+60(2) ).
* If there is only 1, then split on 59.
IF w_num_of_chars = 1.
* Otherwise, we have two characters so we can split at 60.
ELSE.
ENDIF.
I must admit I'm a complete novice when it comes to double byte languages and their handling, so that may just be complete gobbledegook.
Hope that helps.
Cheers,
Brad

Java apps refuse to accept double byte characters

Java apps refuse to accept double byte characters
In my user account, all java apps now refuse to accept double-byte characters (Chinese, Japanese, etc). I have another clean account, and that one works fine.
Things I tried doing:
* repair permissions
* search/delete .plist files with java as a part of the name
* search/detete .plist file that has to do with TCIM, input method
Nothing worked…
MacBook Pro 15" early 2011, Lion 10.7.3.
Can anyone help?

Well, there is no guarantee that you can detect double-byte characters. However if you believe strongly that a file DOES contain double-byte characters, written in big-endian or little-endian format, then you can look at the first two bytes of the file:
FFFE big-endian.
FEFF little-endian.
Code tip: Open the file as a FileInputStream, then wrap it in a PushbackInputStream. This allows you to read the first two bytes (so you can examine them), and push them back. If you find the expected encoding, then you can wrap the PushbackInputStream in an InputStreamReader, specifying the appropriate (big-endian or little-endian) decoding.
Setup tip: I believe the decoding will only work if you have internationalization set up do this by copying i18n.jar from the lib directory (of the JRE) to the extension directory (of the JRE).

Japanese (double byte) on MySQL / CF MX

Similar Messages

Maybe you are looking for