обеспечить стандартизацию кодирования для ввода пользователем и ввода-чтения файлов

Question

Я разрабатываю систему для определения человеческого языка данного текста. Он работает, сохраняя словарь для каждого интересующего языка и затем оценивая, соответствует ли вход пользователя любым словам, хранящимся в словаре. Победителем является язык, словарь которого имеет наибольшее количество хитов.

Я думаю, что для того, чтобы эти две записи, слова пользователя и слово, которое приходит из файла «списокслово», чтобы соответствовать кодировке должны быть такими же, это то, что я пытаюсь исправить.

Я взял список слов от this site.

Когда я использую те из «ASCII» в моем коде все работает, но когда я использую те из «Unicode» ничего не работает.

Это смущает меня, потому что я не хочу, чтобы программа получала некоторый ввод, который был закодирован не таким образом (таким образом, что конфликтует с моими структурами списка слов), а затем сбой.

По этой причине я хочу стандартизировать все входные данные с определенной кодировкой. Я думал, что «Unicode« было бы лучше, потому что, поскольку это система для определения естественного языка текста, я мог бы получить некоторые греческие или русские или китайские символы, и из моего понимания »ASCII« очень не -standardized.

В настоящее время я использую консоль Eclipse для ввода ввода.

Это, как я прочитал в файлах:

//BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(dir.toString()), "UTF-8")); 

BufferedReader br = new BufferedReader(new FileReader(dir.toString())); 
String line = null; 

BloomFilter<String> bloomFilter; 
if (word_holding_directory_path.toLowerCase().contains("/de/")) 
{ 
    bloomFilter = de_bloomFilter; 
} 

Это, как я прочитал на входе пользователя:

//Scanner in = new Scanner(System.in , "UTF-8"); 
Scanner in = new Scanner(System.in); 

System.out.println("Please enter a sentence: "); 

String[] input_text = in.nextLine().split("\\s"); 

Как вы можете видеть, я пытался заставить кодировку быть UTF- 8, (это то же самое, что и Unicode, не так ли?), Но поскольку он не работал, я прокомментировал это.

Это, как я сравниваю слова:

for (String word : input_text) 
{ 
    String normalized = word.trim().toLowerCase(); 
    if (words.contains(normalized)) 
    { 
     ++count; 
    } 
} 

Полная программа here on github это довольно короткий и довольно явно прокомментировал.

Answer 1

Слова, о которых вы цитируете, похоже, находятся в UTF-16LE, а не UTF-8. Вы должны исправить параметр кодирования в экземпляре InputStreamReader соответственно.

Unicode и UTF-8 наиболее категорично не То же самое; и действительно, говоря, что текст является «Unicode», не упоминая, что кодировка недостаточно точна.

(Вы должны быть в состоянии догадаться, что ZIP-файл, который несколько лет может использовать UTF-16LE, который до сих пор по умолчанию в Windows, для многих вещей. Новые ресурсы, как правило, быть UTF-8, даже в Windows.)

Чтение одной строки из файла UTF-16, а другое, содержащее тот же текст с консоли с правильной консольной кодировкой, приведет к получению двух строк Java, которые равны. С другой стороны, если кодировка на одном из входных потоков неверна, то, что вы заканчиваете в строке, будет по существу случайным фиктивным. (В сценарии «Повреждение поездов» у вас разные ошибки кодирования на обоих входах, и просто случайно получается две равные строки, когда на самом деле две строки должны содержать другой текст.)

(Не уверен, что UTF-8 в общем, правильно для консоли, или, возможно, именно в вашей среде - я не программист Java)

---

Вкратце, абстрактные строки Unicode

U+0066 U+00F6 U+0072 

(который представляет. S wedish слово för) будет представлена ​​как

0x66 0xC3 0xB7 0x72 

в UTF-8 (обратите внимание, как простые символы ASCII карту для представления идентичности), и

0x66 0x00 0xF6 0x00 0x72 0x00 

в UTF-16LE (где каждая пара байтов - это одна 16-разрядная последовательность с установленным значением MSB, тогда как LSB вмещает всю значительную часть представления).

В простой ASCII эта строка не может быть представлена; пути назад во время, она была бы написана, как

0x66 0x7C 0x72 

где 0x7c правильно характер | трубы, которая была локально сопоставляется с глифом ö в аппаратных средств. (Соответственно, если вы использовали ресурсы на английском языке, которые должны были содержать правильный характер трубы, что тоже были бы визуализируются как ö;. Поэтому газопровод линия Unix grep cat food | xxd будет отображаться как grep cat food ö xxd)

Несколько позже во время, ISO-8859-1 стал популярным, и эта строка будет представлена ​​как

0x66 0xFC 0x72 

Это, безусловно, просто и эффективно. Почему это не так, как это делает Unicode? Потому что в 8-битной кодировке всего 256 символов, а Unicode намного больше. Вы не можете представлять 上海市 или машина.