- - PR -
桁数とバイト長
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-05-07 23:35
よくファイルレイアウト定義やテーブル定義書、データ項目定義書には桁数とバイト長
というフィールドがあるフォーマットになっています。 桁数 = バイト長 の場合とそうでない場合があります。 また、記述のあり方も会社によって違うように思います。X,N？、etc 何か標準的な記述のルールってあるのでしょうか。 | ||||||||||||||||
|
投稿日時: 2007-05-08 09:18
COBOLer 的なルール、
画面レイアウト、項目仕様などで未だに使っている企業は多いですね。 画面レイアウト仕様を兼ねて、属性もわかるので見やすいと言えば見やすいですが。 # これに関連して "桁数 == バイト長" で困っていることでもあるのでしょうか? _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||
|
投稿日時: 2007-05-08 09:25
参考資料 (?)帳票関係や照会をやっているとお目にかかるケースは多いですね。
_________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||
|
投稿日時: 2007-05-08 09:51
さかもとと申します。
じゃんぬねっと様のCOBOLer 的なルールはまさにそのとおりで現在でも最前線で利用されているかと思います。PICTURE句の文字として指定されているからそのまま利用しているだけかと。標準といえば標準？ COBOL以外でのファイルレイアウトでもプロジェクトの文化によって違いがあるかと。今のプロジェクトは型と画面上入力桁数などに制限がある場合は桁数を記入しています。 帳票定義では「Z,ZZZ,ZZ9」「ＮＮＮＮ」などはCOBOL以外でも使ってます。COBOL経験の有無に関係なく結構分かりやすいと思います。顧客に画面や帳票の定義などを見せるときも簡単な注釈入れるだけで今まで意思疎通困難ということもありませんでした。 | ||||||||||||||||
|
投稿日時: 2007-05-08 10:57
そもそも、「全角」「半角」という言葉は
・フォント幅が固定であるフォントを用いている ・Shift_JISのような1byte文字と2byte文字の混合式の文字コード ・フォント幅が2byte文字では1byte文字の倍になっている という前提でのみ意味を持つのですから、いまや死語になっていると 思ったほうがよいでしょう。 いまでもこの前提が残っているのは携帯電話などに限られるのでは？ TrueTypeFont が使われるようになって久しいですが 以来、文字数では表示幅が決定されなくなりました。 ですから帳票などの文字幅についても文字数で安易に レイアウトできなくなっていますね。 文字列もUNICODEで処理されることが多くなりましたので DBの列長でも1byte文字,2byte文字混合の前提での設定は無意味ですし、 そこに起因する全半角チェックも無意味となってしまいました。 私がやっているシステムではUTF-8で処理していますので UTF-8でxxxbyteを超えたら警告する、といった処理方式になっています。 UTF-8でのbyte数なんて見てわかる人なんてそうそういないわけで、 ユーザフレンドリーとは言えませんが「全角ならx文字、半角ならその倍」 といった説明は実態とかけ離れていますから使えませんからねぇ… | ||||||||||||||||
|
投稿日時: 2007-05-08 11:19
開発環境に合わせて設計書の記載方法を変えたほうが良い例のひとつですね。(開発に依存する設計は良くないとか屁理屈を言って、いまだに「Z,ZZZ,ZZ9」とか書き続ける人もいますが･･･) 開発が COBOL なら設計書の桁数や属性の記載は「Z,ZZZ,ZZ9」「NNNN」のほうが相性が良いのでしょう。最近の言語では「#,###,##0」「0000」としておけば、そのまま書式変換関数に渡せることが多いので、設計書にも同じルールで記載しておいたほうが楽。
数値の場合でも、実際のバイト長と表現できる桁数は異なりますから。COBOL でもパックとか使うと1バイトで数値2桁を表現できたりするんでしょう？ よく知りませんけど･･･。桁数は論理的な概念、バイト長は物理的な概念。外部設計(基本設計)は桁数だけでもいいかもしれませんね。バイト長は内部設計(詳細設計)で容量見積りなどと合わせて考えればよいかと。
････。うちでは、ありえない仕様で驚きました。
そんなこともないですよ。「いわゆる全角・半角」という意識はオフコンから使い続けているエンドユーザーにとても浸透しています。エンドユーザーから帳票設計で「半角にすれば2倍印字できるよね？」と言われることもあるくらい。 それを実現するために、うちでは帳票出力に固定幅フォントを使用し、Shift_JIS 換算でのバイト数で桁数チェックをおこなうということをやっています。画面も入力項目は固定幅フォント、固定表示のラベルやボタンなどはプロポーショナルフォントとしています。 | ||||||||||||||||
|
投稿日時: 2007-05-08 11:26
ですから、Shift_JISにしがみつかないといけないわけですよね？ 少なくともUIなどの処理系がUNICODEになっている以上、 Shift_JISがカバーしていない文字が混入することがありうるわけで、 それらの文字は化けてしまうわけですよね。 そうなると、システム全体で文字がShift_JISか？というチェックを いれていかなければならない… それって昨今の国際化対応と逆行しているんですよね。 もっとも、一般的なお客さんはそんなこと興味ないのですが(苦笑 問題になるとすればVistaでしか表示できない第三水準漢字の類でしょうか。 UNICODEでないと扱えないですが、「日本語」なので、 お客さんに「日本語でも一部の文字は使えないんですよ！」と言わなくてはならない。 そろそろ全角/半角文化と手を切る準備をしておいたほうがよいと私は考えています。 | ||||||||||||||||
|
投稿日時: 2007-05-08 13:16
いいえ。Shift_JIS 換算のバイト数でチェックするのは簡易的なチェックができるから使用しているだけです。(ある種の問題を抱えているけど) ユーザーから Shift_JIS で扱えない文字の使用要件が出てくれば、Unicode でも印字幅のチェックをおこなうようにします。固定幅フォントを使用すれば、Unicode であっても印字幅としての「いわゆる全角・半角」という概念は残ります。 エンドユーザーが全角・半角という言葉を使う場合の多くは印字幅についてです。内部保持形式のバイト数を気にしているわけではないと思います。印字幅という視点でみた場合の「全角・半角」という概念を崩す要因は、文字コードではなくフォント(字形)ですし。
文字コードの話とはまったく関係ないのですが、印字幅という面で全角・半角というのは便利なことも多いですよ。なので、私は単純な文字数制限よりも全角・半角を加味した桁数制限を好んで使います。文字数でも桁数でもなく内部形式のバイト数( UTF-8 )で制限するという方法を聞いて驚いたのです。 Unicode のため「桁数制限」ではなく「文字数制限」というのならともかく。「内部形式でのバイト数制限」というのは私には信じがたいシステムです。。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。