昔、文字コードを調べたときのメモです。文字コードは詳しいサイトがたくさんあって、私が書けることはほとんどないんですが……詳しいサイトが一部消えてしまったようなので、メモを残しておきます。
JIS X 0208:1997を見ると、漢字集合を94個の区、94個の点(区点番号)で定義しています。全部で94x94 = 8336字あります。区点番号をどのバイト値として表現するか?を符号化方式とか符号化表現と言いまして、普及している方式がいくつかあります。
ISO/IEC 2022に出てくる用語G0やGL/GRやエスケープシーケンスを説明なしに使います。私もマスターという訳ではなく、調べて説明するのもしんどいので、他の詳しいサイト様を参照くださいませ。
RFC 1468(リンク)で定義された符号化方式です。JISだとJIS X 0208付属書2に規定があります。MIMEではISO-2022-JPという名前で、JISコードと呼ぶ人もいますが、ISO規格でもJIS規格でもなく、RFCです。変な名前ですね……。
7bitで符号化し、第1、第2バイトともに、0x21〜0x7E(94個)の範囲を使用します。全部で94x94 = 8836字となります。区点番号と同じで素直ですね。文字集合は4つあり、エスケープシーケンスで切り替えます。
Esc Seq Character Set ISOREG ESC ( B ASCII 6 ESC ( J JIS X 0201-1976 ("Roman" set) 14 ESC $ @ JIS X 0208-1978 42 ESC $ B JIS X 0208-1983 87
ISO/IEC 2022的に見ると、G0がASCII、GLにG0がロッキングシフトされている初期状態です。7bitコードなのでGRは使いません。呼び出しInvokeは使いませんのでGLはずっとG0のままです。エスケープシーケンスESC ( はG0への94文字集合(ASCIIなど)の指示Designateで、ESC $ はG0への94n文字集合(漢字など)の指示です。
7bit文字しか理解できないサーバーなどを経由して文章を交換しても、情報が欠落しないように工夫された方式です。その代償と言うのかJIS X 0201片仮名、いわゆる「半角カナ」が使えません。表現する方法がないからです。
EUC-JPが最初に規格化された場所は調べても良くわかりませんでした……。JISだとJIS X 0213付属書3に参考として表記されている符号化方式です。EUC-JIS-2004と呼ばれます。
8bitで符号化し、第1、第2バイトともに0xA1〜0xFE(94個)の範囲を使用します。全部で94x94 = 8836字となり、これも区点番号と同じで素直ですね。半角カナも対応しています。え、要らない?そう?
ISO/IEC 2022的に見ると、文字集合は4つあり、シングルシフトを使ってシフトの直後1文字分だけ切り替えます。エスケープシーケンスは使いません。
ASCIIと漢字以外の文字、例えば半角片仮名を連発すると「シングルシフト+文字」のペアが連発されることになって容量的に効率が悪いですが、EUC-JPには大きな利点があります。
もっと平たく言いましょう。ISO-2022-JPは同じバイト列でも文字の種類(ASCIIか漢字か)がわかりません。最後に出てきたエスケープシーケンス次第で変わるためです。EUC-JPは文字列の途中から読みだしても文字の種類が判定できますので、文字列処理を行う際にはありがたい方式と言えるでしょう。
元々はMicrosoftによる符号化方式です。JISだとJIS X 0208:1997付属書1に規定されています。「シフト符号化表現」が正式名称ですが、大抵Shift JISと呼びます。昔はJIS規格ではありませんでしたが、途中でJIS規格に取り込まれたのだとか。
第1バイトに0x81〜0x9F(31個)、0xE0〜0xEF(16個)が現れたら、第2バイト0x40〜0x7E(63個)、0x80〜0xFC(125個)が続きます。全部で47x188 = 8836字で、総数は同じですがちょっと変則的です。
ISO/IEC 2022的にはそもそも規格に沿っていないため特に何もないですね……。文字集合の切り替えやエスケープシーケンスのような仕組みは一切ありません。
Shift JISはEUC-JPと似たような特徴を持っていて、文字列の途中から読みだしても文字の種類が判定できます。また第1バイトの範囲は、英数字 (ASCII、0x21〜0x7E)や1バイト仮名(半角カナ、0xA1〜0xDF)と重複しないように配置され、シングルシフトのような仕組みなしに漢字と半角片仮名が使えます。
ISO/IEC 2022のような複雑な仕組みを理解する必要がない反面、拡張性が低いという大きな欠点があります。Shift JIS制定後にJIS X 0213が増えたとき、第1バイトの未使用領域0xF0〜0xFCで凌いだ(Shift JIS 2004)ものの、残された領域はもうありません。
TwitterがWeb APIの利用を有料化&メチャクチャ高額な料金設定にしたため、ツイート情報をスクレイピングで取得しようとする人が増加して、Twitterのトラフィックが増えているようです。Twitterはスクレイピングに対する一時的な制限として、
Twitterの制限に関するElon Maskさんのツイート
このような制限を掛けました。文字起こししておくと
To address extreme levels of data scraping & system manipulation, we've applied the following temporary limits:
- Verified accounts are limited to reading 6000 posts/day
- Unverified accounts to 600 posts/day
- New unverified accounts to 300/day
です。つまり、
この制限は結構厳しくて、普通の使い方でも割とすぐに上限に達します。特に青バッジなしの600件/日は厳しそうです……。しかも笑えることにこの制限、他ならぬツイ廃のElon Maskさん自身にも適用されてしまいました。彼はTwitterの会長兼CTOなので権力をフル活用(?)して、制限を速攻で緩和させ数時間後には、
となっていました。行き当たりばったりですね〜。これもTwitterっぽいなーと思いますけど。
私の場合Twitterと自分の生活はあまり関係ないので、今回みたいに制限や緩和でお祭り騒ぎになろうと「ハハハ、何してんだTwitterウケるわ」程度で済みますが、Twitterが商売の生命線(商品の宣伝に使うとか)な人は「何してくれてんだ、ナメてんの??」と怒りたくもなるでしょうね。
私は青バッジユーザーなせいかしばらく制限には引っかからなかったのですが、半日くらい使っていたらついにエラーが出ました。
エラーメッセージを文字起こししておくと、
このリクエストは、コンピュータによる自動的なものと判断されました。アカウントをスパムやその他の迷惑行為から保護するために、現在この操作は実行できません。しばらくしてからやりなおしてください。
いいね!とツイートはできないのになぜかリツイートだけはできるのも謎です。制限の掛け方を間違ってるのでは?という気がしてなりません。
制限を掛けるなとは思いませんが、何も言わずに突然仕様を変えるのはTwitterの良くない癖だと思います。1日前でも良いから予告してからやればあまり混乱しないのに……。今回も突然制限を掛けたので「バグか?サーバーの不具合か!?」と騒ぎになっていました。
< | 2023 | > | ||||
<< | < | 07 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | - | - | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.2.15.
using GD bundled (2.1.0 compatible)(png support.)