WO2016031959A1

WO2016031959A1 - Migration support device

Info

Publication number: WO2016031959A1
Application number: PCT/JP2015/074401
Authority: WO
Inventors: 孝介坂井; 佳範城代; 厚志粟河
Original assignee: 株式会社日立公共システム
Priority date: 2014-08-29
Filing date: 2015-08-28
Publication date: 2016-03-03
Also published as: JP2016051235A; JP6491438B2; CN106663020A; CN106663020B

Abstract

This work PC 1 (migration support device) includes: a character code converting unit (11) that converts an EBCDIK+KEIS code into a UTF-8 code; a program converting unit (12) that converts an input program (22) into an output program (32); an exchange information generating unit (13) which causes the output program (32) to read character data to which the UTF-8 code is allocated, and which generates exchange information E that defines, regarding the read character data, the number of areas on a memory specified by the output program (32) so as to be the same as the number of bytes of a byte sequence expressing the EBCDIK+KEIS code allocated to the character data; and an area storing unit (14) that stores a UTF-8 code allocated to the read character data in the areas the number of which is defined by the exchange information E.

Description

Migration support device

The present invention relates to a technology of so-called legacy migration (hereinafter sometimes simply referred to as “migration”), and more particularly, to a technology of migration that involves switching character code systems.

In recent years, there are many companies, local governments, and the like who desire a migration service for migrating a business system (legacy system) that has been operating on a current computer to a new computer. As a form of migration, for example, an open system in which an OS (Operating System) such as WINDOWS (registered trademark), UNIX (registered trademark), LINUX (registered trademark) is operated from a general-purpose host computer (or office computer). There is a form of migration to a server computer. A number of techniques relating to migration are disclosed, for example, in Patent Document 1.

However, a predetermined character code system (e.g., EBCDIK (Extended Binary Coded Decimal Interchange Kana Code), KEIS (Kanji processing Extended Information System), JIS8, SJIS (Shift JIS), hereinafter referred to as “old character code system”. In some cases, the host computer that handles the data has registered many external characters that are not registered as standard in the character code system (the external character area of the host computer is 9024 characters). In this case, migration to a server computer running an OS that can provide only a small external character area (the external character area provided by WINDOWS is equivalent to 1880 characters) cannot be realized.

In recent years, many companies, local governments, etc. have requested that the number of characters that can be used with new computers be increased compared to the current computer where the number of characters that can be used is limited. Specifically, with internationalization, we want to be able to express not only Kanji but also foreign characters such as Simplified and Hangul characters, or want to be able to express old Kanji in order to correctly represent individuals, etc. There is a request.

Therefore, as a countermeasure for these circumstances, migration to a new computer that handles a larger character code system such as UTF (Unicode Transformation Format) -8, UTF-16, etc. as a new character code system can be considered.

Migration mainly involves (1) migration of existing data on the business system, and (2) migration of existing programs operating on the business system that access such data. Therefore, it is necessary to convert the character code of the existing character data to be migrated so as to correspond to the new character code system. An existing program (for example, a program written in the COBOL language) needs to be converted so that character data obtained by converting the character code can be read.

However, the conventional technique has a problem that the conversion of the program is very complicated and difficult as compared with the conversion of the character code assigned to the character data. The problem is that depending on the combination of the old character code system and the new character code system, the number of bytes in the byte string representing that character may differ between the two character code systems, even for the same character. This is due to the fact that the length of the area in memory that the program specifies to store the byte sequence of characters is a fixed length. When converting a program, it is necessary to modify the contents of the program as appropriate in consideration of these circumstances. Will get different character data). However, since the correction pattern differs depending on the byte string of characters stored in the area, the correction is a very complicated and difficult task. In the prior art including the technique of Patent Document 1, there is no improvement measure for such work.

Japanese Patent No. 4405571

Therefore, the present invention has been made in view of such circumstances, and an object of the present invention is to facilitate the conversion of a program to be migrated in migration involving switching to a different character code system.

In order to achieve the above object, the present invention provides:
A migration support apparatus that supports migration from a first computer to a second computer,
The second character of the second computer has the first character code assigned to the character data in the first document file of the first computer with reference to the character code conversion table of the storage unit. A character code conversion unit that converts the second character code assigned to the character data in the document file;
The first program for processing the first document file included in the first computer is converted into the second program for processing the second document file included in the second computer. A program conversion unit for
By causing the second program to read the character data to which the second character code is assigned, the number of areas on the memory designated by the second program for the read character data is set to the character An exchange information generating unit for generating exchange information determined to be the same as the number of bytes of the byte string expressing the first character code assigned to the data;
An area storage unit for storing one of the second character codes assigned to the read character data in the area having a number determined by the exchange information;
It is characterized by that.
Other means will be described later.

