Twitterの投稿文字数制限は、なぜ英語でも日本語でも140文字なのですか。

簡単明瞭な回答を期待しています。

回答の条件
  • URL必須
  • 1人2回まで
  • 13歳以上
  • 登録:2010/12/24 10:50:35
  • 終了:2010/12/30 11:19:18

ベストアンサー

id:syntaxerror No.2

syntaxerror回答回数354ベストアンサー獲得回数562010/12/24 14:03:31

ポイント100pt

>1.なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか?



元々SMSメッセージを載せる場所として1120ビット用意されていて、7ビット文字で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).


>2.なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?

これは想像になりますが、一般のユーザーにとって半角(1バイトコード)なら何文字、全角(2バイトコード)なら何文字、可変長コードんら・・・というのは理解されにくいことで、あくまでも文字単位が理解されやすくまた日本語だけでなく全ての言語をカバーすることを考えると一律に文字数で制限を設けるのが妥当だという判断だと考えます。

システムでUTF-8を扱う以上可変長が面倒かどうかは関係なく対応しなくてはなりませんからユーザーの利便性優先で作るだけだと思います。

id:asuka645

1番については、引用を含めた具体的な回答をありがとうございます。とても参考になりました。

2番については、おそらくそうなのでしょうね。

2番については決定的な回答はないものと予想しつつも、皆さまからの考えをお伺いいたしたく、よろしくお願いします。

2010/12/24 19:40:28

その他の回答(5件)

id:y-kawaz No.1

y-kawaz回答回数1391ベストアンサー獲得回数2222010/12/24 12:22:43

ポイント40pt

この質問には2つの解釈があると思いますので両方回答しておきます。


■なぜ140文字なのか、という文字数の根拠に関する質問とすると

Twitter、140文字制限の理由とはで分かりやすく説明されていました。要は元々SNSのショートメッセージサービスを想定して作ったらSNSでは160文字制限があって、アカウント名もメッセージに足しても140文字なら20文字位の余裕があるしSNSでエラーが起こることも少ないだろう。という理由で決まったようです。


■英語だと1文字1バイトだけど日本語だと2バイト以上使うのになぜ同じ140文字なのか?という質問とすると

単純にUTF-8で「1文字」という単位でカウントした方が利用者に分かりやすいからだと思います。

英語圏以外でも利用されることを視野に入れてサービスを作る場合文字コードはUTF-8にしておくのが無難だし、言語や人により文字数が変動するほうがユーザに不親切だと考えたからでしょう。

id:asuka645

この質問には2つの解釈があると思いますので両方回答しておきます。

ご指摘ありがとうございます。

両方の意味で質問しています。


なぜ140文字なのか、という文字数の根拠に関する質問とすると

ありがとうございます。

和訳では意味が分からなかったのですが、元の英語を読んだら何となく分かりました。


単純にUTF-8で「1文字」という単位

UTF-8ですと、バイト数に換算すると1文字あたり1~4バイトの可変長になります。

システムにとって可変長になることは面倒なことではないでしょうか。


これ以降に回答される方は

1.なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか?

2.なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?

という2点についてご回答くださいますようお願いします。

2010/12/24 12:43:00
id:syntaxerror No.2

syntaxerror回答回数354ベストアンサー獲得回数562010/12/24 14:03:31ここでベストアンサー

ポイント100pt

>1.なぜTwitterの文字数制限の由来となったSMSは、なぜ160文字にしたのか?



元々SMSメッセージを載せる場所として1120ビット用意されていて、7ビット文字で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).


>2.なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?

これは想像になりますが、一般のユーザーにとって半角(1バイトコード)なら何文字、全角(2バイトコード)なら何文字、可変長コードんら・・・というのは理解されにくいことで、あくまでも文字単位が理解されやすくまた日本語だけでなく全ての言語をカバーすることを考えると一律に文字数で制限を設けるのが妥当だという判断だと考えます。

システムでUTF-8を扱う以上可変長が面倒かどうかは関係なく対応しなくてはなりませんからユーザーの利便性優先で作るだけだと思います。

id:asuka645

1番については、引用を含めた具体的な回答をありがとうございます。とても参考になりました。

2番については、おそらくそうなのでしょうね。

2番については決定的な回答はないものと予想しつつも、皆さまからの考えをお伺いいたしたく、よろしくお願いします。

2010/12/24 19:40:28
id:tama213 No.3

tama213回答回数486ベストアンサー獲得回数302010/12/24 16:42:49

ポイント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バイトで1つの通信と考えて、制御コードとか除いたときに140バイトを文字データとして使いましょうと

決まったんだと思います。

>なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?

単に面倒だからです。

