簡単明瞭な回答を期待しています。
No.2
354
56
100pt
>１．なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか？
元々SMSメッセージを載せる場所として1120ビット用意されていて、７ビット文字で160文字分になったというところから来ているようです。
http://en.wikipedia.org/wiki/SMS
Message size
Transmission of short messages between the SMSC and the handset is done whenever using the Mobile Application Part (MAP) of the SS7 protocol. Messages are sent with the MAP MO- and MT-ForwardSM operations, whose payload length is limited by the constraints of the signaling protocol to precisely 140 octets (140 octets = 140 * 8 bits = 1120 bits). Short messages can be encoded using a variety of alphabets: the default GSM 7-bit alphabet, the 8-bit data alphabet, and the 16-bit UTF-16 alphabet.[27] Depending on which alphabet the subscriber has configured in the handset, this leads to the maximum individual short message sizes of 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters (including spaces). GSM 7-bit alphabet support is mandatory for GSM handsets and network elements,[27] but characters in languages such as Arabic, Chinese, Korean, Japanese or Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.) must be encoded using the 16-bit UTF-16 character encoding (see Unicode). Routing data and other metadata is additional to the payload size.
何故160文字なのかという点については大抵の文章が160文字以内だったということからきているようです。
http://www.berryreview.com/2009/05/06/the-history-behind-the-160...
In 1985 he sat at his typewriter and tried to find the optimal length for a text message. He wrote out a few sentences and found that the characters were always under 160. He then got his magic number and forced the new standard on all GSM carriers as chairman of the nonvoice services committee of the Global System for Mobile Communications Group in 1986…
http://latimesblogs.latimes.com/technology/2009/05/invented-text...
As he went along, Hillebrand counted the number of letters, numbers, punctuation marks and spaces on the page. Each blurb ran on for a line or two and nearly always clocked in under 160 characters.
また一方で、256バイト(文字)単位で考えた場合にオーバーヘッドに96バイト(文字)分が取られるので残りの160文字が決まったという説もあるようです。
http://knuckleskin.blogspot.com/2007/02/why-sms-are-limited-to-1...
Now an SMS needs to have contained within itself who sent the message, when it was sent and who it is going too, these are called overheads and take up exactly 96 characters, which is why you end up with 160 characters left. (256-96=160).
>２．なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
これは想像になりますが、一般のユーザーにとって半角（1バイトコード）なら何文字、全角(2バイトコード)なら何文字、可変長コードんら・・・というのは理解されにくいことで、あくまでも文字単位が理解されやすくまた日本語だけでなく全ての言語をカバーすることを考えると一律に文字数で制限を設けるのが妥当だという判断だと考えます。
システムでUTF-8を扱う以上可変長が面倒かどうかは関係なく対応しなくてはなりませんからユーザーの利便性優先で作るだけだと思います。
No.1
1422226
40pt
この質問には2つの解釈があると思いますので両方回答しておきます。
■なぜ140文字なのか、という文字数の根拠に関する質問とすると
Twitter、140文字制限の理由とはで分かりやすく説明されていました。要は元々SNSのショートメッセージサービスを想定して作ったらSNSでは160文字制限があって、アカウント名もメッセージに足しても140文字なら20文字位の余裕があるしSNSでエラーが起こることも少ないだろう。という理由で決まったようです。
■英語だと1文字1バイトだけど日本語だと2バイト以上使うのになぜ同じ140文字なのか？という質問とすると
単純にUTF-8で「1文字」という単位でカウントした方が利用者に分かりやすいからだと思います。
英語圏以外でも利用されることを視野に入れてサービスを作る場合文字コードはUTF-8にしておくのが無難だし、言語や人により文字数が変動するほうがユーザに不親切だと考えたからでしょう。
この質問には2つの解釈があると思いますので両方回答しておきます。
ご指摘ありがとうございます。
両方の意味で質問しています。
なぜ140文字なのか、という文字数の根拠に関する質問とすると
ありがとうございます。
和訳では意味が分からなかったのですが、元の英語を読んだら何となく分かりました。
単純にUTF-8で「1文字」という単位
UTF-8ですと、バイト数に換算すると１文字あたり１～４バイトの可変長になります。
システムにとって可変長になることは面倒なことではないでしょうか。
これ以降に回答される方は
１．なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか？
２．なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
という2点についてご回答くださいますようお願いします。
No.2
35456
ここでベストアンサー
100pt
>１．なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか？
元々SMSメッセージを載せる場所として1120ビット用意されていて、７ビット文字で160文字分になったというところから来ているようです。
http://en.wikipedia.org/wiki/SMS
Message size
Transmission of short messages between the SMSC and the handset is done whenever using the Mobile Application Part (MAP) of the SS7 protocol. Messages are sent with the MAP MO- and MT-ForwardSM operations, whose payload length is limited by the constraints of the signaling protocol to precisely 140 octets (140 octets = 140 * 8 bits = 1120 bits). Short messages can be encoded using a variety of alphabets: the default GSM 7-bit alphabet, the 8-bit data alphabet, and the 16-bit UTF-16 alphabet.[27] Depending on which alphabet the subscriber has configured in the handset, this leads to the maximum individual short message sizes of 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters (including spaces). GSM 7-bit alphabet support is mandatory for GSM handsets and network elements,[27] but characters in languages such as Arabic, Chinese, Korean, Japanese or Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.) must be encoded using the 16-bit UTF-16 character encoding (see Unicode). Routing data and other metadata is additional to the payload size.
何故160文字なのかという点については大抵の文章が160文字以内だったということからきているようです。
http://www.berryreview.com/2009/05/06/the-history-behind-the-160...
In 1985 he sat at his typewriter and tried to find the optimal length for a text message. He wrote out a few sentences and found that the characters were always under 160. He then got his magic number and forced the new standard on all GSM carriers as chairman of the nonvoice services committee of the Global System for Mobile Communications Group in 1986…
http://latimesblogs.latimes.com/technology/2009/05/invented-text...
As he went along, Hillebrand counted the number of letters, numbers, punctuation marks and spaces on the page. Each blurb ran on for a line or two and nearly always clocked in under 160 characters.
また一方で、256バイト(文字)単位で考えた場合にオーバーヘッドに96バイト(文字)分が取られるので残りの160文字が決まったという説もあるようです。
http://knuckleskin.blogspot.com/2007/02/why-sms-are-limited-to-1...
Now an SMS needs to have contained within itself who sent the message, when it was sent and who it is going too, these are called overheads and take up exactly 96 characters, which is why you end up with 160 characters left. (256-96=160).
>２．なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
これは想像になりますが、一般のユーザーにとって半角（1バイトコード）なら何文字、全角(2バイトコード)なら何文字、可変長コードんら・・・というのは理解されにくいことで、あくまでも文字単位が理解されやすくまた日本語だけでなく全ての言語をカバーすることを考えると一律に文字数で制限を設けるのが妥当だという判断だと考えます。
システムでUTF-8を扱う以上可変長が面倒かどうかは関係なく対応しなくてはなりませんからユーザーの利便性優先で作るだけだと思います。
１番については、引用を含めた具体的な回答をありがとうございます。とても参考になりました。
２番については、おそらくそうなのでしょうね。
２番については決定的な回答はないものと予想しつつも、皆さまからの考えをお伺いいたしたく、よろしくお願いします。
No.3
48630
5pt
＞なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか？
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%8...
1.1回のメッセージで送信可能な文字数は最大140オクテットと決めた。（1オクテットは8ビットのこと）
2.7ビットのアルファベットを使うところは、140オクテットで160文字送れる
7ビットの文字コードを使わないばあいは、160文字も送れない
だだ、これが決まったのは、かなり昔の話ですからどういう経由で決まったのかはわかりませんが、
256バイトで１つの通信と考えて、制御コードとか除いたときに140バイトを文字データとして使いましょうと
決まったんだと思います。
＞なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
単に面倒だからです。
Unicodeが普及した時点で、バイトとか関係なく、１文字は、１文字と扱おうという文化ができたからです。
どっちにしても、英語圏しか考えてなくて、Unicodeのときに英語圏の人がなんとか勉強したのは
１文字は１文字として処理しましょうという考え方だけなんです。
＞UTF-8ですと、バイト数に換算すると１文字あたり１～４バイトの可変長になります。
＞システムにとって可変長になることは面倒なことではないでしょうか。
英語圏に便利なようになってるだけです。
Unicodeでなんとか英語圏とそれ以外の２バイト文字圏が同じ土俵で意識しないで使えるようになったけど
英語圏の人は、アルファベット（１バイト）しか使わないのに２バイトも必要になると、通信するにも保存するにも
かなり無駄になるんです。また、Unicodeだと、２バイトになりますが、UTF-8の場合は、英語圏の文字は１バイトとなり
Unicode以前のプログラムの考え方で、Unicode以前のプログラムがそのまま動くので便利がよいのです。
最悪、英語圏以外で動かないだけで、それまでの資産が有効に利用できるので便利なんです。
すみません。日本語の論理でよく分からないところがあります。
たとえば「UTF-8の場合は、英語圏の文字は１バイトとなりUnicode以前のプログラムの考え方で、Unicode以前のプログラムがそのまま動くので便利がよい」と仰いますが、それでしたらEUCでも、（有り得ないことですが）SJISでも同じではありませんか。なぜ、文字列長が計算しにくい可変長のUTF-8を採用し、文字列長の方を一定にしたのでしょう？
No.4
18127
5pt
前半部分は回答してないのでポイントは０でも構いません。
なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
ほとんどのプログラム言語及び（UNICODEで保存する場合の）データベースがそういう数え方をしているため、
文字列を数えるより、バイト数を数えるのはプログラムとしても楽だからです。
UTF-8ですと、バイト数に換算すると１文字あたり１～４バイトの可変長になります。
システムにとって可変長になることは面倒なことではないでしょうか。
そのあたりは、プログラム言語及びデータベースが吸収してくれます。通常は意識する必要はありません。
多言語対応を行なうため、プログラム言語の文字列の内部形式はUNICODE（UTF-8ではなく）で保持している言語も多く、
表示用の文字コードがなんであれ、内部形式への変換が必要になります。
で、プログラム上ではその内部コードで文字列を取り扱うので、
繰り返しになりますが、むしろ文字数の方が扱いやすいわけです。
（バイト数なら 内部形式→エンコードを指定してバイトデータに変換→そのバイト数を取得 という手間がかかる）
Javaの例： http://javafaq.jp/S008.html#S008-08
JavaScriptの例： http://www.kanaya440.com/contents/tips/javascript/006.html
データベースに関しても、文字列型はUNICODE形式で格納する場合は、「何バイト」ではなく「何文字」で
その領域を指定します。
MySQLの例：http://dev.mysql.com/doc/refman/5.1/ja/char.html
なぜ、文字列長が計算しにくい可変長のUTF-8を採用し、文字列長の方を一定にしたのでしょう？
「多言語対応」を行なうには事実上必須だからでしょう。
実際の話し、Shift_Jisは日本語のみしか対応していません。
EUCにしても技術的には一つのエンコーディングで多言語対応が出来るのかもしれないですが、
現時点で企画として一般的ではありません（EUC-JPとかKRとかの指定をしている）
「なぜEUCではなくUNICODEか」というのはアラビア語などの１バイト言語の多言語対応とか、
ひょっとしたら規格制定時の政治的な動きがあったのかもしれませんが、
とりあえず、一つのエンコーディングで多数の言語が表示できるのは今のところ、
実質UNICODE系のエンコーディングだけのはずです。
#というか、JavaScriptで「バイト数で文字列制限」って結構大変だし…
ご回答ありがとうございます。
ほとんどのプログラム言語及び（UNICODEで保存する場合の）データベースがそういう数え方をしているため、
文字列を数えるより、バイト数を数えるのはプログラムとしても楽だからです。
前半は仰る通りですが、そうすると、後半は「文字列長を数えることが簡単にできる」ということですよね。
プログラム言語の文字列の内部形式はUNICODE（UTF-8ではなく）で保持している言語も多く
Unicodeの表現形式としてUTF-8, UTF-16, UTF-32といったフォーマットがあるのだと考えていましたが、これは間違っていますか？
とりあえず、一つのエンコーディングで多数の言語が表示できるのは今のところ、
実質UNICODE系のエンコーディングだけのはずです。
それは分かりますが、ではなぜUTF-8を選択したのでしょう？
No.5
77896
5pt
＞２．なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか？
低級言語、例えばアセンブラやC言語であればバイトでキッチリと管理しますが、高級言語であればマルチバイト文字宣言を使うからでしょう。
具体的には
C言語の
char text[140];
は140バイトです。ちょっと高級言語のVC++では以下のような宣言が出来ます。
wchar text[140];
で140×4=960バイトです。
ちなみに、何か文字列を入れた場合。例えば"123"と入れると
0x00,0x00,0x00,0x31,0x00,0x00,0x00,0x32,0x00,0x00,0x00,0x33,0x00,0x00,0x00,0x00
となります(1バイト文字でも4バイト使い、3バイトは0が入る)。
文字の処理のしやすさからこのような仕様になっています。
上記仕様のようにすれば、マルチバイトの文字列を簡単に扱えるのです。wcharで文字列コピーや比較、置き換えなどのライブラリも揃っていて、マルチバイト環境であればこちらの方が使いやすいです。
どの国でも140文字制限だとしたら、twitterが高級言語を使っている証拠でしょうね。
ご回答ありがとうございます。
回答４さんが仰っているように、「そのあたりは、プログラム言語及びデータベースが吸収してくれます」ので、あえてマルチバイト文字列宣言しなければならないＣ＋＋は時代遅れの感じがします。
マルチバイト文字列宣言を不要にするのがUTF-8だと考えておりましたが、間違っていますでしょうか？
No.6
77896
5pt
＞マルチバイト文字列宣言を不要にするのがUTF-8だと考えておりましたが、間違っていますでしょうか？
はい、間違ってます。
というのも、言語による指定なし＝コンパイラ(orプリプロセッサorインタプリタ)が判断して勝手に決める、です。
ある程度ちゃんとしたところなら、言語による文字列宣言は結局意識して、キッチリ指定します(コンパイラ任せの文字列宣言で問題が発生した際、プログラマは「コンパイラのせいです」という言い訳は出来ないため)。
＞それは分かりますが、ではなぜUTF-8を選択したのでしょう？
他の人向けの質問ですが、とりあえずここを読んでみて下さい。UTF-8がUTF-16やUTF-32より使いやすい理由が具体的に記載されています。
http://ja.wikipedia.org/wiki/UTF-8
補足すると、TwitterはRT、@、ふぁぼったーなど独特の概念があります。検索がかなり頻繁に行われるので、検索により適したUTF-8が好都合なのではないでしょうか。
ありがとうございます。
あすか
2010/12/24 12:43:34
8
8
tama213
practicalscheme
１番については、引用を含めた具体的な回答をありがとうございます。とても参考になりました。
２番については、おそらくそうなのでしょうね。
２番については決定的な回答はないものと予想しつつも、皆さまからの考えをお伺いいたしたく、よろしくお願いします。