我正在使用 Tweepy 庫(kù) (Python) 和 Kafka 從 Twitter 檢索推文。文本以 UTF-8 編碼，如下行所示：self.producer.send('my-topic', data.encode('UTF-8'))其中“數(shù)據(jù)”是一個(gè)字符串。然后，此數(shù)據(jù)以鍵值格式存儲(chǔ)到 Oracle NoSQL 數(shù)據(jù)庫(kù)中。出于這個(gè)原因，推文本身是經(jīng)過(guò)編碼的。我用 Java 這樣做：Value myValue = Value.createValue(msg.value().getBytes("UTF-8"));最后，推文由用 Java 開(kāi)發(fā)的 Formatter 檢索。為了將其存儲(chǔ)在關(guān)系模式中，我必須解析推文，以便將其作為字符串檢索。String data = new String(value.toByteArray(),StandardCharsets.UTF_8);如您所見(jiàn)，我在執(zhí)行的所有步驟中都保持 UTF-8 編碼。但是，當(dāng)我在我的數(shù)據(jù)庫(kù)中看到推文的文本時(shí)，它總是被刪減。例如：RT @brIIohead：今年我不得不吞下的最難的藥丸是學(xué)習(xí)無(wú)論你對(duì)某人有多好，無(wú)論多么好？注意它是如何以“？”結(jié)尾的 符號(hào)，而且已經(jīng)被清楚地切斷了。好吧，每條長(zhǎng)推文都會(huì)發(fā)生這種情況。我的意思是，如果文本長(zhǎng)度為 30 個(gè)字符，那么它顯示正常，但是任何超過(guò) 100 個(gè)字符的內(nèi)容都會(huì)被剪切掉。起初我以為它可能是我的表定義，但字段“文本”被聲明為VARCHAR2(400 CHAR)推文在社交網(wǎng)絡(luò)中可以包含的最大字符數(shù)。關(guān)于如何發(fā)現(xiàn)剪切文本和放置“？”的任何想法 符號(hào)在最后？“數(shù)據(jù)”的樣子：我還必須提到，這整個(gè)塊都是經(jīng)過(guò)編碼的。然后解碼，最后解析到數(shù)據(jù)庫(kù)中。所有字段都被正確解碼和解析，除了被剪切的“文本”
1 回答
慕仙森
TA貢獻(xiàn)1827條經(jīng)驗(yàn) 獲得超8個(gè)贊
根據(jù)官方文檔，一條推文不超過(guò)“140”個(gè)字符（這是一個(gè)寬泛的定義）；但最近他們將其更改為280。
同一份文件說(shuō)：
Twitter 使用文本的規(guī)范化形式 C (NFC) 版本計(jì)算推文的長(zhǎng)度。
所以他們首先規(guī)范化文本（我會(huì)讓你弄清楚這是如何完成的是java）。后來(lái)他們說(shuō)：
Twitter 還計(jì)算文本中代碼點(diǎn)的數(shù)量，而不是 UTF-8 字節(jié)。
因此：
String test = "RT @briIIohead: the hardest pill i had to swallow this year was learning that no matter how good you could be to somebody, no matter how mu";
System.out.println(test.codePoints().count()); // 139
似乎最初的推文是 280 個(gè)“字符”，而您使用的庫(kù)并不知道這一點(diǎn)，因此它只使用了之前的 140 個(gè)。因?yàn)樗隽艘恍┓謮K，所以分塊似乎也是錯(cuò)誤的，它在最后刪除了一些“部分”字節(jié)。當(dāng)您嘗試打印這些時(shí) - java 不知道那些（最后）字節(jié)的實(shí)際含義（因?yàn)橐恍╁e(cuò)誤的分塊）并且只是說(shuō)?（這是當(dāng)它根本不理解某些東西時(shí)顯示內(nèi)容的默認(rèn)策略）。
添加回答
舉報(bào)
0/150
提交
取消