JP4718282B2 - External character processing system and processing method - Google Patents

Description

  The present invention relates to an external character processing system and a processing method.

  In a system that handles names, addresses, etc., it is indispensable to handle characters that are not defined by the character codes handled by the operating system (OS). In general, a unique character shape is registered and used in the code of the vacant area. These unique characters are read as user external characters or simply external characters. These characters are non-distributable and can only be used in the closed world within the system.

  In systems that receive data such as names and addresses from multiple systems constructed in this format and handle them, external character data defined for each system will be received, and identification work for these different external characters Must be within the range of external characters allowed by the system.

  As means for solving such a problem, there are techniques disclosed in Patent Documents 1 and 2. The character processing device of Patent Document 1 creates a code system conversion table and an external character file for each user, and switches between these for use according to the user. Further, the external character expansion method of Patent Document 2 defines virtually different external characters for each of a plurality of fonts possessed by the OS for one character code, and virtually switches the font according to a specific additional code. It expands the number of external characters.

JP-A-8-179905 JP 2000-187654 A

However, in the conventional method, when defining a new external character, it is necessary to define the external character in all related systems and terminals, that is, to distribute external character data to all display terminals. There was a problem that it took a workload.
For example, when a terminal is connected to the character processing apparatus of Patent Document 1, it is necessary to create a code system conversion table and an external character file similar to those of the character processing apparatus for each user for all terminals. Further, in the external character expansion method of Patent Document 2, it is necessary to set additional codes and define different external characters for a plurality of fonts for all terminals.

  The present invention has been made to solve such a problem, and provides an external character processing system and a processing method that do not require the work that occurs at each terminal in relation to the definition of a new external character. Objective.

EUDC processing system according to the present invention, a unique private character codes each of which is defined at a plurality of different systems, and converts to a co Tsugaiji code, a conversion means, a character string data including external characters represented by the common external character codes Storing character string data storage means, image data storage means for storing image data corresponding to external characters, character string data including external characters input from outside, and image data corresponding to external characters; Characters stored in association with each other in response to an output request from the data fetching means for storing the character string data in the character string data storage means and the image data in the image data storage means. A data utilization means for creating display data based on column data and image data, wherein the display data is an external character in the character string data. Data deletion including deleting data of character string data and image data stored in correspondence with a data utilization means including external character string data and image data corresponding to external characters, and in response to an external deletion request The character string data storage means and the image data storage means store the character string data and the image data by a structure including a two-dimensional table format table represented by a record and a column, respectively. When associating character string data and image data, the table name that uniquely identifies the table within the character string data storage means, the ID that uniquely identifies the record within the table, and the column that uniquely identifies the column within the record The name and the character position including the external character in the column are used.

Output request from the external portion may include the table name and ID.

The processing method of external characters according to the present invention, a unique private character code defined respectively at a plurality of different systems, and converts to a co Tsugaiji code, and the character string data including external characters represented by the common private character code, external character The image data corresponding to each of the character string data is stored in association with each other, and the external character is excluded from the character string data based on the character string data and the image data stored in association with each other in response to an external output request. In the method of creating display data including character string data and image data corresponding to external characters and deleting the character string data and image data stored in association with each other based on an external deletion request, The column data and the image data are stored by a structure including a two-dimensional table format table represented by a record and a column, respectively. When associating character string data and image data, a table name that uniquely identifies the table within the character string data storage means, an ID that uniquely identifies the record within the table, a column name that uniquely identifies the column within the record, In addition, a character position including an external character in a column is used.

  According to the present invention, since the external character processing system and processing method handle external characters as images, it is possible to eliminate the work that occurs at each terminal in relation to the definition of a new external character.

Embodiments of the present invention will be described below with reference to the accompanying drawings.
Embodiment 1 FIG.
FIG. 1 shows a configuration including a collaborative system 4 which is an external character processing system according to Embodiment 1 of the present invention.
The joint system 4 is a system that handles resident information of a plurality of local governments in an integrated manner.