Unicodeが普及した時点で、バイトとか関係なく、1文字は、1文字と扱おうという文化ができたからです。

どっちにしても、英語圏しか考えてなくて、Unicodeのときに英語圏の人がなんとか勉強したのは

1文字は1文字として処理しましょうという考え方だけなんです。

>UTF-8ですと、バイト数に換算すると1文字あたり1~4バイトの可変長になります。

>システムにとって可変長になることは面倒なことではないでしょうか。

英語圏に便利なようになってるだけです。

Unicodeでなんとか英語圏とそれ以外の2バイト文字圏が同じ土俵で意識しないで使えるようになったけど

英語圏の人は、アルファベット(1バイト)しか使わないのに2バイトも必要になると、通信するにも保存するにも

かなり無駄になるんです。また、Unicodeだと、2バイトになりますが、UTF-8の場合は、英語圏の文字は1バイトとなり

Unicode以前のプログラムの考え方で、Unicode以前のプログラムがそのまま動くので便利がよいのです。

最悪、英語圏以外で動かないだけで、それまでの資産が有効に利用できるので便利なんです。

id:asuka645

すみません。日本語の論理でよく分からないところがあります。

たとえば「UTF-8の場合は、英語圏の文字は1バイトとなりUnicode以前のプログラムの考え方で、Unicode以前のプログラムがそのまま動くので便利がよい」と仰いますが、それでしたらEUCでも、(有り得ないことですが)SJISでも同じではありませんか。なぜ、文字列長が計算しにくい可変長のUTF-8を採用し、文字列長の方を一定にしたのでしょう?

2010/12/24 19:45:25
id:khazad-Lefty No.4

khazad-Lefty回答回数180ベストアンサー獲得回数272010/12/25 18:50:13

ポイント5pt

前半部分は回答してないのでポイントは0でも構いません。

なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?

ほとんどのプログラム言語及び(UNICODEで保存する場合の)データベースがそういう数え方をしているため、

文字列を数えるより、バイト数を数えるのはプログラムとしても楽だからです。

UTF-8ですと、バイト数に換算すると1文字あたり1~4バイトの可変長になります。

システムにとって可変長になることは面倒なことではないでしょうか。

そのあたりは、プログラム言語及びデータベースが吸収してくれます。通常は意識する必要はありません。

 

多言語対応を行なうため、プログラム言語の文字列の内部形式は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か」というのはアラビア語などの1バイト言語の多言語対応とか、

ひょっとしたら規格制定時の政治的な動きがあったのかもしれませんが、

とりあえず、一つのエンコーディングで多数の言語が表示できるのは今のところ、

実質UNICODE系のエンコーディングだけのはずです。

#というか、JavaScriptで「バイト数で文字列制限」って結構大変だし…

id:asuka645

ご回答ありがとうございます。

ほとんどのプログラム言語及び(UNICODEで保存する場合の)データベースがそういう数え方をしているため、

文字列を数えるより、バイト数を数えるのはプログラムとしても楽だからです。

前半は仰る通りですが、そうすると、後半は「文字列長を数えることが簡単にできる」ということですよね。

プログラム言語の文字列の内部形式はUNICODE(UTF-8ではなく)で保持している言語も多く

Unicodeの表現形式としてUTF-8, UTF-16, UTF-32といったフォーマットがあるのだと考えていましたが、これは間違っていますか?


とりあえず、一つのエンコーディングで多数の言語が表示できるのは今のところ、

実質UNICODE系のエンコーディングだけのはずです。

それは分かりますが、ではなぜUTF-8を選択したのでしょう?

2010/12/26 01:31:40
id:yossiy7 No.5

yossiy7回答回数741ベストアンサー獲得回数912010/12/25 22:28:08

ポイント5pt

>2.なぜ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が高級言語を使っている証拠でしょうね。

http://www.usefullcode.net/2006/12/windowswchar.html

id:asuka645

ご回答ありがとうございます。


回答4さんが仰っているように、「そのあたりは、プログラム言語及びデータベースが吸収してくれます」ので、あえてマルチバイト文字列宣言しなければならないC++は時代遅れの感じがします。

マルチバイト文字列宣言を不要にするのがUTF-8だと考えておりましたが、間違っていますでしょうか?

2010/12/26 01:35:33
id:yossiy7 No.6

yossiy7回答回数741ベストアンサー獲得回数912010/12/26 13:23:53

ポイント5pt

>マルチバイト文字列宣言を不要にするのがUTF-8だと考えておりましたが、間違っていますでしょうか?

はい、間違ってます。

というのも、言語による指定なし=コンパイラ(orプリプロセッサorインタプリタ)が判断して勝手に決める、です。

