- PR -

桁数とバイト長

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
いげ太
常連さん
会議室デビュー日: 2004/10/27
投稿数: 32
投稿日時: 2007-05-08 14:24
似たようなスレを前にも見たなーと思って過去ログをあさってみた。
nvarcharについて - Insider.NET

# 2 年半も前だったか。。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-05-08 14:33
引用:

未記入さんの書き込み (2007-05-08 13:16) より:
ユーザーから Shift_JIS で扱えない文字の使用要件が出てくれば、Unicode でも印字幅のチェックをおこなうようにします。固定幅フォントを使用すれば、Unicode であっても印字幅としての「いわゆる全角・半角」という概念は残ります。

エンドユーザーが全角・半角という言葉を使う場合の多くは印字幅についてです。内部保持形式のバイト数を気にしているわけではないと思います。印字幅という視点でみた場合の「全角・半角」という概念を崩す要因は、文字コードではなくフォント(字形)ですし。


なるほど。
帳票という点に絞れば全角半角もそれなりの意味は残るのですね。
英字について固定幅ってのはラテン文字の文化圏の人には嫌がられそうですが…。
日本での利用に割り切ればアリなのかな。
ラテン文字を美しく表示したいとなれば半角文字だけですら横幅が可変になるので
根本的な考え方を改めなくてはなりませんね。こちらは後述。

引用:

引用:
そろそろ全角/半角文化と手を切る準備をしておいたほうがよいと私は考えています。

文字コードの話とはまったく関係ないのですが、印字幅という面で全角・半角というのは便利なことも多いですよ。なので、私は単純な文字数制限よりも全角・半角を加味した桁数制限を好んで使います。文字数でも桁数でもなく内部形式のバイト数( UTF-8 )で制限するという方法を聞いて驚いたのです。

Unicode のため「桁数制限」ではなく「文字数制限」というのならともかく。「内部形式でのバイト数制限」というのは私には信じがたいシステムです。。

こちらも前提を省略していたのがよくなかったですね。私のミスです。
私のところのシステムがいわゆるWebシステムで帳票がほぼ存在しないので
システム内部でのデータ保有量制限のみで制約しています。

ところで、等幅フォントを選択したとして、UNICODEのどこからどこの範囲が
果たして半角なのか、私は判別する良い方法論を知らないのですが、
いわゆる全半角の考えでの桁数をどうあつかうべきなのでしょう？

考えて見れば以前のシステムは内部コードはUNICODEだけどもShift_JISのシステムでした。
そちらのシステムでは帳票では全半角で処理していた気がします。
やはり、利便性を考えるとそうなるのでしょうね。

知人のエンジニアいわく、ユーザにとってデータ量なんてものはどうでもよいことで、
単に見た目の幅だけで制限するのが望ましいのかもしれない、といっておりました。
システム屋はまずDBのカラムのバイト数などを気にしますが、そんな制約は表に見せるなと。
DBのカラムのバイト数には余裕をとっておいて、表示幅のみで制約するのが
一番直感的なシステムなのではないかと提唱していました。
わちゃ
大ベテラン
会議室デビュー日: 2005/12/05
投稿数: 162
お住まい・勤務地: 東京
投稿日時: 2007-05-08 15:45
まず、桁数とバイト数の話では、次の３つの長さがあるかと思います。

　文字数
　バイト数
　表示幅

半角カナまでの ANK 文字で、固定幅フォントしかなかった時代は、
すべてが等しく、何も問題がなかったかと思います。

しかし、漢字が出てきたり、プロポーショナルフォントが出てきて、
それぞれの相関性が薄くなってきているのは、ご存じのとおりかと
思います。

この中で、
その中で、上記の長さには、それぞれどういった制約があるかというと、
次のようになるかと思います。

　文字数 - オフラインの環境（手書きフォーム）で、使用可能なユーザへの制約
　バイト数 - 記憶する際の制約
　表示幅 - 画面、または印刷上の制約


この中で、一番最初に制約条件として出やすいのが、「表示幅」で
ないかと思います。

その表示幅を計るための手段として、「Shift-JIS でのバイト数」というのが
最近の使われ方では多いのではないでしょうか？

そのうち、「Shift-JIS のバイト数」による表示幅の計算でなく、
MeasureString による表示幅の計算が主流になったりするのでしょうか？

もっとも、MeasureString は印字対象に依存するので、必ずしも予測可能でないのが、
悩ましいあたりでしょうか。


と、このような前提で、

引用:

UTF-8でxxxbyteを超えたら警告する、といった処理方式になっています。