A city resident information system 1, a B city resident information system 2, and a C city resident, each of which is an individual system that handles resident information of a single local government so that it can communicate electronically with the joint system 4 via the network 10. An information system 3 is installed.
In addition, the A city terminal 5, the B city terminal 6, and the C city terminal 7, which are terminals for using the common system 4 so as to be capable of electronically communicating with the common system 4 via the network 20, are installed. Yes.

Each of the resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7 is a computer having a well-known configuration including a CPU that is a calculation means, a memory that is a storage means, and an HDD (hard disk drive).
In addition, the resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7 each have a function of handling a JIS code, which is a code system representing Japanese characters including hiragana, katakana, and kanji, as a character code. Have. This function is, for example, a function of outputting a character pattern representing the shape of the character by display or printing in correspondence with a code system representing the character.
The resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7 realize the above-described functions by executing a program including a well-known operating system. There are no restrictions on the type of operating system as long as it can handle the code, and it is appropriately selected according to the requirements.

  The character code system used by the resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7 for internal processing or input / output is, for example, a JIS code. However, this may be another system as long as it includes a code corresponding to at least a part of the JIS code, and so-called unicode or the like may be used. Different code systems may be used in each of the resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7. At that time, the resident information systems 1 to 3, the joint system 4, and the terminals 5 to 7 convert a code corresponding to a certain character in a certain code system to a code corresponding to the same character in a different code system. .

The inhabitants information systems 1 to 3 store inhabitants information of corresponding local governments. The resident information includes information related to the residents of each local government, such as name and address, for each resident. The name and address are represented by a JIS code, and the resident information is stored by storing this code in the storage means.
The joint system 4 and the terminals 5 to 7 each input / output data including characters and images represented by character codes including JIS codes, for example, HTML format data. Further, a protocol for transmitting and receiving data in the HTML format via the external network 20, for example, an HTTP protocol can be used.

Characters not included in the JIS code are used for part of the name and address of the residents. For example, the character shown in FIG. 2 is a variant of “yoshi”. In “Yoshi”, the upper part (the part that is not the radical) has a shape close to “Shi”, and the upper horizontal line is longer than the lower horizontal line, but in the variant shown in FIG. The horizontal line of is shorter than the horizontal line below.
Such characters do not correspond to the characters included in the JIS code and cannot be represented by the JIS code. That is, no corresponding definition is made in the character code handled by the OS. For this reason, each of the resident information systems 1 to 3 is individually registered as a user-defined character, that is, an external character.

An external character is defined in each system using an external character code corresponding to each character. This external character code is hereinafter referred to as “unique external character code”. The code area used as the unique external character code is a part of the code area where no character is defined in the JIS code.
When registering an external character, first, one unique external character code is selected and assigned to the registered character. Next, a character pattern representing the character is defined as corresponding to the unique external character code. The character pattern is bitmap format image data.

  When the JIS code is used as the character code system as described above, the unique external character code area is an area including codes that are part of 2921 to 2F7E and part of 7521 to 7E7E in hexadecimal notation. . In the case of other character code systems, a unique area is defined for each.

Although not shown, the address table is stored in the storage means of the A city resident information system 1 as resident information. This associates a name with an address for each inhabitant in A city. This address table includes, for example, only some residents, that is, only residents who are registered with a specific group or the like. However, this address table may include all residents of A city.
In this address table, information on residents who have characters that are not included in the JIS code in their name or address is stored using external characters corresponding to the unique external character code.

The B city resident information system 2 and the C city resident information system 3 also store the same address table as the A city resident information system 1 for the residents of the B city and C city, respectively. However, between the resident information systems 1 to 3, the same unique external character code may be assigned to different characters. For example, different character patterns are defined in the resident information system 1, the resident information system 2, and the resident information system 3 for a single unique external character code.
The inhabitant information may include a table other than the address table. For example, a permanent address table that associates the name of the resident with the permanent address, and other tables may be stored.