ある程度ちゃんとしたところなら、言語による文字列宣言は結局意識して、キッチリ指定します(コンパイラ任せの文字列宣言で問題が発生した際、プログラマは「コンパイラのせいです」という言い訳は出来ないため)。

>それは分かりますが、ではなぜUTF-8を選択したのでしょう?

他の人向けの質問ですが、とりあえずここを読んでみて下さい。UTF-8がUTF-16やUTF-32より使いやすい理由が具体的に記載されています。

http://ja.wikipedia.org/wiki/UTF-8

補足すると、TwitterはRT、@、ふぁぼったーなど独特の概念があります。検索がかなり頻繁に行われるので、検索により適したUTF-8が好都合なのではないでしょうか。

id:asuka645

ありがとうございます。

2010/12/27 15:24:34
  • id:asuka645
    これ以降に回答される方は
     1.Twitterの文字数制限の由来となったSMSは、なぜ160文字になったのか?
     2.なぜ1バイト文字でもマルチバイト文字でも、一律に140文字にしたのか?
    という2点についてご回答くださいますようお願いします。


  • id:tama213
    時代の流れで考えてください。

    1.ASCIIコード
    2.日本語を使うために、SJIS,EUC等ができる
    しかし、このままではSJIS、EUCに対応したプログラムを書かない限り
    国際対応できない
    3.Unicodeができる
    Unicode対応でプログラムを書けば、国際対応は意識しなくてよい
    --ASCIIを前提に書かれたプログラムは、書き換えないとだめ
    --1バイト文字なのに、2バイト必要
    4.ASCIIを前提で書かれたプログラムが最低限の対応で国際化対応でき
     かつバイト数を有効に活用できる
     また、Unicodeで2バイトにすべての文字を収められると考えたが
     それでも足らないので、今後のためにも拡張できる仕組みがほしい
    5.UTF-8の登場
     Unicodeで1バイト目が00なのは、UTF-8では1バイト
     それ以外でのほとんどのUnicode文字は、UTF-8では2バイト
     3バイトとかは拡張用
     こんなイメージ


  • id:asuka645
    >時代の流れで考えてください。
    「時代の流れ」と本件質問がどう関係するのかよく分かりません。

    UTF-8と同時にUTF-32が登場しているのですから、
    文字数のカウントか容易なUTF-32を利用した方が合理的だと思います。
  • id:practicalscheme
    なんだか話がどんどん逸れているような気がする… あくまで「twitterが」なぜそうしたかって話ですよね。
    私もはっきりした回答は持ってないのでコメントで。

    最初のtwitterはRuby on Rails上で実装され、バックエンドはMySQLだったはずです。
    http://blog.twitter.com/2007/06/under-hood-at-twitter.html
    http://www.slideshare.net/Blaine/scaling-twitter
    高級言語がどうの、という話であれば、最初からRubyを使ってたというのが事実ですね。

    当時のRubyとMySQLのエンコーディング対応がどうだったか、私はよく覚えていないので、
    このへんは識者のコメントを待ちたいですが、確かどちらもエンコーディングをutf-8で
    指定しておけば内部表現のバイト数は気にする必要が無い、という状態にはなってたんじゃ
    なかったでしたっけ (Rubyの現在の、文字列毎にエンコーディングを持たせる仕組みは無かった
    けど、実行時にひとつエンコーディングを指定できたような)。なのでコーディング上の
    負担という意味ではutf-8でも特に問題は無かったかと。
  • id:khazad-Lefty
    >文字列を数えるより、バイト数を数えるのはプログラムとしても楽だからです。
    うわ。根本的な間違いを…。
    本来書きたかったのは、「バイト数を数えるより、文字数を数えるほうがはるかに楽」です。


    >Unicodeの表現形式としてUTF-8, UTF-16, UTF-32といったフォーマットがあるのだと考えていましたが、これは間違っていますか?
    確かにそうですね。私の表現がおかしいですね。とりあえずJavaや.Net系の言語の内部形式はUTF-16です
    (UTF-16にも何種類かあったりとかそのあたりの詳しい話はよくわかりませんが)

    >それは分かりますが、ではなぜUTF-8を選択したのでしょう?
    上にも書きましたが、今回問題になっている「文字を数える部分」ではUTF-8は使用していません。
    あくまでも(場合によってはソースコードも含めた)入出力でUTF-8を用いているだけです。


    改めて結論を書くと、Twitterの入力制限文字数が日本語でも英語でも同じ理由は、
    *バイト数を数えるよりも、文字数を数えるほうがプログラマとしてははるかに楽
     →文字制限のチェックプログラムも「文字数」で数えている
    ということじゃないかと。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません