文字列操作関数中のIF文について
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
MTA
投稿数: 16
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
質問ばかりで、申し訳ありません。
"v9Plus"から"uniPaaS v1 plus"のマイグレーションのですが、困った問題があります。
ヘルプの「Unicodeを利用する場合の注意事項」の存在は知っていましたが、今回unicode変数を使わないし関係ないやと思っていましたが、動作確認中に不思議な動きをするので、再確認しました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ただし、IF関数およびCASE関数では、以下の扱いになります。
・文字定数は、Unicode型と扱われます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
文字列操作関数のパラメータに、if文で文字定数をセットするのは、比較的特殊な作りでもないと思いますが、byte単位での処理を期待していた物が、文字単位で処理されてしまいます。
たとえば
・v9,uniPaaS 同じ
len('奇数') → 戻値:4
・v9 と uniPaaS で違う
len(if((X mod 2)=0,'偶数','奇数')) → 戻値:v9は4、uniPaaSは2
見つけ次第UnicodeToANSIをif文にかぶせていますが、問題箇所の対象を絞り込むのが大変なので、この現象を回避できる方法がありましたらと思い投稿しました。
"v9Plus"から"uniPaaS v1 plus"のマイグレーションのですが、困った問題があります。
ヘルプの「Unicodeを利用する場合の注意事項」の存在は知っていましたが、今回unicode変数を使わないし関係ないやと思っていましたが、動作確認中に不思議な動きをするので、再確認しました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ただし、IF関数およびCASE関数では、以下の扱いになります。
・文字定数は、Unicode型と扱われます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
文字列操作関数のパラメータに、if文で文字定数をセットするのは、比較的特殊な作りでもないと思いますが、byte単位での処理を期待していた物が、文字単位で処理されてしまいます。
たとえば
・v9,uniPaaS 同じ
len('奇数') → 戻値:4
・v9 と uniPaaS で違う
len(if((X mod 2)=0,'偶数','奇数')) → 戻値:v9は4、uniPaaSは2
見つけ次第UnicodeToANSIをif文にかぶせていますが、問題箇所の対象を絞り込むのが大変なので、この現象を回避できる方法がありましたらと思い投稿しました。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
MTA さん、こんにちは。
型を「文字」にしているか、「Unicode」にしているかの違いだけでは
ないのでしょうか?
タンダコンピュータ/丹田 昌信
型を「文字」にしているか、「Unicode」にしているかの違いだけでは
ないのでしょうか?
タンダコンピュータ/丹田 昌信
投票数:0
平均点:0.00
mtakata
投稿数: 16
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
丹田 さん、お世話になります。
>型を「文字」にしているか、「Unicode」にしているかの違いだけではないのでしょうか?
”型”とは、例で言うと項目'X'か、戻り値を受け取る変数の型宣言の事でしょうか?
検証して頂くとわかると思いますが、unicode変数(型)は一切使用しておらず、すべて”A=文字”です。
他に型を指定する箇所がありましたでしょうか?
>型を「文字」にしているか、「Unicode」にしているかの違いだけではないのでしょうか?
”型”とは、例で言うと項目'X'か、戻り値を受け取る変数の型宣言の事でしょうか?
検証して頂くとわかると思いますが、unicode変数(型)は一切使用しておらず、すべて”A=文字”です。
他に型を指定する箇所がありましたでしょうか?
投票数:0
平均点:0.00
Jiro123
投稿数: 271
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
>ただし、IF関数およびCASE関数では、以下の扱いになります。
>・文字定数は、Unicode型と扱われます。
If関数の第二、第三引数に、文字定数を指定した場合、その文字定数をUnicode型として扱う、というルールになったということなので、文字定数のところを、UnicodeToANSI関数を使って、次のようにするのはどうですか?
UnicodeToANSI('奇数',932)
※S-JISのコードページは932です。
以下の関数の結果は「4」となりました
Len(IF(1 MOD 2 = 1,UnicodeToANSI('奇数',932),UnicodeToANSI('偶数',932)))
>・文字定数は、Unicode型と扱われます。
If関数の第二、第三引数に、文字定数を指定した場合、その文字定数をUnicode型として扱う、というルールになったということなので、文字定数のところを、UnicodeToANSI関数を使って、次のようにするのはどうですか?
UnicodeToANSI('奇数',932)
※S-JISのコードページは932です。
以下の関数の結果は「4」となりました
Len(IF(1 MOD 2 = 1,UnicodeToANSI('奇数',932),UnicodeToANSI('偶数',932)))
投票数:1
平均点:10.00
MTA
投稿数: 16
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
Jiro123 様、回答ありがとうございます。
仕様という事で、地道に修正して行く他ないという事ですね。
ちなみに"UnicodeToANSI"では、0を指定してプログラムには埋め込まないようにしてます。(変わる数字とは思いませんが念の為)
問題は、マイグレーション作業において、すべての文字列操作関数(数千箇所はあるかも・・・)を探し、IF文の有無・IFで文字定数を使用しているかどうかチェックする必要があります。
融通がきかない文字列関数のインターフェースは、色々総合的に考えられた上で決められた事とは思いますが、このIF・CASE文の仕様の為、マイグレーションを行う際に unicode を使わないにもかかわらず、大きなネックになると思います。
皆様の所では、問題ないのでしょうか?
仕様という事で、地道に修正して行く他ないという事ですね。
ちなみに"UnicodeToANSI"では、0を指定してプログラムには埋め込まないようにしてます。(変わる数字とは思いませんが念の為)
問題は、マイグレーション作業において、すべての文字列操作関数(数千箇所はあるかも・・・)を探し、IF文の有無・IFで文字定数を使用しているかどうかチェックする必要があります。
融通がきかない文字列関数のインターフェースは、色々総合的に考えられた上で決められた事とは思いますが、このIF・CASE文の仕様の為、マイグレーションを行う際に unicode を使わないにもかかわらず、大きなネックになると思います。
皆様の所では、問題ないのでしょうか?
投票数:0
平均点:0.00
Jiro123
投稿数: 271
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
まず、そんなに文字定数を利用されているのでしょうか。
文字定数でなく、文字型変数を使用していれば、今回の問題にも触れませんよ。
問題となっているのは、If関数とCase関数で文字定数を使用している場合と思います。
であれば、If関数とCase関数を探せば済むように思うのですが、すべての文字列操作関数を探す必要があるのは、どのような観点からでしょうか。
if関数とCase関数を検索するのであれば、テキスト検索を2回行えば済みます。
文字定数でなく、文字型変数を使用していれば、今回の問題にも触れませんよ。
問題となっているのは、If関数とCase関数で文字定数を使用している場合と思います。
であれば、If関数とCase関数を探せば済むように思うのですが、すべての文字列操作関数を探す必要があるのは、どのような観点からでしょうか。
if関数とCase関数を検索するのであれば、テキスト検索を2回行えば済みます。
投票数:0
平均点:0.00
MTA
投稿数: 16
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
Jiro123 様、回答がありがとうございます。
>if関数とCase関数を検索するのであれば、テキスト検索を2回行えば済みます。
IF文をキーワードに検索すると10CTLで、2万2千箇所が対象になるので・・・
その中で文字定数を使っていて、文字数単位で処理されるパターンかどうかを見極める(人の目で)のが、大変ですねという事です。
マイグレーションにおいて、unicodeを使ってないのに、そんな作業が必要になる事が疑問です。
皆はどうしているんだろう?とMSJに仕様改善の声がとどけばいいなーと考えたしだいです。
IF・CASE文で返却される文字定数もどっちつかずではないですが、受取る変数の型になるという仕様が良いかと思います。
文字列操作関数内の文字定数は、そういう扱いになってます。
>if関数とCase関数を検索するのであれば、テキスト検索を2回行えば済みます。
IF文をキーワードに検索すると10CTLで、2万2千箇所が対象になるので・・・
その中で文字定数を使っていて、文字数単位で処理されるパターンかどうかを見極める(人の目で)のが、大変ですねという事です。
マイグレーションにおいて、unicodeを使ってないのに、そんな作業が必要になる事が疑問です。
皆はどうしているんだろう?とMSJに仕様改善の声がとどけばいいなーと考えたしだいです。
IF・CASE文で返却される文字定数もどっちつかずではないですが、受取る変数の型になるという仕様が良いかと思います。
文字列操作関数内の文字定数は、そういう扱いになってます。
投票数:0
平均点:0.00