FIG. 3 is a diagram conceptually showing the internal configuration of the collaborative system 4. As described above, the collaborative system 4 includes a CPU and storage means (both not shown).
The CPU functions as the data fetching means 41 by executing the data fetching program. The data fetching means 41 receives data from the resident information systems 1 to 3 via the network 10, and divides it into character string data representing resident information and image data representing a character pattern of external characters, and storage means such as an HDD. To store. Here, the storage means includes a resident information table 44 that is character string data storage means and a bitmap information table 45 that is image data storage means.

In addition, the CPU functions as the data utilization unit 42 by executing the data utilization program. The data utilization means 42 receives a data output request from the terminals 5 to 7 via the network 20, creates display data based on the resident information table 44 and the bitmap information table 45, and sends a request source via the network 20. To terminals 5-7.
Furthermore, the CPU functions as the data deletion unit 43 by executing the data deletion program. The data deleting unit 43 deletes a part of information stored in the resident information table 44 and the bitmap information table 45 of the joint system 4 in response to a deletion request from the outside.

A flow of processing in the configuration including the joint system 4 configured as described above will be described.
First, each of the resident information systems 1 to 3 transmits the stored resident information to the joint system 4 through the network 10 as an input file to the joint system 4.
At this time, the tabular data is transmitted as a CSV file. For example, in the case of an address table, the CSV format file is as follows.
1st line: “Address table”
2nd line: "Name and address"
3rd line: “E0004544442404F3A, 456C357E4554 ..., XXXXXX ..."
4th and subsequent lines: (same format as 3rd line)
The “address table” on the first line of the input file is a character string representing the table name of the resident information included in the file. “Name and address” on the second line is a character string representing each column name of the table.
The character strings on the first and second lines may be included as the contents of the CSV format file as described above, but may be omitted if determined in advance as specifications. That is, the file may not include the first and second lines of the file, and the third line of the file may be the first line.

Resident information about each inhabitant is included in the third and subsequent lines. Here, each resident information is not a character string but converted into a character code in hexadecimal notation. Furthermore, the unique external character code is converted into a predetermined code that does not represent a normal character. Hereinafter, the predetermined code after the conversion is referred to as “common external character code”.
For example, a code that becomes E000 in hexadecimal 4-digit notation is used as the common external character code. As this common external character code, only a single code, for example E000, may be used, or a plurality of codes, for example, E000, E001, E002.
In addition, the resident information may not be a character string converted into a hexadecimal character code, but may be a character string itself represented by the corresponding character code.

  Furthermore, when the resident information includes an external character, a column representing a bitmap is added to the end of each corresponding line, and bitmap data representing the character pattern is included. This bitmap data is in hexadecimal notation format. When two or more external characters are included, the number of columns added corresponding to the number increases.

An example of data included in the third and subsequent lines of the input file thus created is “E0004544442404F3A, 456C357E4554..., XXXXXX...” As described above. Since the name of the resident corresponding to this line is 4 characters, the first column is 16-digit hexadecimal notation. In addition, since the external character was used for the 1st character of this inhabitant, the character code of the 1st character is converted into the common external character code E000. The second column “456C357E4554...” Is a hexadecimal notation corresponding to an address, but a part of the following is omitted for the sake of brevity. The third column “XXXXXXX...” Is actually bitmap data in hexadecimal notation. For example, when the first character of the name of the resident is the character shown in FIG. 2, the bitmap data representing the pattern in FIG. Become. The bitmap data is assumed to use a unified specification such as the BDF format.
As described above, the input file is created as data including character string data including external characters and image data corresponding to the external characters.

The processing flow of the data fetching means 41 of the joint system 4 when receiving the input file as described above will be described with reference to FIGS.
FIG. 4 is a flowchart showing the flow of processing, and FIGS. 5 and 6 are diagrams showing the structures of the resident information table 44 and the bitmap information table 45 created by the data fetching means 41, respectively.

  First, the data taking-in means 41 receives the input file transmitted from the resident information systems 1-3 (step S1).