The first legacy program treats the size of the character data (item length) as the number of bytes in the byte sequence, specifies the same number of bytes as the number of bytes on the memory, and stores the byte sequence of the character data. It was. That is, as in the prior art, the first program uses the area specified on the memory as an area for storing 1-byte data, and processes character data in units of bytes. Further, the description contents of the source code of the first program correspond to the processing.
On the other hand, the converted second program refers to the exchange information when processing the character data in which the number of bytes of the byte string representing one character is different by converting the character code. As many areas as can be used. That is, the second program can process the character data in units of the number of characters by setting the area designated on the memory as one or a plurality of areas for storing data of one character. Therefore, the logic assembled in the second program can be made the same as the logic assembled in the first program, and the portion related to the logic (for example, COBOL language) in the description contents of the source code of the second program There is no need to correct the number of digits in.
Therefore, in a migration that involves switching to a different character code system, it is possible to easily convert a program to be migrated.

According to the present invention, in a migration involving switching to a different character code system, it is possible to easily convert a program to be migrated.

It is a figure which shows the function structure of the migration assistance apparatus of this embodiment. It is a figure which shows the data structure of exchange information. It is a flowchart which shows the process of the migration assistance apparatus of this embodiment. As a comparative example, when converting a COBOL language program in accordance with the conversion from an EBCDIK + KEIS code to a UTF-8 code, it is a diagram for explaining that the description content of the source code needs to be corrected, (a) Is a diagram showing a description example of the data section working section in the source code of the pre-conversion program and a schematic diagram of an area embodying the description example, and (b) of the source code of the post-conversion program It is a schematic diagram of an area that embodies a description example of the data section working section and a description example in which a predetermined correction is made. FIG. 7 is a diagram for explaining that, when a COBOL language program is converted in accordance with the conversion from the EBCDIK + KEIS code to the UTF-8 code, modification of the description content of the source code is not necessary, ) Is a diagram showing a description example of the data section working section in the source code of the pre-conversion program and a schematic diagram of an area embodying the description example, and (b) is a source code of the post-conversion program 2 is a schematic diagram of an area embodying a description example of a data section working section and a description example in which a predetermined correction is unnecessary.

As shown in FIG. 1, the work PC 1 is a computer operated by a worker in charge of migration from the current computer 2 to the new computer 3, and is a migration support apparatus of this embodiment. The work PC 1 acquires the input file 21 and the input program 22 from the current computer 2, performs predetermined conversion (details will be described later), and then outputs the output file 31 and the output program 32 to the new computer 3.

The current computer 2 (first computer) is a general-purpose host computer.
The new computer 3 (second computer) is an open server computer.

The input file 21 (first document file) is a document file including character data and is a legacy of the current computer 2. The character data in the input file 21 follows the character code system handled by the current computer 2. The character code system handled by the current computer 2 is EBCDIC for character data of half-width alphanumeric characters, half-width symbols, and half-width kana characters, and KEIS for character data of full-width characters. In the present embodiment, the character code assigned to the character data in the input file 21 may be referred to as “EBCDIK + KEIS code”.

In addition, EBCDIC expresses one character by 1 byte for half-width alphanumeric characters, half-width symbols, and half-width kana characters (number of bytes = 1). KEIS expresses one character with 2 bytes for double-byte characters (number of bytes = 2).

The input program 22 (first program) is a program for processing the input file 21, and is a legacy of the current computer 2. The input program 22 is described in the COBOL language, and the description content conforms to a character code system composed of EBCDIC and KEIS.

The output file 31 (second document file) is a document file including character data. The character data in the output file 31 follows the character code system handled by the new computer 3. The character code system handled by the new computer 3 is UTF-8 for character data of any one-byte alphanumeric characters, half-width symbols, half-width kana characters, and full-width characters. In the present embodiment, the character code assigned to the character data in the output file 31 may be referred to as “UTF-8 code”.

UTF-8 expresses one character as 1 byte for half-width alphanumeric characters and half-width symbols (number of bytes = 1), and expresses one character as 3 bytes for half-width Kana characters and full-width characters ( Number of bytes = 3).

