Завершающие нулевые (\x00) символы при записи текста в Accumulo

Я пытаюсь записать имя файла в Accumulo. Я использую аккумуло-ядро-1.43.

По какой-то причине некоторые файлы записываются в Accumulo с завершающими символами \x00 в конце имени. Загрузка осуществляется через сервлет Java (с использованием подключаемого модуля загрузки файлов jquery). В сервлете я проверяю имя файла с помощью System.out.println, и оно выглядит нормально, и я даже пытался отменить экранирование строки с помощью

org.apache.commons.lang.StringEscapeUtils.unescapeJava(...);

Фактическая запись в accumulo выглядит так:

Mutation mut = new Mutation(new Text(checkSum)); 
Value val = new Value(new Text(filename).getBytes());
long timestamp = System.currentTimeMillis();
mut.put(new Text(colFam), new Text(EMPTY_BYTES), timestamp, val);

но ничего необычного там не обнаружилось (возможно, \x00 не экранировано)? Но тогда, если я просканирую свою таблицу in accumulo, в имени файла будет один или несколько \x00.

Проблема, по-видимому, заключается в том, что я возвращаю эту строку в XML, когда я получаю список файлов (где он отображается) и передаю его обратно в браузер, XSL, который должен отображать информацию в XML, больше не работает, когда есть эти дополнительные символы (тоже не уверен, почему это так).

В хроме для ответа на эти вызовы я вижу, что после имени файла есть три красные точки, и когда я навожу курсор на него, появляется \u0 (что, я думаю, является другим представлением 0/null?).

Во всяком случае, я просто пытаюсь понять, почему это происходит, или, по крайней мере, как я могу отфильтровать символы \x00 перед возвратом файла в Java. Любые идеи?


java accumulo
person jfoo    schedule 16.01.2014    source источник
comment
Это может помочь. В принятом ответе есть регулярное выражение, которое удаляет нулевые символы. stackoverflow.com/questions/2362302 /   -  person austin    schedule 17.01.2014
comment
Спасибо! Я посмотрю на это и посмотрю, работает ли это.   -  person jfoo    schedule 17.01.2014
comment
При чем тут побег? Проблема в конце нуля. Найдите, откуда это исходит, и исправьте это. Скорее всего, вы где-то игнорируете длину, возвращаемую read(), и предполагаете, что она заполняет буфер.   -  person user207421    schedule 17.01.2014
comment
Хорошая точка зрения. Но все использует вызовы методов Java из библиотеки accumulo, потому что я ничего не написал, где мне нужно вызывать чтение или искать в буферах.   -  person jfoo    schedule 17.01.2014

Ответы (1)


arrow_upward
2
arrow_downward

Скорее всего, вы неправильно используете класс Hadoop Text — это не ошибка Accumulo. В частности, вы делаете ошибку в приведенном выше примере:

Value val = new Value(new Text(filename).getBytes());

Вы должны придерживаться длины, предоставленной классом Text. См. текст javadoc для получения дополнительной информации. Если вы используете Hadoop-2.2.0, вы можете использовать предоставленный метод copyBytes для Text. Если вы используете более старую версию Hadoop, где этот метод еще не существует, вы можете использовать что-то вроде класса ByteBuffer или метода System.arraycopy, чтобы получить копию byte[] с соответствующими ограничениями.

person elserj    schedule 18.01.2014
comment
спасибо, это была проблема! В итоге я использовал System.arraycopy, и он работает как шарм! - person jfoo; 22.01.2014
comment
HTH - Текст может быть действительно хорошим способом избежать проблем с сборщиком мусора с повторяющимся созданием и удалением объектов, но API позволяет вам довольно быстро выстрелить себе в ногу;) - person elserj; 22.01.2014
comment
Круто, отличный момент! Кстати, забыл упомянуть, конечно, мы использовали hadoop 0.20... поэтому мне пришлось использовать arraycopy. - person jfoo; 23.01.2014