Next, the data fetching means 41 adds a record to the corresponding table based on the third and subsequent lines of the input file (step S2). At this time, the resident ID is numbered by the data fetching means 41 so as to be unique within each table.
The record to be added does not include bitmap data. For example, the record R1 in FIG. 5 corresponds to the third line of the input file, ie, “E0004544442404F3A, 456C357E4554..., XXXXXX...”, But the last bit map data “XXXXXXX.
In the record added here, the hexadecimal notation is divided every four digits as shown in FIG. 5, and the data fetching means 41, the data using means 42, and the data deleting means 43 recognize the character breaks. It is a format that can be done.
Note that the data format is not a character string converted into a hexadecimal character code as described above, but may be a character string itself represented by the corresponding character code.

  Next, the data fetching means 41 adds a record to the bitmap information table 45 based on the resident information table created in step S2 and the third and subsequent lines of the input file, in a binary format corresponding to the bitmap data. Data is stored (step S3). Here, the bitmap information table 45 itself is created in advance as a data structure including a two-dimensional table format table represented by records and columns as shown in FIG.

For example, since the record R1 in the address table in FIG. 5 includes one character having the common external character code E000, one line of record R2 is added to the bitmap information table 45 in FIG. . The record R2 is information indicating the position of the external character in the resident information table 44, that is, the table name, the resident ID, the column name, and the character position (a natural number indicating what character the external character is in the corresponding column), This is associated with the binary bitmap data representing the character pattern of the external characters.
In addition, when the bitmap data is stored in the bitmap information table 45, the bitmap data is changed from the hexadecimal notation format to the binary format as long as the data use means 42 and the data deletion means 43 can handle the data. Any thing is acceptable.

Here, the table name is unique to each table, the resident ID is unique to each record, and the column name is unique to each column. That is, the table name uniquely identifies the table within the resident information table 44, the resident ID uniquely identifies the record within the table, and the column name uniquely identifies the column within the record. It is.
In addition, as can be seen from the above explanation, a bitmap information table record is not created for a resident information table record that does not include a common external character code, and a resident information table record that includes a plurality of common external character codes. Depending on the number, a plurality of bitmap information table records are created.

In this way, the data fetching means 41 adds a record to the resident information table 44 and the bitmap information table 45 based on the input file.
The flowchart shown in FIG. 4 is executed when a new record is added to an existing table in response to reception of an input file. In addition, as can be seen from the above description, even when a new record includes an external character, the data fetching means 41 does not add the external character definition to the character code system used by the joint system 4 itself, and the resident information Only the table 44 and the bitmap information table 45 are updated. That is, even if the input file contains a definition of a new external character that was not used before, the external character is not defined or required except for the system that sent the input file. Not.

Note that the flowchart shown in FIG. 4 assumes that all resident information tables are created in advance (during system installation or the like), and no addition is necessary. Otherwise, if there is a possibility that data related to a resident information table that has not been created may be input, the data fetching means 41 will perform a new resident information table between step S1 and step S2. It is also possible to perform the process of creating This is done, for example, as follows.
The data fetching means 41 determines whether or not the table name “address table” shown in the first line of the input file is included in the already created resident information table 44, that is, whether it is a new table.
If it is a new table, the data fetching means 41 creates a two-dimensional table format table represented by records and columns in the resident information table 44 based on the first and second lines of the input file. As a data structure to include, a table framework shown in FIG. 5 is created. Here, the table name is the “address table” on the first line.
The column name is “resident ID” in which the first column records an ID unique to each record in the table, and the column names of the input file are set in order from the second column. That is, the first column of the created table is always “resident ID”, the second column of the created table is “name” corresponding to the first column of the input file, and the third column of the created table. Corresponds to the “address” corresponding to the second column of the input file.