The output program 32 (second program) is a program for processing the output file 31. In the present embodiment, it is assumed that the output program 32 is described in the COBOL language. However, by providing a well-known formal description, the output program 32 can be described in JAVA (registered trademark) language.

Note that the work PC 1 includes hardware such as an input unit, an output unit, a control unit, and a storage unit. For example, when the control unit is constituted by a CPU (Central Processing Unit), information processing by a computer including the control unit is realized by program execution processing by the CPU. In addition, the storage unit included in the computer stores a program that is instructed by the CPU and implements the function of the computer. This realizes cooperation between software and hardware. The program is provided by being recorded on a recording medium or via a network.

As shown in FIG. 1, the work PC 1 has functional units such as a character code conversion unit 11, a program conversion unit 12, an exchange information generation unit 13, and an area storage unit 14, and includes a character code conversion table T, Exchange information E is stored in the storage unit.

The character code conversion unit 11 assigns the EBCDIC + KEIS code (first character code) assigned to the character data in the input file 21 to the character data in the output file 31 with reference to the character code conversion table T. Convert to UTF-8 code (second character code).

The program conversion unit 12 converts the input program 22 into the output program 32 so as to correspond to the character code conversion by the character code conversion unit 11. The program conversion unit 12 can convert the description language of the output program 32 to be the same as the description language of the input program 22 (for example, COBOL → COBOL), or can convert it differently (for example, : COBOL → JAVA).

The exchange information generation unit 13 causes the output program 32 to read the character data to which the UTF-8 code has been assigned, so that the number of areas on the memory designated by the output program 32 is determined for the read character data. The exchange information E defined to be the same as the number of bytes of the byte string expressing the EBCDIC + KEIS code assigned to is generated.
The character data assigned with the UTF-8 code read by the output program 32 is, for example, character data extracted from the output file 31.

The area storage unit 14 stores one UTF-8 code assigned to the character data read by the output program 32 in the area having the number determined by the exchange information E.

The character code conversion table T is assigned to a character included in a predetermined character set (for example, a character set of characters defined by the character code system composed of EBCDIK and KEIS handled by the current computer 2). The EBCDIK + KEIS code and the UTF-8 code are associated with each other. The details of the association are well known and will not be described.

The exchange information E generated by the exchange information generation unit 13 includes, for each character data to which the UTF-8 code is assigned, the number of bytes that is the size of the character data (the length of the item), and a memory designated by the output program 32 Corresponds to the number of upper areas.
As shown in FIG. 2, UTF-8 codes assigned to various character data are character codes that represent half-width alphanumeric characters (half-width alphanumeric characters + half-width symbols), character codes that represent half-width kana characters, full-width characters. It can be classified into character codes representing characters. The “number of bytes” and “number of areas” described above are determined for the classified character codes.

As for the character code representing the character of the half-width alphanumeric symbol, as described above, UTF-8 expresses one corresponding character by 1 byte, so the “number of bytes” is “1”. In addition, as described above, EBCDIC expresses one character in one byte for one-byte alphanumeric characters and one-byte symbols, and therefore, the number of areas becomes “1” by the function of the exchange information generation unit 13.

For character codes that represent half-width kana characters, as described above, UTF-8 represents the corresponding character in 3 bytes, so the “number of bytes” is “3”. In addition, as described above, EBCDIC expresses one character in one byte for half-width kana, and “number of areas” becomes “1” by the function of the exchange information generation unit 13.

For character codes representing full-width characters, as described above, UTF-8 represents the corresponding character in 3 bytes, so the “byte count” is “3”. In addition, as described above, KEIS expresses one character with 2 bytes for double-byte characters, so that the number of areas becomes “2” by the function of the exchange information generation unit 13.

The content of the exchange information E is determined by the combination of the character code system handled by the current computer 2 and the character code system handled by the new computer 3.

<< Process >>
The processing of this embodiment will be described. The subject of this processing is the control unit of the work PC 1, but for convenience of explanation, the term “control unit” is omitted.
As shown in FIG. 3, the work PC 1 starts processing from step S <b> 1 when performing migration from the current computer 2 to the new computer 3.

In step S1, the work PC 1 acquires the input file 21 and the input program 22 from the current computer 2. After step S1, the process proceeds to step S2.

In step S <b> 2, the work PC 1 converts the character code of the acquired character data in the input file 21 from the EBCDIK + KEIS code to the UTF-8 code by the character code conversion unit 11 to generate the output file 31. . After step S2, the process proceeds to step S3.

