Skip to Content
avatar image
Former Member

Convert special characters

Hi all!!

I've a problem with special characters; I need to change some strings that contains special characters (accents, ñ,...) to other strings without them.

Año to Ano

Habitación to Habitacion

I can not use 'TRANSLATE' sentence because I don't know exactly which are these characters, so I need something more generic.

Anybody knows some FM to solve that issue, please?

Thanks anyway!!


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Best Answer
    avatar image
    Former Member
    Mar 06, 2006 at 02:04 PM

    Hi Gemma,

    the function module SCP_REPLACE_STRANGE_CHARS will do the job. I just tested it and found that it changes

    Año to Ano

    Habitación to Habitacion

    as required. When you test the function module in SE37, make sure that you put a check in the checkbox Uppercase/Lowercase.

    Kind regards,

    Michael Kraemer

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Mar 06, 2006 at 01:47 PM

    Checks whether TRANSLATE .. TO UPPER/LOWER CASE statements are working in the correct language environment.

    TRANSLATE .. TO UPPER/LOWER CASE statements are displayed that work on table fields without a preceding SET LOCALE LANGUAGE statement.

    There are two cases:

    1. The table containing the field to which the TRANSLATE statement applies contains a language field.

    In this case, the data processed comes from a table containing a language field (regardless of whether the field occurs in the key). You can probably set the correct language environment before the TRANSLATE statement is executed.

    2. The table does not contain a language field.

    If the current table does not contain a language field, the error is harder to correct. You can either determine the language using other means, or add a language field to the table and fill it with the correct values.


    The TRANSLATE statement depends on the current language environment, which itself depends on the language in which the data was entered.

    Incorrect settings for the language environment can cause loss of data if, for example, you use the TRANSLATE statement to generate matchcodes.

    Examples of problems in the TRANSLATE statement:

    What is the UPPER CASE of 'ä'?

    In German - 'Ä'.

    In French - 'A'.

    In English, however, it would depend on the implementation, since 'ä' is not recognized at all.

    In Japanese, serious errors occur. The byte with the bit combination that looks like 'ä' is in fact the first half of the double-byte representation of many different kanji.

    If your try to process German data in a Russian environment, the result is variable: 'ä' and 'Ä' are processed correctly. However, 'ö' becomes '¦', and 'Ö' is converted to '¶'. The capital 'Ö' has a bit combination that stands for a small 'sch' in the Russian character set.

    When does the problem occur?

    1. Problems of this nature can occur if the wrong language environment has been set up using SET LOCALE. However, this is very rarely the case, and the system does not check for it.

    2. The problem can also occur if you do not use SET LOCALE at all and then process data that has a language other than the logon language, and this is a far more common cause. Since language key fields are not automatically filled, you cannot easily tell from an ABAP program whether it processes texts in foreign languages. (For comparison, think of clients, where you can recognize the source of data from the addition "CLIENT SPECIFIED".) Since this is not easily recognizable for languages, the extended program check lists critical points instead.You must either correct these or flag them as OK using a special pseudocomment.

    Check whether you have set the language environment correctly before the TRANSLATE statement, and if necessary, add a SET LOCALE LANGUAGE statement (as described in the examples below).

    Then, add the pseudocomment


    after the TRANSLATE statement (but on the same line) to indicate that the programming is correct.

    The extended program check automatically takes into account SET LOCALE LANGUAGE statements and 'SCP_MIXED_LANGUAGES_1_SWITCH' calls if they occur shortly before a TRANSLATE statement, but the pseudocomment is a safer way to ensure that the point in the program will not be listed in the check results.

    THere is a further pseudocomment


    to indicate that the TRANSLATE statement is allowed because the data only uses characters from the 'syntactical character set'.


    There are several ways of solving the problems:

    The following examples suppose a table with a text field and a language key:


    langu LIKE sy-langu,

    txt(20) TYPE CHAR,

    END OF data.

    Solution 1:




    New proposal SET LOCALE LANGUAGE data-langu.



    This is a correct solution, and simple because it does not require wide-ranging changes to the program. Each TRANSLATE TO UPPER CASE statement occurs in the correct environment.

    The disadvantage is that there may be a large number of locale switches, and the SET LOCALE command takes up runtime. This solution also fails to account for two conditions, although these should not occur very often:

    The language in data-txt may be invalid. This would cause a runtime error.

    The program may not be running in the logon language. The SET LOCALE LANGUAGE SPACE statement always resets the locale to the logon language.

    Solution 2: With sort:

    If the data can be sorted without a problem because, for example, they are in an internal table that is not too large, it may be quicker to sort the data first. This minimizes the number of switches required:

    SORT data BY langu.

    LOOP AT data.

    IF data-langu >< SY-LANGU.

    SET LOCALE LANGUAGE data-langu.





    SORT data BY keyfield1 keyfield2.

    Solution 3: Several passes:

    This solution requires the most programming, and is only worthwhile if you need to process large amounts of data that could be processed sequentially, but would be time consuming to sort, and are not already sorted more or less by language.

    In the first pass, you only convert the texts that are already in the logon language. Additionally, you use COLLECT to note all of the other languages that occur in an internal table.

    You can then loop through the internal table, switch to the next language, and run through the entire dataset again.

    An example of this would be too long for this documentation. The "2nd procedure" in RSCP0104 is a test of this procedure.

    Solution 4: Only process the logon language:

    IF data-langu = sy-langu.



    " Something important missing ?


    Other considerations


    SET LOCALE also changes the SY-LANGU field. Before processing more than TRANSLATE TO UPPER CASE and small, easy-to-understand actions, you should switch back to the logon language immediately, especially before calling new procedures.


    Depending on the data, it is possible that nosensical contents can appear for a given language key, that you are using a language that cannot be processed on a particular application server, or that a language is not properly installed.

    To ensure that application programs do not have to deal with these cases, there are four function modules that you can use:


    Called at the start of processing


    Switches to a paticular language


    Allows you to switch back temporarily to the language that was active when you called SCP_MIXED_LANGUAGES_1_INIT


    Called at the end of processing.

    Like many function modules, these have few obligatory parameters for normal use, but do have a range of optional additional parameters for special cases.

    If you do not catch any exceptions, you can expect that the function module will either run successfully or that the program will terminate with a short dump. Using these functions, solution 1 looks like this: Lösung 1 folgendermaßen aus:



    LOOP AT data. " Or SELECT, or...



    EXPORTING need_lang = data-langu.

    TRANSLATE data-txt TO UPPER CASE. "old code








    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Mar 06, 2006 at 01:49 PM

    Hi ,

    Please inform us from where these special characters are populating. If you are using a report may be from Text elements or Selection texts.

    You have to maintain tranlations for them by using T/code SE63 .



    Add comment
    10|10000 characters needed characters exceeded

  • Mar 06, 2006 at 02:01 PM


    try this:

    PARAMETERS inp(40) DEFAULT 'Habitación' LOWER CASE.
    DATA: BEGIN OF uml,
      um1 VALUE 'ó',
      um1_e VALUE 'o',
      um2 VALUE 'ä',
      um2_e VALUE 'a',
      um7 VALUE 'ß',
      um7_e(2) VALUE 'ss',
     END OF uml.
    FIELD-SYMBOLS: <h1_string>, <h2_string>.
    DATA string TYPE string.
    DATA outp(40).
    DATA: zaehler TYPE i VALUE 1.
    string = inp.
      ASSIGN COMPONENT zaehler OF STRUCTURE uml TO <h1_string>.
      IF sy-subrc <> 0.
      zaehler = zaehler + 1.
      ASSIGN COMPONENT zaehler OF STRUCTURE uml TO <h2_string>.
      IF sy-subrc <> 0.
        MESSAGE e000(yp).
      IF string CA <h1_string>.
        sy-subrc = 0.
        WHILE sy-subrc = 0.
          REPLACE <h1_string> WITH <h2_string> INTO string.
      zaehler = zaehler + 1.
    WRITE: inp, / string.


    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Mar 06, 2006 at 02:47 PM

    Many thanks to all of you for replying!! I finally could solve my issue with Michael's FM!

    See you soon!

    Add comment
    10|10000 characters needed characters exceeded