With reference to the flowchart shown in FIG. 7, the flow of processing of the data utilization unit 42 when receiving an output request regarding resident information from the terminals 5 to 7 will be described.
First, the data utilization means 42 receives as input the table name and resident ID to be searched from the terminals 5 to 7 (step S21). Here, as an example, it is assumed that a table name “address table” and a resident ID “00001” are input as a request from the terminal 5.

  Next, the data utilization means 42 searches the resident information table having the corresponding table name for a record having the corresponding resident ID, and acquires the record (step S22). In the above example, the record R1 of FIG. 5, that is, the resident ID “00001”, the name “E000 4544 4240 4F3A”, and the address “456C 357E 4554.

Next, the data utilization unit 42 determines whether or not a common external character code is included in the acquired record (step S23). In the above example, the common external character code is included in the first character of the name.
If a common external character code is included in step S23, the data utilization unit 42 searches the bitmap information table 45 and acquires all records having the same resident ID (step S24). In the above example, the corresponding resident ID “00001” is searched, and the record R2 is acquired as the corresponding record.
If the common external character code is not included in step S23, step S24 is not executed, and the process proceeds to step S25.

The data utilization means 42 is based on the record of the resident information table 44 acquired at step S23, or based on the record of the resident information table 44 acquired at step S23 and the record of the bitmap information table 45 acquired at S24. Then, the display data to be used for display in the requesting terminals 5 to 7 is created in the HTML format (step S25).
Here, the character string in hexadecimal notation representing the character code included in the record of the resident information table 44 is replaced with the character represented by the character code. The common external character code is replaced with bitmap data included in the image corresponding to the external character, that is, the bitmap information table record corresponding to the position where the common external character code is included.

  In the above example, the resident ID included in the display data is a character string made up of the number “00001”, and the address is a character string made up of characters corresponding to the character code “456C 357E 4554. The name corresponds to the character code “4544 4240 4F3A” after the image representing the character pattern in FIG. 2, that is, the bitmap data (described by the IMG tag in the HTML format) included in the record R2 in FIG. 6. The data is a combination of an image and a character string, followed by a character string consisting of the characters to be processed.

  Next, the data utilization unit 42 transmits the display data created in step S25 to the terminals 5 to 7 that are request sources (step S26). In the above example, this data is transmitted to the terminal 5. The terminal 5 receives this data and outputs it by a method such as display or printing.

  In this way, the data utilization means 42 receives the table name and the resident ID as input, and based on the records of the resident information table 44 and the bitmap information table 45 corresponding thereto, display data including an external character as an image is received. Create and send. In the display data, the character string data is obtained by removing a portion corresponding to an external character, and the image data is image data corresponding to the external character. By displaying these in combination, the terminals 5 to 7 can perform the same display as when the external characters are defined even if the external characters are not defined for the terminals.

With reference to the flowchart shown in FIG. 8, the flow of processing of the data deleting unit 43 when a deletion request for resident information is received will be described.
First, the data deletion means 43 receives as input the table name and resident ID to be deleted (step S41). Here, as an example, it is assumed that a table name “address table” and a resident ID “00001” are input.
This deletion target input is performed by an operator in the joint system 4, but this may be input by other means. For example, input from the resident information systems 1 to 3 may be received, or input from the terminals 5 to 7 may be received.

Next, the data deletion unit 43 deletes the record having the corresponding resident ID from the corresponding table in the resident information table 44 (step S42). In the above example, the record R1 having the resident ID “00001” in FIG. 5 is deleted.
Next, the data deletion unit 43 deletes the record having the corresponding table name and resident ID from the bitmap information table 45 (step S43). In the above example, the record R2 having the table name “address table” and the resident ID “00001” is deleted in FIG.
As described above, the data deleting unit 43 receives the table name and the resident ID as inputs, and deletes the records of the resident information table 44 and the bitmap information table 45 corresponding thereto.