In step S <b> 3, the work PC 1 converts the acquired input program 22 into the output program 32 by the program conversion unit 12. After step S3, the process proceeds to step S4.

In step S4, the work PC 1 reads the character data to which the UTF-8 code is assigned by the output program 32. After step S4, the process proceeds to step S5.

In step S5, the work PC 1 uses the exchange information generation unit 13 to generate exchange information E for the character data read in step S4. After step S5, the process proceeds to step S6.

In step S6, the work PC 1 uses the area storage unit 14 to store the UTF-8 code corresponding to the area (the area on the memory designated by the output program 32) of the number determined by the exchange information E, that is, in step S4. The UTF-8 code assigned to the character data read in is stored. After step S6, the process of FIG.

The output file 31, the output program 32, and the exchange information E generated by the work PC 1 are output to the new computer 3. Here, consider a case where the output program 32 opens the output file 31 in order to execute a predetermined business process in the new computer 3. In this case, the output program 32 refers to the exchange information E and accesses the UTF-8 code stored in the memory area designated by the output program 32 in the order determined by the output program 32.

The input program 22 treats the size of the character data (item length) in the input file 21 as the number of bytes of the byte sequence, specifies the same number of areas as the number of bytes on the memory, and stores the byte sequence of the character data. Was. In other words, as in the past, in the current computer 2, the input program 22 uses the area specified on the memory as an area for storing 1-byte data, and character data in the input file 21 in units of bytes. By processing, the character data is processed in order substantially one character at a time.

For character data in which the number of bytes in the byte string has changed due to the conversion of the character code from EBCDIK + KEIS code to UTF-8 code, the exchange information E inputs the number of areas specified by the output program 32 on the memory. The program 22 can be the same as the number of areas designated on the memory. For example, when the EBCDIK + KEIS code is converted to UTF-8 code, the output program 32 converts the exchange information E to the full-width character data in which the number of bytes in the byte sequence is changed from “2” to “3”. By referencing, the number of areas designated on the memory can be set to “2” instead of “3” as in the prior art. The area storage unit 14 stores one UTF-8 code assigned to the full-width character in two (continuous) areas.

Therefore, the output program 32 can make the area designated on the memory not an area for storing 1-byte data but an area for storing 1-character data, and the output file 31 in units of the number of characters. The character data inside can be processed. As a result, in the same way as the input program 22 processes the character data in the input file 21 one character at a time, in the new computer 3, the output program 32 outputs the character data in the output file 31 one character at a time. Can be processed. That is, even if migration is performed that involves conversion of character codes having different character data sizes, the logic assembled in the output program 32 can remain the same as the logic assembled in the input file 21. The worker who performs the migration does not need to correct the logic-related part of the description contents of the source code of the output program 32.

The work PC 1 stores an area (one byte of data) of a specified number of bytes (for example, three full-width characters) for storing byte sequences of character data to which a UTF-8 code is assigned one byte at a time. The output program 32 can be controlled so as to be separately designated on the memory. Then, the work PC 1 performs control so that the area storage unit 14 associates one or two areas for storing one UTF-8 code with the predetermined number of areas. Therefore, in the new computer 2, when the output program 32 accesses the UTF-8 code stored in the area storage unit 14, the target program is accessed by accessing the byte string stored in the associated area. Can be processed.

≪Specific example≫
With reference to FIG. 4 and FIG. 5, a specific example of converting a program by migration accompanied by switching of a character code system will be described. In this specific example, both the pre-conversion program (corresponding to the input program 22) and the post-conversion program (corresponding to the output program 32) are described in the COBOL language. The character code handled by the pre-conversion program is EBCDIK + KEIS code, and the character code handled by the post-conversion program is UTF-8 code.

FIG. 4 shows a comparative example as a conventional technique. The upper part of FIG. 4A shows a description example of the data section working section in the source code of the pre-conversion program. In the group item DATA-A, variables (items) DATA-A1 and DATA-A2 are declared in this order.
In DATA-A1, “PIC X” indicates that one byte of data (EBCDIK) storage area is secured in memory, and “(03)” indicates that there are three such areas. (Number of digits is 3). Therefore, data for 3 characters (half-width characters) can be input to DATA-A1.
In DATA-A2, “PIC N” indicates that one character 2 bytes of data (KEIS) storage area is secured on the memory, and “(03)” indicates that there are three such areas. (Number of digits is 3). Therefore, data of 3 characters (double-byte characters) can be input to DATA-A2.
The COBOL language declares variables with a fixed length.