私は、この制約を、条件付きで支持します。
その条件は、「現実的な入力では、その制約条件に達しない」というものです。

例えば、住所のフィールドで、記憶域に、４０００バイトを割り当てた場合などです。


引用:

問題になるとすればVistaでしか表示できない第三水準漢字の類でしょうか。
UNICODEでないと扱えないですが、


あれ、第三水準の字って、Shift-JIS でできなかったですっけ？
＃ Vista は、手元にないです。


さて、さて、入力に対するユーザへの制約は、どのように
なっていくんでしょうね。

私のイメージでは、、、


１．現実的な解は、Shift JIS のバイト数が多い？
　　でも、プロポーショナルフォントで、破綻。

２．オフラインでの入力は、文字数が多い？
　　いかにも日本的でださい。

３．そもそも、制約自体がなくなっていく？
　　Excel のように、文字が多くなると、縮小したりとか

４．MeasureString が、低 DPI でも、高 DPI でも同じになる時代がくるとか？
　　せめて、低 DPI での計測値と、高 DPI での計測値の大小関係が保証されるといいんですけどね。

あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2007-05-08 15:47
ちょっと脇道にそれた話題で恐縮ですが、

引用:

nagiseさんの書き込み (2007-05-08 14:33) より:
知人のエンジニアいわく、ユーザにとってデータ量なんてものはどうでもよいことで、
単に見た目の幅だけで制限するのが望ましいのかもしれない、といっておりました。
システム屋はまずDBのカラムのバイト数などを気にしますが、そんな制約は表に見せるなと。
DBのカラムのバイト数には余裕をとっておいて、表示幅のみで制約するのが
一番直感的なシステムなのではないかと提唱していました。

同感です。

今更Shift_JIS系の地獄にはまりたくないのでUTF-8を使って、
VARCHARなカラムは基本的に必要な文字数×3バイトで定義します。
ユーザーからはカラム幅の1/3の文字数までしか入力させません。
(Vistaまでは普通に考えて3バイト以上はありえないわけで)

今のストレージ容量を考えれば桁数なんてどうでもいい所だと思います。
行連鎖で遅くなる？本当にそうならブロックサイズ大きくすれば？とか。

極限までレコード数の増えるテーブルでVARCHARがあるのは稀だったり、
もしくはとことん検討して設計しないといけないところなので
また少し違ったポリシーになるわけですが。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2007-05-08 15:52
引用:
ところで、等幅フォントを選択したとして、UNICODEのどこからどこの範囲が果たして半角なのか、私は判別する良い方法論を知らないのですが、いわゆる全半角の考えでの桁数をどうあつかうべきなのでしょう？


半角・全角の判定方法ということですか？ Java なら FontMetrics.charWidth() や FontMetrics.stringWidth() で幅が取得できますし。VB6 でも Form.TextWidth を利用することで文字幅を調べることができました。なので別に Unicode のコード範囲などを意識する必要はありません。

プロポーショナルフォントで文字の折り返し処理をおこなうためには印字幅の取得が必要となりますから、最近のコンピュータシステムでは大抵はなんらかの方法でサポートされているのではないかと思います。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-05-08 16:20
引用:

nagiseさんの書き込み (2007-05-08 10:57) より:

そもそも、「全角」「半角」という言葉は

・フォント幅が固定であるフォントを用いている
・Shift_JISのような1byte文字と2byte文字の混合式の文字コード
・フォント幅が2byte文字では1byte文字の倍になっている

という前提でのみ意味を持つのですから、いまや死語になっていると思ったほうがよいでしょう。

これは、ひょっとして私への返信 (突っ込み) でしょうか。(単語の初出は私のようですし)

突っ込みを想定して 「いわゆる半角」「いわゆる全角」 という言い回しにしたり、COBOLer という単語を出していますが、これは固定ピッチフォント前提でかつ、主に帳票レイアウト設計で用いられる手法ですという意味です。
(どこかの記事で 「半角全角なんて時代遅れ」 などと書いたこともありましたが、あれも防御のための伏線だったりします)

仲間内で 「半角・全角」 なんて言葉が飛び出すと、どういう意味で使っているのかわからない (その人によって変わる) ので 「いみふめいです :)」 と返しています。しかし、お客さんからすれば、見た目の意味合いしかないです。("バイト数" なんてどうでも良い)

そのため、画面レイアウトや帳票レイアウトで使うことがあります。

# 何か微妙に話題がそれる一因を買って申し訳ないです。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-05-08 17:18
引用:

未記入さんの書き込み (2007-05-08 15:52) より:
引用:
ところで、等幅フォントを選択したとして、UNICODEのどこからどこの範囲が果たして半角なのか、私は判別する良い方法論を知らないのですが、いわゆる全半角の考えでの桁数をどうあつかうべきなのでしょう？


半角・全角の判定方法ということですか？ Java なら FontMetrics.charWidth() や FontMetrics.stringWidth() で幅が取得できますし。VB6 でも Form.TextWidth を利用することで文字幅を調べることができました。なので別に Unicode のコード範囲などを意識する必要はありません。

プロポーショナルフォントで文字の折り返し処理をおこなうためには印字幅の取得が必要となりますから、最近のコンピュータシステムでは大抵はなんらかの方法でサポートされているのではないかと思います。

折り返し処理をするための文字の表示幅ならそれでいいのですが、
いわゆる全角・半角の区別をする場合のよい方法がないですよね？という話です。
ラテン文字といえど、英語のアルファベットのみではなく、フランス語などで
特有の半角の文字が存在するわけですし。

引用:

わちゃさんの書き込み (2007-05-08 15:45) より:
この中で、一番最初に制約条件として出やすいのが、「表示幅」で
ないかと思います。

その表示幅を計るための手段として、「Shift-JIS でのバイト数」というのが
最近の使われ方では多いのではないでしょうか？

「最近の」というよりも「古典的なシステムでは」ですよね。
そろそろ文字コードも脱Shift_JIS化しつつありますから方法を改めなくてはならない、と。
わちゃ氏がまとめてくださったあたりについては異口同音に発言している方が
いますから、共通認識と捉えてよいのでしょう。（異論がある方は発言を！）

引用:

引用:

問題になるとすればVistaでしか表示できない第三水準漢字の類でしょうか。
UNICODEでないと扱えないですが、


あれ、第三水準の字って、Shift-JIS でできなかったですっけ？


http://ja.wikipedia.org/wiki/JIS_X_0208
を参照。第一水準、第二水準ですね。
PC-98のころは独自拡張で一部の第三水準が使えたとかなんとか。

引用:

じゃんぬねっとさんの書き込み (2007-05-08 16:20) より:
これは、ひょっとして私への返信 (突っ込み) でしょうか。(単語の初出は私のようですし)


一応、スレ主の発言とスレの流れを受けての発言です。

引用:

桁数 = バイト長
の場合とそうでない場合があります。
また、記述のあり方も会社によって違うように思います。X,N？、etc

と桁数とバイト長について言っており、またＮとXといった表記は
Shift_JIS時代の全半角の体系を前提とした話（と私は理解している）なので
全角半角ってどうよ？という話をだしました。
この辺り、じゃんぬねっと氏に対しては釈迦に説法と思っております。

私が一番流を脱線させているのかもしれません・・・
わちゃ
大ベテラン
会議室デビュー日: 2005/12/05
投稿数: 162
お住まい・勤務地: 東京
投稿日時: 2007-05-08 17:36
はげしく、本題からずれていますが、、、

引用:

引用:

この中で、一番最初に制約条件として出やすいのが、「表示幅」で
ないかと思います。

その表示幅を計るための手段として、「Shift-JIS でのバイト数」というのが
最近の使われ方では多いのではないでしょうか？

「最近の」というよりも「古典的なシステムでは」ですよね。
そろそろ文字コードも脱Shift_JIS化しつつありますから方法を改めなくてはならない、と。
わちゃ氏がまとめてくださったあたりについては異口同音に発言している方が
いますから、共通認識と捉えてよいのでしょう。（異論がある方は発言を！）


あぁ、これは私の書き方が悪かったですね。m(_ _)m

「Shift-JIS」の使われ方という意味です。
つまり、保存方法という使い方がだんだんとなくなっていって、
表示幅を計る手段として利用されてきているという意味で書いていました。

EUC で育った人は、"\\" と同じ文字コードが 2byte 目にあったりして、
嫌ってる人も多いですけど、「バイト数」＝「表示幅」というのは、
やはり、楽でしたよね。


引用:

http://ja.wikipedia.org/wiki/JIS_X_0208
を参照。第一水準、第二水準ですね。
PC-98のころは独自拡張で一部の第三水準が使えたとかなんとか。

たしかに、JIS_X_0208 ではそうですね。
ただ、ShiftJIS 2000 という規格では、サポートされているようです。

UNICODE もできた当初は、第三水準の漢字がサポートされていませんでしたし、
どちらも拡張してサポートできるようになったという意味において、
同格ではないかと考えています。
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）