通信端末
【課題】 ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルに起因する変換エラーの発生をなくし、円滑なファイル交換が行える通信端末を提供する。
【解決手段】 ＵＮＩＣＯＤＥのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコード「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）を削除する（ステップＳ１）。残った文字コードで構成されるＵＮＩＣＯＤＥのファイル名を変換処理部３の入力として設定し（Ｓ４）、変換処理（Ｓ５）をコールする。変換処理（Ｓ５）は、市販の変換処理ユニットであり、変換テーブルＡを備えている。変換処理（Ｓ５）では、入力されたファイル名を変換テーブルＡにより変換処理を行い、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ７）。
【解決手段】 ＵＮＩＣＯＤＥのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコード「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）を削除する（ステップＳ１）。残った文字コードで構成されるＵＮＩＣＯＤＥのファイル名を変換処理部３の入力として設定し（Ｓ４）、変換処理（Ｓ５）をコールする。変換処理（Ｓ５）は、市販の変換処理ユニットであり、変換テーブルＡを備えている。変換処理（Ｓ５）では、入力されたファイル名を変換テーブルＡにより変換処理を行い、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ７）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、赤外線通信でのファイル交換において、ＵＮＩＣＯＤＥで定義されたファイル名を受信してＳ−ＪＩＳコードに変換する通信端末に関する。
【背景技術】
【０００２】
（背景技術１）
文字総数の多いＵＮＩＣＯＤＥ体系から、文字総数の少ないＪＩＳコード体系へフォントを自動的に切り換えて印刷する文字印刷方法がある（例えば、特許文献１参照。）。
この特許文献１では、ＵＮＩＣＯＤＥ体系からＪＩＳコード体系への変換にあって、変換がうまくいかない時には、予め指定してある近似のイメージフォントのＪＩＳコードへの変換や、特定のＪＩＳコード「ＦＦＦＦ」への変換により、何らかの変換が行われている。
【０００３】
（背景技術２）
赤外線通信でファイル交換を行う通信端末がある。赤外線通信規格では、ＵＮＩＣＯＤＥを使用することが決められている。通信端末の内部は、ファイル名管理や表示などの文字コードはＳ−ＪＩＳコード（シフトＪＩＳコード。簡易ＪＩＳコード）が使用される。そのため、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換を行っている。
Ｓ−ＪＩＳコードは、日本国内で主に使われる文字や記号について定義された独自コードである。ＵＮＩＣＯＤＥは、日本も包含した世界で使われる膨大な文字や記号について定義された独自コードであり、用途に応じて文字数を限定したＵＮＩＣＯＤＥ規格が複数存在する。ところが、赤外線通信規格では、どのＵＮＩＣＯＤＥ規格を使用するかは規定されていない。
【０００４】
図７は、一般的なＳ−ＪＩＳコードとＵＮＩＣＯＤＥ規格の対応を示す文字コード表であり、一部の文字と記号について図示している。１０１欄に文字と記号を示し、１０２欄にＳ−ＪＩＳコード規格、１０３欄にＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」、１０４欄にＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」を示す。
定義する文字や記号の内、一部の特殊な記号については、類似の複数の記号がある。例えば記号「〜」は、Ｓ−ＪＩＳコードでは、１種類であり、「０ｘ８１６０」で定義されている。ＵＮＩＣＯＤＥでは２種類あり、１つは、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」の「０ｘ３０１Ｃ」で定義したWave Dashと称する「〜」がある。また、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」の「０ｘＦＦ５Ｅ」で定義したFullwidth Tildeと称する「〜」がある。
定義する文字や記号の内、一律に特定できる「？」、「あ」、「ａ」等の標準的な文字記号は、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」と「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」で同じコード番号が定義されている。
これらのＳ−ＪＩＳコードとＵＮＩＣＯＤＥ間の変換テーブルが各種市販されているが、文字記号によって、図７のコード表のどの部分をカバーしているかにより、変換エラーが発生するなどの問題があった。
【特許文献１】特開２００２−２０３２号公報（第３〜４頁、図２、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来の背景技術２の通信端末では、変換エラーが発生した場合に、ファイル交換を行えないという問題があり、これは変換テーブルに起因しておりユーザに責任がなくても発生し、ユーザから苦情を受ける恐れもある。また、変換エラーが発生した時の対策として、背景技術１のように何らかの変換を行うことも考えられるが、変換手段が増えるという問題があった。
【０００６】
本発明は、上記の問題点を解決するためになされたもので、通信端末において、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルに起因する変換エラーの発生をなくし、円滑なファイル交換が行える通信端末を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明の通信端末は、第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを削除して残りの文字列のファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを具備することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、通信端末は、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定されている変換不可能ＵＮＩＣＯＤＥをファイル名から削除するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の各実施例を、図面を参照して説明する。
図１は、本発明の各実施例に係る通信端末の構成図である。通信端末は、図示しない他の装置との間で赤外線通信により、ファイル交換等のデータ通信を行う。この赤外線通信規格では、文字コードは、ＵＮＩＣＯＤＥを使用することが決められているが、複数のＵＮＩＣＯＤＥ規格のどの規格を使うか、また、複数のＵＮＩＣＯＤＥ規格をどこまで重複してカバーするかなどは規定されていない。一方、通信端末の内部のファイル名や表示などの文字コードはＳ−ＪＩＳコード（シフトＪＩＳコード。簡易ＪＩＳコード）が使用される。
【００１０】
通信端末の構成について以下に説明する。通信端末は、赤外線通信部１、ファイル制御部２、変換不可能ＵＮＩＣＯＤＥ記憶部２１、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２、変換処理部３、ＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１、ファイル管理部４、ファイル記憶部５などによって構成される。変換処理部３は、市販されている変換処理ユニットであり、内蔵しているＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１の種類は、以降変換テーブルＡと称する。この内、変換不可能ＵＮＩＣＯＤＥ記憶部２１は後述の実施例１と実施例２で使用する。また、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２は後述の実施例２で使用する。
【００１１】
赤外線通信部１は、図示しない他の装置との間で赤外線通信により、ファイル交換等のデータ通信を行う。ファイル交換でのファイルは、ファイル名等を含むヘッダーと、ファイル本文とから構成され、それらの文字はＵＮＩＣＯＤＥで定義されている。
他の装置からファイルを受信するときの動作について説明する。赤外線通信部１は他の装置からファイルを受信し、ファイル制御部２へ送出する。ファイル制御部２は、受信したファイルからファイル名を取り出して、ＵＮＩＣＯＤＥのファイル名を変換処理部３へ送出する。変換処理部３は、変換テーブルＡなる種別のＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１を参照して、ＵＮＩＣＯＤＥのファイル名をＳ−ＪＩＳコードのファイル名に変換し、変換後のＳ−ＪＩＳコードのファイル名をファイル制御部２へ返す。ファイル制御部２はこれをファイル管理部４へ送る。ファイル管理部４は、Ｓ−ＪＩＳコードのファイル名とファイル本文とを対応付けて、ファイル記憶部５に記憶させる。ファイル制御部２は、必要に応じて、Ｓ−ＪＩＳコードのファイル名とファイル本文を図示しない表示部に表示する。
【００１２】
他の装置へファイルを送信するときの動作について説明する。ファイル制御部２は、ファイル管理部４から、送信するファイル名（Ｓ−ＪＩＳコード）とファイル本文を入手する。そして、ファイル制御部２は、Ｓ−ＪＩＳコードのファイル名を変換処理部３へ送出する。変換処理部３は、変換テーブルＡなる種別のＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１を参照して、Ｓ−ＪＩＳコードのファイル名をＵＮＩＣＯＤＥのファイル名に変換し、変換後のＵＮＩＣＯＤＥのファイル名をファイル制御部２へ返す。ファイル制御部２はこのＵＮＩＣＯＤＥのファイル名とファイル本文とから構成されるファイルを赤外線通信部１へ送出する。赤外線通信部１は、このファイルを他の装置へ送信する。
【００１３】
図２は、本発明の各実施例に係る変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を説明する図である。図７で説明した文字コード表に対して、変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を示す。１０１欄に文字と記号を示し、１０２欄にＳ−ＪＩＳコード規格、１０３欄にＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」、１０４欄にＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」を示す。
定義する文字や記号の内、一部の特殊な記号については、類似の複数の記号がある。例えば記号「〜」は、Ｓ−ＪＩＳコードでは、１種類であり、「０ｘ８１６０」で定義されている。ＵＮＩＣＯＤＥでは２種類あり、１つは、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」の「０ｘ３０１Ｃ」で定義したWave Dashと称する「〜」がある。また、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」の「０ｘＦＦ５Ｅ」で定義したFullwidth Tildeと称する「〜」がある。他の「‖」、「−」、「＼」、「¢」、「£」等についても、類似の記号が存在する。一律に特定できる「？」、「あ」、「ａ」等の標準的な文字記号は、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」と「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」で同じコード番号が定義されている。
【００１４】
これらのＳ−ＪＩＳコードとＵＮＩＣＯＤＥ間の変換テーブルが各種市販されており、その１つである変換テーブルＡがカバーしている範囲をハッチングで図示する。変換テーブルＡは、Ｓ−ＪＩＳで定義された文字と記号のほとんどについて、両方のＵＮＩＣＯＤＥ規格に対応しているが、一部の記号「〜」、「‖」、「−」については、１０３欄のＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」しか対応していない。これは、記号「〜」、「‖」、「−」については、ＵＮＩＣＯＤＥで定義された類似の記号を、Ｓ−ＪＩＳコードで定義した記号にどう対応付けるかの解釈が変換テーブルの種類によって色々あることを意味する。記号「＼」、「¢」、「£」等についても、類似の記号が存在するが、市販の変換テーブルでは、両方のＵＮＩＣＯＤＥ規格に対応しているものが多い。
【００１５】
そのため、例えば、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」のＵＮＩＣＯＤＥを受信して、変換テーブルＡによりＳ−ＪＩＳコードに変換する場合、変換テーブルＡには１０４欄のＵＮＩＣＯＤＥ「０ｘＦＦ５Ｅ」（「〜」）、「０ｘ２２２５」（「‖」）、「０ｘＦＦ０Ｄ」（「−」）が存在しないため、変換不可能である。この変換テーブルＡに存在しない１０４欄のＵＮＩＣＯＤＥ「０ｘＦＦ５Ｅ」（「〜」）、「０ｘ２２２５」（「‖」）、「０ｘＦＦ０Ｄ」（「−」）を予め、変換不可能ＵＮＩＣＯＤＥ記憶部２１に格納しておく。
【００１６】
図２では特定の例について、説明したが、一般的な定義について、以下に説明する。変換テーブルＡは、ＵＮＩＣＯＤＥ−ＳＪＩＳ間の変換に限定しない。変換テーブルＡは、複数の規格の存在する第１の文字コード（ＵＮＩＣＯＤＥなど）と１種類に限定した第２の文字コード（Ｓ−ＪＩＳコードなど）間の変換テーブルである。そして、第１の文字コード（ＵＮＩＣＯＤＥなど）については、すべての複数の規格に対応する必要はなくて、例えば、日本国内で使用する当該通信端末の赤外線通信というアプリケーションで一般的に使用されるＵＮＩＣＯＤＥ規格をピックアップすればよい。そして、ピックアップした複数の規格の第１の文字コード（ＵＮＩＣＯＤＥなど）の内、変換テーブルＡが備えていないＵＮＩＣＯＤＥを予め、変換不可能ＵＮＩＣＯＤＥとして、変換不可能ＵＮＩＣＯＤＥ記憶部２１に格納しておく。
【００１７】
なお、第１の文字コード（ＵＮＩＣＯＤＥなど）の規格としては、ハングル語やアラビア語等、世界中の多くの規格があり、変換テーブルＡには当然備えていない。従って、変換テーブルＡが備える第２の文字コード（Ｓ−ＪＩＳコードなど）に限定して、対応する第１の文字コード（ＵＮＩＣＯＤＥなど）を判断すればよい。仮に、ハングル語やアラビア語等の第１の文字コード（ＵＮＩＣＯＤＥなど）を受信したとしても、それは、通信端末側に帰する問題ではなく、エラー処理としてよい。
【実施例１】
【００１８】
図３は、実施例１に係る通信端末のファイル制御のフローチャートである。実施例１は、変換する前に、ファイル名から、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格のコードを削除する例である。ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコードがあるかをチェックし、「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）がファイル名に有れば、この文字コードを削除する（ステップＳ１）。変換可能なＵＮＩＣＯＤＥ規格のコード「０ｘ３０１Ｃ」（〜）、「０ｘ２０１６」（‖）、「０ｘ２２１２」（−）については、削除しない。ファイル名を構成する文字コードがすべて削除されてしまったら（Ｓ２でＹＥＳ）、ファイル名がなくなってしまうのでエラー処理を行う（Ｓ３）。すべて削除されたのでなければ（Ｓ２でＮＯ）、残った文字コードで構成されるファイル名とする。そして、このファイル名（ＵＮＩＣＯＤＥ）を変換処理部３の入力として設定して（Ｓ４）、変換処理（Ｓ５）をコールする。
【００１９】
変換処理（Ｓ５）は、市販の変換処理ユニットであり、変換テーブルＡを備えている。変換処理（Ｓ５）では、入力されたファイル名を変換テーブルＡにより変換処理を行い、変換可能な場合（Ｓ６でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ７）。変換できない場合（Ｓ６でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ８）。
【００２０】
ファイル制御部２は、受け取ったＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ９）、含まれていなければ（Ｓ１０で無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ１２）。文字「／」、「？」などが含まれていれば（Ｓ１０で有り）、エラー処理を行う（Ｓ１１）。ここで、含まれている文字「？」には、２通りの意味がある。１つ目は、他の装置から送られてきたファイル名そのものに、文字「？」が有った場合である。２つ目は、変換処理（Ｓ５）において、変換できない文字があったために、変換処理（Ｓ５）の中で文字「？」に変換した場合（Ｓ８）である。
【００２１】
しかし、ステップＳ１において、変換できない可能性のあるＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」を削除しているために、前記２つ目のステップＳ８となることは、ほとんど発生しない。従って、ステップＳ９、Ｓ１０において、文字「／」、「？」などが含まれている場合（Ｓ１０でＹＥＳ）、これは、ほぼ、他の装置から送られてきたファイル名そのものに、ファイル名として使用してはいけない文字「／」、「？」などがあったと判断できる。そのため、エラー処理（Ｓ１１）としても、通信端末の変換性能に起因する問題ではなく、他の装置側でのファイル名の付け方に問題があったということになり、通信端末に対する問題指摘等は発生することはない。
【００２２】
他の装置へＵＮＩＣＯＤＥを送信する場合について説明する。文字「〜」、「‖」、「−」については、自端末がどのようなＵＮＩＣＯＤＥ規格のコードで他の装置へ送信したとしても、これを受信した他の装置次第で変換エラーとなる可能性がある。そのため、自端末はファイル名として、文字「〜」、「‖」、「−」のＳ−ＪＩＳコードが含まれる場合、このＳ−ＪＩＳコードを削除してから、残りの文字をＵＮＩＣＯＤＥに変換する。そしてこれを他の装置へ送信する。これにより、他の装置は、問題となる文字「〜」、「‖」、「−」のＵＮＩＣＯＤＥを受信することはないため、エラーが発生することはない。
【００２３】
なお、変換テーブルＡとして、図２のハッチング部分を例示したが、これに限らず、通信端末に搭載した変換テーブルのカバー範囲により、カバーしていないＵＮＩＣＯＤＥを予め記憶しておくことにより、どのような変換テーブルにも対応することが可能である。
【００２４】
実施例１によれば、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定されている変換不可能ＵＮＩＣＯＤＥをファイル名から削除するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
また、送信時、変換エラーが起こり得る可能性のある文字「〜」、「‖」、「−」のＳ−ＪＩＳコードを予め削除してから、残りをＵＮＩＣＯＤＥに変換して、他の装置へ送信することにより、他の装置でのエラー発生を防止することができる。
【実施例２】
【００２５】
図４は、実施例２に係る通信端末のファイル制御のフローチャートである。実施例２は、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードを、予め設定してある変換可能なＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードに変換する例である。
ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコードがあるかをチェックする。そして、「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）がファイル名に有れば、この文字コードを、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２を参照して、「０ｘ３０１Ｃ」（〜）、「０ｘ２０１６」（‖）、「０ｘ２２１２」（−）に変換する（Ｓ２１）。そして、このファイル名（ＵＮＩＣＯＤＥ）を変換処理部３の入力として設定して（Ｓ２４）、変換処理（Ｓ２５）をコールする。変換処理（Ｓ２５）は、実施例１、図３の変換処理（Ｓ５）と同じ処理であるが、与えられた入力がすでに変換できるＵＮＩＣＯＤＥであるため、「〜」、「‖」、「−」をＳ−ＪＩＳコードに変換して出力する。
【００２６】
ファイル制御部２は、受け取ったＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ２９）、含まれていなければ（Ｓ３０で無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ３２）。文字「／」、「？」などが含まれていれば（Ｓ３０で有り）、エラー処理を行う（Ｓ３１）。
【００２７】
なお、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルＡとして、図２のハッチング部分を例示したが、これに限らず、通信端末に搭載した変換テーブルのカバー範囲により、カバーしていないＵＮＩＣＯＤＥと、当該ＵＮＩＣＯＤＥについてのＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブルを予め備えておくことにより、どのようなＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルにも対応することが可能である。
【００２８】
実施例２によれば、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードを、予め設定してある変換可能なＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードに変換するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【実施例３】
【００２９】
図５は、実施例３に係る通信端末のファイル制御のフローチャートである。実施例３は、変換処理を行った後で、変換不可能な文字を削除する例である。ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名を変換処理部３の入力として設定して（Ｓ４１）、変換処理（Ｓ４２）をコールする。この変換処理（Ｓ４２）は、実施例１の図４の変換処理（Ｓ５）と同じ処理の市販の変換処理ユニットであるが、変換テーブルの種類は限定しない。変換処理（Ｓ４２）では、入力されたファイル名を変換テーブルにより変換処理を行い、変換可能な場合（Ｓ４３でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ４４）。変換できない場合（Ｓ４３でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ４５）。
【００３０】
ファイル制御部２は、出力されたＳ−ＪＩＳコードのファイル名が文字「？」である場合、この出力に該当する変換処理（Ｓ４２）の入力文字（ＵＮＩＣＯＤＥ）をチェックする（Ｓ４６）。そして、Ｓ４７でＵＮＩＣＯＤＥの当該入力文字が「？」以外であれば、変換できなかったために出力がＳ−ＪＩＳコードの「？」になったと判断して、当該出力のＳ−ＪＩＳコードの「？」を削除する（Ｓ４８）。これは、変換した結果、変換できなかった文字を自動で削除するものである。従って、変換テーブルの種類によっては、文字「〜」、「‖」、「−」以外の変換できない文字も見逃すことなく、削除することができる。
Ｓ４７でＵＮＩＣＯＤＥの入力文字が「？」の場合は、図２に示すように、ＵＮＩＣＯＤＥの「？」は確実にＳ−ＪＩＳコードに変換できることがわかっているので、入力文字そのものが「？」であると判断して、削除せずに次のＳ４９へ進む。
【００３１】
そして、出力されたＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ４９）、含まれていなければ（Ｓ５０で、無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ５２）。文字「／」、「？」などが含まれていれば（Ｓ５０で、有り）、エラー処理を行う（Ｓ５１）。
【００３２】
実施例２によれば、変換できない文字を予め決めておく必要がない。そして、変換テーブルの種類が何であっても、変換できない文字を見逃すことなく、削除することができる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【実施例４】
【００３３】
図６は、実施例４に係る通信端末のファイル制御のフローチャートである。実施例４は、変換処理ユニットに変更を加えて、変換処理ユニットが変換ステータスを出力する。そして、ファイル制御部は、変換処理ユニットが変換処理を行った後で、変換不可能な文字を削除する例である。
ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名を変換処理部３の入力として設定して（Ｓ６１）、変換処理（Ｓ６２）をコールする。この変換処理（Ｓ６２）は、市販の変換処理ユニットに変更を加えている。変換テーブルの種類は限定しない。変換処理（Ｓ６２）では、入力されたファイル名を変換テーブルにより変換処理を行い、変換可能な場合（Ｓ６３でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ６４）。そして、変換ステータスを「正常」にして出力する（Ｓ６５）。変換できない場合（Ｓ６３でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ６６）。そして、変換ステータスを「異常」にして出力する（Ｓ６７）。
【００３４】
ファイル制御部２は、出力された変換ステータスが異常の場合（Ｓ６８で異常）、当該変換出力のＳ−ＪＩＳコードの「？」を削除する（Ｓ６９）。なお、この削除は、変換処理ユニットの中のステップＳ６６において削除処理を行ってもよい。その場合、ファイル制御部２のステップＳ６９の削除は不要となる。一般に、変換処理ユニットは、変換処理と変換ステータスを出力し、後の削除等の処理は、変換処理ユニットを使う側のファイル制御部に任せるのが普通であろう。
【００３５】
次に、出力されたＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ７０）、含まれていなければ（Ｓ７１で、無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ７３）。文字「／」、「？」などが含まれていれば（Ｓ７１で、有り）、エラー処理を行う（Ｓ７２）。
【００３６】
実施例３によれば、予め、変換できない文字を決めておく必要がない。そして、変換テーブルの種類が何であっても、変換できない文字を見逃すことなく、削除することができる。
なお、各実施例は、赤外線通信を行う通信端末について実施例を示したが、第１の文字コードと第２の文字コード間の変換を行う装置にも適用できる。
【図面の簡単な説明】
【００３７】
【図１】本発明の各実施例に係る通信端末の構成図。
【図２】本発明の各実施例に係る変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を説明する図。
【図３】実施例１に係る通信端末のファイル制御のフローチャート。
【図４】実施例２に係る通信端末のファイル制御のフローチャート。
【図５】実施例３に係る通信端末のファイル制御のフローチャート。
【図６】実施例４に係る通信端末のファイル制御のフローチャート。
【図７】一般的なＳ−ＪＩＳコードとＵＮＩＣＯＤＥ規格の対応を示す文字コード表。
【符号の説明】
【００３８】
１ 赤外線通信部
２ ファイル制御部
２１ 変換不可能ＵＮＩＣＯＤＥ記憶部
２２ ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル
３ 変換処理部
３１ 変換テーブル
４ ファイル管理部
５ ファイル記憶部
１０１ 文字
１０２ Ｓ−ＪＩＳコード
１０３ ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」
１０４ ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」
【技術分野】
【０００１】
本発明は、赤外線通信でのファイル交換において、ＵＮＩＣＯＤＥで定義されたファイル名を受信してＳ−ＪＩＳコードに変換する通信端末に関する。
【背景技術】
【０００２】
（背景技術１）
文字総数の多いＵＮＩＣＯＤＥ体系から、文字総数の少ないＪＩＳコード体系へフォントを自動的に切り換えて印刷する文字印刷方法がある（例えば、特許文献１参照。）。
この特許文献１では、ＵＮＩＣＯＤＥ体系からＪＩＳコード体系への変換にあって、変換がうまくいかない時には、予め指定してある近似のイメージフォントのＪＩＳコードへの変換や、特定のＪＩＳコード「ＦＦＦＦ」への変換により、何らかの変換が行われている。
【０００３】
（背景技術２）
赤外線通信でファイル交換を行う通信端末がある。赤外線通信規格では、ＵＮＩＣＯＤＥを使用することが決められている。通信端末の内部は、ファイル名管理や表示などの文字コードはＳ−ＪＩＳコード（シフトＪＩＳコード。簡易ＪＩＳコード）が使用される。そのため、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換を行っている。
Ｓ−ＪＩＳコードは、日本国内で主に使われる文字や記号について定義された独自コードである。ＵＮＩＣＯＤＥは、日本も包含した世界で使われる膨大な文字や記号について定義された独自コードであり、用途に応じて文字数を限定したＵＮＩＣＯＤＥ規格が複数存在する。ところが、赤外線通信規格では、どのＵＮＩＣＯＤＥ規格を使用するかは規定されていない。
【０００４】
図７は、一般的なＳ−ＪＩＳコードとＵＮＩＣＯＤＥ規格の対応を示す文字コード表であり、一部の文字と記号について図示している。１０１欄に文字と記号を示し、１０２欄にＳ−ＪＩＳコード規格、１０３欄にＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」、１０４欄にＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」を示す。
定義する文字や記号の内、一部の特殊な記号については、類似の複数の記号がある。例えば記号「〜」は、Ｓ−ＪＩＳコードでは、１種類であり、「０ｘ８１６０」で定義されている。ＵＮＩＣＯＤＥでは２種類あり、１つは、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」の「０ｘ３０１Ｃ」で定義したWave Dashと称する「〜」がある。また、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」の「０ｘＦＦ５Ｅ」で定義したFullwidth Tildeと称する「〜」がある。
定義する文字や記号の内、一律に特定できる「？」、「あ」、「ａ」等の標準的な文字記号は、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」と「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」で同じコード番号が定義されている。
これらのＳ−ＪＩＳコードとＵＮＩＣＯＤＥ間の変換テーブルが各種市販されているが、文字記号によって、図７のコード表のどの部分をカバーしているかにより、変換エラーが発生するなどの問題があった。
【特許文献１】特開２００２−２０３２号公報（第３〜４頁、図２、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来の背景技術２の通信端末では、変換エラーが発生した場合に、ファイル交換を行えないという問題があり、これは変換テーブルに起因しておりユーザに責任がなくても発生し、ユーザから苦情を受ける恐れもある。また、変換エラーが発生した時の対策として、背景技術１のように何らかの変換を行うことも考えられるが、変換手段が増えるという問題があった。
【０００６】
本発明は、上記の問題点を解決するためになされたもので、通信端末において、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルに起因する変換エラーの発生をなくし、円滑なファイル交換が行える通信端末を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明の通信端末は、第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを削除して残りの文字列のファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを具備することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、通信端末は、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定されている変換不可能ＵＮＩＣＯＤＥをファイル名から削除するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の各実施例を、図面を参照して説明する。
図１は、本発明の各実施例に係る通信端末の構成図である。通信端末は、図示しない他の装置との間で赤外線通信により、ファイル交換等のデータ通信を行う。この赤外線通信規格では、文字コードは、ＵＮＩＣＯＤＥを使用することが決められているが、複数のＵＮＩＣＯＤＥ規格のどの規格を使うか、また、複数のＵＮＩＣＯＤＥ規格をどこまで重複してカバーするかなどは規定されていない。一方、通信端末の内部のファイル名や表示などの文字コードはＳ−ＪＩＳコード（シフトＪＩＳコード。簡易ＪＩＳコード）が使用される。
【００１０】
通信端末の構成について以下に説明する。通信端末は、赤外線通信部１、ファイル制御部２、変換不可能ＵＮＩＣＯＤＥ記憶部２１、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２、変換処理部３、ＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１、ファイル管理部４、ファイル記憶部５などによって構成される。変換処理部３は、市販されている変換処理ユニットであり、内蔵しているＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１の種類は、以降変換テーブルＡと称する。この内、変換不可能ＵＮＩＣＯＤＥ記憶部２１は後述の実施例１と実施例２で使用する。また、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２は後述の実施例２で使用する。
【００１１】
赤外線通信部１は、図示しない他の装置との間で赤外線通信により、ファイル交換等のデータ通信を行う。ファイル交換でのファイルは、ファイル名等を含むヘッダーと、ファイル本文とから構成され、それらの文字はＵＮＩＣＯＤＥで定義されている。
他の装置からファイルを受信するときの動作について説明する。赤外線通信部１は他の装置からファイルを受信し、ファイル制御部２へ送出する。ファイル制御部２は、受信したファイルからファイル名を取り出して、ＵＮＩＣＯＤＥのファイル名を変換処理部３へ送出する。変換処理部３は、変換テーブルＡなる種別のＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１を参照して、ＵＮＩＣＯＤＥのファイル名をＳ−ＪＩＳコードのファイル名に変換し、変換後のＳ−ＪＩＳコードのファイル名をファイル制御部２へ返す。ファイル制御部２はこれをファイル管理部４へ送る。ファイル管理部４は、Ｓ−ＪＩＳコードのファイル名とファイル本文とを対応付けて、ファイル記憶部５に記憶させる。ファイル制御部２は、必要に応じて、Ｓ−ＪＩＳコードのファイル名とファイル本文を図示しない表示部に表示する。
【００１２】
他の装置へファイルを送信するときの動作について説明する。ファイル制御部２は、ファイル管理部４から、送信するファイル名（Ｓ−ＪＩＳコード）とファイル本文を入手する。そして、ファイル制御部２は、Ｓ−ＪＩＳコードのファイル名を変換処理部３へ送出する。変換処理部３は、変換テーブルＡなる種別のＵＮＩＣＯＤＥ−ＳＪＩＳ変換テーブル３１を参照して、Ｓ−ＪＩＳコードのファイル名をＵＮＩＣＯＤＥのファイル名に変換し、変換後のＵＮＩＣＯＤＥのファイル名をファイル制御部２へ返す。ファイル制御部２はこのＵＮＩＣＯＤＥのファイル名とファイル本文とから構成されるファイルを赤外線通信部１へ送出する。赤外線通信部１は、このファイルを他の装置へ送信する。
【００１３】
図２は、本発明の各実施例に係る変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を説明する図である。図７で説明した文字コード表に対して、変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を示す。１０１欄に文字と記号を示し、１０２欄にＳ−ＪＩＳコード規格、１０３欄にＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」、１０４欄にＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」を示す。
定義する文字や記号の内、一部の特殊な記号については、類似の複数の記号がある。例えば記号「〜」は、Ｓ−ＪＩＳコードでは、１種類であり、「０ｘ８１６０」で定義されている。ＵＮＩＣＯＤＥでは２種類あり、１つは、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」の「０ｘ３０１Ｃ」で定義したWave Dashと称する「〜」がある。また、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」の「０ｘＦＦ５Ｅ」で定義したFullwidth Tildeと称する「〜」がある。他の「‖」、「−」、「＼」、「¢」、「£」等についても、類似の記号が存在する。一律に特定できる「？」、「あ」、「ａ」等の標準的な文字記号は、ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」と「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」で同じコード番号が定義されている。
【００１４】
これらのＳ−ＪＩＳコードとＵＮＩＣＯＤＥ間の変換テーブルが各種市販されており、その１つである変換テーブルＡがカバーしている範囲をハッチングで図示する。変換テーブルＡは、Ｓ−ＪＩＳで定義された文字と記号のほとんどについて、両方のＵＮＩＣＯＤＥ規格に対応しているが、一部の記号「〜」、「‖」、「−」については、１０３欄のＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」しか対応していない。これは、記号「〜」、「‖」、「−」については、ＵＮＩＣＯＤＥで定義された類似の記号を、Ｓ−ＪＩＳコードで定義した記号にどう対応付けるかの解釈が変換テーブルの種類によって色々あることを意味する。記号「＼」、「¢」、「£」等についても、類似の記号が存在するが、市販の変換テーブルでは、両方のＵＮＩＣＯＤＥ規格に対応しているものが多い。
【００１５】
そのため、例えば、ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」のＵＮＩＣＯＤＥを受信して、変換テーブルＡによりＳ−ＪＩＳコードに変換する場合、変換テーブルＡには１０４欄のＵＮＩＣＯＤＥ「０ｘＦＦ５Ｅ」（「〜」）、「０ｘ２２２５」（「‖」）、「０ｘＦＦ０Ｄ」（「−」）が存在しないため、変換不可能である。この変換テーブルＡに存在しない１０４欄のＵＮＩＣＯＤＥ「０ｘＦＦ５Ｅ」（「〜」）、「０ｘ２２２５」（「‖」）、「０ｘＦＦ０Ｄ」（「−」）を予め、変換不可能ＵＮＩＣＯＤＥ記憶部２１に格納しておく。
【００１６】
図２では特定の例について、説明したが、一般的な定義について、以下に説明する。変換テーブルＡは、ＵＮＩＣＯＤＥ−ＳＪＩＳ間の変換に限定しない。変換テーブルＡは、複数の規格の存在する第１の文字コード（ＵＮＩＣＯＤＥなど）と１種類に限定した第２の文字コード（Ｓ−ＪＩＳコードなど）間の変換テーブルである。そして、第１の文字コード（ＵＮＩＣＯＤＥなど）については、すべての複数の規格に対応する必要はなくて、例えば、日本国内で使用する当該通信端末の赤外線通信というアプリケーションで一般的に使用されるＵＮＩＣＯＤＥ規格をピックアップすればよい。そして、ピックアップした複数の規格の第１の文字コード（ＵＮＩＣＯＤＥなど）の内、変換テーブルＡが備えていないＵＮＩＣＯＤＥを予め、変換不可能ＵＮＩＣＯＤＥとして、変換不可能ＵＮＩＣＯＤＥ記憶部２１に格納しておく。
【００１７】
なお、第１の文字コード（ＵＮＩＣＯＤＥなど）の規格としては、ハングル語やアラビア語等、世界中の多くの規格があり、変換テーブルＡには当然備えていない。従って、変換テーブルＡが備える第２の文字コード（Ｓ−ＪＩＳコードなど）に限定して、対応する第１の文字コード（ＵＮＩＣＯＤＥなど）を判断すればよい。仮に、ハングル語やアラビア語等の第１の文字コード（ＵＮＩＣＯＤＥなど）を受信したとしても、それは、通信端末側に帰する問題ではなく、エラー処理としてよい。
【実施例１】
【００１８】
図３は、実施例１に係る通信端末のファイル制御のフローチャートである。実施例１は、変換する前に、ファイル名から、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格のコードを削除する例である。ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコードがあるかをチェックし、「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）がファイル名に有れば、この文字コードを削除する（ステップＳ１）。変換可能なＵＮＩＣＯＤＥ規格のコード「０ｘ３０１Ｃ」（〜）、「０ｘ２０１６」（‖）、「０ｘ２２１２」（−）については、削除しない。ファイル名を構成する文字コードがすべて削除されてしまったら（Ｓ２でＹＥＳ）、ファイル名がなくなってしまうのでエラー処理を行う（Ｓ３）。すべて削除されたのでなければ（Ｓ２でＮＯ）、残った文字コードで構成されるファイル名とする。そして、このファイル名（ＵＮＩＣＯＤＥ）を変換処理部３の入力として設定して（Ｓ４）、変換処理（Ｓ５）をコールする。
【００１９】
変換処理（Ｓ５）は、市販の変換処理ユニットであり、変換テーブルＡを備えている。変換処理（Ｓ５）では、入力されたファイル名を変換テーブルＡにより変換処理を行い、変換可能な場合（Ｓ６でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ７）。変換できない場合（Ｓ６でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ８）。
【００２０】
ファイル制御部２は、受け取ったＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ９）、含まれていなければ（Ｓ１０で無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ１２）。文字「／」、「？」などが含まれていれば（Ｓ１０で有り）、エラー処理を行う（Ｓ１１）。ここで、含まれている文字「？」には、２通りの意味がある。１つ目は、他の装置から送られてきたファイル名そのものに、文字「？」が有った場合である。２つ目は、変換処理（Ｓ５）において、変換できない文字があったために、変換処理（Ｓ５）の中で文字「？」に変換した場合（Ｓ８）である。
【００２１】
しかし、ステップＳ１において、変換できない可能性のあるＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」を削除しているために、前記２つ目のステップＳ８となることは、ほとんど発生しない。従って、ステップＳ９、Ｓ１０において、文字「／」、「？」などが含まれている場合（Ｓ１０でＹＥＳ）、これは、ほぼ、他の装置から送られてきたファイル名そのものに、ファイル名として使用してはいけない文字「／」、「？」などがあったと判断できる。そのため、エラー処理（Ｓ１１）としても、通信端末の変換性能に起因する問題ではなく、他の装置側でのファイル名の付け方に問題があったということになり、通信端末に対する問題指摘等は発生することはない。
【００２２】
他の装置へＵＮＩＣＯＤＥを送信する場合について説明する。文字「〜」、「‖」、「−」については、自端末がどのようなＵＮＩＣＯＤＥ規格のコードで他の装置へ送信したとしても、これを受信した他の装置次第で変換エラーとなる可能性がある。そのため、自端末はファイル名として、文字「〜」、「‖」、「−」のＳ−ＪＩＳコードが含まれる場合、このＳ−ＪＩＳコードを削除してから、残りの文字をＵＮＩＣＯＤＥに変換する。そしてこれを他の装置へ送信する。これにより、他の装置は、問題となる文字「〜」、「‖」、「−」のＵＮＩＣＯＤＥを受信することはないため、エラーが発生することはない。
【００２３】
なお、変換テーブルＡとして、図２のハッチング部分を例示したが、これに限らず、通信端末に搭載した変換テーブルのカバー範囲により、カバーしていないＵＮＩＣＯＤＥを予め記憶しておくことにより、どのような変換テーブルにも対応することが可能である。
【００２４】
実施例１によれば、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定されている変換不可能ＵＮＩＣＯＤＥをファイル名から削除するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
また、送信時、変換エラーが起こり得る可能性のある文字「〜」、「‖」、「−」のＳ−ＪＩＳコードを予め削除してから、残りをＵＮＩＣＯＤＥに変換して、他の装置へ送信することにより、他の装置でのエラー発生を防止することができる。
【実施例２】
【００２５】
図４は、実施例２に係る通信端末のファイル制御のフローチャートである。実施例２は、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードを、予め設定してある変換可能なＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードに変換する例である。
ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名部分の文字について、変換不可能ＵＮＩＣＯＤＥ記憶部２１に予め格納されている変換不可能ＵＮＩＣＯＤＥ規格のコードがあるかをチェックする。そして、「０ｘＦＦ５Ｅ」（〜）、「０ｘ２２２５」（‖）、「０ｘＦＦ０Ｄ」（−）がファイル名に有れば、この文字コードを、ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル２２を参照して、「０ｘ３０１Ｃ」（〜）、「０ｘ２０１６」（‖）、「０ｘ２２１２」（−）に変換する（Ｓ２１）。そして、このファイル名（ＵＮＩＣＯＤＥ）を変換処理部３の入力として設定して（Ｓ２４）、変換処理（Ｓ２５）をコールする。変換処理（Ｓ２５）は、実施例１、図３の変換処理（Ｓ５）と同じ処理であるが、与えられた入力がすでに変換できるＵＮＩＣＯＤＥであるため、「〜」、「‖」、「−」をＳ−ＪＩＳコードに変換して出力する。
【００２６】
ファイル制御部２は、受け取ったＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ２９）、含まれていなければ（Ｓ３０で無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ３２）。文字「／」、「？」などが含まれていれば（Ｓ３０で有り）、エラー処理を行う（Ｓ３１）。
【００２７】
なお、ＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルＡとして、図２のハッチング部分を例示したが、これに限らず、通信端末に搭載した変換テーブルのカバー範囲により、カバーしていないＵＮＩＣＯＤＥと、当該ＵＮＩＣＯＤＥについてのＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブルを予め備えておくことにより、どのようなＵＮＩＣＯＤＥとＳ−ＪＩＳコード間の変換テーブルにも対応することが可能である。
【００２８】
実施例２によれば、ファイル名をＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換する前に、予め設定してある変換不可能ＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードを、予め設定してある変換可能なＵＮＩＣＯＤＥ規格の「〜」、「‖」、「−」コードに変換するという簡単な処理により、変換エラーの発生を防ぐことが可能になり、ファイル交換が停止してしまうことを防止することが可能となる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【実施例３】
【００２９】
図５は、実施例３に係る通信端末のファイル制御のフローチャートである。実施例３は、変換処理を行った後で、変換不可能な文字を削除する例である。ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名を変換処理部３の入力として設定して（Ｓ４１）、変換処理（Ｓ４２）をコールする。この変換処理（Ｓ４２）は、実施例１の図４の変換処理（Ｓ５）と同じ処理の市販の変換処理ユニットであるが、変換テーブルの種類は限定しない。変換処理（Ｓ４２）では、入力されたファイル名を変換テーブルにより変換処理を行い、変換可能な場合（Ｓ４３でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ４４）。変換できない場合（Ｓ４３でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ４５）。
【００３０】
ファイル制御部２は、出力されたＳ−ＪＩＳコードのファイル名が文字「？」である場合、この出力に該当する変換処理（Ｓ４２）の入力文字（ＵＮＩＣＯＤＥ）をチェックする（Ｓ４６）。そして、Ｓ４７でＵＮＩＣＯＤＥの当該入力文字が「？」以外であれば、変換できなかったために出力がＳ−ＪＩＳコードの「？」になったと判断して、当該出力のＳ−ＪＩＳコードの「？」を削除する（Ｓ４８）。これは、変換した結果、変換できなかった文字を自動で削除するものである。従って、変換テーブルの種類によっては、文字「〜」、「‖」、「−」以外の変換できない文字も見逃すことなく、削除することができる。
Ｓ４７でＵＮＩＣＯＤＥの入力文字が「？」の場合は、図２に示すように、ＵＮＩＣＯＤＥの「？」は確実にＳ−ＪＩＳコードに変換できることがわかっているので、入力文字そのものが「？」であると判断して、削除せずに次のＳ４９へ進む。
【００３１】
そして、出力されたＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ４９）、含まれていなければ（Ｓ５０で、無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ５２）。文字「／」、「？」などが含まれていれば（Ｓ５０で、有り）、エラー処理を行う（Ｓ５１）。
【００３２】
実施例２によれば、変換できない文字を予め決めておく必要がない。そして、変換テーブルの種類が何であっても、変換できない文字を見逃すことなく、削除することができる。また、市販の変換処理ユニットをそのまま使用することができ、新たな変換処理ユニットを開発する必要がない。
【実施例４】
【００３３】
図６は、実施例４に係る通信端末のファイル制御のフローチャートである。実施例４は、変換処理ユニットに変更を加えて、変換処理ユニットが変換ステータスを出力する。そして、ファイル制御部は、変換処理ユニットが変換処理を行った後で、変換不可能な文字を削除する例である。
ファイル制御部２は、他の装置から赤外線通信部１を経由して受信したＵＮＩＣＯＤＥのファイルのファイル名を変換処理部３の入力として設定して（Ｓ６１）、変換処理（Ｓ６２）をコールする。この変換処理（Ｓ６２）は、市販の変換処理ユニットに変更を加えている。変換テーブルの種類は限定しない。変換処理（Ｓ６２）では、入力されたファイル名を変換テーブルにより変換処理を行い、変換可能な場合（Ｓ６３でＹＥＳ）、ＵＮＩＣＯＤＥからＳ−ＪＩＳコードに変換してファイル制御部２へ出力する（Ｓ６４）。そして、変換ステータスを「正常」にして出力する（Ｓ６５）。変換できない場合（Ｓ６３でＮＯ）、変換できない文字をＳ−ＪＩＳコードの「？」に一律変換してファイル制御部２へ出力する（Ｓ６６）。そして、変換ステータスを「異常」にして出力する（Ｓ６７）。
【００３４】
ファイル制御部２は、出力された変換ステータスが異常の場合（Ｓ６８で異常）、当該変換出力のＳ−ＪＩＳコードの「？」を削除する（Ｓ６９）。なお、この削除は、変換処理ユニットの中のステップＳ６６において削除処理を行ってもよい。その場合、ファイル制御部２のステップＳ６９の削除は不要となる。一般に、変換処理ユニットは、変換処理と変換ステータスを出力し、後の削除等の処理は、変換処理ユニットを使う側のファイル制御部に任せるのが普通であろう。
【００３５】
次に、出力されたＳ−ＪＩＳコードのファイル名に、ファイル名として使用してはいけないとよく知られている文字「／」、「？」などが含まれているかをチェックし（Ｓ７０）、含まれていなければ（Ｓ７１で、無し）、受け取ったＳ−ＪＩＳコードのファイル名でファイルを管理する（Ｓ７３）。文字「／」、「？」などが含まれていれば（Ｓ７１で、有り）、エラー処理を行う（Ｓ７２）。
【００３６】
実施例３によれば、予め、変換できない文字を決めておく必要がない。そして、変換テーブルの種類が何であっても、変換できない文字を見逃すことなく、削除することができる。
なお、各実施例は、赤外線通信を行う通信端末について実施例を示したが、第１の文字コードと第２の文字コード間の変換を行う装置にも適用できる。
【図面の簡単な説明】
【００３７】
【図１】本発明の各実施例に係る通信端末の構成図。
【図２】本発明の各実施例に係る変換テーブルＡおよび変換不可能ＵＮＩＣＯＤＥ記憶部の内容を説明する図。
【図３】実施例１に係る通信端末のファイル制御のフローチャート。
【図４】実施例２に係る通信端末のファイル制御のフローチャート。
【図５】実施例３に係る通信端末のファイル制御のフローチャート。
【図６】実施例４に係る通信端末のファイル制御のフローチャート。
【図７】一般的なＳ−ＪＩＳコードとＵＮＩＣＯＤＥ規格の対応を示す文字コード表。
【符号の説明】
【００３８】
１ 赤外線通信部
２ ファイル制御部
２１ 変換不可能ＵＮＩＣＯＤＥ記憶部
２２ ＵＮＩＣＯＤＥ−ＵＮＩＣＯＤＥ変換テーブル
３ 変換処理部
３１ 変換テーブル
４ ファイル管理部
５ ファイル記憶部
１０１ 文字
１０２ Ｓ−ＪＩＳコード
１０３ ＵＮＩＣＯＤＥ規格「ＪＩＳＸ０２２１」
１０４ ＵＮＩＣＯＤＥ規格「Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ」
【特許請求の範囲】
【請求項１】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、
第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを削除して残りの文字列のファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項２】
前記第１の文字コードはＵＮＩＣＯＤＥであり、前記第２の文字コードはＳ−ＪＩＳコードであり、前記変換不可能第１の文字コードは、記号「〜」、「‖」、および「−」を表すＵＮＩＣＯＤＥであることを特徴とする請求項１に記載の通信端末。
【請求項３】
前記ファイル制御手段は、
前記第１の文字コードで定義されたファイル名の文字列がすべて前記変換不可能第１の文字コードの場合、エラー処理を行うことを特徴とする請求項１に記載の通信端末。
【請求項４】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、
前記変換不可能第１の文字コードと別の第１の文字コードとが対応付けて格納された第１の文字コード間変換テーブルと、
第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを前記別の第１の文字コードに変換し、当該変換後の第１の文字コードファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項５】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段で変換エラーとなった前記変換処理手段からの第２の文字コード出力を削除し、削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項６】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換し、変換異常の場合に変換異常を表す特定文字の第２の文字コードを出力する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの出力が前記特定文字の第２の文字コードである場合、当該特定文字に対応する入力データが前記特定文字の第１の文字コードでなければ当該特定文字のＳ−ＪＩＳコードを削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項７】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換して出力すると共に、変換の正常および異常を表す変換ステータスを出力する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換ステータスが異常の場合、当該異常に該当する第２の文字コードを削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項１】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、
第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを削除して残りの文字列のファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項２】
前記第１の文字コードはＵＮＩＣＯＤＥであり、前記第２の文字コードはＳ−ＪＩＳコードであり、前記変換不可能第１の文字コードは、記号「〜」、「‖」、および「−」を表すＵＮＩＣＯＤＥであることを特徴とする請求項１に記載の通信端末。
【請求項３】
前記ファイル制御手段は、
前記第１の文字コードで定義されたファイル名の文字列がすべて前記変換不可能第１の文字コードの場合、エラー処理を行うことを特徴とする請求項１に記載の通信端末。
【請求項４】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
前記変換テーブルに備わっていない第１の文字コードを予め変換不可能第１の文字コードとして記憶する手段と、
前記変換不可能第１の文字コードと別の第１の文字コードとが対応付けて格納された第１の文字コード間変換テーブルと、
第１の文字コードで定義されたファイル名の文字列から前記変換不可能第１の文字コードを前記別の第１の文字コードに変換し、当該変換後の第１の文字コードファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの第２の文字コードに変換されたファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項５】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段で変換エラーとなった前記変換処理手段からの第２の文字コード出力を削除し、削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項６】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換し、変換異常の場合に変換異常を表す特定文字の第２の文字コードを出力する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換処理手段からの出力が前記特定文字の第２の文字コードである場合、当該特定文字に対応する入力データが前記特定文字の第１の文字コードでなければ当該特定文字のＳ−ＪＩＳコードを削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【請求項７】
第１の文字コードと第２の文字コードとが対応付けて格納された変換テーブルと、
入力された第１の文字コードを前記変換テーブルに基づいて第２の文字コードへ変換して出力すると共に、変換の正常および異常を表す変換ステータスを出力する変換処理手段と、
第１の文字コードで定義されたファイル名を前記変換処理手段への入力データとして供給し、前記変換ステータスが異常の場合、当該異常に該当する第２の文字コードを削除した残りの文字列のファイル名でファイル制御を行うファイル制御手段とを
具備することを特徴とする通信端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−２２１３３６（Ｐ２００６−２２１３３６Ａ）
【公開日】平成１８年８月２４日（２００６．８．２４）
【国際特許分類】
【出願番号】特願２００５−３２９８０（Ｐ２００５−３２９８０）
【出願日】平成１７年２月９日（２００５．２．９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成１８年８月２４日（２００６．８．２４）
【国際特許分類】
【出願日】平成１７年２月９日（２００５．２．９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]