4A shows a schematic diagram of an area that embodies the above description example. If one area is represented by one box, this box represents a 1-byte data storage area. According to this schematic diagram, the pre-conversion program can input data for 3 characters into DATA-A1 by designating an area for 3 bytes on the memory for DATA-A1. In addition, by specifying an area of 6 bytes (2 bytes × 3) on the memory for DATA-A2, data of 3 characters can be input to DATA-A2. Thus, as before, the pre-conversion program specifies the area where the byte string of character data is stored for each byte, and processes the character data in units of bytes (in the box in order from the left). One byte sequence at a time).

Here, when character code is converted by migration and the program is also converted, in order to correctly process character data in which the number of bytes in a byte string representing one character is different (the target character data is reliably read out) Therefore, in the prior art, it was necessary to manually correct the logic of the converted program.

In the upper part of FIG. 4B, a description example of the data section working section in the source code of the converted program is shown. In order to make the logic the same before and after the conversion of the program, it is necessary to modify the description example of FIG. 4A by adding a description as indicated by the underlined portion in the figure.
As a modification, the number of digits is changed from 3 to 9 for DATA-A1. The reason for changing the number of digits in this way is that EBCDIK expresses one half-width kana character in 1 byte, whereas UTF-8 expresses one half-width kana character in 3 bytes. This is because DATA-A1 has an area of 9 bytes (3 bytes × 3 characters) so that it can cope with a case where a byte string of characters is input (to prevent data overflow).
As a modification, the number of digits is changed from 3 to 5 for DATA-A2. The reason for changing the number of digits in this way is that KEIS expresses one full-width character in 2 bytes, whereas UTF-8 expresses one full-width character in 3 bytes. This is because DATA-A2 is provided with an area of at least 9 bytes (3 bytes × 3 characters) so as to cope with the case where a character byte string is input. In the example of FIG. 4B, by setting the number of digits of DATA-A2 to 5, DATA-A2 has an area of 10 bytes.

In the lower part of FIG. 4 (b), a schematic diagram of an area embodying the description example with the above modifications is shown. The box shown in FIG. 4B represents a 1-byte data storage area, like the box shown in FIG. As a result of the above modification, the characteristics of the pre-conversion program that data of 3 characters can be input to DATA-A1 and data of 3 characters can be input to DATA-A2 by increasing the number of boxes are converted. It is retained in the program. However, modifying the logic built into the program so as to increase such boxes requires a large amount of work because it needs to be performed for all variables in the program.

FIG. 5 shows this embodiment. FIG. 5A is the same as FIG. That is, data for three characters can be input to the variable DATA-A1, and data for three characters can be input to the variable DATA-A2.
In the upper part of FIG. 5B, a description example of the data section working section in the source code of the converted program is shown. When the program is converted in this embodiment, the exchange information E already described is used.

As already described, the area specified by the converted program on the memory by the exchange information E functions as an area for storing 1-character data, not an area for storing 1-byte data. This is synonymous with the fact that one box represents one area as a data storage area for one half-width alphanumeric symbol Kana character as shown in the lower part of FIG. 5B. Here, the term “single-byte alphanumeric symbol kana characters” is a word that is a collection of single-byte alphanumeric characters, half-width symbols, and half-width kana characters. A data storage area for one half-width alphanumeric symbol kana character can represent a data storage area for one full-width character when arranged in two.

Therefore, in the description example of FIG. 5B, “PICAX (03)” of DATA-A1 secures three data (UTF-8) storage areas in memory for one-byte alphanumeric symbol Kana characters. Can be expressed. This means that even if the number of digits is not increased as shown in FIG. 4B (the logic is not corrected), the variable DATA-A1 has three characters of data (characters assigned with UTF-8 code). Data).

Also, “PIC N (03)” in DATA-A2 can indicate that three double-byte character (UTF-8) data storage areas are secured in the memory. This means that even if the number of digits is not increased as shown in FIG. 4B (the logic is not modified), the variable DATA-A2 has three characters of data (characters assigned with UTF-8 code). Data).

As already explained, one UTF-8 code is stored in the data storage area of one or two single-byte alphanumeric symbols and one kana character. Therefore, when executing a predetermined job process, the converted program can process character data in units of the number of characters by accessing the UTF-8 code stored in the area in a predetermined order.