As described above, according to the present invention, the collaborative system 4 stores the external characters included in the input file in the storage means as an image, and when there is a request to output the external characters from an external system, the external characters Display data including an image corresponding to, and characters other than external characters. For this reason, the requesting terminal only has to display the image and characters as they are, and it is not necessary to define a special font or introduce a special function for each terminal. Therefore, this external character processing system and processing method can eliminate the work that occurs at the terminal in connection with the definition of a new external character.
Further, since it is not necessary to add the definition of the external character at the request source terminal, the display can be performed without depending on the limitation of the number of external characters of the OS. Further, for this reason, when data is diverted from a system having a different external character system, the external character identification work can be made unnecessary.

In the first embodiment described above, the input file is transmitted from the resident information systems 1 to 3 to the joint system 4 via the network 10. For this, other file transmission means may be used, for example, a portable storage medium.
The input file may not be a CSV file as long as the character string data using a common external character code as an external character and the external character image data are associated with each other.
In addition, the resident information systems 1 to 3 may not be related to the local government, and may be a system used by, for example, a company or the like inside or outside.

It is a figure which shows the structure containing the joint system 4 which concerns on Embodiment 1 of this invention. It is a figure which shows the example of an external character. It is a figure which shows the structure of the joint system 4 which concerns on Embodiment 1 of this invention. It is a flowchart which shows the flow of a process of the data taking-in means 41 concerning Embodiment 1 of this invention. It is a figure which shows the structure of the resident information table 44 which concerns on Embodiment 1 of this invention. It is a figure which shows the structure of the bitmap information table 45 concerning Embodiment 1 of this invention. It is a flowchart which shows the flow of a process of the data utilization means 42 which concerns on Embodiment 1 of this invention. It is a flowchart which shows the flow of a process of the data deletion means 43 which concerns on Embodiment 1 of this invention.

Explanation of symbols

  4 external character processing system (joint system), 41 data capturing means, 42 data using means, 43 data deleting means, 44 character string data storing means (resident information table), 45 image data storing means (bitmap information table), R1, R2 records.

Claims (3)

A unique private character codes each of which is defined at a plurality of different systems, and converts to a co Tsugaiji code, a conversion unit,
Character string data storage means for storing character string data including an external character represented by the common external character code;
Image data storage means for storing image data corresponding to the external characters;
Receiving externally input character string data including the external characters and image data corresponding to the external characters, associating them, the character string data in the character string data storage means, and the image data in the character data Data capture means for storing in the image data storage means;
In response to an output request from the outside, data utilization means for creating display data based on the character string data and the image data stored in association with each other, wherein the display data is the data Data utilization means including character string data of character string data excluding external characters and image data corresponding to the external characters;
In response to an external deletion request, the data deletion means for deleting the character string data and the image data stored in association with each other, and
The character string data storage means and the image data storage means store the character string data and the image data by a structure including a two-dimensional table format table represented by a record and a column, respectively.
The data fetching means, when associating the character string data and the image data, a table name that uniquely identifies the table in the character string data storage means, and an ID that uniquely identifies the record in the table A system for processing an external character using a column name that uniquely identifies the column in the record, and a character position at which the external character is included in the column.   The external character processing system according to claim 1, wherein the external output request includes the table name and the ID. A unique private character codes each of which is defined at a plurality of different systems, and converts to a co Tsugaiji code,
Receiving character string data including an external character represented by the common external character code and image data corresponding to the external character, storing them in association with each other,
In response to an output request from the outside, based on the character string data and the image data stored in association with each other, character string data of the character string data excluding an external character and image data corresponding to the external character Create display data including and
In the external character processing method for deleting the character string data and the image data stored in association with each other based on an external deletion request,
The character string data and the image data are stored in a structure including a two-dimensional table format table represented by a record and a column, respectively.
When associating the character string data and the image data, a table name that uniquely identifies the table within the character string data storage means, an ID that uniquely identifies the record within the table, and a unique identifier within the record An external character processing method in which a column name for specifying the column and a character position including the external character in the column are used.

Images