As described above, by using the exchange information E, it is possible to eliminate a large amount of work such as correcting the logic built in the program by changing the handling of the area designated on the memory by the converted program.

≪Summary≫
According to this embodiment, the converted output program 32 refers to the exchange information E when processing character data in which the number of bytes in a byte string representing one character is different by converting character codes. The same number of areas as the number of areas used by the program 32 can be used. That is, the output program 32 can process the character data in units of the number of characters, with the area designated on the memory being one or a plurality of areas for storing one character data. Therefore, the logic assembled in the output program 32 can be made the same as the logic assembled in the input program 32, and it is not necessary to modify the logic-related part of the description contents of the source code of the output program 32.
Therefore, in a migration that involves switching to a different character code system, it is possible to easily convert a program to be migrated.

≪Others≫
In the present embodiment, the migration accompanied by the switching from the character code system using EBCDIK and KEIS to the character code system using UTF-8 has been described. However, the present invention can also be applied to migration involving switching from a character code system using JIS8 and SJIS to a character code system using UTF-8.

JIS8 expresses one character with 1 byte for half-width alphanumeric characters, half-width symbols, and half-width kana characters (number of bytes = 1). In SJIS, for double-byte characters, one character is represented by 2 bytes (number of bytes = 2).

In this embodiment, the area storage unit 14 stores the UTF-8 code in an area on the memory designated by the output program 32. However, it is also possible to store data in any format that can identify the corresponding character data instead of the UTF-8 code.

In this embodiment, when the exchange information generating unit 13 generates the exchange information E, the character data assigned with the UTF-8 code read by the output program 32 is, for example, the character data extracted from the output file 31. did. However, for example, the work PC 1 replaces all characters included in a predetermined character set (for example, in the case of migration to an open server computer that handles UTF-8, a character set consisting of all existing characters). In order to generate the information E, character data to which a UTF-8 code is assigned may be acquired in advance from the outside, and the acquired character data may be read into the output program 32.

In addition, it is possible to realize a technique in which various techniques described in this embodiment are appropriately combined.
The software described in this embodiment can be realized as hardware, and the hardware can also be realized as software.
In addition, hardware, software, flowcharts, and the like can be changed as appropriate without departing from the spirit of the present invention.

1 Work PC (migration support device)
11 Character code conversion unit 12 Program conversion unit 13 Exchange information generation unit 14 Area storage unit 2 Current computer (first computer)
21 Input file (first document file)
22 Input program (first program)
3 New computer (second computer)
31 Output file (second document file)
32 Output program (second program)
T Character code conversion table E Exchange information

Claims

A migration support apparatus that supports migration from a first computer to a second computer,
The second character of the second computer has the first character code assigned to the character data in the first document file of the first computer with reference to the character code conversion table of the storage unit. A character code conversion unit that converts the second character code assigned to the character data in the document file;
The first program for processing the first document file included in the first computer is converted into the second program for processing the second document file included in the second computer. A program conversion unit for
By causing the second program to read the character data to which the second character code is assigned, the number of areas on the memory designated by the second program for the read character data is set to the character An exchange information generating unit for generating exchange information determined to be the same as the number of bytes of the byte string expressing the first character code assigned to the data;
An area storage unit for storing one of the second character codes assigned to the read character data in the area having a number determined by the exchange information;
A migration support apparatus characterized by that.
The character code system that defines the first character code is: EBCDIK (Extended Binary Coded Decimal Interchange Kana Code) for half-width alphanumeric characters, half-width symbols, and half-width kana characters, and KEIS (Kanji) for full-width characters. processing Extended Information System), and the character code system defining the second character code is UTF (Unicode Transformation Format) -8,
When the character data is half-width alphanumeric characters, half-width symbols, or half-width kana characters, the number of areas defined by the exchange information is 1,
When the character data is double-byte character data, the number of areas defined by the exchange information is two.
The migration support apparatus according to claim 1.
The character code system that prescribes the first character code is JIS8 for character codes for half-width alphanumeric characters, half-width symbols, and half-width kana characters, SJIS (Shift JIS) for full-width characters, and the second character The character code system that defines the code is UTF-8.
When the character data is half-width alphanumeric characters, half-width symbols, or half-width kana characters, the number of areas defined by the exchange information is 1,
When the character data is double-byte character data, the number of areas defined by the exchange information is two.
The migration support apparatus according to claim 1.